Compliance Frameworks to Consider When Embedding an MPC Wallet in Payments

Embedding an MPC wallet changes how transactions are signed, but it does not by itself determine whether a product is custodial, regulated or exempt. Regulators and banking partners will examine the service actually provided: who controls funds, who can approve or stop transfers, whether value is moved for customers, and which entities and jurisdictions participate.

Multi-party computation distributes the cryptographic work required to sign a transaction across multiple participants or systems. A complete private key does not need to be reconstructed in one place. This can reduce single-key risk and support quorum-based authorization, but it does not replace licensing, anti-money laundering, sanctions or operational-resilience controls.

Start with the product and funds flow

Before choosing frameworks or commissioning an audit, create a transaction-level funds-flow diagram. Cover the path from customer onboarding and wallet creation through beneficiary approval, signing, blockchain confirmation, conversion and final settlement.

For every step, record the legal entity performing the activity, asset, account or wallet owner, signing authority, service provider and jurisdiction. The analysis should answer the following questions:

• Control: Can the company initiate, block, redirect or recover a transaction? Who holds each MPC share, and what quorum is required?
• Ownership: Does the wallet belong to the operating company, an individual customer or another business? Are assets pooled or separately identified?
• Activity: Does the product only provide software, or does it receive, safeguard, exchange or transmit value for another party?
• Assets and rails: Does it support USDC, USDT, other cryptoassets, fiat accounts, cards, bank transfers or on- and off-ramps?
• Geography: Where are the operator, customers, recipients, banks and wallet or infrastructure providers established?
• Timing: When is a payment considered accepted, released, confirmed and final? Who bears the risk of a delayed or failed blockchain transaction?

A company using an MPC wallet solely to pay its own suppliers presents a different licensing profile from a platform that accepts customer funds and forwards them to third parties. Likewise, describing a wallet as non-custodial is not conclusive if the provider controls a required signing share, can change the quorum or operates the only recovery process.

Map each framework to a specific trigger

These categories overlap but are not substitutes for one another. A SOC 2 report does not grant permission to transmit money, and an AML registration does not demonstrate that an MPC recovery process is secure.

Licensing follows the service, not the signing method

In the United States, products that accept and transmit or exchange value may require analysis under federal FinCEN rules and state money transmitter laws. State definitions, exemptions and licensing processes vary. Restrictions administered by the Office of Foreign Assets Control must be considered separately from money transmission status.

In the European Union, assess whether the activity falls within the Markets in Crypto-Assets Regulation, payment-services requirements or both. The Transfer of Funds Regulation imposes information requirements on covered cryptoasset transfers. The precise obligations depend on the entities, assets and transfer model.

In the United Kingdom, registration for certain cryptoasset activity under the Money Laundering Regulations is distinct from authorization to provide regulated payment services. Singapore’s Payment Services Act similarly covers specified payment activities, including certain digital payment token services.

A licence, registration or exemption in one market generally does not authorize activity in every other market. Build a jurisdiction matrix covering the operating entity, customer location, recipient location, asset, service and responsible regulator. Obtain local advice where a product crosses borders or combines fiat and stablecoin rails.

Translate the MPC design into control ownership

The compliance review should explain the practical authority attached to every signing share. Document who generates and stores shares, which combinations can sign, how participants are authenticated, and whether a vendor or customer can act without the operating company.

Quorum changes deserve the same scrutiny as transaction signing. Identify who can add a signer, lower an approval threshold, change a destination allowlist, disable screening or start recovery. Sensitive changes should require documented authorization, separation of duties and durable evidence.

Also define procedures for a lost device, unavailable signer, compromised administrator, employee departure and vendor outage. Recovery should not create an undocumented path that bypasses the normal quorum. Logs should connect the business request, approvers, screening outcome, signing event, transaction hash and final status.

Build AML, sanctions and Travel Rule checks into payment events

Compliance controls are more effective when attached to specific events rather than added as a final dashboard. Relevant events include account opening, wallet registration, beneficiary creation, asset conversion, policy changes and transaction release.

Perform KYC for individuals and KYB for companies where required, including beneficial-owner checks. Screen relevant customers and counterparties, and assess destination addresses before release. Wallet screening can identify exposure to sanctioned addresses and other risk categories, but a score alone should not make the decision. Define alert thresholds, review ownership, escalation routes and the evidence required to release or reject a payment.

Transaction-monitoring scenarios should reflect the product’s customers, corridors, assets and expected activity. Examples include rapid movement after funding, repeated transfers just below an internal review level, abrupt changes in destination behavior and interaction with prohibited addresses. Each scenario needs a documented rationale, reviewer and disposition process.

Travel Rule requirements differ by jurisdiction, transfer type, counterparty and applicable threshold. Covered transfers may require originator and beneficiary information to be collected and transmitted to another regulated provider. Transfers involving self-hosted wallets can require additional checks in some markets, so a single global threshold or workflow may be insufficient.

For example, Stablerail can combine approval and signing quorum, sanctions and address screening before send, global payouts, fiat off-ramp and exportable audit evidence in one stablecoin business account. The operating company remains responsible for setting its policies, reviewing exceptions and confirming where legal obligations apply.

Use SOC 2 and ISO 27001 for assurance, not licensing

SOC 2 is an independent attestation report based on the AICPA Trust Services Criteria. A Type I report addresses control design at a point in time, while a Type II report also tests operating effectiveness over a period. SOC 2 is neither a regulatory licence nor a certification.

ISO 27001 is a certifiable standard for an information security management system. It focuses on identifying information-security risks, selecting controls and continually managing the programme. Neither framework replaces AML, sanctions, privacy or payment licensing obligations.

For an MPC deployment, the assurance scope should include share generation and storage, privileged access, quorum changes, recovery, software releases, cloud infrastructure, transaction records and third-party wallet dependencies. Excluding a critical signing or recovery provider can make an otherwise strong report less useful to customers.

Plan for privacy, resilience and blockchain failure modes

Wallet addresses can become personal data when linked to an identifiable person. KYC records, beneficial-owner details, device information, IP addresses and transaction histories also require defined purposes, access restrictions, retention periods and cross-border transfer analysis.

Operational resilience extends beyond uptime. Test the loss of a signing participant, cloud region, blockchain node or RPC provider, screening provider and critical employee. Plans should cover queued transactions, duplicate-payment prevention, customer communication and reconciliation after recovery.

Separate internal processing targets from blockchain confirmation and economic finality. Network congestion, chain reorganization, paused stablecoin contracts or an unavailable off-ramp can delay settlement after a transaction has been approved. Define when accounting records are posted and how pending, failed or replaced transactions are reconciled.

Apply PCI DSS only when card data creates scope

PCI DSS does not apply merely because an MPC wallet holds stablecoins. It becomes relevant when systems store, process or transmit cardholder data, or can affect the security of the cardholder-data environment.

If a product includes corporate cards, map where primary account numbers and authentication data pass. Tokenization and outsourcing can reduce direct exposure, but they do not automatically remove all responsibilities. Confirm scope with the relevant card partners and document network segmentation between wallet infrastructure and card-data systems.

Implementation checklist for finance and compliance teams

1. Approve an end-to-end funds-flow and control diagram before launch.
2. Assign a legal conclusion to every entity, service and target jurisdiction.
3. Document MPC share holders, quorum rules, privileged changes and recovery paths.
4. Place customer, beneficiary, sanctions and address checks at defined payment events.
5. Specify Travel Rule handling by jurisdiction and counterparty type.
6. Test signer, provider, network and off-ramp failure scenarios.
7. Confirm whether card features introduce PCI DSS scope.
8. Retain evidence linking approvals, screening decisions, signatures, transaction hashes and reconciliation.

The resulting control pack should be usable by legal counsel, auditors, banking partners and internal finance teams. It should show not only that policies exist, but also how each payment was authorized, screened, signed, settled and recorded.