Trump's Bank Citizenship Rule: What the New KYC Order Means for US Financial Institutions

On April 15, 2026, US Treasury Secretary Scott Bessent publicly confirmed what had been circulating in Washington since February: the Trump administration is drafting an executive order that will require US banks to collect citizenship information from their customers. Speaking on CNBC, Bessent said the order is "in process." He framed the logic plainly: "I don't think it's unreasonable, because: why don't we have information on who's in our banking system?"

For US financial institutions, this is the most significant change to customer identification rules since the USA PATRIOT Act codified Customer Identification Programs (CIP) in 2003. For identity verification vendors, it is a redefinition of what "KYC" means in the United States. For the tens of millions of existing account holders whose files do not currently capture citizenship status, it is the start of a very large re-verification project.

This post walks through what has been confirmed, what is still ambiguous, the documents that will be in scope, the operational problem banks now have to solve, and the architecture that makes it manageable.

What Has Been Confirmed

The draft executive order has not yet been signed. A White House spokesperson has described earlier reporting as "baseless speculation" about a policy that has not been formally announced. But Bessent's on-record confirmation on April 15 and follow-up comments on April 16 move the proposal from rumor to stated administration intent.

What we know:

• Scope: Banks and, by extension, other regulated financial institutions will be required to collect and verify citizenship information as part of customer onboarding.
• Documents: The documents being discussed as acceptable proof include the US passport, Certificate of Naturalization (USCIS forms N-550/N-570), and US birth certificate. REAL ID credentials are explicitly excluded — a REAL ID driver's license proves lawful presence, not citizenship.
• Retroactive application: Early reporting indicates the rule could apply to existing account holders, not just new ones. That would force banks to re-verify hundreds of millions of active accounts.
• Stated motivation: The administration has framed the rule as part of broader immigration enforcement and data integrity goals, building on related moves around voter verification and the SAVE database.
• Industry reaction: Banking trade groups have pushed back privately on feasibility. One industry advisor publicly asked: "What current proceeds of crime, money laundering, or tax evasion problem does this address that isn't already dealt with?" Some Treasury staff have reportedly floated a lighter version where banks certify rather than re-document every customer.

What is still ambiguous: whether the rule applies to non-citizens with lawful status (green card holders, visa holders, refugees, asylees) or only flags undocumented persons; whether it extends to brokerages, credit unions, fintechs, and crypto exchanges beyond depository banks; the exact timeline; and how the new data will be stored, retained, and accessed by other agencies.

Why This Is Harder Than It Sounds

On the surface, "collect citizenship data" reads like a small delta on top of existing KYC. The existing CIP rule under the Bank Secrecy Act already requires banks to collect a customer's name, date of birth, address, and taxpayer identification number (SSN or ITIN), plus verify identity via government-issued photo ID — typically a driver's license.

But a driver's license does not establish citizenship. Neither does an SSN. And an ITIN explicitly does not. The existing stack captures identity; the new rule demands nationality. Those are adjacent but distinct data classes, and the documents, extraction logic, and authenticity checks are different.

Three specific operational problems emerge.

1. Document Diversity

US passports are straightforward — machine-readable zone (MRZ), NFC chip on newer editions, well-understood authentication. Birth certificates are not. There is no standardized US birth certificate. Every state, territory, and many counties issue their own formats. Security features vary wildly. Document fraud on birth certificates is a mature criminal industry — fake birth certificate templates are sold online for tens of dollars.

Certificates of Naturalization (N-550/N-570) are a single federal format, which simplifies extraction, but they are issued in physical paper form and most holders do not keep a digital copy. That creates a customer-experience problem: "bring me your naturalization certificate" is not a request that a customer can satisfy from a mobile phone in thirty seconds.

2. Retroactive Re-verification at Scale

If the rule applies retroactively, a mid-sized regional bank with five million accounts is looking at five million re-verification flows, each requiring document collection, authenticity checks, and file updates. That cannot be handled by a branch-based process in any reasonable timeframe. It has to be done remotely, via a verification flow the customer completes on a phone, with automated document parsing and human review for edge cases.

Banks that built their KYC stack in-house, or on top of a legacy vendor tuned for driver's license checks, do not have the document coverage or the operational throughput to absorb this. A vendor that supports only passports and driver's licenses cannot process a state-issued birth certificate from Alabama or a Certificate of Naturalization from 1998.

3. Adjacent Compliance Surface

Citizenship data is sensitive under several overlapping frameworks. The Equal Credit Opportunity Act (ECOA) prohibits discrimination based on national origin in credit decisions. The Fair Housing Act has similar constraints for mortgages. State-level privacy laws (California CCPA/CPRA, Colorado, Virginia, Utah, Connecticut) treat national origin and immigration status as sensitive personal information with heightened consent and deletion obligations. Any bank that collects citizenship data without a lawful basis, or stores it without the right controls, creates a second compliance problem while trying to solve the first.

The winning architecture collects exactly what the rule requires, separates it from adjacent decisioning systems, and maintains an auditable trail of lawful basis.

The Documents That Will Actually Show Up

If the draft executive order tracks current proposals, here is the realistic document mix banks will see:

Document	Coverage	Verification Notes
US Passport	Most reliable proof — MRZ, visual zone, and on newer editions an NFC chip with ICAO-compliant biometric data	Strong authenticity signals, easy to parse, ~48% of US adults hold one
US Passport Card	Wallet-sized, same issuance process as passport book	Strong authenticity, lower adoption
Certificate of Naturalization (N-550 / N-570)	Single federal format, issued to naturalized citizens	No digital version — customer must photograph paper document
Certificate of Citizenship (N-560 / N-561)	Issued to individuals who acquired citizenship through parents	Similar challenge — paper document only
US Birth Certificate	State or territory issued, highly variable formats	No standardization, highest fraud risk, lowest OCR confidence
Consular Report of Birth Abroad (CRBA / FS-240)	Issued to US citizens born outside the US	Low volume, well-formatted federal document

Any verification provider serving US banks under this rule needs document coverage, field extraction, and authenticity checks across all six categories — not just passports.

What a Compliant Verification Flow Looks Like

The minimum flow a bank has to support, for both new and existing customers, looks like this:

1. Capture. Customer uploads or photographs the eligible citizenship document on a mobile device. The flow accepts multiple document types — a customer with no passport should be able to use a naturalization certificate or birth certificate.
2. Extract. OCR and structured parsing pull the relevant fields: document type, document number, name, date of birth, place of birth, country of citizenship, issue date, issuing authority. Field extraction has to handle the variability of 50+ state birth certificate formats.
3. Authenticate. Authenticity checks against the document: security feature presence, font consistency, template matching, tampering detection, and — for passports — MRZ checksum validation and NFC chip verification when available.
4. Match. Biometric match between the document photo and a live selfie with liveness detection, to confirm the document belongs to the person submitting it.
5. Screen. Sanctions, PEP, and adverse media screening on the verified identity. This is a pre-existing obligation that still applies.
6. Record. Tamper-evident audit trail with the document images, extracted fields, authenticity scores, match scores, screening results, decision, and timestamps — retained for the retention window required by the Bank Secrecy Act and any subsequent guidance on citizenship data.
7. Route. Anything that fails automated checks routes to human review with the full context attached, not a restart of the flow.

This has to work on the customer's phone, in under two minutes, with a completion rate above 90% for legitimate customers. Anything less breaks the existing digital account opening funnel.

Where Didit Fits

Didit is built for exactly this shape. The core numbers:

• 14,000+ document types across 220+ countries, including every US state birth certificate format, naturalization and citizenship certificates, passports, passport cards, and consular reports of birth abroad.
• 48+ languages for flows serving naturalized citizens and customers with non-English source documents.
• Document authenticity checks combining OCR, template matching, security feature detection, tampering analysis, and MRZ/NFC validation where available.
• Biometric liveness with passive and active modes, tuned for mobile completion rates.
• Sanctions and watchlist screening across 1,000+ watchlists, with ongoing monitoring and re-verification triggers.
• Pay-per-verification pricing at $0.30 per check, with no minimums and no contracts — banks can deploy the flow against a test population first, measure completion rates, then scale.

The point is not that banks should rip out their existing KYC vendor. The point is that the new rule demands document coverage and operational throughput that most existing stacks were not designed for. Bolting a citizenship verification layer onto the existing flow — for both new accounts and retroactive re-verification — is the architecturally cleanest move.

What to Do Now

If you run compliance or operations at a US bank, credit union, fintech, broker-dealer, or crypto exchange, four things are worth doing in the next 30 days regardless of the final executive order text.

First, map your existing customer base by likely citizenship document availability. How many existing customers have a passport on file already? How many have a driver's license only? That ratio tells you how big the retroactive re-verification problem will be.

Second, audit your current KYC vendor's document coverage against the six document types above. A vendor that cannot cleanly process all 50 US state birth certificate formats, plus N-550 and N-560, will not get you through this rule at scale.

Third, model the cost of running a retroactive re-verification campaign. If your verification unit cost is $2-5 per check at current vendor pricing and you have several million customers to re-verify, the line item is material. Pricing that sits at $0.30 per verification changes the economics.

Fourth, prepare the customer communications. The regulatory rationale is not the customer's problem. A well-crafted flow explains what the bank is doing, why it is required, and how long it will take. Banks that treat this as a silent compliance exercise will lose customers. Banks that treat it as a trust-building moment — "we are asking for this because the law now requires it, here is what we do with it, here is how to complete it in two minutes" — will retain them.

The Bigger Picture

The draft order is part of a wider move to tie financial infrastructure to immigration and citizenship data. Whether or not this specific executive order is signed, and whether it survives the legal challenges that are certain to follow, the direction of travel is clear: identity verification in US financial services is expanding from "who are you" to "who are you, and can you prove your status." The same pattern is showing up in voter databases, employer verification (E-Verify expansion), and the SAVE database for federal benefits.

The compliance stack that US banks built for the 2003 USA PATRIOT Act was tuned for one job: verify identity for AML purposes. The stack required for 2026 is broader — identity, nationality, sanctions, PEP, adverse media, ongoing monitoring, and retroactive re-verification — delivered in a flow that works on a phone in two minutes. The banks that get that stack in place early will absorb the rule change. The ones that wait will be re-verifying their customer base under regulatory pressure, on a compressed timeline, with a vendor that cannot handle the document mix.

Didit's infrastructure is already in production for regulated financial institutions across 220+ countries. When the order lands, the verification layer should not be the hard part.

---

Didit builds identity verification, AML screening, and compliance infrastructure for banks, fintechs, and crypto platforms. 14,000+ document types, 220+ countries, 48+ languages, $0.30 per verification, no minimums, no contracts. Start for free or talk to the team.