On June 27, 2025, the U.S. Treasury’s Financial Crimes Enforcement Network (FinCEN) released a compliance exemption that’s already reshaping how financial institutions verify customers — not just at onboarding, but across the full customer lifecycle.
For the first time, banks regulated by the OCC, FDIC, or NCUA can rely on third-party providers to retrieve and verify a customer’s full Tax Identification Number (TIN), rather than collecting it directly. Customers may only need to enter the last four digits, with the bank responsible for completing verification behind the scenes. It’s one of the most significant updates to the Customer Identification Program (CIP) rule since its introduction — offering a path to smarter onboarding, lower drop-off, and more dynamic verification practices going forward.
Understanding the shift
Traditionally, CIP compliance required banks to collect and verify four data points before onboarding: full name, date of birth, address, and full TIN (e.g., Social Security Number or EIN). A narrow exception had allowed credit card issuers to verify TINs through consumer reporting agencies, but only for that specific account type.
The June 2025 order extends this model across all account types, including deposit accounts, digital accounts, and small business banking relationships. Under the new framework, institutions may collect only the last four digits of a TIN, use a secure third-party database to retrieve and verify the full number, and proceed with account opening — so long as all other CIP requirements are met. The move is designed to reduce friction, support privacy expectations, and reflect how consumers and businesses increasingly engage with digital financial products.
What it means for banks
For traditional banks and credit unions, the exemption offers an opportunity to modernize not just onboarding flows but also ongoing identity verification and customer servicing. To adopt the new approach, banks will need to update internal CIP documentation and risk-based procedures, vet and integrate with approved TIN verification vendors, and demonstrate to examiners how “reasonable belief” in customer identity is achieved — without direct TIN collection.
The impact doesn’t stop at onboarding. Banks can also explore using this approach during re-verification processes, account updates, or when triggering downstream compliance checks during events like ownership changes.
It’s important to note that this exemption does not apply to Ultimate Beneficial Owners (UBOs) tied to business accounts. Full TINs must still be collected directly from individuals with significant ownership stakes.
There’s also an open question: can banks use their own historical customer databases instead of a third-party lookup? The order specifies reliance on a “third-party,” but it's unclear whether a financial institution’s previously verified records would qualify. Legal teams and examiners will likely seek further clarification on this point in future guidance.
What it means for fintechs and BaaS platforms
For fintechs that partner with banks to power onboarding and ongoing identity management, this exemption has immediate downstream implications. If a bank adopts a partial TIN plus third-party verification workflow, the fintech can prompt only for the last four digits of a TIN, build backend logic to check for a match via the partner bank’s systems, and streamline user interactions across the account lifecycle.
This doesn't just benefit initial onboarding. The same approach could power periodic reverification, faster onboarding of returning customers, or silent fraud checks when something about a user or business changes.
But fintechs can’t implement this unilaterally. They’ll need to confirm whether their bank partner is using the new method, coordinate fallback logic, revisit data-sharing and compliance contracts, and ensure they’re not violating customer rights or vendor licensing agreements — especially if TINs submitted previously are stored or reused.
These new capabilities are also prompting teams to rethink identity verification itself — moving away from static, one-size-fits-all inputs toward smarter, adaptive workflows.
A new model for identity verification
The exemption opens the door for adaptive, intelligent verification — where identity checks evolve with context. A sample onboarding or re-verification flow could look like this:
- User inputs business name and address
- Backend lookup attempts to match full TIN using a third-party database
- If a match is found: continue the flow without prompting for full TIN
- If no match is found: prompt the user to enter the full TIN manually
- Optional: escalate to enhanced due diligence such as ID scans or document uploads
This approach is already gaining traction among product and risk teams aiming to reduce friction without compromising trust. It shifts the burden away from static input fields and toward identity workflows that adapt in real time — based on what’s already known, verified, or high-confidence.
Balancing flexibility with compliance
Even as onboarding becomes more flexible, the core expectation remains: financial institutions must know who they’re doing business with. This exemption doesn’t relax anti-money laundering obligations, and fallback mechanisms must still be in place when data gaps exist.
Teams will need to design tiered workflows based on risk, prepare for audits with documented verification logic, and navigate data usage policies, especially working with sole proprietors or using SSN-based lookups. Solving for these harder-to-verify segments will require thoughtful layering of authoritative sources, contextual signals, and integration controls.
There’s also the question of how verification data is sourced and reused. If identity information is being retrieved from third-party databases, what are the boundaries for prefill, fallback logic, or confidence scoring? These decisions sit at the intersection of compliance, legal, and product — and must be handled with transparency and precision.
What's ahead
This shift is likely to spark a wave of product experimentation. We may see rapid adoption across onboarding and servicing flows, regulator feedback on internal versus third-party lookup validity, and greater use of contextual signals — like business registration events or behavioral patterns — to trigger or bypass verification.
Some teams are already exploring how to pair TIN data with other signals to silently verify legitimate businesses —reducing friction without sacrificing accuracy. Done right, this could unlock faster paths to “yes,” while maintaining the rigorous controls financial institutions need to operate with confidence.
Thinking about how this exemption applies to your onboarding flow?
Let’s talk through use cases, fallback logic, and integration options. Contact our team.
