Who is responsible for what
Understanding the technical architecture of payments explains how messages route and how funds clear. However, examining payments through a regulatory and legal lens reveals an entirely different set of operational realities. In financial services, legal obligations do not distribute uniformly across technical vendors; they concentrate heavily upon whichever entity takes custody of consumer funds and whichever institution holds licensed status.
Four core regulatory responsibilities govern commercial transactions: validating that businesses are authentic and managed by verified individuals; continuously monitoring transactions for indicators of financial crime; obtaining proper regulatory licenses to hold third-party funds; and serving as the legal entity of record for consumer consumer contracts, refunds, and tax filings.
While an organization can outsource processing infrastructure to technology providers, it cannot contractually transfer statutory regulatory liability if it acts as the regulated principal.
Regulatory compliance framework
The primary obligations governing payment ecosystems originate from statutory financial legislation rather than internal card scheme rulebooks:
| Regulatory obligation | Operational description | Authoritative regulatory source |
|---|---|---|
| Merchant underwriting | Evaluating business legitimacy and financial creditworthiness | Card scheme rules and acquiring risk policies |
| KYB and KYC compliance | Verifying corporate entity registration and identifying ultimate beneficial owners | Anti-Money Laundering (AML) and counter-terrorist financing statutes |
| Sanctions screening | Verifying transacting parties against governmental watchlists (e.g. OFAC) | National sanctions regulations (strict liability enforcement) |
| Transaction monitoring | Analyzing payment velocities and flows to identify money laundering patterns | Statutory AML reporting mandates |
| Client fund custody licensing | Legally holding and safeguarding funds belonging to third parties | Money Transmission Licensing (US) / Payment Institution Licensing (UK/EU) |
| Operating as Merchant of Record | Assuming legal responsibility for the sale, customer warranty, and tax remittance | Consumer protection statutes and corporate sales tax legislation |
| PCI DSS compliance | Safeguarding cardholder data environments against unauthorized compromise | Payment Card Industry Security Standards Council mandates |
Notice that only merchant underwriting and PCI DSS compliance are defined internally by card networks. All other obligations stem from federal and international financial regulations, which is why acquiring banks enforce compliance controls far more strictly than purely technical API providers.
Distribution of regulatory obligations across entities
| Regulatory duty | Technical Gateway | Payment Processor | Aggregator (PSP) | Payment Facilitator (PayFac) | Licensed Acquirer |
|---|---|---|---|---|---|
| Merchant underwriting | None | None | Internal, bounded by acquirer | Full liability for sub-merchant losses | Ultimate statutory liability |
| KYB and KYC execution | None | None | Required on direct merchant | Required on all sub-merchants | Required on all sponsored merchants |
| Sanctions screening | None | None | Mandatory | Mandatory | Mandatory |
| Anti-money-laundering monitoring | None | None | Mandatory | Mandatory | Mandatory |
| Client funds custody | None | None | Transitory custodial holding | Custodial holding of sub-merchant funds | Licensed banking custody |
| Merchant of Record designation | Never | Never | Typically the merchant | Platform or sub-merchant | Merchant |
Because a pure gateway only encrypts and routes digital messages without touching capital, anti-money laundering statutes impose zero onboarding or transaction monitoring duties upon it. Conversely, the moment a platform receives, holds, or disburses funds belonging to commercial sellers, comprehensive custodial licensing and monitoring requirements activate immediately.
Onboarding diligence: KYB, KYC, and beneficial ownership
Before an entity can process electronic transactions, the underwriting institution executes Know Your Business (KYB) checks to verify that the corporate entity exists in good standing, holds an authentic business address, maintains legitimate commercial banking relationships, and operates within the bounds of its declared MCC.
Concurrently, Know Your Customer (KYC) regulations require identifying the natural persons behind the corporation—specifically executive directors and any beneficial owner (an individual who directly or indirectly owns or controls a equity stake exceeding statutory thresholds, typically 25%). Underwriting requires submitting official articles of incorporation, proof of operating address, corporate bank statements, and government identity verification for all primary controllers.
Continuous compliance: sanctions, AML monitoring, and SAR filings
Onboarding verification establishes an initial baseline, but compliance obligations operate continuously across all active transaction traffic:
- Sanctions screening: Every participant in a transaction—including cross-border payees and marketplace sellers—must be screened against national and international sanctions lists (such as the US Office of Foreign Assets Control or EU consolidated sanctions lists). Sanctions violations carry strict liability, meaning payment providers will freeze transactions immediately upon a phonetic or name match.
- Transaction monitoring: Automated monitoring platforms analyze transaction streams for structural anomalies indicative of money laundering, including structured smurfing, abnormal velocity bursts, high refund ratios, or atypical cross-border transfers.
- Suspicious Activity Reports: When monitoring models detect patterns characteristic of illicit finance, the regulated institution is legally required to file a formal suspicious activity report (SAR) with financial enforcement authorities (such as FinCEN in the US or the NCA in the UK).
- Statutory non-disclosure ("tipping off"): In nearly all jurisdictions, federal statutes strictly prohibit regulated financial institutions from disclosing to an account holder that a SAR has been filed or that a law enforcement inquiry is underway. When a payment provider freezes an account and customer support refuses to explain the underlying cause, this silence is often legally mandated rather than a service failure.
Client fund custody and safeguarding mandates
When an e-commerce platform or marketplace collects payments from buyers and subsequently disburses funds to independent third-party sellers, the platform is engaged in financial custody. In the United States, receiving money for transmission requires obtaining Money Transmitter Licenses (MTLs) across individual states. In the United Kingdom and European Union, it requires authorization as an Authorized Payment Institution (API) or Electronic Money Institution (EMI).
Licensed entities must comply with strict safeguarding regulations. Safeguarding mandates that all client funds be kept completely segregated from the platform's own corporate operating capital in dedicated trust accounts at regulated credit institutions. This legal segregation ensures that if the platform becomes insolvent, merchant funds remain fully shielded from corporate creditors.
Marketplaces and software platforms can navigate custody obligations through three architectural paths:
- Split settlement at the processor level: Designing payment flows so the payment processor routes the seller's proceeds directly to the seller's bank account while routing the marketplace's commission separately. Because marketplace corporate accounts never touch seller funds, custodial licensing obligations are avoided.
- PayFac-as-a-Service integration: Partnering with a licensed payment facilitator that assumes regulatory onboarding, KYC verification, and fund safeguarding duties on behalf of platform sellers.
- Direct institutional licensing: Acquiring direct Money Transmitter or Payment Institution licenses—a complex multi-year regulatory endeavor requiring significant regulatory capital reserves and dedicated compliance operations.
The Merchant of Record designation
The merchant of record (MoR) is the specific legal entity whose name appears on the cardholder's statement, and which holds the primary legal relationship with the consumer under commercial law. The MoR is legally responsible for:
- Executing the commercial contract of sale with the buyer.
- Processing refunds and handling consumer warranty claims.
- Calculating, collecting, and remitting local sales tax, VAT, or GST across jurisdictions.
- Absorbing financial liabilities from chargebacks and card scheme penalties.
On multi-vendor platforms, selecting who serves as Merchant of Record represents a fundamental strategic decision:
- Where individual sellers act as Merchant of Record, the sellers assume primary dispute liabilities and tax remittance obligations, but the platform must navigate complex payout and fund custody architectures.
- Where the platform acts as Merchant of Record, the platform delivers a unified customer checkout experience and manages global sales tax centrally, but directly assumes all chargeback risks and consumer refund liabilities across every seller on its marketplace.
Determine legal and custodial boundaries before selecting an integration architecture.
- Identify the exact legal entity designated as the Merchant of Record for every transaction flow.
- Confirm which entity maintains legal custody of customer balances, verifying appropriate licenses.
- Establish which organization is contractually responsible for executing KYB and KYC diligence on sellers.
- Document the platform's contingency procedures if a processor imposes risk holds or compliance freezes.
Terms introduced
- Underwriting: deciding whether a merchant may trade and pricing the risk of it, done by whoever will carry the loss.
- Know your business: the checks that establish what a company is and what it does. Often shortened to KYB.
- Know your customer: the checks that establish who the people behind a business are. Often shortened to KYC.
- Beneficial owner: an individual who ultimately owns or controls a business, above a threshold set in law.
- Sanctions screening: checking parties against government lists, at onboarding and on every payment.
- Transaction monitoring: watching payments for the patterns that indicate laundering.
- Suspicious activity report: the filing a regulated entity makes when a pattern looks like financial crime, which it is usually forbidden from telling you about. Often shortened to SAR.
- Safeguarding: holding client funds separately from your own, so they survive your insolvency.
How providers do it
Regulatory and operational responsibilities—including merchant underwriting, Know Your Customer (KYC) screening, sanctions monitoring, PCI DSS validation, and chargeback exposure—are allocated according to a provider's legal role rather than its marketing branding.
Where a provider acts solely as a technology gateway, compliance obligations and financial liabilities remain entirely with the merchant. When a provider acts as an acquirer or payment facilitator, it assumes direct regulatory oversight and enforces compliance rules on its merchants.
| Provider | Operational role | Legal merchant of record | Status |
|---|---|---|---|
| Stripe | Full-stack Payment Service Provider (PSP) | The merchant business entity | confirmed |
| Stripe Connect | Multi-party platform orchestrator | Configured dynamically based on charge type (Direct, Destination, or Separate) | confirmed |
| Adyen | Direct merchant acquirer and processor | The merchant business entity | confirmed |
| Worldpay Express | Payment gateway service | The merchant business entity | unconfirmed |
| Payrix | Payment-Facilitator-as-a-Service infrastructure | Typically the platform acting as master payment facilitator | unconfirmed |
| Global Payments | Traditional merchant acquirer | The merchant business entity | unconfirmed |
| Braintree | Payment Service Provider (PSP) | The merchant business entity | unconfirmed |
| Checkout.com | Direct merchant acquirer | The merchant business entity | unconfirmed |
| Square | Payment Facilitator (PayFac) aggregating merchants | Square operates as master merchant of record on network rails | unconfirmed |
| Fiserv | Core payment processor | The merchant business entity | unconfirmed |
Underwriting rigour and AML/sanctions screening follow the operating role: acquirers and payment facilitators are legally obligated by card brand rules and federal banking regulators to verify beneficial ownership and monitor transactions for suspicious activity. Gateways, by contrast, pass data transparently without assuming financial settlement risk.
Two configurations require careful operational analysis:
- Stripe Connect: Allows platforms to choose their charge architecture. Selecting an inappropriate charge model can inadvertently transfer seller chargeback debts and fraud liabilities onto the platform's balance sheet.
- Payrix: Designed for platforms becoming registered payment facilitators. The division of KYC underwriting duties, fraud reserves, and compliance oversight varies significantly based on whether the platform operates on a fully sponsored, managed, or self-directed program tier.
- Stripe
- Stripe Connect
- Adyen
- Worldpay Express
- Payrix
- Global Payments
- Braintree
- Checkout.com
- Square
- Fiserv
What they are: a PSP. A merchant on Stripe sits inside Stripe's acquiring relationship rather than holding one of its own, so every duty on this page that follows custody of funds is Stripe's.
| Duty | Whose | Status |
|---|---|---|
| Underwriting the merchant | Stripe's, against its own risk policy | confirmed |
| KYB and KYC on the merchant | Stripe's. The merchant supplies the documents; Stripe decides | confirmed |
| Sanctions screening and transaction monitoring | Stripe's | confirmed |
| Holding funds, and the licence for it | Stripe's | confirmed |
| Merchant of record | The merchant's. It sells to the customer, and owes the refund and the tax | confirmed |
| PCI scope | The merchant's, and small only while no card number reaches its servers | confirmed |
| Question | Answer | Status |
|---|---|---|
| What triggers a risk review, and what is the merchant told? | unconfirmed; expect little, for the reason the core page gives | |
| How much notice comes before an account action? | unconfirmed | |
| What do they need when the business changes what it sells? | unconfirmed; tell them before it changes, not after |
Last verified: never.
What they are: the layer where these duties get allocated. Connect makes the split configurable, and the configuration is a compliance decision that an engineer usually makes while wiring up onboarding.
Two settings on a connected account carry most of it: who collects the account's requirements, and who is liable when that account goes negative.
| Setting | If Stripe takes it | If the platform takes it | Status |
|---|---|---|---|
| Collecting requirements | Stripe hosts or embeds the onboarding, handles the flow logic, and keeps up with changing verification rules | The platform builds and maintains every onboarding flow, and re-checks the requirements as they change | confirmed |
| Liability for negative balances | Stripe monitors risk signals, intervenes on accounts, emails sellers on the platform's behalf, and seeks to recover | The platform reviews every new seller, monitors for ongoing risk, and builds the remediation flows. The loss is the platform's | confirmed |
Taking API onboarding is not only an integration choice. Stripe's own documentation pairs it with full platform responsibility for negative balances, so a decision made for the sake of a smoother signup form moves the losses onto the platform.
| Question | Answer | Status |
|---|---|---|
| Which setting is each account type on? | unconfirmed; answer this before anything else on the page | |
| Who is the merchant of record for a seller's sale? | The charge type decides it. See funding and merchant and cardholder | confirmed |
| Can the dashboard type change later? | No. It is fixed when the account is created, and changing it means a new account | confirmed |
| Is there an operational team to run risk, where the liability sits with the platform? | unconfirmed; the honest answer decides the setting | |
| Who screens sellers against sanctions lists? | Stripe, as the licensed party | unconfirmed per configuration |
Where to look
The connected account's controller configuration is the record of what was chosen, whatever the onboarding code appears to do.
Last verified: 2026-09-09 against Stripe's public Connect documentation.
What they are: the acquirer, and a licensed bank in the EU, the UK and the US. There is no split to negotiate on a merchant's own volume. Adyen holds the licence, and the duties that follow custody are Adyen's.
| Duty | Whose | Status |
|---|---|---|
| Underwriting the merchant | Adyen's, as the acquirer | confirmed |
| KYB and KYC on the merchant | Adyen's | confirmed |
| Sanctions screening and transaction monitoring | Adyen's | confirmed |
| Holding funds, and the licence for it | Adyen's, under its own banking licences in the EU, the UK and the US | confirmed |
| Merchant of record | The merchant's | confirmed |
Their platform product changes the shape of this. A platform onboarding sellers collects verification data on each one and passes it over. The duty to verify stays with Adyen. The work of collecting it moves to the platform.
| Question | Answer | Status |
|---|---|---|
| Is the platform product in use for seller payouts? | unconfirmed | |
| If so, what data must be collected per seller, and who chases a seller who will not supply it? | unconfirmed | |
| In markets where Adyen is not the licensed acquirer, who is? | unconfirmed; ask per country |
Last verified: 2026-09-09 against Adyen's public documentation.
What they are: a gateway and processing platform. On the layer table that puts them in the two columns that owe almost nothing, which is the practical point of this tab.
| Duty | Whose | Status |
|---|---|---|
| Underwriting the merchant | The acquirer behind the platform, not the gateway | unconfirmed; the acquiring entity is worth identifying |
| KYB and KYC on the merchant | The acquirer's | unconfirmed |
| Sanctions screening and transaction monitoring | The acquirer's | unconfirmed |
| Holding funds | Not the gateway's. Whoever settles holds them | unconfirmed |
| Merchant of record | The merchant's, which holds its own merchant account | unconfirmed |
Because these sit with the acquirer rather than with the integration, a compliance question raised with Express support usually cannot be answered there. Find the acquiring entity and ask it directly.
| Question | Answer | Status |
|---|---|---|
| Which entity underwrites the merchant behind Express? | unconfirmed | |
| Who is notified when the business changes what it sells? | unconfirmed; the acquirer needs to know, and the gateway does not care |
Last verified: never.
What they are: the party carrying the facilitator's duties on a platform's behalf, which is the whole product. The engagement model decides how much of that is genuinely theirs.
In Payrix's own terms, a facilitator is the partner that assumes the risk and underwriting liabilities of the PayFac business, and a partner offers those capabilities on to merchants. Where a platform sits in that chain decides which column of the table below applies to it.
| Duty | PayFac-as-a-service | Registered PayFac model | Status |
|---|---|---|---|
| Underwriting a seller | Worldpay's, and the losses are theirs | The platform's, and the losses are the platform's | unconfirmed; find which model the contract names before reading the rest of this table |
| KYB and KYC on a seller | Theirs to decide. The platform collects, in most integrations | The platform's, end to end | unconfirmed |
| Sanctions screening and monitoring | Theirs | The platform's, under its own permission | unconfirmed |
| Holding seller funds | Theirs | The platform's, with the licence and safeguarding that implies | unconfirmed |
| Merchant of record | Usually the facilitator | Usually the platform | unconfirmed |
| Question | Answer | Status |
|---|---|---|
| Which model does the contract name? | unconfirmed; every row above depends on it | |
| Can a platform overrule a decline on a seller it wants? | unconfirmed; under PayFac-as-a-service, expect not | |
| What may a seller be told when its onboarding is refused? | unconfirmed; ask what disclosure is permitted, because a refusal a platform cannot explain still has to be explained to the seller | |
| Moving to the registered model would mean building what? | unconfirmed; underwriting, monitoring, and a compliance function, at minimum |
Answer the first row before quoting a seller anything. The rest of this tab is unreadable without it.
Last verified: 2026-09-09 against Payrix's public resource centre.
What they are: an acquirer, so the duties that follow the licence are theirs and the merchant relationship is direct.
| Duty | Whose | Status |
|---|---|---|
| Underwriting the merchant | Theirs, as the acquiring bank | unconfirmed; which entity in the group holds it is worth confirming |
| KYB and KYC on the merchant | Theirs | unconfirmed |
| Sanctions screening and transaction monitoring | Theirs | unconfirmed |
| Holding funds | Theirs, until funding reaches the merchant | unconfirmed |
| Merchant of record | The merchant's | unconfirmed |
One wrinkle comes from how they are sold. Where the contract runs through a reseller or a bank partner rather than directly, the party that underwrote the merchant may not be the party whose name is on the software.
| Question | Answer | Status |
|---|---|---|
| Is the contract direct, or through a reseller? | unconfirmed | |
| Which legal entity underwrote each MID? | unconfirmed | |
| Since the Worldpay merger, has the underwriting entity changed? | unconfirmed |
Last verified: never.
What they are: a gateway and PSP owned by PayPal, which puts two sets of duties on one integration.
| Duty | Whose | Status |
|---|---|---|
| Underwriting the merchant | Braintree's, or the acquirer behind it, depending on the arrangement | unconfirmed |
| KYB and KYC on the merchant | Braintree's | unconfirmed |
| Sanctions screening and monitoring | Braintree's on card volume. PayPal's on PayPal and Venmo volume | unconfirmed |
| Holding funds | Whoever settles that payment method | unconfirmed |
| Merchant of record | The merchant's | unconfirmed |
The split on the third row is the thing to plan for. A PayPal-funded sale runs under PayPal's own rules and its buyer protection process, which is not a card chargeback and does not follow the dispute path this primer describes. One order can therefore be reviewed by two organisations under two rulebooks, with two outcomes.
| Question | Answer | Status |
|---|---|---|
| Which entity holds the merchant agreement? | unconfirmed | |
| Where do PayPal buyer-protection claims land, and who answers them? | unconfirmed | |
| Do those claims count anywhere in the card chargeback ratio? | unconfirmed |
Last verified: never.
What they are: an acquirer, so the licence and everything attached to it is theirs.
| Duty | Whose | Status |
|---|---|---|
| Underwriting the merchant | Theirs | unconfirmed |
| KYB and KYC on the merchant | Theirs, per legal entity | unconfirmed |
| Sanctions screening and transaction monitoring | Theirs | unconfirmed |
| Holding funds | Theirs, until funding reaches the merchant | unconfirmed |
| Merchant of record | The merchant's | unconfirmed |
Because they underwrite per entity, a group with several selling entities is several applications rather than one. Budget for that in a launch plan, since each entity is a fresh set of documents and a fresh decision.
| Question | Answer | Status |
|---|---|---|
| Which entities are onboarded, and which are not? | unconfirmed | |
| Where they do not hold the acquiring licence, who underwrites the merchant? | unconfirmed |
Last verified: never.
What they are: a payment facilitator, and the clearest example on this page of duties bought wholesale. A seller on Square gets working card acceptance in an afternoon because Square did the underwriting, holds the funds, and carries the loss.
| Duty | Whose | Status |
|---|---|---|
| Underwriting a seller | Square's | confirmed |
| KYB and KYC on a seller | Square's, at signup | confirmed |
| Sanctions screening and transaction monitoring | Square's | unconfirmed |
| Holding funds | Square's, until a deposit lands | confirmed |
| Merchant of record | unconfirmed; assume Square until the contract says otherwise | |
| Accurate description of what the seller sells | The seller's, always | confirmed |
What a seller gives up is the appeal. Everything above sits with one company, so a seller whose account is restricted has nobody else in the chain to escalate to. There is no acquirer of its own, and no separate gateway relationship to fall back on.
| Question | Answer | Status |
|---|---|---|
| What triggers a restriction, and how is it appealed? | unconfirmed | |
| How much of a seller's business must change before Square has to be told? | unconfirmed |
Last verified: never.
What they are: a processor, with acquiring supplied through bank partnerships. So the party that underwrote the merchant is often a bank whose name is nowhere in the integration.
| Duty | Whose | Status |
|---|---|---|
| Underwriting the merchant | The sponsoring bank's | unconfirmed; which bank is worth finding out |
| KYB and KYC on the merchant | The sponsoring bank's | unconfirmed |
| Sanctions screening and transaction monitoring | The sponsoring bank's, with Fiserv running much of the operation | unconfirmed |
| Holding funds | The sponsoring bank's | unconfirmed |
| Merchant of record | The merchant's | unconfirmed |
Bank-branded merchant services are frequently Fiserv underneath, so "who is the acquirer" and "who is the processor" have different answers here more often than anywhere else on this page. Both names are worth writing down while somebody knows them.
| Question | Answer | Status |
|---|---|---|
| Which bank sponsors each MID? | unconfirmed | |
| Who is notified about a change of business, the bank or Fiserv? | unconfirmed |
Last verified: 2026-09-09 against Fiserv's Commerce Hub developer documentation.