KYC verification services: third-party vendors or in-house builds?

It doesn't.

That seamless little ritual — the one we all tolerate as the price of opening a checking account from a couch — covers a sliver of what U.S. banks are actually obligated to do under federal anti-money-laundering rules. And the question of who performs that broader work, an outsourced vendor whose dashboard you've never seen, or an in-house team whose code you've never reviewed, is where the real architectural choice lives. This is the build-versus-buy decision for KYC verification services, and it doesn't play out the way vendor marketing decks suggest.

The Regulatory Floor: What KYC Actually Includes

Let's strip the term back to what regulators mean by it. For a U.S. bank, the Customer Identification Program — the formal CIP — is the baseline. It requires collecting at least four pieces of information before opening any account: name, date of birth, address, and identification number (typically a TIN for U.S. persons, or for non-U.S. persons, a passport number with country, an alien ID card, or similar). Collecting those four fields isn't the whole job. The bank also has to verify them, document how it verified them, retain that information for five years after the account closes, and keep the records of verification methods and any discrepancies for five years after the record is made.

That's just CIP. Customer Due Diligence adds another layer. FinCEN defines four CDD requirements: verify the customer, identify and verify beneficial owners of any legal-entity customer, understand the nature and purpose of the relationship to build a risk profile, and conduct ongoing monitoring for suspicious activity. For businesses, "beneficial owner" means anyone holding 25% or more of the equity plus one person who controls the entity — FinCEN's CDD Rule FAQs were updated as recently as May 6, 2026, so the operational details keep moving.

If you stop reading at this paragraph, the takeaway is straightforward: KYC is not a single API call. It's a program. The question is who runs it.

KYC isn't a feature you turn on. It's a compliance program with retention clocks, beneficial-owner math, and a privacy assessment you can't skip.

The Hidden Cost of Outsourcing

Vendor pitches tend to focus on speed. "Verify in seconds." "Global coverage." "Drop-in integration." What tends to disappear in the demo is the third-party risk-management lifecycle the federal banking agencies laid out in their June 6, 2023 interagency guidance — applicable to every bank with any third-party relationship, no matter the size.

That lifecycle has five stages: planning, due diligence and selection, contract negotiation, ongoing monitoring, and termination. Each one is bank work, not vendor work. Planning means defining what activity is being outsourced and why. Due diligence means assessing the vendor's security, privacy, auditability, operational controls, and financial health before signing. Contract negotiation means embedding the right exit clauses, audit rights, data-handling obligations, and service-level expectations. Ongoing monitoring means the bank keeps watching, even after the contract is live. And termination means having a plan to leave without losing data continuity or compliance posture.

When you buy a KYC vendor, you don't buy less work. You buy different work. The friction moves from engineering an identity pipeline to managing a vendor relationship, and the regulators hold the bank to the same outcome either way. Outsourcing doesn't transfer the obligation; it transfers the activity.

The last row matters more than it looks. Even when an outsourced platform surfaces a transaction anomaly, the bank files the suspicious activity report — or doesn't. That decision can't be contracted out, and it shouldn't be.

Engineering Compliance From the Inside

So what does an in-house build actually entail? It's worth being honest about this, because the build side of the trade-off rarely gets the same glossy treatment as the buy side.

An in-house identity-proofing system has to meet, at minimum, the equivalent security, privacy, auditability, and operational-control requirements a vendor would. It needs an authenticated protected channel for every identity-proofing transaction — mandatory under NIST SP 800-63A-4, published in July 2025, regardless of whether a third party touches the data. Personal information has to be encrypted at rest and protected for confidentiality and integrity in transit. The bank has to document a privacy risk assessment covering identity attributes, biometrics, images, video, scans or copies of evidence, retention schedules, AI/ML-related re-identification risk, and personal information processed by any third-party service used along the way.

Then there's the evidence model. NIST defines identity assurance levels IAL1, IAL2, and IAL3, and the controls scale up accordingly. For IAL2, evidence collection requires one FAIR and one STRONG item, two STRONG items, or one SUPERIOR item — combinations, not a single source. Verification at IAL2 can run through non-biometric, biometric, or digital-evidence pathways; biometric verification is not always required, despite what the marketing of every selfie-matching vendor might suggest. The security baseline for any identity-proofing service is consistent with the NIST SP 800-53 moderate baseline, regardless of which IAL the bank ultimately targets.

Add to that the controls you don't see: automated attack protections, retention policies mapped to the CIP recordkeeping periods, discrepancy-resolution workflows, audit logs that survive a regulator's review, and the engineering capacity to keep all of it current when NIST or FinCEN issues an update. An in-house build trades vendor-management friction for engineering friction, and the latter is invisible until your auditors ask for the documentation trail.

The Sanctions Side and the Recordkeeping Clock

One more layer trips up build-versus-buy conversations: OFAC screening. The Office of Foreign Assets Control runs the Sanctions List Service as its primary delivery channel for sanctions lists and data, with retrieval through a user interface or an API. That sounds simple, but it turns sanctions screening into a continuous integration problem, not a one-time onboarding task. List updates have to be ingested as they drop, but the rescreening cadence itself is governed by the bank's risk-based AML program — high-risk customers and counterparties checked more aggressively, lower-risk ones on intervals that reflect their exposure and the materiality of the list change. Every match (true or false) still has to be logged with the reasoning that resolved it, because the regulator will ask how the bank got from alert to disposition.

And OFAC screening is distinct from CIP. The FFIEC treats sanctions-list checking as a separate requirement; it isn't folded into the Customer Identification Program even though both happen at onboarding. Vendors will sometimes describe their offering as "complete KYC and sanctions coverage." Read the contract. The bank's screening decision — and the records proving how it was made — remain bank work.

Then come the retention clocks. CIP requires identifying information for five years after account closure. CIP verification records, non-documentary verification methods and results, and discrepancy resolutions: five years after the record is made. The CDD risk profile and ongoing-monitoring artifacts sit on top of that. None of this is optional, and storage isn't free — especially when biometric images, document scans, and video sessions are part of the evidence set under NIST SP 800-63A-4.

Retention isn't a footnote in a vendor contract. It's a five-year clock anchored at account closure for identifying information and at record creation for verification evidence — and it runs whether you built the system or bought it.

Choosing Between Two Kinds of Friction

The honest answer to "build or buy" is that you're picking between two distinct kinds of friction, and the right answer depends on what your institution is actually built to absorb.

Outsourcing concentrates the work into vendor due diligence, contract negotiation, and ongoing monitoring — three activities that scale with the number of relationships, not the number of users. The bank's engineering team gets to focus on product, and the compliance team gets a dashboard. But the bank inherits a third-party risk-management program that, per the 2023 interagency guidance, has to be commensurate with the bank's risk profile, the complexity of the outsourced activity, and its criticality. Skip a step, and your next exam will find it.

Building in-house concentrates the work into engineering and documentation — controls aligned to NIST's moderate baseline, a privacy risk assessment that covers re-identification risk in AI/ML models, encrypted protected channels, automated attack protections, and a records system that holds up under regulatory review. You own every clock and every retention decision. You also own every line of code, which is both a feature and a maintenance liability.

Neither path is cheap, and neither eliminates the underlying obligation. What the federal banking agencies have made clear, across FinCEN's CDD Rule FAQs, the FFIEC's BSA/AML Examination Manual, the 2023 third-party guidance, and NIST's 2025 identity-proofing standards, is that the bank is the accountable party. The vendor is a tool. The in-house system is a tool. The compliance program is the institution.

Where That Leaves Us

If there's a behavioral insight buried in all of this, it's that we tend to evaluate KYC the way we evaluate other consumer fintech: by the speed of the green checkmark on the screen. We feel the friction of the selfie. We don't feel the five-year retention clock, the beneficial-owner math, or the privacy risk assessment running underneath it.

The build-versus-buy decision should be made by the people who feel those invisible frictions — the ones who answer the auditor, who manage the vendor, who update the risk profile when FinCEN publishes a FAQ revision. They know whether their institution's bandwidth lives in engineering or in relationship management. The wrong choice isn't buying or building; it's choosing without knowing which kind of work your team can actually absorb at scale.

Because in the end, the regulator won't care which side of the build-versus-buy line you picked. They'll care whether you can produce the records.