Compliance Frameworks to Consider When Embedding an MPC Wallet in Payments

Embedding an MPC wallet into a payment product changes how transactions are authorized, but it does not determine the product’s regulatory classification. That classification usually depends on what the business does: who controls funds, whether it transfers value for customers, which assets and payment rails it supports, and where the parties are located.

Multi-party computation, or MPC, distributes the cryptographic process used to sign a transaction across multiple participants or systems. No single participant needs to reconstruct a complete private key. Quorum signing can reduce single-key risk and support approval policies, but regulators will still examine the practical control model rather than the cryptography alone.

Before selecting frameworks or commissioning audits, document the payment flow, jurisdictions, customer types, supported networks and allocation of responsibilities. This article provides a research framework, not legal advice; licensing and compliance conclusions should be confirmed in each relevant jurisdiction.

Start with the product and funds flow

Create a diagram covering every step from customer onboarding to final settlement. For each step, record the legal entity involved, asset, account owner, signing authority, service provider and location.

• Control: Can your company initiate, block, redirect or recover a transaction? Who holds the MPC signing shares, and how many shares are required?
• Ownership: Is each wallet owned by your business, an individual customer or another company? Are assets pooled or separately identified?
• Activity: Is the product limited to software, or does it receive, exchange, transmit or safeguard value for others?
• Assets and rails: Does it support USDC or USDT, fiat accounts, cards, bank transfers, or on/off-ramps?
• Geography: Where are the operating entity, customers, recipients, banking partners and technology providers established?
• Timing and limits: Which transfers are instant, same-day or dependent on blockchain confirmation? What transaction, daily and approval limits apply?

For example, a treasury wallet used only to pay a company’s own invoices presents a different licensing analysis from a platform that accepts customer funds and forwards them to third-party recipients. An MPC wallet may be described as self-custodial, but the legal analysis should test whether the customer has genuine and exclusive practical control.

Framework and obligation map

Licensing follows the service, not the signing method

In the United States, a model involving the transmission or exchange of value may require analysis under FinCEN rules and state money transmitter laws. State definitions and exemptions vary. Sanctions obligations administered by OFAC must also be considered separately from licensing.

In the European Union, determine whether the service falls within the Markets in Crypto-Assets Regulation, payment-services rules or both. The EU Transfer of Funds Regulation includes information requirements for certain cryptoasset transfers. In the United Kingdom, cryptoasset registration under the Money Laundering Regulations is distinct from authorization for regulated payment services.

Other markets use their own definitions. Singapore’s Payment Services Act, for example, covers specified payment services, including certain digital payment token activities. A licence or registration in one country generally does not authorize activity everywhere else.

Do not assume that calling an interface “non-custodial” resolves the question. Review who selects transaction destinations, can change signing policies, operates recovery procedures, pays network fees and controls the other MPC shares.

Build AML, sanctions and Travel Rule steps into the flow

Payment compliance should be designed around events rather than added as a final dashboard. Relevant events include account opening, wallet registration, beneficiary creation, asset conversion and transaction release.

• Perform KYC for individuals and KYB for companies, including beneficial-owner checks where required.
• Screen customers and relevant counterparties against sanctions and other required lists.
• Use wallet screening to identify exposure to sanctioned addresses, theft, scams or other risk categories.
• Set transaction-monitoring scenarios based on the product, corridors, assets and customer profile.
• Define who reviews alerts, who can hold a payment and how decisions are documented.

Travel Rule requirements differ by jurisdiction, transaction type and amount. The implementation may require originator and beneficiary information to be exchanged with another regulated provider. Transfers to or from self-hosted wallets can require additional checks in some markets. Avoid using a single global threshold without confirming local law.

Stablerail supports KYB and eligibility checks, approval limits, allowlists, sanctions and wallet screening, audit logs and evidence packs. These features can support a compliance programme, but the operating company still needs to define its policies, review alerts and confirm its legal obligations. The wallet checker can support address-level review.

Treat SOC 2 and ISO 27001 correctly

SOC 2 is an independent attestation report based on the AICPA Trust Services Criteria; it is not a regulatory licence or certification. A Type I report considers control design at a point in time, while Type II also examines operating effectiveness over a period.

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

For an MPC deployment, the security scope should include share generation and storage, quorum changes, privileged access, transaction-policy changes, backup and recovery, software releases, cloud infrastructure and third-party MPC dependencies.

Plan for privacy and operational resilience

Wallet addresses may become personal data when they can be linked to an individual. KYC records, device information, IP addresses and transaction histories also require a documented purpose, access controls, retention periods and cross-border transfer analysis.

Operational resilience goes beyond system uptime. Test what happens if a signing participant, cloud region, blockchain RPC provider, screening vendor or key employee becomes unavailable. Regulated firms may face specific requirements, such as the EU Digital Operational Resilience Act or UK operational-resilience rules.

Document recovery time objectives, approval alternatives, provider exit plans and procedures for congested or halted networks. For payouts across Ethereum, Base, Arbitrum, Polygon, Tron, BNB Chain, Optimism or Solana, distinguish an internal processing target from final blockchain confirmation. See the practical options for stablecoin payouts.

Apply PCI DSS only where card data creates scope

PCI DSS applies when systems store, process or transmit cardholder data, and can also cover systems that affect the security of the cardholder-data environment. It does not apply merely because a wallet holds stablecoins.

If the product includes virtual or physical corporate cards, map where primary account numbers and authentication data pass. Using a processor’s hosted fields or tokens may reduce scope, but does not automatically remove every obligation. Confirm the correct PCI DSS 4.0.1 validation method with the acquiring bank or card programme provider. Stablerail’s corporate card controls include spending limits and merchant category restrictions.

A practical pre-launch checklist

• Complete a legal-entity, jurisdiction and funds-flow map.
• Write down the exact MPC share, quorum, recovery and policy-change model.
• Obtain jurisdiction-specific advice on payments, money transmission and cryptoasset licensing.
• Define KYB/KYC, sanctions, wallet-screening, monitoring and Travel Rule workflows.
• Map personal data and card data before setting security or PCI scope.
• Assess MPC, cloud, banking, blockchain and compliance-provider dependencies.
• Test failed signatures, provider outages, compromised administrator accounts and network congestion.
• Retain approvals, screening results, policy changes and transaction evidence in an auditable format.

The central principle is straightforward: MPC is a security and authorization architecture. It can improve key management and enable quorum approvals, but it does not by itself make a payment product custodial, non-custodial, licensed or exempt. Start with the actual service and funds flow, then apply the frameworks that match the activity, data and jurisdictions involved.