Decide sub-merchant risk fast, and make it hold up
The card networks turned PayFac risk into a speed problem. VAMP tightened its thresholds in April. SMMP gives you 72 hours to decide on a scam flag. Your sponsor samples sub-merchant files every quarter. FinQub is the decision layer on the stack you already run.
Three jobs, four clocks
A PayFac risk team is paid to do three things under network pressure, and every one of them now has a clock on it.
Board fast without eating risk. Revenue is measured in days from application to first transaction. The queue is where that dies: the file where the KYB report says one owner and the processor application says another sits for two days of registry ping-pong while a competitor boards the merchant.
Decide SMMP flags inside 72 hours. Since July 24, 2026, a Mastercard scam flag starts a 72-hour investigation clock, and a confirmed scam means immediate termination. The clock does not wait while someone reassembles the sub-merchant's history from five consoles. Here is how SMMP works.
Act on VAMP drift before the report does. TC40s reach you through the aggregator weeks late, so the ratio you are accountable for is a rear-view mirror. By the time the monthly number moves, the sub-merchants that moved it have been drifting for weeks. The 2026 thresholds leave less room than they used to.
And underneath all three, the recurring exam: your sponsor or acquirer samples sub-merchant files and asks how each decision was made. Timestamps missing on the sanctions screens, an override with no written rationale, and the finding lands on you.
Your stack already does its job. This is the gap.
You already run the tools: a KYB data vendor, a fraud score, the processor's reporting, chargeback and dispute tools, transaction monitoring, and the spreadsheets that glue them together. Dashboards and monitoring are solved problems; every vendor in that list claims them, and most deliver.
What none of them does:
- Reconcile disagreement. When the KYB report, the processor application, and the fraud tool tell three stories about the same sub-merchant, that is where your automation stops and the queue begins.
- Decide on the full picture. Each console decides on its own slice. The boarding call that determines your VAMP exposure gets made on whichever screen was open.
- Record what was known at decision time. Six months later, the question is never "what does the vendor say now" but "what did you see the day you decided" - and a re-pull cannot answer it.
- Assemble the packet. A sponsor request on 47 sub-merchants is a two-week assembly job across consoles, every time, unless the record already exists.
The decision layer on the stack you keep
FinQub sits on top of your existing vendors and lands every signal they produce on one record per sub-merchant. Then it does the three jobs at the speed the networks now demand.
At boarding, your codified policy decides on the assembled picture: KYB, sanctions, fraud, processor data, prior history. Where records disagree, the disagreement is adjudicated by rule instead of parking the file in a queue. Files that used to wait two days clear in minutes; the ones that genuinely need a human arrive with the conflict laid out. Every call, automated or override, is captured with its rationale and policy version at decision time.
When the flag lands - SMMP, a VAMP spike, an acquirer question - the investigation starts from the record, not from five logins. The 72 hours go to judgment, not archaeology.
When anyone asks why, the answer is a query. The sponsor sample, the VAMP investigation, the MATCH justification: one record per sub-merchant produces the packet with every signal, every decision, and every override as they stood at the time.
The PayFac reading room
- Mastercard SMMP: 72 hours to investigate, document, and decide. The triggers, the consequences, the readiness checklist.
- Visa VAMP 2026: what the new thresholds mean for sub-merchant monitoring. Catching the drift before the monthly report.
- Visa Integrity Risk Program (VIRP): what PayFacs and acquirers actually owe. Legality rather than ratios, and the seven-day evidence request.
- Mastercard MATCH: documenting sub-merchant boarding decisions. Point-in-time list state at boarding.
- Continuous sub-merchant monitoring after boarding. Boarding is one decision; the risk is after.
- From ISO to PayFac: the compliance stack you inherit when you move up. The ladder and the eight layers.
Frequently asked questions
Who does FinQub serve on the PayFac side?
Payment Facilitators registered with Visa and Mastercard, vertical SaaS companies with embedded payments that own merchant underwriting, ISOs in transition to PayFac registration, and PayFac-as-a-Service platforms. Any team boarding sub-merchants under a master MID, subject to VAMP and SMMP monitoring, and answering to a sponsor bank or acquirer.
How does FinQub help with the Mastercard SMMP 72-hour window?
SMMP (the Scam Merchant Monitoring Program, in full effect since July 24, 2026) requires the acquirer side to investigate a scam flag and decide within 72 hours. FinQub keeps every sub-merchant's boarding decision, monitoring signals, prior alerts and their resolutions on one record, so the investigation starts from an assembled picture. Your policy makes the call, and the decision plus the evidence it saw is captured at decision time.
Does FinQub replace my KYB, fraud, or chargeback tools?
No. FinQub is vendor-neutral and sits on top of the stack you already run: your KYB data vendor, your fraud score, your card processor's reporting, your chargeback and dispute tools, your transaction monitoring. Each keeps doing its job. FinQub is the layer that reconciles what they say about the same sub-merchant, decides by your codified policy on the full picture, and records what was known at decision time.
How does FinQub help with a VAMP investigation or sponsor audit?
Visa's Acquirer Monitoring Program measures portfolio-level fraud and dispute ratios; when the number moves, the investigation traces to specific sub-merchants and specific decisions. A sponsor or acquirer review samples files the same way. Because every signal and every decision already sits on one record per sub-merchant, either request becomes a query that produces the packet: signals, decision, policy version, overrides with rationale, as they stood at the time.
Bring your hardest file: the sub-merchant where the records disagree, or the last sponsor request that took two weeks. A short walkthrough shows both decided and answered on one record, on the vendors you already run.