Watching every fintech you sponsor from one record

The bar changed after Synapse

For sponsor banks, third-party oversight used to look like an annual review cycle: quarterly business reviews, an annual program audit, and an exception process when something escalated. That model is gone. Three things ended it: the Synapse Financial Technologies collapse in 2024 (which left tens of thousands of end customers with frozen funds), the public FDIC and OCC consent orders against roughly 25 to 35 sponsor banks in 2024-2025, and the 2023 Interagency Third-Party Risk Management Guidance, which was already trending toward continuous monitoring before Synapse made it concrete.

The new bar is real-time visibility. Examiners expect the sponsor bank to know, today, whether each partner's compliance metrics are tracking. They expect a complete customer file (across any partner) to be producible within hours when a regulator asks. Banks that demonstrate this capability sustain larger partner portfolios. Banks that cannot are being asked, in writing, to reduce the partner count.

The seven oversight dimensions per partner

The 2023 Interagency Guidance and the consent orders that followed point to a consistent set of dimensions the sponsor bank should be monitoring continuously, per partner:

• BSA/AML program health. Alert volume, alert-to-SAR conversion, alert disposition latency, false-positive rate. Drift on any of these is the earliest signal something is changing in the partner's book.
• KYC and KYB outcomes. Pass rates, document rejection rates, manual-review queue size, time-to-decision. Drift can mean a vendor change, a new geography, or a fraud wave.
• Sanctions screening. Hit volume, hit-to-disposition path, list-version drift across the partner's screening vendor and the bank's own.
• Reconciliation and ledger integrity. Daily reconciliation pass rates, FBO account balance proof, customer-funds-versus-partner-funds segregation. This is the dimension Synapse exposed; expect every examiner to ask about it.
• Consumer complaints. Complaint volume, complaint-to-resolution time, regulator-routed complaints (CFPB, state AG) versus direct. Drift in regulator-routed complaints is a leading indicator of CFPB attention.
• System availability and incident reporting. Partner-side uptime, incident notification SLA, root-cause turnaround. The sponsor bank's incident-response process depends on the partner's.
• Information-request response time. When the bank asks the partner for evidence on a specific customer, how long does the partner take? This is the dimension partners hate measuring (because it scores their compliance maturity) and banks need to measure (because their examiner measures it).

Seven dimensions, per partner, across 5-25 partners. That is the table the sponsor-bank compliance team has to populate before each quarterly review and keep current between reviews.

Why information-request response time is the load-bearing metric

Of the seven dimensions, information-request response time is the one that structurally cannot be faked. The bank asks the partner: “produce the complete customer file for customer X, including every signal, every decision, and every disposition.” The partner has 7 to 14 days. If the partner takes 3 weeks, three things follow. First, the bank's examiner sees the partner's response time on the bank's record and counts it against the bank. Second, the partner has demonstrated that they do not have a single source of truth for that customer's evidence; assembling across vendor consoles is the only way they could have taken that long. Third, the bank cannot trust the partner's continuous-monitoring claims, because the per-customer evidence is what backs the partner-level KRIs.

Sponsor banks are increasingly making 7-to-14-day response time a contract term. Partners that cannot meet it lose the relationship. The fix, on both sides, is structural: each side keeps a record beneath their vendor stack, and the bank's request becomes a query against the partner's record, not an assembly job. See one compliance record, many sponsor formats for the partner-side detail.

One record per partner. One record across every customer.

The sponsor bank's side of the record holds two layers:

• Per-partner KRIs and oversight events. The seven dimensions above, updated continuously, with drift detection and the policy version that defines what “passing” means. When a KRI drifts past threshold, the record holds the event, the alert, the bank's response (e.g. open an information request), and the partner's reply.
• Customer-level evidence on demand. When the bank queries a partner's record for a specific customer, the response lands on the bank's record alongside the partner-level KRI history. An examiner asking the bank about a specific customer at a specific partner sees both layers on one record.

FinQub is the single source of truth for fintech risk decisions, and the sponsor-bank-side configuration is the inverse of the partner side. The same architecture; the partition is by partner program, not by customer. Each partner's KRIs are aggregated from the partner's own record (when the partner runs FinQub) or from the bank's ingestion of partner reports (when the partner does not). Either way, the bank ends up with one record across every partner, queryable on every dimension.

The escalation flow when something drifts

With one record across partners, the escalation pattern that emerges is consistent:

• Drift detection. A partner's AML alert volume on accounts opened in the last 30 days is 2x the 90-day baseline.
• Auto-alert. The bank's record fires an internal alert to the partner-management team and logs it. Threshold and policy version pinned.
• Targeted information request. The bank's team sends a structured request to the partner: “send the dispositions on the alerts from the 30-day cohort.” The request itself lands on the bank's record as an event.
• Partner response on the bank's record. When the partner replies, the response lands on the bank's record with the partner's evidence attached. Hash-chained, source-tagged.
• Bank decision. The bank decides: accept the partner's explanation, escalate to a program-level review, restrict new onboardings, or terminate. The decision and the rationale land on the record next to the alert that started the chain.
• Examiner sees the loop. At the next OCC or FDIC review, the examiner sees the full loop on one record: drift, alert, request, response, decision. Without the record, the same story is reconstructed from email threads. With the record, the bank has demonstrated continuous monitoring on the spot.

A checklist for sponsor-bank oversight in 2026

• Track the seven dimensions per partner continuously, not quarterly.
• Set drift thresholds for each dimension and require a written rationale when one is breached, on the record.
• Measure information-request response time. Make it a contract term. Hold partners to 7-14 days.
• Keep customer-level evidence on demand. When the regulator asks for a specific customer, you should not have to ask the partner first.
• Pin the policy version. Drift detection depends on knowing what “passing” meant at the time the KRI was measured.
• Run the escalation loop on the record, not in email. A drift event, a request, a response, and a decision should be queryable as one chain.
• Plan the partner-portfolio size against the oversight capacity, not the other way around. Examiners are now checking the ratio.

Frequently asked questions

FinQub runs on the bank's side and on the partner's side. Same architecture, partitioned differently. See the examiner-ready monitoring pattern in more detail, or book a short walkthrough below.