Sub-Merchant Liability and Risk Exposure in PayFac Models

A payment facilitator that decides to become a master merchant is making a specific, irreversible choice: it is agreeing to sit between the card networks and every business it onboards, and to answer for what those businesses do. That's the whole model. The PayFac is the entity that holds the acquiring agreement, accepts liability for card transactions on behalf of everyone underneath it, and gets registered with Visa and Mastercard as such, a formal scheme-designation. It's the entity that holds the acquiring agreement, accepts liability for card transactions on behalf of everyone underneath it, and gets registered with Visa and Mastercard as such, a formal scheme-defined role with its own set of obligations, not an arrangement anyone backs into casually.

The structure runs three tiers deep. An acquirer sits at the top, the PayFac holds a pooled master merchant account in the middle, and sub-merchants sit at the bottom, processing under the PayFac's agreement rather than one of their own. Money moves from the acquirer down to the PayFac, and the PayFac then decides how and when to pay out to each sub-merchant on its own schedule. Compare that to an ISO, which simply introduces merchants to an acquirer and walks away from any ongoing transaction liability once the introduction is made. A PayFac can't walk away. It holds the agreement, so it holds the exposure, for as long as that sub-merchant processes a single transaction.

Where liability sits across the three tiers

The PayFac's job starts with due diligence and underwriting on every sub-merchant it brings on, and it doesn't end there. It has to run ongoing transaction monitoring for fraud and compliance issues, and it carries chargeback and scheme-violation liability for the entire portfolio, including the merchants that happen to be causing trouble this month.

The sponsor bank sits above that, and its position is different in kind. It keeps ultimate regulatory responsibility, the authority to audit the PayFac's underwriting program whenever it wants, and the power to review any high-risk merchant approval, impose restrictions on the portfolio, or simply end the relationship if it doesn't like what it sees.

Sub-merchants, for their part, still carry full liability for their own chargebacks, disputes, taxes, and fraud losses. But they operate inside the PayFac's risk rules, not their own. A PayFac can impose a hold, raise a reserve, or terminate a merchant based on portfolio-level metrics that have nothing to do with that specific merchant's individual behavior. Risk aggregates at the PayFac level. A single sub-merchant's chargeback spike doesn't stay contained to that merchant. It feeds into a portfolio-wide ratio that the acquirer and the card networks are watching, and everyone underneath that PayFac shares in the consequences of that number moving the wrong way.

How chargeback exposure compounds at portfolio scale

Run the math on a mid-size PayFac processing $50 million a month across 500 sub-merchants at a 1.2% chargeback rate, and that's $600,000 in monthly chargeback exposure sitting on the books. That's $600,000 in monthly chargeback exposure sitting on the books. If reserves aren't sized to cover it, or if the PayFac has already distributed those funds down to sub-merchants before the disputes land, that liability doesn't just disappear. It transfers up to the acquirer.

That's a fundamentally different risk shape than traditional merchant underwriting. A standalone merchant gets evaluated on its own history and its own numbers. A PayFac's acquirer is evaluating the behavior of the entire book at once. One bad vertical, one poorly vetted segment, one merchant category that runs hot on disputes, can drag down the metrics for every well-behaved merchant sitting next to it in the portfolio.

Visa formalized this concern in April 2025 with the Visa Acquirer Monitoring Program, or VAMP, which folds five previously separate fraud and dispute programs into one framework. VAMP produces direct accountability: it holds acquirers and the payment platforms underneath them responsible for how the whole portfolio performs on fraud and disputes, including how individual merchants perform. The hard number in that framework is a 0.9% dispute threshold for acquirers, effective the same month VAMP launched. Cross it, and the fines that follow don't stay with the acquirer. They flow downstream, landing hardest on whichever merchant categories are driving the dispute rate up.

Fraud and AML obligations that begin at onboarding and never end

A separate compliance obligation never really turns off: verifying who a merchant actually is, and continuing to check that periodically for as long as the relationship lasts. The framework usually gets described in three layers. KYC verifies the natural persons involved, owners and authorized signers. KYB verifies the legal entity itself and its ownership structure. KYM takes both of those checks and applies them specifically to a payments relationship, adding a layer of review around storefront fit, payout risk, underwriting, merchant category code assessment, and ongoing monitoring once the account is live.

The verification stack behind that runs through identity databases, OFAC sanctions lists, and the card networks' own MATCH list, layered with automated risk models that weigh business type, expected processing volume, industry-level chargeback rates, and signals from a merchant's online presence.

None of this is optional or discretionary. The Bank Secrecy Act and the AML rules built on top of it require financial institutions to identify and verify legal entity customers, including their beneficial owners. FinCEN's Beneficial Ownership Rule adds a reporting requirement for beneficial ownership information covering most domestic entities. The scale of monitoring this regulatory environment expects isn't abstract, either: financial institutions filed 4.7 million suspicious activity reports in fiscal year 2024 alone. That's the volume of activity the system is built to catch, and it's the baseline a PayFac's own compliance program gets measured against.

Onboarding quality as a direct risk control, beyond a conversion metric

Most PayFacs run a tiered approval system, sorting merchants by risk profile. Low-risk categories, retail, software, professional services, tend to clear automatically. Higher-risk profiles get flagged for manual review, or declined. That sorting decision is itself a risk control, arguably the first one that matters, because everything downstream depends on getting it right.

Watchlist matches, the kind that flag a name against a sanctions list or an adverse media hit, turn out to be cases of mistaken identity up to 95% of the time. Watchlist matches, the kind that flag a name against a sanctions list or an adverse media hit, turn out to be cases of mistaken identity up to 95% of the time, so a blunt name match is only a weak signal on its own. It's a compliance process that needs intelligent triage behind it, or it turns into a friction factory that blocks legitimate merchants for no good reason.

That's part of why step-up KYC agents built on one model are gaining ground, reviewing documentary data alongside device and behavioral signals to resolve an ambiguous watchlist hit without routing every single flag into manual review. The cost of getting this wrong in the other direction, over-screening every borderline case, is measurable: slow, manual onboarding is estimated to cost platforms $250 per applicant in lost conversion. Onboarding friction is a cost for the merchant stuck waiting. It's a line item.

The controls that contain ongoing sub-merchant risk

Underwriting a merchant once at onboarding tells a PayFac almost nothing about what that merchant looks like eighteen months later. Ongoing transaction monitoring has to flag volume spikes, structuring patterns, and chargeback rates that stop matching what the merchant said its business would look like when it applied. The monitoring program needs a clear line between what triggers an automated response, a hold, a reserve increase, and what gets escalated to a human compliance analyst for review. Blur that line and either everything gets flagged or nothing does.

Reserves function as the financial backstop. Rolling reserves, upfront reserves, and capped reserves each create a different liquidity squeeze for the sub-merchant holding them, and the PayFac's choice of reserve structure is both a risk management tool and a variable in how that merchant relationship actually feels day to day. Reserve terms typically get negotiated individually, based on the business's age, its dispute history, the product it sells, and its processing volume. The PayFac is exercising real discretion here, and that discretion carries its own risk implications.

Velocity limits and per-merchant transaction caps do similar work from a different angle, capping how much exposure a single sub-merchant can generate before a review has a chance to catch a problem in progress. And when a sub-merchant gets terminated for cause and meets the qualifying criteria under Mastercard's rules, reporting that merchant to the MATCH list isn't discretionary. The PayFac's acquirer is required to do it. That has consequences for the terminated merchant's ability to find another processor, and it has consequences for the PayFac's own compliance record.

The state-level regulatory patchwork that is adding new compliance surface area

Absent a single federal framework, states have started writing their own payment rules, and the result is a patchwork that any acquirer, ISO, or PayFac with merchants spread across multiple states now has to track state by state.

Louisiana's Act 751 takes effect August 1, 2026, and bans merchants from surcharging customers who pay with a debit card, whether by PIN, a tap, or a signature. Consumers who get surcharged anyway can seek a refund, and if the merchant refuses, they can take it to court, which opens a real class-action exposure for any merchant that gets this wrong at the point of sale.

Illinois has been fighting over its Interchange Fee Prohibition Act for a while now. The law would exclude tips and sales taxes from interchange fee calculations starting July 1, 2027, a date that's already been pushed back twice, first from 2025 to 2026, then again to 2027, after sustained lobbying and litigation from banks and credit unions. A federal district court ruled in June 2026 that national banks, out-of-state state-chartered banks, federal savings associations, and the card networks themselves aren't bound by the law, and merchants are appealing that ruling now.

Alabama's Senate Bill 221, signed by Governor Kay Ivey, takes effect September 1, 2026, and addresses how merchants may apply surcharges when a customer pays by credit card, creating compliance questions for processors whose systems currently have no way to separate the relevant transaction components out.

Pennsylvania has similar legislation that's cleared a state House committee but still needs a full House vote, a state Senate vote, and the governor's signature, so its status is unconfirmed. New Jersey appears to have momentum building toward an Illinois-style interchange law, though nothing there has been formally announced.

The practical upshot for a national processor, or an ISO with merchants scattered across a dozen states, is that it needs real monitoring capacity, because each state is drawing its own legal lines in its own place. For a PayFac specifically, a sub-merchant's surcharging practice that's perfectly legal in one state can create liability in another. The platform's acceptable use policy and its onboarding documentation have to reflect that variation rather than assuming one national rulebook applies everywhere.

How PayFac-as-a-Service changes the liability distribution without eliminating it

Full PayFac registration is not a fast or cheap path. It typically takes twelve to eighteen months and a meaningful amount of capital, and platforms that choose to build the infrastructure themselves often spend twelve to twenty-four months doing it, with development costs that can exceed $1,000,000 before the first transaction ever runs.

PayFac-as-a-Service splits that burden differently. The infrastructure provider takes on the sponsor bank relationship, the regulatory compliance work, the reporting, and the processing infrastructure, while the platform keeps control over merchant pricing, the onboarding experience, and the day-to-day merchant relationship.

What that split doesn't do is make the underlying liability disappear. The platform is still the distribution layer for sub-merchants whose transaction behavior feeds directly into the master account's portfolio metrics, whoever technically holds that master account. Acceptable use policy violations, onboarding failures, gaps in monitoring, these still generate real liability events, because the infrastructure partner manages the bank relationship, but the platform's own conduct determines what actually flows through that relationship. State-level rules on surcharging and tax treatment apply to whichever merchants the platform brings on, regardless of whose name sits on the scheme registration.

The scheme registration and the direct acquirer relationship belong to the PFaaS provider, the sponsor bank's audit attention lands on the provider's underwriting program rather than the platform's own, and the time it takes to get from decision to live merchants compresses from many months down to a matter of weeks. That's a real shift in who answers to whom. It is not a shift in whether the platform's choices still carry weight.