What your sponsor bank's controls audit will ask about your sub-merchant decisions
Every PayFac and every acquirer-sponsored program sits inside a periodic controls review. The bank does not audit your intentions or your policy binder. It samples individual sub-merchant files and asks you to show the decision. Here is the request list, why vendor consoles cannot answer it, and what a pass looks like.
What will a sponsor bank's controls audit ask about your sub-merchant decisions?
The bank samples individual sub-merchant files and asks you to show the decision: what was known at the time, which policy version applied, who decided, and how the file evolved after boarding. The audit tests whether your decisions are reproducible, not whether they were right.
That distinction is the whole game. Reviewers do not expect a portfolio with zero bad boardings. They expect that when they pull a file, any file, you can reconstruct the call as it was made. A judgment call that went wrong but was documented at decision time is a survivable finding. A correct call that nobody can reconstruct is a control failure, because the reviewer cannot tell it apart from luck.
Why the audit happens: you are inside someone else's exam
Your sponsor bank is not auditing you out of curiosity. The bank carries the regulatory exposure for the program. Under the interagency third-party risk guidance, a fintech partner or PayFac program is a third-party relationship the bank must evidence across a full lifecycle, and the stage examiners probe hardest is ongoing monitoring. When the OCC or FDIC examines the bank, the examiner samples through the bank into the partner's files. The bank's controls audit of you is a rehearsal for that moment, and its request list is a pass-through of the examiner's.
The bar moved after Synapse. The collapse of a middleware provider that left end customers unable to reach their funds turned partner oversight from an annual-review formality into a continuous-monitoring expectation, backed by public consent orders against sponsor banks. Banks that cannot evidence their partners are being asked, in writing, to shrink their partner count. See the bank-side view of this oversight for what your bank is being measured on. The practical consequence for you: the audit is not going away, it is getting more granular, and the bank has a regulatory incentive to drop partners who make it look bad in front of its examiner.
So read every request in the audit letter as a proxy question. The bank is not really asking "show me this sub-merchant's KYB result." It is asking "if my examiner pulls this file through me next quarter, will you make me look like a bank that controls its program, or one that does not?"
The actual request list, file by file
The format varies by bank, but the substance of a sub-merchant file sampling is consistent. For each sampled sub-merchant, expect requests in four groups.
1. The boarding decision. Show the decision to approve, as it was made. That means the KYB result and beneficial ownership as verified on boarding day, the MATCH inquiry as of boarding day and what it returned, the fraud and credit scores that were in front of the decision, the underwriting policy version that applied, and the identity of the approver, human or automated rule. If an underwriter overrode a decline recommendation, the reviewer wants the override and its rationale, recorded at the time, not reconstructed for the audit.
2. The ongoing-monitoring history. Boarding is a snapshot; the file is a timeline. What changed on this sub-merchant after approval: ownership changes, list movements, chargeback and refund trends, velocity anomalies. Which monitoring rules fired, and what you did each time. A monitoring alert with no recorded disposition is worse than no alert, because it proves the signal arrived and nobody can show what happened next. The reviewer is checking that monitoring produces decisions, not just dashboards.
3. Adverse actions and terminations. For any sub-merchant you restricted, held funds on, or terminated: the trigger, the evidence reviewed, the policy basis, the decision maker, and the notice. Termination files get extra attention because they carry MATCH-placement consequences and because they are where a PayFac's process is under the most pressure. The same reproducibility standard applies to the sub-merchants you cleared: a documented decision to take no action is part of the file.
4. The clock. The request comes with a deadline, and the deadline is tightening. Sponsor banks are increasingly writing a 7-to-14-day response time into the program agreement as a contract term, because the bank's examiner measures the bank on how fast its partners produce evidence. Response time is the one metric in the audit that structurally cannot be faked. If assembling one sub-merchant file takes you three weeks, you have told the bank two things: you missed the term, and you do not have a single source of truth for the file, because assembly across consoles is the only way it could have taken that long.
Why assembling this from vendor consoles fails
Every PayFac risk lead who has been through one of these reviews knows the failure mode. The evidence exists, somewhere. The KYB vendor has a report. The fraud vendor has scores. The processor has chargeback data. The policy lives in a document repository, the approvals live in email or a ticketing tool. Assembling one file means logging into five or six systems and stitching screenshots into a packet, per sampled sub-merchant.
The deeper problem is not the stitching effort. It is that consoles show current state, and the audit asks about decision-time state. The KYB vendor's console shows the business as it verifies today, not as it verified on boarding day two years ago; the vendor has re-run the check, the data has refreshed, the boarding-day answer is gone. Your underwriting policy is on version nine; the decision was made under version four, and the reviewer asks what version four said. The fraud vendor recalibrated its scores last quarter; the score in front of the approver no longer exists in any screen you can open.
When the decision-time state is unrecoverable, teams do the only thing left: they reconstruct. They pull current data, annotate it with what they believe was true at the time, and hope the reviewer accepts the narrative. Reviewers recognize reconstruction on sight, and it converts a sampling exercise into a finding. The capability the audit is actually testing for is point-in-time replay: the ability to show the file exactly as it stood at the moment of decision, because it was captured then, not rebuilt later.
What a pass looks like
The PayFacs that clear these reviews without a war room share one structural property: the decision and its evidence were written to the same place at the same time, and never separated. Concretely:
- One record per sub-merchant. Boarding signals, monitoring signals, alerts, dispositions, and decisions land on the same record for the life of the relationship. No signal lives only in a vendor console.
- Signals tagged with vendor and policy version. Every input carries which vendor produced it, when, and which policy version evaluated it. "What did version four say" is answerable because version four is pinned to every decision it made.
- Decisions and overrides recorded at decision time. The decision engine decides on the full record, and the decision, the signals it saw, and any human override with its rationale are captured in the same write. The defensible file is not an extra step after the decision; it is what deciding this way produces.
- A signed export per sampled file. When the audit letter arrives with its sample list, each file is a query: one export per sub-merchant, tamper-evident, in the format the bank asked for. See one record, many sponsor formats for how the same record serves different sponsors' request templates.
With that in place, the audit changes shape. The two-week assembly scramble becomes an afternoon of running exports. The response lands inside the contract window with days to spare. And the packet the bank receives shows decision-time state, which is the one thing reconstruction can never convincingly produce.
The relationship dividend
There is a second-order payoff that matters more than passing any single review. Your sponsor relationship is the license your whole business runs on, and the bank is under standing pressure to justify every partner it keeps. A PayFac that answers evidence requests in days becomes the partner the bank cites to its examiner as proof the program is controlled. A PayFac that answers in weeks becomes a line item in the bank's own findings, and slow answers compound into contract-renewal risk, because the easiest way for a bank to fix an oversight finding is to exit the partner that caused it.
The same asymmetry works in your favor when you grow. Adding a second sponsor, or negotiating better terms with the current one, starts with the bank's diligence team pulling sample files. Walking into that diligence with reproducible decisions is a commercial asset, not just a compliance posture. Teams making the ISO-to-PayFac transition feel this earliest: the first sponsor agreement is won or lost partly on whether the bank believes your decisions will be evidenceable at scale.
Frequently asked questions
What does a sponsor bank audit of a PayFac cover?
A sponsor bank's controls review samples individual sub-merchant files and asks the PayFac to reproduce each decision: the boarding decision with the KYB result, MATCH inquiry, and risk scores as they stood on boarding day, the policy version that applied, and who approved; the ongoing-monitoring history, what changed, what fired, and what the PayFac did; and any adverse-action or termination decisions with their rationale. The review tests whether decisions are reproducible from the file, not whether every call was right.
How fast do I have to respond to a sponsor bank information request?
Sponsor banks are increasingly writing a 7-to-14-day response time into the program agreement as a contract term, because the bank's own examiner measures the bank on how fast its partners produce evidence. A PayFac that takes three weeks to assemble one sub-merchant file has demonstrated it has no single source of truth for that file, and the bank counts that against the relationship. Teams that keep one record per sub-merchant answer in days because the request is a query, not an assembly job.
Can FinQub talk to my sponsor bank's systems?
FinQub does not need to. The bank asks for evidence in its own requested format, and the record produces a signed export per sampled sub-merchant: the decision, every signal it saw with vendor and policy-version tags, and any override with its rationale. One record can serve multiple sponsors, each in the format that sponsor asks for. If the bank runs its own oversight record, your exports feed it; if it works from spreadsheets and PDFs, the same export covers that too.
Does the audit judge whether our decisions were right?
Not primarily. Reviewers know that risk decisions involve judgment and that some approved sub-merchants will later go bad. What the review tests is whether each decision is reproducible: can you show what was known at the time, which policy version applied, who decided, and how the file evolved afterward. A defensible wrong call, documented at decision time, reads far better than a right call nobody can reconstruct.
What happens if we fail the sub-merchant file sampling?
Findings escalate. A gap in a sampled file typically produces a remediation item with a deadline, a wider follow-up sample, and closer scrutiny at the next review. Repeated findings show up in the bank's own exam file, and because the bank carries the regulatory exposure for the program, a partner it cannot evidence becomes a partner it is pressured to restrict or exit. Slow or incomplete audit responses are a known input to non-renewal decisions.
The controls audit is the sponsor relationship made concrete: the bank's third-party risk obligations flowing through its oversight program into your sub-merchant files. FinQub keeps one record per sub-merchant so that when the sample list arrives, each file is a query with point-in-time replay behind it, exported in whatever format your sponsor asks for. Book a short walkthrough below to see what your next review would look like on your stack.