Related Questions
.png)
The rails are only half the story. Governance is the other half.
When a merchant tells you their stablecoin payment processing is "handled by a regulated partner," that statement describes the technical infrastructure. It does not describe the compliance ownership, the governance structure, or the risk exposure for the acquiring institution. Evaluating stablecoin arrangements requires a different verification frame than standard card-based merchant underwriting. The controls that matter are not the partner's license status; they are the contractual allocation of responsibilities, the completeness of the settlement path, and the actual monitoring coverage applied to this specific merchant's activity.
This guide walks through the complete verification framework for acquirers, PSPs (Payment Service Providers), PayFacs (Payment Facilitators), and program managers who need to assess a merchant operating with stablecoin payment rails.
Stablecoin payments are a licensing problem only in part. They are a governance and monitoring problem first.
A stablecoin is a digital currency pegged to a fiat currency, most commonly the US dollar. USD Coin (USDC) and Tether (USDT) are among the most widely used. Merchants in categories including cross-border e-commerce, crypto-adjacent services, and digital goods increasingly use stablecoins for some portion of their settlement flow, routing transactions through a VASP (Virtual Asset Service Provider), a crypto payments processor, or a technology intermediary before conversion to fiat.
The compliance challenge for acquiring institutions is not primarily about identifying that stablecoin rails are in use. It is about determining who owns which obligations once those rails are in use, and whether the controls applied to the merchant's activity are adequate under applicable rules.
The regulatory perimeter around stablecoin payments is active and uneven across jurisdictions. The following frameworks are directly relevant to acquirers evaluating merchant stablecoin arrangements.
United States
OFAC (Office of Foreign Assets Control) sanctions obligations apply to stablecoin transactions. OFAC published guidance specifically addressing virtual currency in 2021, confirming that sanctions screening obligations extend to on-chain activity.
Source: OFAC Sanctions Compliance Guidance for the Virtual Currency Industry (October 2021)
FinCEN (Financial Crimes Enforcement Network) has issued interpretive guidance confirming that persons who act as exchangers of convertible virtual currency are money transmitters subject to BSA (Bank Secrecy Act) obligations.
Source: FinCEN Guidance FIN-2019-G001
The CFPB (Consumer Financial Protection Bureau) has indicated supervisory interest in digital payment instruments. Regulation E (12 CFR 1005), which governs error resolution for electronic fund transfers, may apply depending on how stablecoin payments are structured. Legal coverage in this area continues to evolve.
Source: CFPB, Electronic Fund Transfers (Regulation E)
European Union
MiCA (Markets in Crypto-Assets Regulation), which took effect progressively from 2024, establishes a licensing and conduct framework for crypto-asset service providers operating in the EU, including issuers of asset-referenced tokens and e-money tokens. Acquirers with EU merchant exposure should verify whether the stablecoin partner holds applicable MiCA authorization.
Source: European Parliament, MiCA Regulation (EU) 2023/1114
Card Scheme Rules
Mastercard and Visa maintain specific rules for payment facilitators, sub-merchant registration, and merchant of record designation. Where a stablecoin arrangement changes who appears as the merchant of record, those rules apply directly to how the acquiring institution registers and monitors the merchant.
Source: Mastercard Rules (current edition, Chapter 7: Payment Facilitators)
A merchant applies for or holds an acquiring relationship. During onboarding or ongoing review, you determine that a portion of their payment volume is settled in stablecoins, processed through a third-party partner the merchant describes as "regulated," "licensed," or "compliant."
The merchant's position: the partner handles compliance.
The acquiring institution's obligation: verify what that means in practice, for this merchant's specific activity, against your program requirements and applicable regulatory standards.
This is not an edge case. Stablecoin payment arrangements are structured in materially different ways. The compliance ownership in each arrangement is not uniform and is not determined by the partner's license alone.
Why it matters: Who appears as the merchant of record determines chargeback liability, card scheme rule applicability, consumer protection obligations, and regulatory accountability. In stablecoin arrangements, the partner sometimes appears as the merchant of record rather than the actual business the acquiring institution has underwritten.
Merchant is the record holder
The merchant accepts payment from the consumer directly, with the stablecoin partner providing settlement infrastructure only. This is the cleaner structure from an acquiring perspective.
Underwriting implications: Standard merchant-level assessment applies. Verify that the partner's involvement in the payment flow is disclosed in the merchant's terms of service and to the acquiring institution.
Partner is the record holder
The stablecoin partner appears as the merchant of record, with the actual business operating as a sub-merchant. This structure has direct implications for scheme rule compliance and consumer disclosure.
Underwriting implications: Verify registration as a sub-merchant under the partner's facilitation program. Evaluate whether the consumer is informed of the record holder's identity at point of sale. Confirm which entity bears chargeback liability.
Ambiguous or undocumented
No written agreement clearly establishes who is the merchant of record. This is the most common gap we see in early-stage stablecoin arrangements.
Underwriting implications: Treat as disqualifying until resolved in writing.
What to Request
Red Flags
Why it matters: Stablecoin payments may involve multiple conversion steps across wallets, custodians, and exchanges before reaching the merchant as fiat. Each step introduces a potential gap in fund accountability, sanctions coverage, and audit trail integrity. Settlement flow documentation should be specific enough that a reviewer can trace a single transaction from origination to final settlement without inference.
Direct fiat conversion
Stablecoin received by processor, converted to fiat, and settled to merchant. One conversion step. Cleaner audit trail.
Multi-step on-chain settlement
Stablecoin moves across one or more wallets or custodians before conversion. Common in arrangements involving multiple intermediary entities or cross-border settlement.
Risk implication: Each intermediate wallet is a sanctions screening point. Gaps in screening at any step create exposure.
Hybrid settlement
Some transactions settle in fiat, others in stablecoin, depending on amount, geography, or merchant preference. Settlement documentation is typically less complete for the stablecoin leg.
Risk implication: Transaction monitoring configurations are frequently set up only for the fiat leg, leaving the on-chain leg unmonitored.
What to Request
Red Flags
Why it matters: On-chain stablecoin transactions are generally irreversible once confirmed on the blockchain. Unlike card payments, there is no network-level mechanism to reverse a confirmed on-chain transfer. This has direct implications for dispute resolution, refund processing, and the consumer protections that the acquiring institution's program may require.
On-chain reissuance
A new transaction is initiated to return stablecoin to the customer. Requires the customer to maintain a stablecoin wallet. In practice, this limits usability for mainstream consumer-facing merchants.
Verification requirement: Confirm this mechanism is documented and operationally viable at volume.
Fiat reimbursement
The merchant processes a refund in fiat currency to the customer's bank account or card. This is the more common structure for merchants whose customers paid in stablecoin but do not hold stablecoin wallets.
Verification requirement: Confirm which entity funds and processes the fiat refund, the timeline, and whether this is disclosed to the customer at point of sale.
Account credit
The refund is applied as a credit to the customer's account balance with the merchant, to be used for future transactions. This structure may not satisfy consumer protection obligations in all jurisdictions, particularly for merchants not operating a stored value arrangement.
Verification requirement: Assess whether this mechanism is compliant with consumer protection requirements in the merchant's operating jurisdiction.
What to Request
Red Flags
Why it matters: Stablecoin transactions can involve wallet addresses linked to sanctioned entities, jurisdictions, or individuals. The partner's sanctions compliance program does not automatically satisfy the acquiring institution's obligations. OFAC has confirmed that US persons and financial institutions have obligations that extend to virtual currency transactions and that ignorance of a counterparty's sanctions status does not provide a complete defense.
Source: OFAC Sanctions Compliance Guidance for the Virtual Currency Industry (October 2021)
Wallet address screening
Wallet addresses involved in the transaction should be screened against OFAC's SDN (Specially Designated Nationals and Blocked Persons) list, OFAC's sectoral sanctions lists, and equivalent lists under other applicable regimes.
What to verify: Whether screening is conducted at transaction initiation (real-time) or on a delayed/batch basis. Real-time screening is required to prevent prohibited transactions from completing.
Counterparty entity screening
Where the merchant's customer is an identifiable entity (business or individual with KYC on file), that entity should be screened against sanctions lists independently of wallet screening.
What to verify: Whether the partner conducts entity-level screening in addition to wallet-level screening, and what the screening methodology is.
Jurisdictional screening
OFAC maintains comprehensive sanctions programs against specific countries (for example, Iran, North Korea, Russia, Cuba, Syria). Transactions involving wallet addresses or counterparties associated with sanctioned jurisdictions require additional assessment.
What to verify: Whether the partner screens for jurisdiction-level exposure, not solely against named individuals and entities.
Escalation and reporting
When a sanctions alert is generated, there must be a documented process for blocking the transaction, escalating internally, and reporting to the relevant authority where required.
What to verify: Who receives the escalation, what the response timeline is, and how outcomes are documented.
What to Request
Red Flags
Why it matters: Consumer protection obligations depend on jurisdiction, payment instrument, and the structure of the merchant's business. Stablecoin payments are not uniformly covered by card scheme chargeback rights or by national consumer protection statutes. The gap between what a customer expects to be able to dispute and what mechanism is actually available can be significant, and that gap creates exposure for the acquiring institution.
Merchant-managed disputes
The merchant handles disputes directly, applying a documented internal process. The stablecoin partner is not involved in the dispute adjudication.
Verification requirement: Review the merchant's dispute policy for stablecoin transactions. Confirm it is disclosed at point of sale and operationally implemented.
Partner-managed disputes
The stablecoin partner adjudicates disputes on behalf of the merchant. This is common in arrangements where the partner has a more developed compliance infrastructure.
Verification requirement: Confirm the partner's dispute procedure is contractually documented, that the merchant agrees to its terms, and that outcomes are communicated to customers in writing.
Hybrid or undefined
No clear assignment of dispute responsibility. We see this frequently in arrangements where the stablecoin integration was operationalized before the compliance structure was formalized.
Verification requirement: Treat as disqualifying until responsibility is documented in writing.
What to Request
Red Flags
A well-controlled stablecoin payment arrangement includes each of the following elements. We use this profile as an evaluation benchmark when reviewing merchant submissions.
There is a written agreement between the merchant and the stablecoin processing partner that specifies which entity is responsible for each of the following:
The acquiring institution should be able to obtain this agreement, or a summary of its material provisions, at onboarding and at each subsequent periodic review. Verbal representations from the merchant about what the partner "handles" are not a substitute for the written record.
The acquiring institution should have a documented right to audit the stablecoin partner's compliance program, or to receive periodic third-party assurance reports. Where direct audit rights are not available, the program should document this limitation and specify what compensating evidence exists: SOC 2 Type II reports, regulatory examination results, or equivalent third-party assessments.
Programs that have no audit mechanism for the stablecoin partner are accepting an unquantified compliance dependency with no independent validation.
The merchant's stablecoin payment volume should be included in their transaction monitoring profile. This means the monitoring scope covers:
Transaction monitoring limited to the fiat settlement leg has a structural blind spot for risks that materialize on-chain before conversion. This is a common configuration gap.
The merchant's program should include documented escalation procedures covering at minimum:
The acquiring institution should have a named contact at the stablecoin partner, a defined communication protocol, and a documented response time commitment for compliance-related inquiries.
Assuming the Partner's License Equals Merchant Compliance
This is the most frequent gap we observe. A licensed VASP or regulated crypto payments processor has obligations under its own authorization. Those obligations may not align with, or fully satisfy, the acquiring institution's obligations under card scheme rules, applicable financial regulations, or internal risk policy.
A partner license answers the question: is this entity authorized to operate in this jurisdiction? It does not answer the question: does this merchant's specific payment activity comply with our program requirements?
We typically advise risk teams to treat partner credentials as the starting point for due diligence, not as a conclusion. The license tells you the partner is supervised. It does not tell you what controls apply to this merchant's activity under the partner's program, or whether those controls meet your standards.
Incomplete Settlement Path Documentation
We have seen arrangements where the stated settlement path was accurate but materially incomplete: intermediary wallets or custodians were not disclosed in documentation provided at onboarding. This creates gaps in sanctions screening coverage and breaks the chain of fund accountability required for a defensible compliance record.
Settlement path documentation should be verified against actual transaction data where possible. Merchant representations about settlement flow are a starting point, not a verified fact.
Transaction Monitoring Configured Only for Fiat Settlement
Programs that configure transaction monitoring exclusively for fiat settlement activity will not capture risks that occur on-chain before conversion. Wallet address risk, transaction clustering, layering signals, and jurisdiction exposure are categories of risk that require visibility into on-chain activity.
Where a transaction monitoring system does not have on-chain data feeds, this is a structural monitoring gap. It should be identified, documented, and addressed through compensating controls or partner data sharing, not treated as acceptable because the fiat leg appears clean.
Undefined or Non-Compliant Consumer Recourse
In many arrangements we review, the dispute and refund process applicable to stablecoin payments is undocumented, inconsistent with the merchant's general terms of service, or structured in a way that would not satisfy consumer protection requirements in the merchant's operating jurisdiction.
This is particularly relevant in jurisdictions where regulatory authorities have extended consumer protection oversight to digital payment instruments. The acquiring institution's exposure is not limited to chargebacks. Where a merchant's dispute process is inadequate, the acquiring institution may face regulatory inquiry about the adequacy of its merchant oversight program.
No Documented Escalation Path for Compliance Issues
We have seen compliance structures where the merchant had a sanctions policy and the partner had a sanctions policy, but no one had documented what happens when a sanctions issue arises: who contacts whom, in what timeframe, and what action is taken. This gap does not become visible during normal operations. It becomes visible at exactly the moment a sanctions issue arises.
Escalation documentation is not administrative overhead. It is the mechanism that determines whether the compliance program functions under pressure.
When a merchant presents a stablecoin arrangement supported by a regulated partner, there is one question that determines the quality of your evaluation:
Do you underwrite the partner, or the merchant's actual controls?
Partner credentials are a necessary input. They are not a substitute for reviewing the contractual structure, the settlement path, the sanctions program, the dispute process, and the monitoring coverage that applies to this specific merchant's activity.
Risk teams that treat a partner's license as a compliance pass-through are underwriting the partner's status, not the merchant's behavior or obligations. Those are two distinct objects of review. Conflating them is where oversight gaps arise and where regulatory and scheme exposure accumulates.
The controls that matter are the ones that apply to this merchant, in this arrangement, under this contract. The verification framework in this guide is designed to surface exactly those controls and to identify where they are absent, incomplete, or not adequately documented.
Stablecoin payment arrangements introduce a structural separation between the technical rail and the compliance ownership. That separation is not inherently problematic; it exists in many payment models. What makes it manageable is documentation: clear written allocation of responsibilities, audit-ready settlement path records, real-time sanctions controls with documented escalation, and a dispute mechanism that is both operable and disclosed.
Where that documentation exists, the acquiring institution can evaluate the arrangement against its program standards and make a defensible decision. Where it does not exist, the institution is accepting undocumented dependencies in its compliance chain.
The evaluation question is not whether stablecoin payments are permissible under the program. It is whether the specific controls in place for this merchant's stablecoin activity meet the same standard you would apply to any other payment structure.
Ballerine builds AI-powered merchant underwriting and ongoing monitoring infrastructure for acquirers, PSPs, PayFacs, marketplaces, BIN sponsors, and banks. Our platform supports compliance and risk teams in documenting merchant oversight, evaluating complex payment arrangements including stablecoin and crypto-adjacent structures, and producing defensible evidence for scheme inquiries and regulatory review.
We build toward what we describe as agentic underwriting: AI-assisted workflows that collect evidence, navigate gated content, surface wallet and counterparty risk signals, and route cases for human review with structured rationale. For programs managing stablecoin merchant exposure at scale, this translates to consistent evidence collection, configurable monitoring rules, and governance tooling designed to hold up under scrutiny.
Ballerine is a Mastercard MMSP (Mastercard Merchant Monitoring Service Provider) certified partner.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.png)
