Published on
August 3, 2026
AML/KYC Compliance for Fintech and Banking Partners
Map control ownership, vet vendors, lock data-sharing, and set alert SLAs so sponsor banks and fintechs meet AML/KYC obligations.
If you’re a fintech working with a sponsor bank, the bank still owns the AML program. That’s the core point. You may run onboarding, screening, and first-pass alerts, but the bank answers to regulators when controls fail.
Here’s the short version:
- AML, KYC, CIP, and CDD are not the same thing
- One control needs one owner
- The split of work must be set before launch
- Vendors need review, testing, and audit access
- Shared data must use the same IDs, fields, and retention rules
- Alerts, SARs, and CTRs need fixed timelines
- Contracts and governance must match the day-to-day workflow
I’d sum it up like this: the fintech may do much of the work, but the bank keeps legal accountability. That’s why weak ownership turns into launch delays, duplicate reviews, missed escalations, and exam trouble.
A few numbers make the point clear:
- Sponsor-bank AML gaps led to more than $150 million in BSA/AML penalties across 2023–2024
- SAR filing is usually due within 30 calendar days
- CTR filing can apply when cash activity goes over $10,000 in one business day
- BSA records often need to be kept for at least 5 years
What matters most is simple: write a control map, approve onboarding rules, test vendors, lock down data sharing, set alert SLAs, and put all of it into the contract.
This article shows how I’d think about that split so neither side assumes the other is handling a control that no one actually owns.
AML Training Session | AML Framework | KYC & CDD Training | KYC vs CDD Explained | AML/KYC Tutorial
sbb-itb-e766981
Set the Control Model Before You Launch
AML/KYC Control Ownership: Bank vs. Fintech vs. Vendor Responsibilities
Set the RACI before launch so every lifecycle step has a named owner, from application through record retention. That cuts down on duplicate reviews, missed alerts, and fuzzy audit responses.
Map AML/KYC Tasks Across Bank, Fintech, and Vendors
A common setup looks like this: the fintech does the work, the bank keeps accountability, and vendors support the tools.
| Task | Fintech | Bank | Vendor |
|---|---|---|---|
| CIP data collection | Collects and submits onboarding data | Approves CIP standards and program effectiveness | May provide identity verification tools |
| Identity verification | Runs verification workflow | Ensures coverage meets regulatory requirements | IDV vendor provides matching and scoring |
| Sanctions screening | Performs initial screening | Confirms screening effectiveness and coverage | Screening engine provides watchlist matching |
| KYB / beneficial ownership | Gathers ownership data, flags complex structures | Owns risk-based procedures and final oversight | May support data enrichment or registry lookups |
| Customer risk scoring | Assigns initial risk rating | Reviews and approves scoring methodology | May provide risk model or data inputs |
| Transaction monitoring | Supplies product data, supports alert tuning | Owns model governance and suspicious activity oversight | TM vendor provides rules, models, and alerts |
| Alert triage | Handles first-line review | Receives escalations and makes final compliance decisions | Case management vendor may support workflow |
| SAR escalation | Routes cases and preserves evidence | Decides filing and retains full responsibility | May support drafting or documentation |
| Record retention | Maintains operational records | Ensures retention meets regulatory standards | May host logs or evidence storage |
Recent OCC orders have cited failures in risk assessment, CDD, transaction monitoring, and independent audit in fintech-partner programs.[4][5] A full task map makes each handoff plain before it turns into a headache.
Once that control map is in place, vendor diligence and data-sharing rules can follow the same ownership model.
Build Onboarding Rules That Match the Bank's Risk Appetite
Turn the bank's risk appetite into onboarding rules before launch. In plain terms, decide up front:
- Which customer types are allowed
- Which states or geographies are in scope
- Which data fields are mandatory
- Whether each segment needs documentary verification, non-documentary verification, or a mix of both
It also helps to set three due diligence tiers ahead of time. Standard customer due diligence can cover lower-risk consumers with automated identity verification and sanctions screening. Higher-risk flows, like small business accounts or cash-like products, should move to manual review when identity data doesn't match, beneficial ownership can't be verified, industries are restricted, or geographies carry more risk. Enhanced due diligence should require deeper documents, source-of-funds review, more frequent refresh cycles, and direct sign-off from compliance or the sponsor bank before activation.
The key point is simple: these tiers need fixed decision rules, not case-by-case guessing. If a reviewer has to stop and wonder whether a file needs enhanced review, the process won't be repeatable. And during an exam, that's where things can start to crack.
The bank should approve the tiers, banned business types, and geographic limits before launch. Those launch rules also shape what vendors need to support and what data has to move between systems.
These rules also decide which vendor controls are acceptable and which data fields must be shared through secure channels.
Close the Key Gaps: Vendor Due Diligence and Data Sharing
Once onboarding rules are in place, the next weak spot is the vendor stack that carries them out. The bank still owns oversight, but the fintech may depend on outside tools to run those controls day to day. That setup breaks down fast when a vendor's data, logic, or audit trail is shaky. A policy that says it screens against OFAC doesn't mean much if the vendor's watchlist data is old or its matching logic can't be explained.
Review Vendors for Data Quality, Audit Rights, and Compliance Support
Use vendor-specific diligence. Banks need to validate data, models, and AI/ML tools on their own instead of taking vendor statements at face value.[1][9] The table below shows what to review by vendor type, what to ask, and what proof to gather before go-live. The fintech provides evidence for its own tools, the bank keeps the diligence file, and the bank's compliance team signs off before launch.
| Criterion | Fintech Partner | KYC/KYB Data Provider | Monitoring/Case-Management Vendor |
|---|---|---|---|
| Governance, controls & documentation | BSA/AML program design, staffing, training, governance structure, and program documentation for exam support | Data sourcing policies, refresh cadence, quality controls, SOC reports, and validation summaries | Rule/model documentation, configuration-change controls, approval workflows, SOC reports, and test summaries |
| Methodology, validation & testing | Validation process for proprietary models, model risk management, and back-testing results | Match logic, scoring logic, sanctions list coverage, independent validation of data quality, and back-testing results | Scenario logic, alert-generation rules, tuning methodology, periodic effectiveness testing, scenario coverage analysis, and UAT support |
| Data quality & coverage | Alignment with the bank's risk appetite and customer segments | Jurisdictions covered, identity types supported, and historical error rates | Data inputs required, field completeness checks, and integration dependencies |
| False-positive management | Alert triage capacity and escalation staffing | Suppression controls and bulk-disposition options | Alert-to-case conversion rates, tuning support, and detection-effectiveness metrics |
| SLAs & uptime | Operational resilience, incident response timelines, and rule-update timing | Latency for screening decisions and refresh commitments | Uptime targets, maximum alert-delivery latency, and new-list deployment timing |
| Remediation processes | Defect severity classification, fix timelines, and escalation paths | Notification timelines for data errors and correction procedures | Incident classification, service credits or other remedies, and communication protocols |
| Audit logs & access | Exportable logs of decisions, configurations, and user actions | Timestamps on screening results and list versions in effect at each query | Logs of alerts, investigations, dispositions, and user actions with timestamps |
| Integration & data exchange | Stable APIs, file delivery, and onboarding-data handoffs | Data formats, refresh files, and reconciliation support | APIs, batch feeds, and case-system integration support |
Collecting documents isn't enough. You also need sample testing on real or synthetic accounts so you can compare vendor output with expected results. That means testing known typologies like structuring around the $10,000 CTR threshold, fast movement of funds, and sanctioned-party matches. Then check whether the system flags them with full context and usable logs.[8][9][7]
Vendor review only goes so far if the bank and fintech aren't sharing clean, consistent data.
Create a Shared Data Schema and Secure Information-Sharing Rules
Even a well-vetted vendor will fail if the incoming data is messy. One common problem is mismatched customer IDs. When transactions, alerts, and KYC records sit under different identifiers across systems, it's hard to see the full risk picture, and SAR opportunities can slip through the cracks.[6][10][12] The fix is simple: choose one bank-approved customer ID as the primary key across every system and vendor before launch. Then document any transformations, like tokenization or hashing, in a data-lineage map.
Capture beneficial-ownership fields during onboarding so downstream monitoring can assess entity risk. Under 31 CFR 1010.230, institutions must collect at minimum the name, date of birth, address, and identification number for each beneficial owner holding 25% or more of a legal entity, plus a designated control person.[3][11] If those fields are missing from the shared schema, the monitoring system can't assess entity risk the way it should.
The shared schema needs to line up with the bank-approved onboarding rules and the control ownership map. Every record moving between the bank, fintech, and vendors should include a consistent field set:
- Customer data: unique customer ID, legal name, DOB, tax ID, government ID, address, customer type, risk rating, and beneficial-owner data for entities
- Transaction data: transaction ID, customer and account IDs, timestamp, amount, channel, counterparty, and product-specific attributes that drive monitoring rules[10][7][12]
How the data moves matters just as much as which fields you include. Use encrypted SFTP or HTTPS-based APIs with TLS and strong authentication, such as OAuth 2.0 or mutual TLS. Restrict sensitive fields - SSNs, full account numbers, and beneficial-ownership details - to specific roles under a least-privilege access model, and log each access event. BSA rules generally require customer identification data, SARs, CTRs, and monitoring logs to be kept for at least five years. Contracts should also require five-year retention, data return, and secure destruction at termination.[3][11]
Clean identifiers, consistent timestamps, and clear retention rules make later alert handling and escalation far more workable.
Run Alerts, Escalations, and Reporting Without Delays
Once data rules and vendor controls are set, the next problem is simple: slow alert handling. If nobody has a written process for who reviews each alert, when it moves up, and who makes the final call, cases stack up fast. Deadlines slip. FinCEN’s 2024 TD Bank action is a clear example of what happens when alert backlogs and filing failures get out of hand.[13]
Define First-Line Alert Handling and Bank Escalation Triggers
The fintech or its vendor does the first review. The bank owns escalation and filing. That split sounds straightforward, but it only works if it’s written down before launch, not after the first exam finding.
One simple way to make that split stick is a joint alert table. It cuts out guesswork about who acts first, who takes over, and what filing duty may come next.
| Alert Category | First-Line Handler | Escalation Owner | Reporting Obligation |
|---|---|---|---|
| Cash deposits or withdrawals near or above $10,000 | Fintech compliance team | Bank BSA officer | CTR evaluation; SAR if suspicious patterns are identified |
| Unusual cross-border transfers | Fintech compliance team | Bank BSA officer | SAR if suspicion is confirmed |
| Sanctions / OFAC match | Fintech compliance team (flag immediately) | Bank BSA officer (immediate escalation) | Immediate bank review |
| Suspected structuring | Fintech compliance team | Bank BSA officer | SAR; CTR if cash thresholds are met |
| High-risk onboarding discrepancies | Fintech compliance team | Bank BSA officer | Internal review; SAR if suspicion is confirmed |
| Pattern-based alerts | Fintech compliance team | Bank BSA officer + senior management | SAR; escalation review per FFIEC guidance |
The table matters, but SLAs are what give it bite. A practical starting point is:
- Initial review within 24 hours of alert generation
- Escalation to the bank’s BSA team within 48 hours for high-risk alerts
- Same-week bank review for any case that may require a SAR
Each escalation should include the full case file, built from the shared customer ID and records already set in the data schema. That file should include customer KYC data, transaction history, investigation notes, prior alert history, and the analyst’s rationale. An informal email handoff without that support is the kind of thing examiners flag right away.[25][26]
Clarify SAR and CTR Responsibilities, Timelines, and Recordkeeping
The sponsor bank files. Even if the fintech spots the activity, drafts the narrative, and pulls the transaction history together, the sponsor bank is still on the hook for the accuracy and timing of every SAR and CTR submission.[27]
The deadlines are fixed by rule, and there’s not much room for slow handoffs. For SARs, the clock starts at initial detection. Filing is due within 30 calendar days, or up to 60 calendar days if no suspect is identified at the start.[14][15][17][18] For CTRs, any currency transaction over $10,000 in one business day, including aggregated transactions for the same customer, creates a filing duty.[19] And if that same activity also looks suspicious, both a CTR and a SAR may be needed.[19]
The fintech’s job is to get those cases in front of the bank early and in a clean package. In practice, that means flagging SAR-worthy cases as soon as they appear, preparing a full draft case file, and sending it over early enough for the bank to review and file without a last-minute scramble. Build in a workflow step that flags any open case coming up on the 30-day mark and sends it to senior review right away. Don’t rely on someone noticing it in time.
Keep all SAR and CTR files, plus the supporting documents, in one shared and searchable repository, not spread across inboxes or sitting on local drives.[19][20][21][22][23] If the SAR backlog starts to grow, treat it as a governance issue that goes to bank management, not just an ops problem to work through quietly.[16][24] Backlog thresholds and reporting cadence should be written into the governance model that comes next.
Put Compliance Ownership Into Contracts and Governance
Alerts, escalations, and SAR/CTR deadlines only hold up when the contract makes ownership crystal clear. If the written terms are fuzzy, small control gaps can turn into exam findings and enforcement risk. The contract should match the RACI, escalation paths, and data flows you’ve already set.
Contract Terms That Decide Who Owns Which Controls
Vague wording won’t cut it. The agreement should assign a specific party to each control, spell out what “done” means, and set a baseline auditors can test. A program-specific RACI should identify who performs, reviews, approves, and is accountable for each control.
| Contract Term | Accountable Party | Minimum Standard |
|---|---|---|
| CIP and CDD/EDD execution | Fintech | Bank-approved procedures; complete audit trail per customer |
| Sanctions screening rules and overrides | Fintech runs; Bank approves rules and clears hits | Bank-approved screening logic; documented rationale for every override |
| Transaction monitoring and alert triage | Fintech | Timely review; documented escalation within a fixed window for high-risk alerts |
| SAR/CTR filing authority | Bank | Bank retains filing authority; fintech delivers the complete case file and evidence on time |
| Audit and data access | Bank | Bank has full access to policies, logs, case files, model logic, and training records, plus independent test rights |
| Issue remediation | Fintech executes; Bank approves closure | Written plan with owner, due date, root-cause analysis, and closure evidence |
| Data confidentiality and retention | Both parties | Both parties must meet confidentiality, access-control, and retention requirements |
| Breach notice | Fintech | Prompt notice to the bank upon any security or compliance breach |
| Termination rights | Bank | Clear right to exit if AML/KYC standards are not met; obligation to offboard non-compliant accounts |
It also helps to lock in SLAs for data delivery, alert response, and regulatory requests. Name primary and backup contacts, and set a fixed escalation window to the bank’s compliance team.
Those same duties should flow down to sub-vendors, including AI screening and monitoring tools.[2][28]
Those clauses matter most when governance reviews exceptions and gets issues closed on time.
Governance, Reporting, and System Support for a Scalable Program
Contracts set the rules. Governance makes sure people follow them.
A workable model usually includes monthly operating meetings for process issues, quarterly program reviews for control performance, and quarterly executive reporting on material risk. Each meeting should run on evidence, not just commentary. That means a KPI dashboard that tracks alert aging, SAR conversion rates, KYC pass rates, false-positive trends, and vendor SLA performance. Just as important, the dashboard should map back to the named control owners and escalation deadlines already listed in the RACI and contract.
You also need a formal issue log. Every finding should be recorded with a severity rating, named owner, due date, and closure evidence. Regulators want dashboards and proof of closure, not verbal comfort. Recent FDIC consent orders have set deadlines as short as 90 days to collect missing customer information and 180 days to put revised AML/CFT programs in place.[29][30] An issue log makes it much easier to show movement against deadlines like that.
FAQs
Who is ultimately liable for AML/KYC compliance?
The fintech or financial institution remains ultimately liable for AML/KYC compliance, even when parts of the work are outsourced to vendors or banking partners. If something goes wrong, regulators still look to the main institution for oversight and any compliance failures.
In Banking-as-a-Service arrangements, sponsor banks may also be held accountable for actions taken by their fintech partners. In plain terms, a contract doesn't make that risk go away. Firms still need documented due diligence, internal controls, and ongoing vendor oversight.
How should a fintech and sponsor bank divide AML tasks before launch?
Before launch, fintechs and sponsor banks should spell out AML/KYC duties in detailed, board-approved contracts. Sponsor banks still answer to regulators, so the agreement needs to clearly assign who owns identity verification, transaction monitoring, and regulatory reporting.
The fintech should also map customer and transaction flows to spot integration points, such as real-time OFAC screening. On top of that, compliance and operations roles should stay clearly separate, with monthly reviews to deal with risk and keep an audit trail in place.
What should contracts include to avoid AML/KYC ownership gaps?
Contracts should clearly spell out who handles the main AML/KYC duties. That includes customer identity verification, transaction monitoring, and regulatory reporting. If those lines are blurry, problems can pile up fast.
The agreement should also set clear rules for data protection, breach notification, and day-to-day compliance duties. In plain English: if something goes wrong, both sides should already know who does what, when they need to act, and how they need to report it.
It also helps to build in audit rights and regular reviews. Common examples include checking a SOC 2 Type II report and reviewing penetration test results. Those reviews give you a way to confirm that controls aren’t just promised on paper - they’re actually in place.
Termination terms matter too. When the relationship ends, the contract should require secure data return or destruction so sensitive information doesn’t linger where it shouldn’t.
