QA before a partner bank integration goes live

A new partner bank, a due diligence questionnaire, and a launch date

The trigger is a signed term sheet with a bank. Its third-party risk team sends a due diligence questionnaire, its implementation team shares an API specification, file layouts, and sandbox credentials, and a launch date is set. The fintech company is launching its first programme or moving one from a bank that is exiting. The CTO, the compliance lead, and the founder who promised the date to investors own the outcome. Products include accounts, corporate cards, earned wage access, and loans built on a partner bank or a Banking-as-a-Service platform. Reviews of a live programme are covered in the sponsor bank compliance audit scenario.

In the United States, the bank runs sponsor bank due diligence as part of its third-party risk management, which the federal banking agencies address in the Interagency Guidance on Third-Party Relationships (88 FR 37920, 9 June 2023). Due diligence includes assessing the third party's ability to perform the activity as expected and to conduct it in a safe and sound manner. When technology is a major component of the relationship, the guidance calls it an effective practice to review both parties' information systems to identify gaps in service-level expectations and interoperability issues (section C.2.h). The agencies published proposed replacement guidance (91 FR 58536) on 15 September 2026, with comments due by 16 November 2026. Status verified on 2026-09-16: the 2023 guidance still applies, and the proposal keeps information security and cybersecurity capabilities among the factors due diligence may assess.

In the European Union, the partner is often an e-money or payment institution. Where the fintech company or its platform provides information and communication technology (ICT) services to that institution, DORA Article 28(4)(d) requires the institution, before it enters the contractual arrangement, to undertake all due diligence on the prospective ICT third-party service provider (Regulation (EU) 2022/2554).

The testing sequence before go-live

1. Collect the bank's integration terms. Gather the API specification, event list, file layouts, cut-off times, and every limit and gate in the programme agreement. Output: an integration inventory with a source document for each item.
2. Map the money flows. Trace each flow from end-user request to bank core posting, with failure paths and the party posting each entry. Output: a payment flow map.
3. Prepare synthetic test data. Create synthetic end users, sandbox KYC outcomes, and test cards, and keep production account data out of every test environment. Output: a test data set and an environment access list.
4. Test the API contract. Check every request, response, and error code against the bank's specification. Output: an API contract test suite that runs in CI.
5. Test events and files. Replay duplicate, out-of-order, delayed, and unsigned events, and parse every return, statement, and settlement file layout the bank sends. Output: a webhook delivery, ordering, and retry test report and a payment file format validation suite.
6. Test limits and gates per channel. Send values below, at, and above each limit through every channel, and confirm no money moves before KYC approval. Output: programme control and limit checks.
7. Run a reconciliation dry run. Match several business days of sandbox activity item by item against bank statement files, with injected returns. Output: reconciliation test scenarios with a break log.
8. Run the security and resilience tests the bank asks for. Output: a penetration test report and failover results where the questionnaire requests them.
9. Fix, retest, and decide. Retest every defect that affects a balance, a limit, or a customer message. Output: a defect log with financial impact per defect and retest status.
10. Assemble the evidence. Map scope, environments, API versions, run dates, results, and open defects to the bank's questionnaire. Output: a partner bank due diligence test evidence pack.

How we help before launch

We test partner bank integrations for fintech companies and platforms, and our output goes into the bank's due diligence. The bank decides whether and when the programme launches.

• BaaS and partner bank integration testing covers steps 4 to 6 and 10: the API contract test suite; the webhook delivery, ordering, and retry test report; programme control and limit checks; and the partner bank due diligence test evidence pack.
• Ledger reconciliation testing covers step 7 with reconciliation test scenarios against bank, processor, and scheme files.
• Payment rails testing covers bank files in step 5 with return, reject, and recall test cases. Card issuing testing adds a card lifecycle test suite for a card programme.
• Data migration testing covers a move from a previous bank with a balance and transaction history comparison report and cutover and rollback rehearsal results.
• Security testing covers step 8 with a web, API, and mobile penetration test report, and operational resilience testing adds failover and recovery time results.