Fintech compliance software, for a sponsor bank, is software that tests whether its fintech partners' compliance work meets the bank's own BSA/AML program: whether end customers were properly identified, whether monitoring and SAR referrals work, and whether the partner's records of who owns each dollar match the bank's FBO accounts. The best way to choose such software is a pilot on the bank's own data: take one partner's last quarter, run it through the tool in parallel with nothing changed for the partner, and compare the tool's results with what the bank's analysts found by hand. The regulators have said a pilot that fails will not by itself draw criticism, and that a tool finding more than the old process does not automatically make the old process deficient. Botminds' BaaS Compliance is built to be tested this way, on a sample of a bank's own partner files and a month of one partner's records.
The examples follow a fictional sample bank, Tessaly Community Bank, and one partner program, Fernquill Pay; their figures are sample data, and the time estimates are ours. The regulatory statements are quoted and linked.
Two markets share the name fintech compliance software
Tools a fintech uses for its own compliance: The fintech, or its middleware platform.
Tools a sponsor bank uses to oversee fintechs: The sponsor bank's BSA officer and third-party risk manager.
Tools a fintech uses for its own compliance: Verify identities, screen sanctions, monitor transactions, manage cases.
Tools a sponsor bank uses to oversee fintechs: Test that the partner did those jobs to the bank's standard, and keep the evidence.
Tools a fintech uses for its own compliance: The fintech's own customers and transactions, live.
Tools a sponsor bank uses to oversee fintechs: The partner's files, re-checked with the bank's own identity service, OFAC history and FBO balances.
Tools a fintech uses for its own compliance: Decisions: open, decline, alert, refer.
Tools a sponsor bank uses to oversee fintechs: Findings, restrictions and remediation, approved by named bank officers.
Tools a fintech uses for its own compliance: A missed check or alert at the fintech.
Tools a sponsor bank uses to oversee fintechs: The bank signing off on what the partner reported, untested.
What is fintech compliance software?
Fintech compliance software covers two different products sold under one name. Fintechs buy identity-verification, sanctions-screening, transaction-monitoring and case-management tools to run their own programs. Sponsor banks need something else: a way to test those programs from outside, because the agencies hold the bank responsible for the identification, due diligence, monitoring and SAR work a partner performs on its behalf (joint statement, July 2024).
The distinction decides what a pilot should measure. A fintech's monitoring tool is judged by what it catches. Oversight software is judged by what it proves: whether its re-checks agree with the bank's own findings, whether it finds what the bank missed, and whether an examiner can follow each conclusion back to its evidence. This page is about the second kind.
How do sponsor banks oversee fintech compliance today?
Most sponsor banks oversee fintech compliance by requesting evidence from the partner and checking it by hand. A typical quarterly test means asking each partner for a list of new accounts, picking 25 to 60 files in a spreadsheet, requesting screenshots of the partner's identity-vendor results and ticking a checklist, while finance compares the partner's total with the FBO balance and emails the partner about any difference. Our estimate for one program's quarterly test and its follow-up is about twelve analyst days.
Where a partner test's time goes, by hand and with the agents doing the checking
By hand: about 12 analyst days
- Checking and sampling · 38%
- Requests and chasing · 33%
- Findings, approvals and evidence · 29%
With BaaS Compliance: about 1.5 analyst days
- Checking and sampling · 27%
- Requests and chasing · 33%
- Findings, approvals and evidence · 40%
The weakness of the hand method is not effort; it is what it tests. A screenshot of the partner's identity-vendor result shows what the partner's system displayed, and a total-to-total comparison shows that the partner's file adds up. Neither shows whether the check actually ran or whether each customer's balance is right. Community banks also lean on vendors for this work: in the 2025 CSBS survey, 47.8% of community banks reported sourcing BSA/AML technology through a combination of in-house and third-party tools and 17.9% fully outsourced (CSBS, 2025 Annual Survey of Community Banks), so a new tool enters a stack of existing ones and must prove what it adds.
How do you pilot compliance software? Replay one partner's last quarter
Pilot compliance software by replaying a period the bank has already tested, so every result can be compared with a known answer. One partner's last quarter is the right size: big enough to include real onboarding, real reconciliation breaks and real referrals, small enough to review every disagreement. The pilot runs in parallel; nothing reaches the partner, no restriction is applied, and the bank's existing process stays the system of record until the pilot ends.
The regulators have taken much of the risk out of trying. The 2018 joint statement says "pilot programs undertaken by banks, in conjunction with existing BSA/AML processes, are an important means of testing and validating the effectiveness of innovative approaches," and that a pilot that fails does not, on its own, invite supervisory criticism. If the new tool finds activity the old process missed, the agencies will not take that alone as proof the old process was deficient (Joint Statement on Innovative Efforts, 2018). What the statement does not excuse is ignoring a real finding: anything the pilot surfaces that warrants action, a missed SAR or an unverified customer, the bank must still act on.
What data does a sponsor bank need from fintechs for a pilot?
A pilot needs the partner data the bank should already be entitled to under its program agreement, plus the bank's own reference data for re-checking. If a partner cannot supply the raw files for a pilot, the bank has learned something important about its oversight before buying anything.
Data for a one-partner, one-quarter pilot
- Onboarding files with raw identity responses
For every account opened in the quarter: the data collected, the identity vendor's response and the open decision. Not pass rates.
- Daily end-customer balance files
At least one month of the partner's daily per-customer files, to rebuild balances and tie them to the FBO account.
- FBO balances from the core and general ledger
The same days, as the bank booked them at close.
- Settlement and payment files
Card processor settlements, ACH returns, wires and fees for the month, to explain any break.
- SAR referrals with detection dates
Every referral the partner made in the quarter, with when it detected and when it sent.
- The bank's hand results
What the bank's own test of that quarter found: the sample, the failures, the open differences and the findings.
- The program agreement and the bank's procedures
So that every failure can cite the clause or procedure it breaks.
How do you measure a compliance pilot?
Measure a compliance pilot against the bank's own known answers, and decide the pass marks before the run, not after. The measures below are the ones that separate a tool that proves things from one that summarises them. The thresholds are a bank's choice; ours are suggestions.
Measures and exit tests for a fintech compliance software pilot
| Measure | How it is computed | Why it matters | Suggested exit test |
|---|---|---|---|
| Agreement with hand results | Share of files where the tool and the bank's analysts reached the same pass or fail | A tool that disagrees often must be right more often to be trusted | Every disagreement explained; none unexplained |
| New failures found | Files the tool failed that the hand test passed, confirmed by a bank reviewer | The reason to change tools at all | Each confirmed with the evidence cited |
| False failures | Files the tool failed that a reviewer, on evidence, passes | Each one costs analyst time and partner goodwill | Low enough that reviewers stop re-checking passes |
| Breaks explained | Reconciliation differences the tool traced to a cause that the partner confirmed | An unexplained difference is the bank not knowing what it owes | No difference left labelled timing without a matching payment |
| Population tests run | Times shared causes led to a whole-population test, and what it found | Sampling alone underestimates a systemic gap | Run whenever the bank's rule triggers it |
| Time to a drafted finding | From a failed test to a cited draft ready for the analyst | Speed only matters if the draft is usable | Within the bank's own clock; the solution's design target is one day |
| Evidence an examiner can follow | Share of finding sentences that cite a rule, agreement clause or record | The test is whether someone outside can check it | Every sentence cited |
Run on the sample bank's Fernquill Pay quarter, the comparison would read like this: the partner reported all 60 sampled files as passing every test; the re-performance failed four, all on date of birth, and confirmed the cause in the partner's own identity responses; a population test found 212 of 3,412 accounts with the same gap; and the reconciliation traced a $22,790.75 difference the partner had called timing to 23 card funding reversals. Those are sample results on fictional data; the point of a pilot is to see what the equivalent numbers are on yours.
What a pilot should produce: re-performed files beside a tie-out, on one partner
How long does a compliance software pilot take?
A one-partner, one-quarter pilot can run in about six weeks if the partner data arrives in the first one. Most of the time goes on getting the data and reviewing disagreements, not on running the tool. The plan below is our suggestion for a sponsor bank; the neighbouring guide on piloting oversight software on your own loan tapes covers the lending version.
A six-week pilot on one partner's last quarter
- Data and settingsWeek 1
- Re-perform the sample; population testsWeek 2
- A month of daily tie-outsWeek 3
- Compare with hand results; review disagreementsWeeks 4–5
- Findings, approvals and the examiner packWeeks 5–6
Two settings decisions belong in week one because they change the results. The sample design: how many files per program and in which risk strata. And the reconciliation tolerance: the sample bank allows $0.00 of unexplained difference and treats "timing" as valid only with a matching payment in flight. A pilot run on looser settings than the bank would use in production proves less than it appears to.
What is the best fintech compliance software? Ask what it proves
The best fintech compliance software for a sponsor bank is the one whose output an examiner can verify without trusting the software or the partner. That rules out tools whose main product is a dashboard of the partner's own numbers. The questions that separate tools are about evidence and limits, not features.
Ask each vendor, on your own data: Does it re-run checks with your sources, or read the partner's results? When failures share a cause, does it test the whole population? Does it rebuild each end customer's balance, or compare totals? What does each automated component never do? Who approves a finding, and can the same person draft and approve? How does it keep SAR decisions from reaching a partner? Agentic AI in third-party risk management turns these into a full vendor checklist.
The output to judge a tool by: a finding an examiner can check line by line
Where BaaS Compliance fits, and where it does not
BaaS Compliance fits a sponsor bank that needs independent evidence about its fintech partners' identification, reconciliation and referral work, at a coverage its team cannot reach by hand. Its agents re-perform a risk-based sample of each partner's files every quarter with the bank's sources, tie every partner's records to its FBO account each business day, review referrals, and draft findings and remediation; named people submit, concur, approve and close.
It does not replace other parts of the stack, and a pilot should not pretend it does. It is not a transaction monitoring system and does not replace the bank's own alerts on its FBO accounts. It is not the partner's identity vendor or onboarding platform. It does not decide or file SARs; referrals go to the bank's investigators in case management. It does not certify compliance with any rule, including the FDIC's pending custodial-account proposal; it is set up around the rules, and whether the program meets them is the examiner's judgement. And it needs the partner's raw files: where a program agreement does not deliver them, the first fix is contractual. The 2023 interagency guidance lists timely access to the bank's data among the contract terms to negotiate (88 FR 37920).
What a pilot proves to an examiner
A well-run pilot gives the bank three things to show an examiner: evidence that it evaluated a new approach with care, a documented comparison with its existing process, and a decision with reasons. The 2018 joint statement expects management to judge carefully whether, and when, a new approach is ready to replace or supplement an existing BSA/AML process, with third-party risk among the factors (2018 joint statement). A pilot file with the measures above, the disagreements and how each was resolved is that evaluation in writing.
It also strengthens the bank's independent testing. The FFIEC manual notes there is no fixed testing frequency and that testing should follow significant changes in a bank's systems or processes (FFIEC manual); adopting a new oversight tool is such a change, and the pilot's comparison is the natural starting point for the tester. FinCEN's April 2026 proposal, if finalised, would also let effective use of AI, federated learning and other advanced monitoring tools count in a bank's favour (91 FR 18704, proposed).
After the pilot: remediation that closes only on a passing re-test
Questions people ask
Do we need regulator approval to pilot compliance software?
No approval is required to pilot a tool in parallel with existing processes. The 2018 joint statement encourages pilots and says the agencies "may provide feedback"; it also notes FinCEN can consider exceptive relief under 31 CFR 1010.970 to facilitate testing, which a parallel pilot does not usually need.
Can we run the pilot without telling the partner?
A replay of last quarter uses data the bank should already receive under its agreement, and nothing reaches the partner during the pilot. Whether to tell the partner is a relationship decision; if the pilot finds real problems, the partner will hear about them through the bank's normal findings process.
What if the pilot finds problems our own test missed?
Act on them as you would on any finding: unverified customers need remediation, and suspicious activity needs the bank's normal SAR review. Under the 2018 joint statement, finding more does not automatically mean the old process was deficient; examiners assess the old process on its own merits.
Should we pilot on our riskiest partner?
Usually on a partner with enough activity to test every function and a recent hand test to compare with. The riskiest partner is often a good choice for that reason, provided its data feeds are reliable; a pilot that stalls on missing files tests the partner's data delivery more than the software.
How do we compare two vendors fairly?
Give both the same partner quarter, the same settings and the same exit tests, and compare disagreements with the bank's hand results file by file. To try it on BaaS Compliance, we run it on a sample of your own partner files and a month of one partner's records.