A sponsor bank's BSA/AML program covers every customer and every transaction that touches its charter, including the accounts opened by fintech partners the bank's staff will never meet. There is no partner-channel exception in the Bank Secrecy Act, and examiners evaluate the program against the full volume flowing through the bank, not just the traffic in its branches. If your bank sponsors fintech programs, AML is where the gap between what you delegate and what you own becomes most visible.
Key Takeaways:
- The five BSA program pillars under 31 CFR § 1020.210 apply to every partner channel; the fintech can execute, but the bank defines the standard and validates the results
- Transaction monitoring must cover all partner products, which means the bank needs independent access to transaction data held in partner or middleware ledgers
- SAR decisions and filings belong to the bank under 31 CFR § 1020.320; partners escalate, the bank decides
- Independent testing, training, and the BSA risk assessment must all expand when partners or products are added, not on the next annual cycle
Why the BSA Program Is the Bank's, Across Every Partner Channel
Under 31 CFR § 1020.210, every bank must maintain a BSA/AML program built on five pillars: internal controls, independent testing, a designated BSA officer, training, and ongoing customer due diligence. The regulation attaches these obligations to the bank, and no contract with a fintech or middleware provider changes that.
In a BaaS arrangement, each pillar has to stretch across the partner portfolio. Internal controls must address how partners onboard customers and move money. Independent testing must sample partner-channel activity. Training must reach the staff who oversee partners. The FFIEC BSA/AML Examination Manual directs examiners to evaluate the program against the institution's full risk profile, and for a sponsor bank that profile is dominated by partner activity.
The practical division of labor is consistent across well-run programs: the bank defines, the partner executes, the bank validates. Anything the fintech performs operationally, from identity verification to alert triage, happens against standards the bank wrote and under evidence requirements the bank enforces. For the broader responsibility picture, see our overview of sponsor bank compliance obligations.
CIP and CDD Standards: The Bank Defines, the Fintech Executes
Customer identification in a BaaS program is almost always performed by the fintech, typically through an identity verification vendor embedded in the onboarding flow. That operational reality does not move the CIP obligation. The bank must specify which vendors are acceptable, what match thresholds constitute a pass, when documentary verification is required instead of non-documentary methods, and what happens when verification fails.
The same applies to risk rating and enhanced due diligence. If the bank's policy says certain occupations, geographies, or funding patterns trigger EDD, that trigger has to fire inside the partner's onboarding system, and the bank has to be able to prove it does. Validation is the piece most programs miss: periodic file testing of partner-onboarded accounts against the bank's CIP and CDD standards, with results documented and exceptions remediated.
Business accounts opened through partners bring the beneficial ownership rule into scope. 31 CFR § 1010.230 requires identification and verification of beneficial owners of legal entity customers. When a fintech serves small businesses, its onboarding flow must collect ownership and control information to the bank's standard, and the bank needs those records accessible for its own reporting and for examiners.
Transaction Monitoring When the Data Lives in Partner Ledgers
Transaction monitoring is the hardest AML requirement to satisfy in BaaS because of a structural problem: transactions often settle in an omnibus account while the detail lives in a ledger maintained by the fintech or a middleware provider. A bank that only sees net settlement activity cannot detect structuring, velocity anomalies, or funnel patterns at the end-user level.
Examiners now treat independent data access as a baseline expectation. The bank needs end-user-level transaction data flowing into its own monitoring environment, on a schedule that supports timely detection, without depending on the partner to hand-select what gets shared. Public enforcement actions against BaaS banks have repeatedly cited the bank's inability to independently see partner transaction and customer data.
Coverage and tuning matter as much as access. Monitoring scenarios written for a community bank's retail base will not fit a payroll advance product, a cross-border remittance flow, or a crypto on-ramp. Each partner product needs a documented decision about which scenarios apply, what thresholds fit its risk profile, and when tuning was last reviewed. Our BSA/AML checklist for community banks covers the underlying monitoring fundamentals that partner channels inherit.
SAR Authority and Timelines: Partners Escalate, the Bank Files
Under 31 CFR § 1020.320, the bank must file a suspicious activity report within 30 calendar days of initial detection, or 60 days if no suspect is identified. The clock starts at detection, and in a partner channel, detection often happens first in the fintech's systems. That makes escalation speed a regulatory issue, not a service-level nicety.
The filing decision cannot be outsourced. A partner may investigate and escalate alerts, but the bank reviews the case, decides whether to file, and owns the narrative quality. Consent orders in the BaaS space have flagged banks that accepted partner-drafted conclusions without independent review. The bank also owns SAR confidentiality, which means partner-facing workflows must be designed so filing status never leaks back to the customer-facing team in ways that tip off the subject.
OFAC Screening, Independent Testing, and Training in Partner Channels
OFAC screening must run at onboarding and against transaction flows for every partner program, including screening of counterparties in payment products. The bank sets the screening lists, fuzzy-match thresholds, and escalation path; the partner or middleware layer typically executes the screen; and the bank tests match handling on a schedule.
Independent testing scope is a recurring exam finding. An audit that reviews the bank's legacy retail program but samples nothing from partner channels does not satisfy the independent testing pillar. Testing plans should name each partner program, state the transaction and account sample drawn from it, and trace findings to remediation.
Training follows the same logic. Partner-facing bank staff, relationship managers, BSA analysts working partner alerts, and onboarding reviewers need training specific to the products they oversee. And the BSA/AML risk assessment must be refreshed when a partner or product is added, because the bank's risk profile changed the day the program launched, not at the next annual review.
Common AML Exam Findings in BaaS Programs
Examiner findings in partner banking cluster around a handful of themes, most of which also appear in the public consent orders against sponsor banks:
- Monitoring scenarios that never incorporated partner products, leaving whole transaction types uncovered
- CDD and EDD performed to the fintech's internal standard rather than the bank's documented policy
- SAR decisions delayed because partner escalations arrived late or incomplete
- Risk assessments that still described the bank's pre-BaaS profile years after partner launch
- Independent testing that excluded partner channels entirely
- No demonstrated bank access to partner-held customer and transaction records
Each of these is an evidence problem as much as a control problem. The banks that exit exams cleanly are the ones that can produce, per partner, the standard they set, the validation they ran, and the exceptions they worked.
How Modern Sponsor Banks Run One AML Standard Across Every Partner
The operational challenge is not writing the BSA program; it is proving the program executed across ten partners with different products, vendors, and ledgers. Spreadsheet trackers and quarterly email chases break down at exactly the moment examiners start asking for partner-level evidence.
Canarie lets a sponsor bank define its AML requirements once, CIP standards, CDD thresholds, monitoring coverage, escalation timelines, testing cadence, and continuously evaluates every fintech partner against them. Each partner's evidence lands in one portfolio view, so the BSA officer can see which programs are current, which are delinquent, and what the board needs to know, without rebuilding the picture by hand before each exam.
See how sponsor banks hold every partner to one AML standard →
Frequently Asked Questions
Can a fintech partner file SARs on behalf of its sponsor bank?
No. The SAR obligation under 31 CFR § 1020.320 belongs to the bank, and the filing decision must be made by the bank. A fintech can investigate activity and escalate cases with supporting detail, but the bank reviews each case independently, decides whether the filing threshold is met, and owns the narrative. Banks that rubber-stamp partner-drafted conclusions have been cited in public enforcement actions.
Who performs CIP when customers onboard through a fintech app?
The fintech typically executes identity verification operationally, usually through an embedded vendor, but the bank remains responsible for the CIP program. The bank must define acceptable verification methods, match thresholds, and failure handling, then validate through periodic file testing that partner-onboarded accounts meet those standards. The obligation cannot be transferred by contract.
Does a sponsor bank need direct access to partner transaction data?
Yes, as a practical matter. Effective transaction monitoring requires end-user-level data, and examiners have repeatedly criticized banks that could only see omnibus settlement activity while the detail sat in a partner or middleware ledger. The bank should receive transaction detail into its own monitoring environment on a schedule that supports timely detection and SAR deadlines.
How often should the BSA risk assessment be updated in a BaaS program?
Whenever the risk profile materially changes, which in partner banking means every time a new fintech program or product launches, not just annually. A risk assessment that predates half the partner portfolio is a standard exam finding. Well-run programs treat partner onboarding as a trigger event that forces a risk assessment refresh, monitoring coverage review, and testing plan update before launch.