Sponsor bank compliance audit of a live programme

A sponsor bank review of a live programme, with a request list and a fieldwork date

The trigger is a notice from the sponsor bank's third-party risk team: a programme review, an audit period, a request list, and a fieldwork date. End users already hold balances and cards in the programme. The compliance lead answers the request list, and the CTO owns the systems behind every sampled transaction. Products include consumer and business accounts, corporate cards, and earned wage access built on a bank or a Banking-as-a-Service platform. Launch with a new bank is a separate partner bank integration scenario. Sources on this page were checked on 2026-09-16.

In the United States, sponsor bank compliance reviews come from three directions:

• The bank's ongoing monitoring. Under the Interagency Guidance on Third-Party Relationships (88 FR 37920, final as of 6 June 2023), typical monitoring activities include review of reports on the third party's performance and the effectiveness of its controls, and regular testing of the bank's own controls over third-party risk. In certain circumstances, based on risk, a bank may also perform direct testing of the third party's own controls (section C.4).
• The bank's own examination. When reviewing third-party risk management, examiners typically perform transaction testing or review results of testing to evaluate the activities performed by the third party (section E).
• An enforcement action against the bank. The Federal Reserve cease and desist order against Evolve Bank & Trust (effective 11 June 2024) required policies to identify, manage, and monitor compliance and fraud risks associated with each fintech partner (paragraph 3(a)(i)), and complaint-handling policies for fintech partners through remediation validation and reporting to the bank (paragraph 3(b)(i)(B)). The FDIC consent order against Lineage Bank (FDIC-23-0041b, dated 30 January 2024) required an annual BaaS Risk Assessment Report by an independent firm, covering each fintech partner's compliance with applicable laws, consumer complaints, operational or transaction concerns, and compliance with its contracts (paragraphs 17(a), 17(b), and 17(d)).

The agencies published proposed third-party risk management guidance (91 FR 58536) on 15 September 2026. Status verified on 2026-09-16: comments close on 16 November 2026, the 2023 guidance still applies, and any final version would replace the 2023 guidance and the July 2024 joint statement on bank deposit arrangements.

Sequence to prepare evidence for the review

1. Fix the scope in writing. Confirm the audit period, the rails and channels in scope, the sample, and the fieldwork date. Output: a request register with one owner per item on the bank's list.
2. Map each request to a test. Link each request and each programme agreement obligation to test cases and their latest run inside the audit period. Output: Requirement-to-test traceability matrix.
3. Find the gaps before fieldwork. List requests with no test case, no run inside the audit period, a failed run without a retest, or a record without build, environment, or reviewer fields. Output: Gap report before the assessment.
4. Rerun reconciliation on sampled days. Match the for-benefit-of (FBO) account balance in the bank core with the sum of end-user sub-ledger balances for each sampled day, and rebuild each end user's balance from the daily export without the platform's API. Output: Reconciliation test scenarios against bank, processor, and scheme files, and a Balance drift and rounding report.
5. Test programme limits per channel. Send values below, at, and above each limit and gate in the programme agreement through the app, the API, batch upload, and scheduled transfers. Output: Programme control and limit checks.
6. Trace error notices end to end. Submit synthetic notices of error through each intake channel and compare received times, investigation timers, and provisional credit with the Regulation E time limits for consumer accounts. Output: error-resolution test results with timestamps per case.
7. Rerun onboarding and screening tests. Run synthetic applicants with known matches and near matches through identity verification, sanctions screening, and politically exposed person (PEP) screening. Output: Onboarding and verification scenario suite results, and a Sanctions and PEP screening test data set and results.
8. Retest every fix with the same test case version. Link each failed test to its defect, the fix commit, and a passing rerun on a build that contains the fix. Output: Retest evidence after remediation.
9. Assemble the pack in the bank's order. File dated records under each item on the request list, and state open defects with owners and fix dates. Output: Test evidence pack per audit scope.

How we help during a sponsor bank review

• Audit and certification test evidence covers steps 2, 3, 8, and 9 with its four deliverables, from the Requirement-to-test traceability matrix to the Test evidence pack per audit scope.
• BaaS and partner bank integration testing covers step 5 with Programme control and limit checks, and adds the Webhook delivery, ordering, and retry test report for provider events that post to sampled balances.
• Ledger and reconciliation testing covers step 4 and adds Audit trail completeness checks.
• KYC, AML and fraud testing covers step 7.

The bank, its independent firm, or its examiner performs the review; our test records are input to it. Your team keeps the bank relationship and the answers sent to the bank.