Card issuer signals on one record: MATCH, RiskRecon, Decision Intelligence, Ethoca

The card issuer compliance landscape

Card issuers carry a different compliance shape than acquirers or PayFacs. The acquirer side worries about merchant boarding, chargeback ratios at the portfolio level, and MATCH list management. The issuer side worries about the cardholder instead: identity at issuance, sanctions and PEP screening on the cardholder and on counterparties as transactions flow, real-time fraud and authorization risk, dispute management as the issuer, and the BIN-sponsor relationship that sits beneath the whole program.

Many fintechs are both an issuer and an acquirer-adjacent program at once. A BaaS-shaped neobank issues debit cards (issuer side) while supporting a payments product (acquirer side). A vertical SaaS company with embedded cards and embedded payments is in the same shape. Both sides generate signals, both report to network programs, and both ultimately answer to the same BIN sponsor.

The five Mastercard surfaces every issuer touches

Mastercard's issuer-side program surface is large. Five of those programs generate signals or decisions that have to land on your compliance record:

• Decision Intelligence (DI). A real-time, transaction-level fraud risk score delivered by Mastercard's switch during authorization. It is an input to the issuer's authorization decision, not the decision itself. The issuer's rulebook combines DI with the cardholder profile, the merchant, the velocity, and the BIN-level risk posture. The record holds the DI score, the other inputs, the issuer's decision, and the rulebook version that applied.
• MATCH (Member Alert to Control High-Risk Merchants). Mastercard's terminated-merchant list. Issuers query MATCH when relevant, and the queries themselves are auditable events that need to land on the record with the point-in-time list state.
• RiskRecon. Mastercard's cyber and third-party risk monitoring. Issuers use it to assess their own vendors, sub-issuers, and program managers. The findings (which then drive vendor risk decisions) need to land on the same record that holds your vendor risk posture.
• Ethoca. Pre-dispute alert program. When a cardholder disputes a transaction with the issuer, an Ethoca alert can resolve it before it becomes a formal chargeback. Each alert, the path chosen, the rule that decided, and the analyst who acted needs to land on the record with the dispute itself.
• Finicity. Mastercard-owned open-banking and data connectivity. For issuers running funding flows or income verification, Finicity outputs become signals on the cardholder record alongside KYC, sanctions, and other identity data.

The Visa equivalents (and where they overlap)

Visa runs an analogous set of issuer-facing programs that the same record needs to hold:

• Visa Risk Manager. Real-time transaction risk scoring and rule-based controls, similar in role to Mastercard DI. The score is one input among several; the issuer's authorization decision is the output.
• RDR (Rapid Dispute Resolution) and CDRN (Cardholder Dispute Resolution Network). Visa's pre-dispute alert programs. Same shape as Ethoca on the Mastercard side. Both can run in parallel for issuers serving both networks.
• VMPI (Visa Merchant Purchase Inquiry). Provides transaction-level details to issuers and cardholders during a dispute. The information returned, and the decision the issuer made on it, become events on the dispute record.
• VAMP (Visa Acquirer Monitoring Program). Primarily an acquirer-side program, but issuers in mixed BaaS shapes touch it on the acquirer flank. See Visa VAMP 2026 for the threshold-tightening this year.

Issuers serving both networks face the cross-network reconciliation problem: a Mastercard cardholder and a Visa cardholder produce signals through different programs that look slightly different on paper but mean the same thing. The record normalizes them so a query about a customer's dispute history returns the same shape whether the underlying card is Mastercard or Visa.

The issuer compliance stack

On top of the network programs above, an issuer typically runs eight categories of tooling:

• KYC at issuance. Persona, Onfido, Sumsub, Veriff for cardholder identity. Persona and Sumsub are most common for US issuers.
• Sanctions and PEP screening. ComplyAdvantage, Refinitiv (LSEG), Dow Jones Risk Center. Continuous re-screening as lists update.
• Transaction monitoring and AML. Verafin (Nasdaq), Unit21, Featurespace, Hummingbird (case management). Sponsor banks often mandate a specific tool.
• Fraud and risk decisioning. Sardine, Sift, Featurespace, Forter. Real-time authorization risk on top of the network-provided scores.
• Card processor and program manager. Marqeta, Galileo, Lithic, Highnote. The platform that actually issues and authorizes.
• Dispute and chargeback management. Ethoca, Verifi, plus issuer-side platforms like Chargehound, Justt. Cross-network in a mixed program.
• 3DS and authentication. Cardinal (Visa), Mastercard Identity Check. Network-defined, but the outcomes land on the issuer's record.
• Reporting and reconciliation. 1099-K and 1099-MISC for cardholder programs that produce taxable events; BIN-sponsor reporting on portfolio metrics monthly.

One cardholder. Every program. One record.

FinQub is the single source of truth for fintech risk decisions. For a card issuer, that means: one record per cardholder, per program, per transaction. KYC outputs from Persona, sanctions checks from ComplyAdvantage, the Mastercard DI score on the authorization, the issuer rulebook's decision, the analyst override if there was one, the Ethoca alert if a dispute came in, and the chargeback resolution if it went that way. All of it on one record. All of it pinned to the policy version that applied at the time.

What that means in practice for the three buyers of a card-issuer record:

• The BIN sponsor. Quarterly reviews and exam-prep requests become queries against the record, not assembly jobs. The sponsor sees the same record format across every cardholder in your portfolio, with the policy version pinned to each decision.
• The network (Mastercard or Visa). When DI or VAMP or MATCH triggers an inquiry, the explanation comes from the record. Every input the network program emitted and every decision the issuer made on it is on one record per cardholder.
• The examiner. When a federal examiner subpoenas a cardholder's history, the response is the record as it stood on the date asked. Hash-chained, signed, and exportable in the format the examiner accepts.

A checklist for card-issuer evidence readiness

• Decide where the record lives before you board your first cardholder. Adding it later means rebuilding evidence history with the BIN sponsor and the network.
• Hold the Mastercard DI score and the issuer's authorization decision on the same transaction record. They are not the same thing.
• Normalize Visa Risk Manager and Mastercard DI to one signal shape so cross-network queries return one answer, not two.
• Keep every Ethoca / Verifi / RDR alert with the resolution path, the rule that decided, and the analyst who acted. The dispute history is one record, not three vendor logs.
• Pin the issuer rulebook version to every authorization and every dispute decision. The rulebook changes; the record of what applied does not.
• Plan for cross-network examiner requests. A federal examiner does not care whether the customer's card was Mastercard or Visa; they want the cardholder history.

Frequently asked questions

Issuer compliance is a record problem dressed as a program problem. FinQub runs beneath your KYC, your fraud vendor, your card processor, and your dispute platform. See how every vendor signal lands on one record, or book a short walkthrough below.