The compliance and counterparty-risk layer that envelops a working operation. Vendor diligence, processor and custodian review, stablecoin issuer assessment, KYB and sanctions posture, Travel Rule awareness, jurisdictional exposure mapping, and the documented approval workflow that converts ad-hoc vendor selection into an institutional process.
Scope Note · Educational and operational content — not legal, tax, accounting, financial, investment, or compliance advice · Verify current terms directly with each provider · Full disclaimers at module end
Compliance may be the most intimidating word in this course, so here is the reframe: this module is about being able to show your work. Banks, auditors and acquirers do not expect perfection — they expect a folder proving vendors were chosen carefully and obligations are understood. Most of that folder gets built calmly at vendor selection rather than under regulator pressure. The material stays practical, and it flags exactly where counsel should look before anything here is relied upon.
Module 05 produced an operable system — checkout discipline, support runbooks, refund policy, incident playbooks, operational metrics. This module produces the compliance and counterparty-risk layer that envelops that operation. It is the work that satisfies external parties — auditors, regulators, banking partners, acquirers, investors — that the operation is run as an institution, not as an experiment. It is also the work that prevents the most expensive failure modes in this space: vendor failure, regulatory drift, custody loss, and the slow accumulation of jurisdictional exposure that nobody notices until it is material.
Two SaaS operators expand into stablecoin payments over the same twelve-month window. Both close institutional financing rounds the following year. One closes in six weeks with a diligence checklist that the buyer's compliance team describes as "the cleanest crypto-payment file we've seen." The other closes in eleven weeks after a forensic vendor review that surfaces four undocumented dependencies, two unmapped jurisdictions, and a single-signer custody arrangement that the buyer requires to be restructured as a closing condition.
Operator A kept a single living compliance folder from week one: approved vendor list with documentation, stablecoin acceptance policy, jurisdictional exposure map, processor and custodian regulatory disclosures, an annual review calendar with an assigned owner. The diligence pack went to the buyer's counsel as a single zip file.
Operator B selected each vendor on operational merit alone, kept the vendor terms in inboxes and shared drives, and never produced a consolidated compliance file. The diligence cycle reconstructed it under deadline pressure, with the buyer's counsel doing work the operator should have done at vendor selection.
Both operations function. Only one is institutionally legible. This module is about institutional legibility.
Three principles thread through every lesson. First: compliance is a posture, not a department. Most of the work happens at vendor selection, contract signature, and documented review — not at the moment of regulatory contact. Operations that treat compliance as something that begins with a regulator inquiry are operations that have already failed the inquiry. Second: good infrastructure providers carry much of the burden, but not all of it. Processors handle transaction-level AML and customer-facing KYC; issuers handle reserve disclosure and freeze capability; custodians handle key security. The operator owns the choices among them, the documentation that records those choices, and the residual responsibilities that no vendor absorbs. Third: the classification line between using crypto rails and being a crypto service provider is not aspirational — it is operational. Most merchants who accept stablecoin payments through regulated processors are not VASPs. Operators who drift into holding customer funds, facilitating exchange between users, or offering hosted wallets may become VASPs by activity regardless of intent. The line is real, the drift is recognizable, and counsel review at business-model design is the safeguard.
For most merchants on regulated processors, the heavy compliance lifting — transaction-level AML, customer KYC — sits with the vendor. Choosing those vendors well, and documenting the choice, is the part that’s yours.
Compliance posture is mostly a folder. Who you chose, why, what their published disclosures say, and when you last reviewed it. Boring to build, priceless in diligence.
The dangerous drift is accidental. Holding customer funds, facilitating exchange between users, or hosting wallets can change your regulatory category regardless of intent. When anything feels close to that line, that’s a counsel conversation — not a guess.
Compliance in a crypto-payment operation is frequently misframed as a legal review that happens before launch and a filing that happens once a year. In practice it is neither. It is the cross-cutting operational discipline that determines vendor selection, transaction monitoring, customer disclosures, internal approvals, audit trail, and incident posture — every day, in small motions, recorded as they occur. Operations that treat compliance as an event accumulate findings. Operations that treat it as a posture accumulate clean documentation.
Five dimensions sit beneath the discipline. Vendor diligence: the regulated standing, contractual terms, and operational maturity of every counterparty the business depends on — processors, custodians, issuers, banks, infrastructure providers, key tooling. Transaction monitoring: the systematic observation of inflows and outflows for sanctions exposure, unusual patterns, and customer-base composition, performed at the level appropriate to the business model. Customer disclosures: the published terms, refund policy, asset and chain support, fee disclosure, and risk language that govern the relationship with paying customers. Internal approvals: the documented authorization workflow that governs vendor selection, treasury action, signer changes, policy updates, and material decisions. Audit trail: the record that proves the other four were done — not described, not promised, but evidenced.
The work scales by documentation, not by headcount. An SMB operator can satisfy the compliance posture with a single compliance folder, a quarterly review cadence, and a designated owner. An enterprise requires more roles and more cadence but not a different posture. The mistake that recurs across operator sizes is the assumption that the discipline scales the other way — that small operators can defer it and large operators can hire it. Neither is true. The small operator who defers it produces the most predictable diligence finding in the next financing round. The large operator who hires it without operationalizing it produces an expensive compliance function that does not change the operation's actual posture.
Compliance as an event: "We submit our annual filing, we passed legal review at launch, we will deal with regulators if they contact us." Compliance as a posture: "Every vendor in our stack has documented regulatory standing, every material decision has a written approval, every change to our jurisdictional footprint triggers a review, every customer-facing disclosure is current, and the file is up to date today." The first posture passes nothing under examination. The second produces the documentation external parties expect to find, before they ask.
The relationship between this module and Module 05 is direct. Operations is what the business does day to day; compliance is the evidence that the business did it correctly. An incident playbook is operational; the documented post-mortem and the change to controls that follows it is compliance. A vendor relationship is operational; the documented diligence and the annual review that follows it is compliance. A refund policy is operational; the published disclosure to customers and the approval record for policy changes is compliance. The two layers are continuous; the same activities, viewed from different angles, satisfy different external expectations.
Compliance is the institutional habit of writing things down before they are asked for. The cost of the habit is small — minutes per decision, recorded as they occur. The cost of its absence is paid in diligence cycles, financing delays, regulator inquiries, and the slow accumulation of operational ambiguity that becomes acute under examination. This module is the operational form the habit takes.
The single most consequential compliance question a business answers about its crypto-payment operation is whether the business is using crypto rails or operating as a crypto service provider. The first is a merchant activity comparable to accepting card payments; the second triggers a separate regulatory regime that varies by jurisdiction and typically requires registration, licensing, or both. Most operators belong on the first side of the line. Operators that drift across it without realizing they have done so accumulate the most expensive class of regulatory exposure in this space.
Compliance obligations vary by jurisdiction, business model, customer profile, payment flow, and vendor arrangement. Confirm requirements with qualified counsel or compliance professionals before implementation.
The merchant pattern is recognizable. The business accepts payment in stablecoins through a regulated processor. The processor handles wallet connection, customer KYC where applicable, sanctions screening at the transaction level, and settlement to the merchant in stablecoins or fiat. The merchant receives funds into a treasury wallet or bank account, fulfills the order, and recognizes revenue. The merchant does not custody customer funds beyond the moment of settlement, does not exchange one crypto asset for another on behalf of customers, does not facilitate transfers between users, does not operate a wallet that customers can use to hold balances, and does not bridge fiat and crypto for parties other than itself. Within those constraints, the merchant is using a payment rail.
The service-provider pattern is also recognizable. The business holds customer balances in operator-controlled wallets pending withdrawal. The business operates a marketplace where users transact with each other in crypto. The business offers a hosted wallet, an on-ramp, an off-ramp, or a conversion service. The business facilitates exchange between crypto assets for customers. Any of these activities, depending on jurisdiction and the specific structure, may trigger Money Services Business (MSB), Virtual Asset Service Provider (VASP), Crypto-Asset Service Provider (CASP under EU MiCA), or Money Transmitter Licensee (MTL) obligations. The classification analysis is jurisdiction-specific and requires counsel review.
The responsibility map below states where compliance work typically sits in a merchant flow that uses a regulated processor. It is illustrative — actual division varies by vendor agreement, jurisdiction, and business activity — and is intended to orient the operator on what to expect from each counterparty and what remains in-house.
| Function | Operator | Processor | Issuer | Custodian | Bank |
|---|---|---|---|---|---|
| Customer KYC | Generally not required for the payment itself | Primary at processor account level | — | — | Account-holder KYC for fiat side |
| Operator KYB | Provides documentation | Performs at onboarding and recertification | — | Performs at onboarding | Performs at account opening |
| Transaction-level AML | Limited; pattern-level oversight | Primary at transaction level | — | Where in-scope | Fiat-side monitoring |
| Sanctions screening | Counterparty and vendor level | Transaction-level against major lists | Wallet-level freeze on listed addresses | Transaction-level | Account-level |
| Reserve & redemption | — | — | Primary; issuer-specific regime | — | — |
| Custody of operational treasury | Primary if self-custody | Transient (in-flight) | — | Primary if custodial | Bank account side |
| Travel Rule data exchange | Generally not — depends on classification | Where in-scope and above threshold | — | Where in-scope | — |
| Suspicious Activity Reporting | Operator's own observations and obligations | Processor's filing where required | — | Custodian's filing where required | Bank's filing where required |
| Tax information reporting | Operator filings on its own activity | Vendor information returns where applicable | — | Custodian reports where applicable | 1099/equivalent on bank side |
| Recordkeeping | Primary on operator's own books and records | Counterparty data within service | Reserve and attestation records | Custody records within service | Bank records within service |
The single most useful compliance artifact a merchant can maintain is a one-page document that names the operator's activities, lists what is performed in-house, lists what each counterparty performs, and identifies the gaps where neither side covers a function. The document satisfies the most common diligence question — "What do you do, and what do your vendors do?" — without ambiguity. Operations that maintain this document have a conversation. Operations that don't have it have a discovery cycle.
The drift across the boundary is recognizable. It typically begins as an operational accommodation rather than a strategic choice. A marketplace operator decides to hold platform credits for customers and quietly becomes a custodian. A SaaS operator builds an off-ramp for customers in a region where their preferred payout is fiat and quietly becomes a money transmitter in that region. An e-commerce operator allows customer-to-customer settlement on a return and quietly facilitates a peer transfer. Each of these is a small operational decision that may change the regulatory classification of the business in one or more jurisdictions. The discipline is to recognize the boundary before a small decision becomes structural, and to route any feature that approaches it through counsel review before launch.
Holding any customer-attributable balance — platform credits, marketplace escrow, refund queues kept in operator wallets, in-app wallet balances, "store credit" denominated in stablecoins, withdrawal queues — may move the business toward a custodial classification depending on jurisdiction and structure. The activity often arises operationally rather than strategically; the team building the feature may not be the team responsible for compliance posture. Feature reviews that touch customer-attributable balances should always include the compliance question, and counsel review should occur before the feature ships, not after the regulator inquires.
The acronyms recur in vendor contracts, regulator communications, and diligence questionnaires, and the operational meaning of each is narrower and more practical than the regulatory framing suggests. KYB is the diligence the processor performs on the business. KYC is the diligence performed on the customer, generally upstream at the wallet or processor account. AML is the systematic monitoring of transactions for unusual patterns. Sanctions screening is the act of checking counterparties against published lists. Each has an operational form the operator should understand and document, regardless of which counterparty performs the underlying work.
KYB is the diligence the processor performs on the operator at account onboarding and at recertification thereafter. Documents typically required include entity formation papers, beneficial ownership disclosure above relevant thresholds, business description with expected transaction volume and customer-base composition, source-of-funds information, and the contact and authorization structure for the account. Recertification cadence is typically annual; material changes to the operation (ownership, structure, business model, jurisdiction) often trigger an interim recertification. The operator's discipline here is to maintain a single KYB packet in current form, ready to provide on request, and to refresh it on the same cadence the processor expects.
For most merchant flows, KYC of the paying customer is handled upstream by the processor at the wallet-level account or at the moment of fiat conversion. The merchant typically does not collect customer identity documents for individual transactions; doing so for a transaction-level flow is often unnecessary and may itself create data-handling obligations. The exception is B2B flows where the operator has its own contractual KYB obligation on its counterparties — these are not transaction-driven and are handled through the operator's onboarding process for business customers.
AML at the transaction level is performed by the processor against industry-standard typologies and screening lists. The operator's role is the residual: pattern observation across the operator's own customer base, escalation when something looks unusual, and documented response if a counterparty is flagged. Operators are rarely AML examiners; operators are pattern-aware. The compliance posture is to know what the processor monitors, document the operator's own escalation procedure for anomalies, and engage counsel if a counterparty becomes the subject of a regulator inquiry.
The major lists are OFAC's Specially Designated Nationals and Blocked Persons (US), HM Treasury / OFSI consolidated list (UK), EU consolidated financial sanctions list, and UN Security Council Consolidated List. Processors typically screen at the transaction level against these and additional lists they elect to maintain. Stablecoin issuers maintain wallet-level freeze capabilities tied to law-enforcement and sanctions designations. The operator's screening discipline applies to its own vendor and counterparty relationships outside the processor flow — vendor payments, B2B counterparties, employee or contractor payments, treasury counterparties. The screening can be performed manually for low-volume operations and automated for higher-volume operations through a screening provider, but the documented procedure is what diligence cycles look for.
A current KYB packet contains: entity formation document, current good-standing certificate, beneficial ownership disclosure to the relevant threshold, board or member authorization for the operating account, current business description with volume and customer composition, current source-of-funds memo, and a named authorized contact. The packet is refreshed annually and at material change. The operations that maintain this discipline complete recertification cycles in days; operations that don't reconstruct under deadline pressure, often during periods (financing rounds, M&A, regulator inquiry) when the time pressure is least welcome.
Two further pieces of the screening discipline deserve specific framing. The first is the question of when stablecoin-issuer wallet freezes intersect the operator's flow. Issuers — Circle for USDC and EURC, Paxos for PYUSD and USDG, Tether for USDT — maintain the capability to freeze tokens at named addresses in response to law-enforcement or sanctions orders. The operator's exposure is typically downstream: a counterparty's address may be frozen, in which case a payment in transit may not arrive or a held balance may not be moved. The operator's policy should acknowledge this risk, document the issuer's published freeze posture, and treat it as a low-probability but defined operational scenario rather than a surprise. The second piece is the relationship between sanctions screening and the operator's customer base composition. Operations serving customers in high-risk jurisdictions, even where service is permitted, typically warrant a more deliberate screening posture, and the analysis should be in the compliance folder before scaling into such jurisdictions.
It is true that the processor handles transaction-level AML and sanctions screening for the flow that runs through the processor. It is not true that the processor handles every form of AML and sanctions obligation the operator may have. Vendor payments, B2B counterparties, treasury counterparty selection, and any flow that bypasses the processor are the operator's responsibility. The compliance posture documents which screening sits where and avoids the assumption that "the processor handles it" covers every angle.
Travel Rule and VASP classification are the two compliance concepts most likely to be misunderstood by operators new to the space, and the two whose misunderstanding produces the most expensive corrections. Both have origins in international anti-money-laundering frameworks, both have been implemented variously across jurisdictions, and both attach primarily to a category of business that most merchants accepting stablecoin payments are not. The discipline is to know the line, document the operator's position relative to it, and route any feature that approaches the line through counsel review before launch.
The Travel Rule originates in FATF Recommendation 16, which extends pre-existing financial-system rules requiring the transmission of originator and beneficiary information alongside wire transfers to virtual-asset transactions above a defined threshold. Implementation differs by jurisdiction: the United States applies the rule through FinCEN at a $3,000 threshold for traditional wires and at a $1,000 threshold for crypto under proposed and existing rules; the European Union implements the rule through the Transfer of Funds Regulation aligned with MiCA; the United Kingdom applies its own version through the Money Laundering Regulations; Singapore applies it through MAS guidance under the Payment Services Act. Thresholds, in-scope counterparty definitions, and information-exchange protocols vary across regimes and continue to evolve.
The Travel Rule's operational obligations attach to the parties classified as Virtual Asset Service Providers — typically exchanges, custodians, certain payment processors, and certain wallet providers — not to the merchant accepting payment through a regulated counterparty. For most operators in scope of this course, the Travel Rule is a discipline observed by the processor and the upstream wallet provider rather than a workflow the merchant builds. The operator's compliance posture documents which counterparties carry the Travel Rule obligation in the flow, confirms those counterparties' published compliance approach, and registers any change in the operator's own activity that might move them into scope.
The Virtual Asset Service Provider classification originates in FATF guidance and is implemented in regional variants: VASP under FATF and many national regimes, CASP (Crypto-Asset Service Provider) under EU MiCA, MSB (Money Services Business) under US federal rules with state-level overlays including Money Transmitter Licensee requirements, registered crypto-asset firm under UK FCA rules, licensed payment institution under MAS rules in Singapore. The categories overlap in spirit and differ in detail. The common thread is that businesses performing certain activities involving virtual assets — exchange between virtual assets and fiat, exchange between virtual assets, transfer on behalf of a customer, custody of virtual assets, financial services related to virtual-asset issuance or sale — typically require registration, licensing, or both, with associated AML, KYC, reporting, and capital requirements.
The merchant pattern, as framed in Lesson 02, sits outside these activities when conducted through a regulated processor. The activities that move a business into the classification are recognizable: holding customer balances, facilitating customer-to-customer transfers, offering hosted wallets, operating on-ramp or off-ramp services, providing exchange between crypto assets for customers. The classification analysis is jurisdiction-specific, fact-specific, and requires qualified counsel; this module does not — and cannot — substitute for that analysis.
The operational posture for a merchant operator is to maintain a documented description of the business's activities, sit on the merchant side of the line as understood by counsel, and route any new product feature that touches custody, exchange, transfer, or hosted balances through counsel review before launch. Counsel produces the classification opinion; operations produces the activity description and the change-detection discipline. Operations does not produce regulatory opinions, and operations does not classify the business.
Two further pieces of context shape how Travel Rule and VASP concepts intersect a merchant's operation. The first is that processor selection materially affects the operator's exposure to these concepts. A processor that is licensed as a CASP in the EU, an MSB in the US, or a licensed payment institution in Singapore has built the Travel Rule and AML infrastructure into its service; the operator inherits the benefit of that infrastructure by operating through the processor. A processor that has not built such infrastructure may transfer more residual responsibility to the operator regardless of the operator's intent. Processor diligence in Lesson 06 is the practical form this consideration takes. The second piece is that the regulatory regime is moving — globally, continuously, and not in a uniform direction. The compliance posture builds in an annual review of the regulatory environment in each jurisdiction the operator is exposed to (Lesson 08), and a counsel touchpoint at material change.
Marketplace operations are the most common source of accidental drift into VASP classification. A platform that lets users transact with each other in stablecoins, particularly one where the platform holds funds in escrow or facilitates the transfer, may be classified as a VASP in one or more jurisdictions even when the platform's revenue model is a service fee rather than a financial service. The structure of the escrow, the custody of the funds, and the activity of the platform all factor in. Marketplace product decisions warrant counsel review at the design stage, not after launch.
The stablecoin choice in Module 02 was an operational decision. The diligence behind it is a compliance posture. Each stablecoin in the operator's stack carries its own regulatory regime, reserve composition, attestation cadence, redemption mechanics, freeze capability, and concentration profile. Operators that select stablecoins on operational merit alone may carry a different risk profile than they realize. The diligence is finite and stable across most institutional issuers, and the documentation lives in the compliance folder.
The framework below applies six diligence dimensions to the issuers most relevant to operator-grade payment flows. The selection mirrors the locked canon from Module 02 — USDC and EURC (Circle) as primary and EU-denominated defaults, USDT (Tether) as the secondary global option, PYUSD (Paxos for PayPal) for PayPal-native flows, USDG (Paxos within the Global Dollar Network) for institutional network flows, and DAI/USDS (MakerDAO / Sky) noted as DeFi-adjacent and outside the operational-treasury default. The framework is descriptive; the issuers themselves are evolving, and current attestations and disclosures should be consulted at the moment of decision.
| Issuer / Asset | Regulatory Regime | Reserve Composition | Attestation Cadence | Freeze Capability | Concentration Note |
|---|---|---|---|---|---|
| Circle · USDC | US federal and state regimes; NY DFS-supervised affiliate; disclosed MiCA-compliant in EU | Cash and short-duration US Treasury obligations | Monthly attestation, third-party | Yes; documented freeze policy | Highest support across processors and chains; operational default |
| Circle · EURC | EU MiCA-compliant; euro-denominated EMT issuance under EU framework | Euro reserves at European credit institutions | Monthly attestation, third-party | Yes | Primary EUR-denominated stablecoin; liquidity thinner than USDC |
| Tether · USDT | Issuer outside major institutional regulatory regimes; subject to enforcement and disclosure regimes in jurisdictions where it operates | Mixed: US Treasury bills, secured loans, gold, other; composition disclosed | Quarterly attestation | Yes; selective freeze history | Largest market cap; deepest global liquidity; regulatory profile distinct from USDC |
| Paxos · PYUSD | Issued by Paxos Trust Company; New York-supervised trust regime | Cash, US Treasury obligations, cash equivalents | Monthly attestation, third-party | Yes | Strong US institutional posture; tied to PayPal ecosystem |
| Paxos · USDG (Global Dollar) | NY-supervised issuance; Global Dollar Network governance structure | Cash and short-duration US Treasury obligations | Monthly attestation, third-party | Yes | Newer issuance; institutional consortium model; liquidity maturing |
| MakerDAO / Sky · DAI / USDS | Decentralized issuance; no centralized issuer license | Mixed: stablecoin reserves (significant USDC), real-world assets, crypto collateral | Real-time on-chain transparency; no third-party attestation in the regulated sense | Limited; protocol-governed | DeFi-adjacent per project canon; outside operational-treasury default |
Each dimension carries operational weight. Regulatory regime: the regime determines who supervises the issuer, what disclosures are mandatory, and what recourse is available in adverse scenarios. Reserve composition: cash and short-duration government securities are the institutional standard; other compositions are legitimate but require additional analysis. Attestation cadence: monthly third-party attestation is the modern bar; less frequent attestation is legitimate but warrants explicit acknowledgment. Freeze capability: documented capability is generally a positive — it indicates the issuer has mature law-enforcement and sanctions-response procedures — though the operator should understand the policy under which freezes occur. Concentration: stablecoin operations that depend on a single issuer have the simplest treasury operation and the most concentrated counterparty risk; operations that diversify across issuers carry more complexity and lower single-counterparty exposure.
The diversification question is not whether stablecoins are individually safe; it is whether the operation's treasury should depend on a single issuer for material balance. A common operational pattern is USDC as the operational default for receipts and operating treasury, with a documented policy on maintaining a working portion in fiat or a second institutional stablecoin where the operator's banking and treasury setup supports it. The exact split is a treasury decision shaped by the operation's banking relationships, processor coverage, and risk tolerance. The diligence posture is to make the choice, document it, and review annually.
An operation that holds the entirety of its operational treasury in a single stablecoin from a single issuer has accepted a counterparty profile that is invisible until it becomes acute. The 2023 depeg episode affecting USDC during a brief banking-system stress event is the cleanest recent example: the asset returned to par within days, but the period of uncertainty was operationally meaningful for operators with concentrated single-issuer balances. The lesson is not to avoid the issuer; the lesson is to size the exposure deliberately, document the rationale, and have the secondary-rail path defined before the next event arrives.
Two recurring questions intersect issuer diligence and merit brief framing. The first is the relationship between an issuer's freeze capability and the operator's posture toward customer funds. An issuer's freeze of a counterparty address is a third-party action over which the operator has no control; the operator's exposure is to the funds in transit or the operational relationship that depended on those funds. The operator's posture is to monitor for material counterparty events, document the operational response, and ensure customer-facing communication is calibrated when an incident touches the operation. The second question is the treatment of issuer attestations as evidence. Monthly attestations are professional opinions issued by independent firms; they are not full audits in the GAAP sense and they typically opine on reserves at a point in time. The diligence posture treats attestations as one input among several, alongside the issuer's regulatory regime, disclosure history, and public conduct.
The processor is the regulated counterparty through which most of the operation's compliance burden is carried. Its regulatory standing, contractual posture, operational maturity, and continuity profile determine more of the operator's compliance posture than any other vendor choice. The diligence is finite — a defined set of questions, asked at selection and reviewed annually — and the answer set distinguishes processors that can carry institutional operations from those that cannot.
Vendor features, fees, supported assets, settlement options, and jurisdictional availability can change. Verify current terms directly before relying on any provider.
The matrix below summarizes the diligence dimensions most relevant to processor selection. The included processors are descriptive — representative of the categories operator-grade businesses encounter — not endorsements. Specific terms, supported assets, jurisdictions, and contract language change with time and require verification at the moment of decision. The dimensions, however, are stable; the questions to ask remain the same regardless of which processor is under evaluation.
| Processor | Regulatory Standing | Settlement Options | Reporting / Export | Notes on Profile |
|---|---|---|---|---|
| Coinbase Business / Commerce | Operated by US-regulated entities with a publicly traded parent; license types and scope vary by subsidiary and product, per their public disclosures (verify current registrations directly). | Stablecoin or fiat (ACH/wire) settlement; auto-conversion options | Dashboard + API exports; accounting integrations | Mature institutional posture; broad asset and chain support |
| BitPay | US-registered; long-operating processor | Stablecoin or fiat settlement; multiple currencies | Yes; CSV and API exports | Mature merchant tooling; established merchant relationships |
| Stripe Crypto | Operated by Stripe; inherits Stripe's regulatory and contractual structure | Integrated with Stripe settlement; fiat or stablecoin destinations | Stripe dashboard, API, and reporting | Strong for existing Stripe merchants; chain support more limited than crypto-native processors |
| Request Finance | EU-based; B2B-focused | Stablecoin settlement primarily; multi-chain | Robust accounting exports; vendor/invoice workflow | B2B invoicing and recurring-payment strength |
| Triple-A | Singapore-based; describes MAS licensing in its public disclosures (verify current status and scope directly). | Multiple settlement options including fiat | Dashboard and exports | Strong APAC posture; expanding global presence |
| CoinGate | EU-based | Broad asset, multiple settlement currencies | Dashboard, API, exports | Long-established; broad consumer-merchant fit |
| NOWPayments | EU-based | Very broad asset and chain support; multiple settlement options | Dashboard, API | Breadth of asset support exceeds most peers; institutional posture varies by tier |
The diligence is built around eight questions. Regulatory registration: what entities operate the service, in which jurisdictions, under which licenses? Customer base served: can the processor serve customers and merchants in the operator's target jurisdictions, and are there geographies it cannot? Asset and chain support: does the processor support the operator's chosen stablecoins on the operator's chosen chains, and what is the change cadence for adding new ones? Settlement options and timing: what destinations are supported (stablecoin or fiat), what is the settlement window, and what are the conditions under which settlement can be delayed or paused? Refund workflow: is there built-in refund tooling, what is the operator's refund SLA, and how are refunds reflected in reporting? Reporting and export capability: what data is available through dashboard, API, and bulk export, in what formats, and at what frequency? Status page and historical uptime: is the published uptime independently observable, what is the historical incident record, and what is the incident-communication discipline? Contract terms and recourse: what are the termination provisions, what is the operator's recourse in service interruption, and what notice provisions apply?
No single processor should be a single point of failure for the operation. The diligence at primary-processor selection includes the identification of a viable secondary rail — a second processor, or a fallback to direct wallet receipt for select counterparties, or a manual payment pathway — that can carry essential volume during an outage. The secondary rail does not require equal sophistication; it requires that it exists, that it has been tested at least once, and that the playbook for activating it is in the incident-response folder from Module 05.
Two recurring procedural patterns deserve specific note. The first is the diligence on the processor's published status page and incident history. A processor that publishes a status page with historical incident data, communicates clearly during outages, and produces post-incident reviews has a transparent operational posture. A processor that does not publish status data, communicates inconsistently during outages, or attributes incidents to ambiguous causes is a higher-friction counterparty regardless of its other strengths. The second pattern is the diligence on data export and accounting integration. A processor that produces machine-readable exports compatible with the operator's accounting stack (Module 04) materially reduces the reconciliation work in monthly close; a processor whose only export is a screenshot or a PDF places that burden on the operator. The export capability is a compliance factor as much as an operational one — the audit trail discussed in Module 04 depends on it.
Before signing with any processor, read the last twelve months of status-page incidents. The incidents themselves are not disqualifying — every processor has them — but the communication pattern is informative. Concise root-cause statements, defined remediation, and post-incident reviews indicate a mature operational posture. Vague language, missing post-mortems, and incidents that disappear from the timeline indicate the opposite. The diligence cost is one hour; the information returned shapes the contract negotiation and the operator's expectations for the next twelve months.
The custody decision is the second most consequential vendor decision in a crypto-payment operation, after the processor. It determines who controls the operational treasury, what happens when something goes wrong, and what recourse exists if a custody event occurs. The market offers credible options on both ends of the spectrum — pure self-custody for operators with the internal discipline to operate it, fully custodial arrangements for operators who prefer to delegate, hybrid structures for the middle. The diligence applies to each.
Self-custody means the operator's team controls the private keys to the operational treasury, typically through some combination of hardware wallets (Ledger, Trezor), software wallets for low-value flows (MetaMask, Coinbase Wallet, Phantom, Rabby), and multi-signature contracts for governance (Safe on EVM chains, Squads on Solana). The three-tier wallet architecture from Module 02 — hot, cold, multi-sig — is the operational form of self-custody at scale. The vendor diligence here is on the wallet and hardware providers; the operational risk is on the team that holds the keys.
Self-custody risks concentrate in three areas. Key-person risk: any signer whose unavailability would halt operations is a single point of failure. The discipline is at least two independent signers for any material multi-sig, with signer independence verified — different devices, different geographies, different recovery seeds, different backup channels. Recovery procedure: what happens when a signer becomes unavailable, when a hardware wallet is lost, when a recovery phrase is destroyed in a household incident, when an inheritance event must be handled. The procedure is documented, tested annually, and stored where the team can access it during the event it is meant to address. Operational hygiene: hardware wallet firmware updates, software wallet versioning, blind-signing posture, transaction-review discipline, phishing resistance, signer device security. None of these are exotic; all of them are absent from operations that have not yet been audited for them.
Custodial arrangements place the operational treasury, or part of it, with a third-party custodian that controls keys on the operator's behalf under contractual terms. The institutional spectrum includes Anchorage Digital (describes itself as a federally chartered digital-asset bank per its public disclosures), BitGo (describes itself as a state-regulated trust company per its public disclosures), Fireblocks (operational platform with MPC-based custody architecture), Coinbase Custody (subsidiary of Coinbase Global), and Copper (describes UK-regulated status per its public disclosures). Regulatory status, charter scope, and applicable frameworks vary and should be verified directly with each custodian before engagement. Each carries a distinct regulatory profile, custody architecture, fee structure, and operational integration approach.
Custodial risks differ from self-custody risks in profile, not severity. Vendor solvency and counterparty risk: the custodian's financial stability and operational continuity affect access to the operator's assets. Vendor key management: how the custodian itself secures keys (hardware security modules, MPC, sharded custody) and what its operational track record demonstrates. Insurance coverage: the scope, named perils, and limits of any insurance the custodian advertises — typically narrower than headline summaries imply, often subject to deductibles and exclusions, and never a replacement for sound operational architecture. Withdrawal mechanics under stress: the operational process for moving assets out of custody, including any review queues, authorization windows, or operational dependencies that might delay withdrawal in an adverse scenario. Vendor lock-in: the data-export, withdrawal, and migration provisions that determine how easily the operator can change custodians if circumstances change.
Custody-vendor insurance is one of the most commonly overstated diligence factors in this category. Headline coverage figures often describe pool insurance shared across all customers of the platform, with per-incident sublimits, named-peril restrictions (typically internal theft or cyber-incident, with explicit exclusions for protocol failures, blockchain reorgs, customer-side credential compromise, or third-party-vendor failures), and deductibles measured in significant percentages of insured value. Operators should read the policy summary in detail, understand what is and is not covered, and treat insurance as a backstop to a sound custody architecture rather than as a substitute for one.
Most operator-grade operations land in a hybrid architecture. Operational hot wallets — small balances, frequent transactions, processor-side or self-custody software wallets — handle daily flow. Cold wallets (hardware-backed, infrequently accessed) hold reserve treasury. Multi-signature contracts govern large transfers and policy actions. A custodial provider may hold a portion of the reserve treasury, particularly in operations with institutional regulatory or insurance requirements that favor it. The diligence applies to each tier on its own terms, and the architecture is documented in the operator's custody policy.
Multi-signature contracts protect against a single key compromise. They do not protect against correlated signer compromise — two signers who share a device, a household, a cloud account, a recovery phrase store, or a phishing exposure are functionally a single signer. Diligence on a multi-sig setup includes the verification of independence: distinct devices, distinct geographies (or at least distinct physical environments), distinct backup procedures, distinct phishing-attack surfaces. Multi-sig is only as strong as the weakest correlation among its signers.
Two further considerations apply across self-custody and custodial models. The first is the recovery drill. The custody architecture is tested at least annually through a documented exercise: a simulated key event (hardware loss, signer unavailability, custodian outage) walked through end to end, with timing recorded, gaps identified, and the procedure updated. Operations that have run a recovery drill recover faster when a real event arrives; operations that have not are the source material for post-mortems. The second is the segregation of operational and reserve treasury. Funds that must move quickly belong in operational wallets sized to the working balance; funds that should not move quickly belong in reserve wallets sized to a deliberate retention policy. The segregation discipline links forward to Module 07's treasury governance discussion and back to Module 02's three-tier architecture.
Jurisdictional exposure is the dimension of compliance posture most likely to be under-mapped at small scale and most likely to be expensive when finally examined. Most operations have customers in multiple jurisdictions, vendors in multiple jurisdictions, treasury exposure to multiple jurisdictions, and team members in multiple jurisdictions — without ever having drawn the map. The mapping exercise is finite, the map fits on a page, and the discipline of maintaining it is the difference between operating in plain view of the regulatory environment and operating in spite of it.
The seven dimensions of jurisdictional exposure. Entity location: where the operating company is incorporated and where it maintains its registered office. Customer location: where the paying customers reside, with attention to customer-base concentration in particular jurisdictions. Processor location: where the payment processor is licensed and which jurisdictions it can serve customers in. Issuer location: where the stablecoin issuer is regulated and which jurisdictions have classified or otherwise positioned the asset. Custodian location: where the custodian (where applicable) is regulated and operates. Bank location: where the operator's fiat banking is held and what cross-border implications its terms include. Operator location: where the team members operating the business reside and work, including remote and distributed-team patterns.
| Jurisdiction | Primary Regime | Stablecoin Treatment | Service-Provider Threshold | Operator Posture |
|---|---|---|---|---|
| United States | FinCEN (federal AML); state MTLs; NY DFS (BitLicense); OFAC sanctions; GENIUS Act framework for payment stablecoins | Federal stablecoin framework establishing; state-level overlay continues | MSB / MTL registration triggers vary by state and activity | Counsel review at material change; state-by-state analysis where customers concentrate |
| European Union | MiCA (Markets in Crypto-Assets); TFR (Transfer of Funds Regulation); AMLD | MiCA-compliant issuers required for most institutional use; EURC compliant | CASP authorization required for in-scope services | Counsel review if EU customers are material; processor's MiCA posture confirmed |
| United Kingdom | FCA crypto-asset registration regime; UK MLR | UK regime distinct from EU post-Brexit; evolving | FCA registration required for in-scope activities | Counsel review if UK customers are material; FCA-registered providers preferred |
| Singapore | MAS (Payment Services Act); licensed institution regime | Licensed-issuer regime; clarity on classification | MAS licensing required for in-scope payment services | Counsel review for direct Singapore presence; use processors that disclose MAS licensing for APAC flows (verify current status directly) |
| Hong Kong | SFC VASP regime; SFC virtual asset rules | Licensed exchange regime; issuer rules evolving | SFC licensing required for in-scope activities | Counsel review for direct Hong Kong presence |
| UAE | VARA (Dubai); ADGM and DIFC free-zone regimes | Issuer-specific licensing | VARA / ADGM / DIFC licensing required in scope | Free-zone-specific structure; counsel review at entity formation |
| Other APAC / LatAm / Africa | Varies widely; regimes evolving in many jurisdictions | Often unclear or in development | Country-specific analysis required | Counsel review for any market exceeding the operator's exposure threshold |
The mapping practice is straightforward in form and continuous in maintenance. For each of the seven dimensions, the operator records the relevant jurisdictions, identifies any combined exposure (the same jurisdiction appearing in multiple dimensions amplifies relevance), and notes the regulatory regime that applies. A single jurisdiction appearing in three or more dimensions — for example, an operator incorporated in Delaware, with a US-licensed processor, US-regulated bank, US-based team, and material US customer concentration — clearly warrants a thorough US analysis. A jurisdiction appearing in one dimension at modest exposure (a small fraction of customers in a single APAC market) warrants awareness rather than immediate counsel engagement. The thresholds at which exposure becomes material are an operator decision and should be written into the compliance folder.
The jurisdictional map is refreshed annually and on any material change to the operation: a new region of customer concentration, a new processor or custodian, a new banking relationship, a change in entity structure, a new product feature that may affect classification, or any signal from a regulator in any jurisdiction. The annual review is short — typically an hour or two for an SMB, longer for an enterprise — and produces an updated map signed off by the compliance owner. Re-mapping at material change is the discipline that prevents the slow accumulation of unrecognized exposure.
A note on the relationship between jurisdictional exposure and the rest of the compliance posture. Processor selection (Lesson 06) is jurisdictionally consequential: processors with broader regulatory footprints carry operators into more jurisdictions than processors with narrower footprints, and the choice should be aligned to the operator's target customer base. Issuer selection (Lesson 05) is jurisdictionally consequential: an issuer regulated in a jurisdiction where the operator's customers concentrate may be the operationally simpler choice. Custody selection (Lesson 07) is jurisdictionally consequential: a custodian regulated in a jurisdiction whose framework aligns with the operator's regulatory profile may simplify the compliance posture. The jurisdictional map ties these decisions together.
Vendor diligence as an ad-hoc activity produces inconsistent results, partial documentation, and surprises. Vendor diligence as a documented workflow produces a consistent file, predictable cycle times, and the audit trail external parties expect. The workflow below is the institutional standard scaled to operator size — an SMB runs the sequence with one or two owners; an enterprise runs the same sequence with more cross-functional involvement, but the steps and artifacts are the same.
The workflow rests on three structural choices. Risk tiering: not every vendor warrants the same diligence; tiering scales the effort to the importance. Required artifacts per tier: the file produced is finite and known in advance. Defined triggers for escalation: legal review, security review, and executive sign-off are required under stated conditions, not at discretion. The discipline removes the "I'll just call counsel and ask" pattern in favor of "the workflow says counsel review is required because tier and condition met."
Three tiers cover most operator-grade vendor relationships. Tier 1 — Critical: vendors that hold operator funds (custodians), process customer payments (processors), issue assets the operator holds (stablecoin issuers, for any material exposure), or could materially affect the operator's regulatory standing. Counsel review and full documentation required. Tier 2 — Significant: vendors providing material tooling that touches financial data, compliance reporting, customer data, or operational continuity (accounting platforms, monitoring tools, security tools, contractor platforms with payment exposure). Standard diligence with security review; counsel review above contract-value threshold. Tier 3 — Routine: standard SaaS tooling with no financial or compliance footprint (marketing tools, productivity tools, communication tools). Standard terms and finance approval; counsel review only at unusual provisions.
| Stage | Owner | Required Artifact | Time Standard |
|---|---|---|---|
| Intake | Initiator (proposed user) | Vendor profile, business case, tier proposal | 1 business day |
| Risk tiering | Compliance owner | Tier decision memo | 1–2 business days |
| Document collection | Initiator | Documentation packet per tier requirements | 1–2 weeks |
| Legal review (if triggered) | Counsel | Counsel sign-off memo; contract markup | 1–3 weeks |
| Finance approval | Finance lead | Budget and contract terms approval | 1 week |
| Security review | Security owner | Security questionnaire response; data-handling sign-off | 1–2 weeks |
| Final decision | Executive sponsor | Approve / decline / conditional approval memo | 1–2 business days |
| Annual review | Compliance owner | Recertification packet; performance review | Annual cadence |
| Offboarding | Initiator + finance | Data-export confirmation, account closure, key rotation, wind-down checklist | 1–4 weeks |
The Tier 1 packet typically contains: entity formation and good-standing documentation, regulatory registration evidence (license, registration number, supervising authority), the executed master service agreement and any data-processing addendum, the most recent SOC 2 Type II or ISO 27001 certification where applicable, the security questionnaire response, the published incident-response and breach-notification policy, the insurance summary where claimed, and at least two reference contacts from comparable operators. The Tier 2 packet narrows the regulatory and insurance items but retains contract, security, and incident materials. The Tier 3 packet is the standard SaaS package: terms of service, security summary, billing terms. The documentation is collected at onboarding, refreshed annually, and stored in the compliance folder.
| Red Flag | Why It Matters | Operator Action |
|---|---|---|
| No clear regulatory disclosures | Regulatory standing is the foundation of the vendor relationship; missing or vague disclosure transfers risk to the operator | Decline; require explicit regulatory disclosure for reconsideration |
| No status page or poor uptime visibility | Operator cannot independently detect outages; SLA disputes have no operator-side evidence | Decline at Tier 1; require independent monitoring at Tier 2 |
| No machine-readable export | Accounting (Module 04) and compliance reporting (this module) break | Decline at Tier 1; non-negotiable for financial flows |
| No refund workflow | Customer-facing operational gap (Module 05); refund discipline cannot be maintained | Decline for customer-facing payment flows |
| Unclear settlement timing | Treasury planning fails; reconciliation timing assumptions break | Require written commitment with stated SLA before signature |
| Single-issuer treasury concentration | Counterparty risk concentrated; depeg or freeze affects the entire operational treasury | Diversify per Lesson 05 or document the rationale and accept the exposure deliberately |
| Single-processor dependence | Processor outage equals revenue zero; no operational continuity path | Define secondary rail per Lesson 06 before launching with primary |
| Custodian without documented recovery | Loss event has no defined path forward; assets in jeopardy under stress | Decline custodial engagement; require documented recovery procedure |
| Signing process dependent on one person | Bus number equals one; correlated incidents are catastrophic | Restructure signer architecture before scaling treasury further |
| Activity drift toward custodial / VASP territory | Classification change may trigger registration, licensing, and operational obligations | Engage counsel at feature design; do not launch boundary-adjacent features without review |
| Marketing overstates compliance or safety posture | Vendor's marketing risk becomes the operator's risk when claims are repeated downstream | Verify each claim against the vendor's actual published disclosures; treat verified claims only |
Vendor diligence done well is not a personality trait; it is a workflow. The same questions asked of every vendor, the same artifacts collected at every onboarding, the same review cadence applied annually, the same offboarding executed at termination. The work scales with the operation; the structure does not change. Operations that maintain the workflow have an answer to every diligence question they receive. Operations that do not run the work cycle for every diligence cycle they enter.
Vendor marketing pages, sales decks, and homepage claims are not regulatory disclosures. They are marketing assertions, often phrased aspirationally, and they should not be relied on in diligence. The actual disclosures live in published policies, contractual terms, audit reports, and regulator filings. When marketing exceeds disclosure — for example, "fully compliant in all jurisdictions" on a homepage where the disclosures specify a narrower footprint — the operator's diligence treats only the disclosure as the basis of decision. Marketing-disclosure gaps are themselves a diligence signal; they tell the operator something about how the vendor will represent itself in adverse moments.
The ten patterns below are the compliance failures that recur across crypto-payment operations regardless of size, processor, or jurisdiction. Each is preventable by a discipline established in this module; each is materially expensive once it surfaces — typically during a financing diligence, an audit, an acquisition cycle, or a regulator inquiry. The asymmetry is consistent: small upfront cost to prevent, structural cost to remediate.
| Failure Pattern | Why It Happens | Diligence Cost |
|---|---|---|
| No documented compliance boundary | Operator and counterparty responsibilities never written down; "the processor handles it" is the default explanation | Discovery cycle during diligence; ambiguity becomes finding |
| No KYB packet maintained | Documents collected once at processor onboarding and never refreshed; material change occurs but recertification is reactive | Recertification cycle becomes weeks of document reconstruction at unwelcome timing |
| Custodial drift without counsel review | Feature decisions touch customer-attributable balances; compliance review never triggered | Classification change discovered in diligence or by regulator; remediation costs significant |
| Single-issuer treasury concentration | Operational simplicity preferred at selection; diversification deferred indefinitely | Counterparty event during depeg or regulatory stress affects entire treasury |
| No secondary processor rail defined | Primary processor selected on merit; secondary never identified or tested | Outage equals revenue zero for the duration; customer trust degrades |
| Custody without documented recovery | Custody architecture set at launch; recovery procedure never written or tested | Recovery event becomes improvisation under pressure; outcome variable |
| Multi-sig with correlated signers | Signers selected for availability rather than independence; correlation never audited | Single phishing event, household incident, or shared exposure compromises multiple signers simultaneously |
| No jurisdictional exposure map | Customer and vendor footprint expands organically without compliance review | Material exposure surfaces during diligence in a jurisdiction where no analysis exists |
| Vendor diligence as ad-hoc activity | Each vendor onboarded under its own urgency; documentation lives in inboxes | Diligence pack reconstruction consumes weeks at the worst moment |
| Marketing-driven compliance posture | Vendor's marketing language treated as disclosure; downstream claims based on insufficient evidence | Marketing gap becomes the operator's exposure when scrutinized |
Nine of the ten failures above share the same root cause: compliance posture treated as an event rather than as an operating discipline. The cost asymmetry is consistent — minutes to record a decision at the moment it is made, weeks to reconstruct the rationale months or years later. Operations that internalize the asymmetry produce institutionally legible files. Operations that don't produce diligence cycles in which the buyer's counsel does the work the operator should have done at selection.
Mistake 1. Treating compliance as a one-time legal review rather than as a continuous operating posture. The work happens at vendor selection, decision documentation, and annual review — every day, in small motions.
Mistake 2. Assuming "the processor handles it" covers every angle. The processor handles transaction-level AML and customer-side KYC. Vendor payments, B2B counterparties, treasury counterparties, and product features that approach the custodial boundary are the operator's responsibility.
Mistake 3. Holding the entire operational treasury in a single stablecoin from a single issuer without documenting the rationale or maintaining a secondary path.
Mistake 4. Launching features that touch customer-attributable balances without counsel review. Custodial drift is the most expensive accidental classification change in this space.
Mistake 5. Running vendor selection as a series of one-off decisions instead of a documented workflow. Diligence cycles surface every gap that selection skipped.
Mistake 6. Refreshing nothing. The compliance folder is current, or it is decoration. Annual review is the cadence that keeps it current.
Everything in this module converges in an implementation sequence that an SMB can complete in a focused business week and an enterprise can stage across a quarter. The output is concrete: a single compliance folder, with an assigned owner, containing the artifacts an external party would expect to find. The folder is the file the operation hands over during diligence; the work below is what fills it.
The five-day sequence produces one tangible output: a compliance folder that contains the approved-vendor list, the approved-stablecoin list, the compliance responsibility map, the KYB packet, the custody documentation, the recovery procedure, the jurisdictional exposure map, the vendor packets at each tier, the approval workflow template, the named owner, the review calendar, the legal-review triggers, and the test exports. An external party — counsel reviewing the operation for a financing round, an acquirer's diligence team, a regulator responding to a complaint, an auditor opening the file — should find the answer to most questions inside the folder without needing to ask. That is the practical definition of institutional legibility.
Compliance is the layer that converts an operable system into an institutionally legible one. Most of the work happens at vendor selection, decision documentation, and annual review — not at the moment of external contact. The operator's boundary with processors, issuers, custodians, and banks is documentable and finite. The KYB, AML, and sanctions discipline is operational, not theoretical. Travel Rule and VASP concepts attach primarily to a category of business that most merchants accepting stablecoin payments are not — and the line, when approached, is resolved at counsel rather than in operations.
Stablecoin issuer diligence is finite across six dimensions, and the operator's compliance folder records the choice and the rationale. Processor diligence is the single most consequential vendor decision in the stack, and a secondary rail is the discipline that turns one-processor dependence into operational continuity. Custody diligence applies whether the operator self-custodies or delegates, and signer independence is the structural property multi-sig actually protects. Jurisdictional exposure maps to seven dimensions and is refreshed annually. Vendor selection runs through a documented workflow with risk tiering, defined artifacts, escalation triggers, and offboarding procedures. The output of the whole module is a single compliance folder with a named owner and a review cadence.
Module 07 turns to tax treatment, legal structure, and governance — the surrounding institutional architecture that determines how the operation files, how it is owned, and how its decisions are authorized. The compliance posture established here feeds directly into that architecture; the work below is the foundation it stands on.
If your roadmap includes holding customer funds, facilitating exchange between users, hosted wallets — or anything adjacent to those — stop and book counsel review before building. Regulatory classification turns on activity, not intent, and it is far cheaper to design on the right side of the line than to restructure across it.