--- title: "Cross-border stablecoin payments risk register: a fill-in template with 16 risks, scores, and owners" seoTitle: "Cross-border stablecoin payments risk register template" description: "A copyable risk register for cross-border stablecoin payouts: 16 risks across six categories, a 5x5 scoring method, controls, indicators, and owners." date: "2026-10-16" updated: "2026-10-16" category: "compliance" author: "BlindPay Team" faq: - q: "What is a risk register for stablecoin payments?" a: "It is a table that lists each risk in your cross-border stablecoin payment flow, its cause, how likely it is, how much damage it would do, the control that reduces it, the indicator that warns you early, and the person who owns it. Auditors, banks, and boards ask for it because it proves risks were thought through before money moved." - q: "Which risks belong in a cross-border stablecoin payments risk register?" a: "Group them in six categories: stablecoin and issuer, FX and liquidity, counterparty and custody, compliance, operations and technology, and legal and regulatory. A starting register usually holds 12 to 20 rows. Depeg, wrong network, expired quotes, sanctions exposure, provider failure, bank-detail errors, and corridor rule changes appear in almost every one." - q: "How do you score risks in the register?" a: "Score likelihood and impact from 1 to 5 each and multiply them, so every risk lands between 1 and 25. Score twice: inherent risk before controls and residual risk after them. Write down what each number means in your business, for example impact 5 as a loss above a set amount, so two people scoring the same risk get the same result." - q: "How often should the risk register be reviewed?" a: "Review it quarterly, and also after any incident, any new corridor or rail, any change of provider, and any regulatory change in a corridor you pay into. Record the review date and who attended. A register with no review history reads to an auditor as a document written once for approval and then forgotten." - q: "Who should own risks in a stablecoin payment flow?" a: "A named person, not a team. Treasury usually owns depeg and liquidity, compliance owns sanctions, Travel Rule, and information requests, engineering owns network, quote, and duplicate-payment risks, operations owns bank details and returns, and finance owns provider and counterparty risk. The owner reports on the control and its indicator at each review." --- A cross-border stablecoin payments risk register lists every risk in your payout flow with its cause, a likelihood and impact score, the control that reduces it, an early-warning indicator, and a named owner. Use the template below: 16 starter risks in six categories, scored on a 5x5 scale before and after controls. If you are new to the flow itself, read [what a stablecoin sandwich is](/resources/more/what-is-a-stablecoin-sandwich) first: each layer of the sandwich adds its own risks. **Key takeaways** - Score every risk twice: inherent (no controls) and residual (with controls). The gap is what your controls are worth. - Most residual risk in stablecoin payouts sits in operations and compliance, not in the blockchain. - Every row needs an indicator you can measure weekly, or the register can't warn you of anything. - One owner per risk, by name. Shared ownership means nobody checks. - Review quarterly and after every incident, new corridor, or rule change. ## How is this different from an incident playbook? A risk register is written before anything breaks; a playbook is used while something is breaking. The [blockchain payment incident playbook](/resources/more/blockchain-payment-incident-playbook) covers the six steps once a payment goes wrong, with a short register of its own. This page adds scoring, indicators, and a starter set you can paste into a spreadsheet. ## What columns should the register have? Ten columns. Fewer and auditors find gaps; more and nobody keeps it current. | Column | What goes in it | | --- | --- | | ID | Short code, for example SC-01 | | Category | One of the six categories below | | Risk | What could happen, in one sentence | | Cause | Why it would happen | | Inherent score | Likelihood x impact with no controls (1 to 25) | | Controls | What you do to reduce it | | Residual score | Likelihood x impact with controls in place | | Key risk indicator | A number you can measure that rises before the risk hits | | Owner | One named person | | Last reviewed | Date and reviewer | ## How do you score likelihood and impact? Use a 1 to 5 scale for each and multiply. Define the scale in your own numbers before you score anything. | Score | Likelihood | Impact (example definitions, set your own) | | --- | --- | --- | | 1 | Less than once in 5 years | Loss under a small set amount; no customer affected | | 2 | Once in 2 to 5 years | Small loss; a few payouts delayed by a day | | 3 | Once a year | Moderate loss; a corridor paused for a day | | 4 | Several times a year | Large loss; many customers affected; regulator notification possible | | 5 | Monthly or more | Loss that threatens the program; license or banking relationship at risk | Scores of 15 and above need a control plan and a sponsor sign-off. Scores of 8 to 14 need an owner and an indicator. Below 8, record the risk and review it quarterly. This tiering follows the logic of enterprise risk frameworks such as [COSO's enterprise risk management guidance](https://www.coso.org/enterprise-risk-management): tie risk appetite to what the business can absorb, then act on what exceeds it. ## What are the 16 starter risks? Copy these rows, then rescore them for your volumes and corridors. The scores below are illustrative, for a mid-size payout program, not a benchmark. ### Stablecoin and issuer | ID | Risk | Cause | Inherent | Controls | Residual | Indicator | Owner | | --- | --- | --- | --- | --- | --- | --- | --- | | SC-01 | Stablecoin trades below one dollar while you hold it | Reserve problem at the issuer | 3x4 = 12 | Hold for minutes, not days; cap holdings per token; execute only against locked quotes | 2x2 = 4 | Market price of each token you hold; hours of holdings | Treasury | | SC-02 | Issuer freezes a token at an address you pay from or to | Address linked to illicit activity | 2x4 = 8 | Wallet screening before sending; registered wallets only | 1x3 = 3 | Screening alerts per month | Compliance | The depeg row is not theoretical. When Silicon Valley Bank failed in March 2023, USDC traded as low as 86 cents, per a [December 2025 Federal Reserve note](https://www.federalreserve.gov/econres/notes/feds-notes/in-the-shadow-of-bank-run-lessons-from-the-silicon-valley-bank-failure-and-its-impact-on-stablecoins-20251217.html). It recovered within days. A payment flow that converts within minutes is far less exposed than a treasury that holds for weeks, which is why holding time is the indicator. [Stablecoin depeg risk for payment companies](/resources/more/stablecoin-depeg-risk-payments) covers the limits in detail. ### FX and liquidity | ID | Risk | Cause | Inherent | Controls | Residual | Indicator | Owner | | --- | --- | --- | --- | --- | --- | --- | --- | | FX-01 | Rate moves between approval and execution | Slow approvals; quote expiry | 4x2 = 8 | Approve intent, then execute within the quote window; re-quote tolerance in the FX policy | 2x2 = 4 | Quote expiry rate; re-quote delta | Treasury | | FX-02 | Thin local-currency liquidity on a large payout | Payout size above what the corridor absorbs at a good price | 3x3 = 9 | Split large payouts; test depth with quotes at several sizes | 2x2 = 4 | Spread versus mid-market by payout size | Treasury | | FX-03 | Funds stuck on the wrong chain for the corridor | Treasury holds USDC on a network the payout doesn't take | 3x2 = 6 | Map each corridor to supported networks; rebalance ahead of payout runs | 1x2 = 2 | Payouts blocked by network mismatch | Engineering | Measure FX-01 before you set a tolerance. [Payout quality metrics](/resources/more/payout-quality-metrics-slippage-expiry-rate) defines quote expiry rate and re-quote delta. ### Counterparty and custody | ID | Risk | Cause | Inherent | Controls | Residual | Indicator | Owner | | --- | --- | --- | --- | --- | --- | --- | --- | | CP-01 | Payout provider fails or freezes operations | Insolvency, license loss, banking partner loss | 2x5 = 10 | Know who holds funds at each step; avoid idle balances at the provider; second provider for top corridor | 1x4 = 4 | Idle balance at provider; provider status page incidents | Finance | | CP-02 | Payout fails after the stablecoins were collected | Recipient bank rejects; review times out | 3x3 = 9 | Written refund rules per rail; status webhooks into your ledger; refund wallet set on each quote | 2x2 = 4 | Payouts in failed or refunded per week; days to refund | Operations | For CP-01, map the failure modes in [what happens if a stablecoin payment provider fails](/resources/more/what-happens-if-a-stablecoin-payment-provider-fails) before you sign. ### Compliance | ID | Risk | Cause | Inherent | Controls | Residual | Indicator | Owner | | --- | --- | --- | --- | --- | --- | --- | --- | | CO-01 | Payment to a sanctioned person or address | Recipient or wallet on a sanctions list | 2x5 = 10 | Screen recipients and wallets before the first payout and on list updates | 1x5 = 5 | Screening hits; time since last rescreen | Compliance | | CO-02 | Travel Rule data missing on a transfer | Counterparty provider asks for originator or beneficiary data you didn't collect | 3x3 = 9 | Collect originator and beneficiary data at onboarding | 2x2 = 4 | Transfers held for missing data | Compliance | | CO-03 | Customer or payout held for a request for information | Incomplete KYC or KYB, unusual activity | 4x2 = 8 | Answer within days, not weeks; keep invoices and source-of-funds documents ready | 3x1 = 3 | Open information requests and their age | Compliance | Sanctions screening on wallets needs analytics, not just a list check: [OFAC FAQ 562](https://ofac.treasury.gov/faqs/562) says listed digital currency addresses are not likely to be exhaustive. For CO-02, FATF adopted a [revised Recommendation 16](https://www.fatf-gafi.org/en/publications/Fatfrecommendations/update-Recommendation-16-payment-transparency-june-2025.html) on payment transparency in June 2025, with implementation expected by the end of 2030, so expect data requests to grow. ### Operations and technology | ID | Risk | Cause | Inherent | Controls | Residual | Indicator | Owner | | --- | --- | --- | --- | --- | --- | --- | --- | | OP-01 | Payout sent to wrong bank account | Manual entry; recipient changed details | 3x4 = 12 | Validate details before the first payout; re-approval on changes; small first payout | 2x3 = 6 | Bank returns; detail changes per month | Operations | | OP-02 | Same obligation paid twice | Retry after a timeout | 3x3 = 9 | Idempotency key on every create call; one internal ID per obligation | 1x3 = 3 | Duplicate payouts found in reconciliation | Engineering | | OP-03 | Tokens sent on the wrong network | Address or network mismatch | 2x4 = 8 | Network and token fixed by the quote; allowlisted addresses | 1x3 = 3 | Funding transactions rejected | Engineering | | OP-04 | Payout lands after a rail's cut-off | Weekend, holiday, batch timing | 4x1 = 4 | Rail calendar in the payout scheduler; tell recipients the expected date | 2x1 = 2 | Payouts credited later than promised | Operations | OP-02 is the cheapest to remove. A retried create call with the same `Idempotency-Key` header replays the original response instead of creating a second payout ([idempotency](/docs/learn/idempotency)). ### Legal and regulatory | ID | Risk | Cause | Inherent | Controls | Residual | Indicator | Owner | | --- | --- | --- | --- | --- | --- | --- | --- | | LR-01 | Rules change in a corridor you pay into | New stablecoin, FX, or VASP rules | 3x4 = 12 | Dated legal sign-off per corridor; quarterly regulatory review | 2x3 = 6 | Days since last corridor review | Compliance | | LR-02 | Your own flow needs a license you don't hold | Holding customer funds or transmitting on their behalf | 2x5 = 10 | Legal opinion on the flow before launch; licensed provider for the regulated steps | 1x4 = 4 | Flow changes since the last opinion | Legal | US rules are moving on a schedule. The [GENIUS Act](https://www.congress.gov/119/bills/s1582/BILLS-119s1582enr.htm), signed in July 2025, sets deadlines measured from its enactment and effective dates, so LR-01 belongs on a calendar, not only in a table. The [GENIUS Act timeline](/resources/more/genius-act-timeline-key-dates) lists the dates. ## What do auditors and banking partners look for? Three things: that each risk has an owner, that indicators are measured, and that reviews happened. Rows whose score doesn't move between inherent and residual are controls that exist on paper only, so expect questions there. Keep the review log next to the register: ```text REVIEW LOG Date Trigger Attendees Changes made [date] Quarterly review [names] [rows rescored, controls added] [date] New corridor: [X] [names] [new rows FX-04, LR-03] [date] Incident [ID] [names] [OP-01 residual raised to 3x3] ``` ## How does BlindPay handle the risks it owns? Several controls in this register map to the provider's side of the flow. On BlindPay, each payout quote locks the rate and fees for 5 minutes ([payout quotes](/docs/payout-quotes)), KYC and KYB run in the same API, and payouts report `processing`, `on_hold`, `completed`, `failed`, or `refunded` through webhooks ([payouts](/docs/payouts)). BlindPay operates as a non-custodial payment processor for payout flows from customer-controlled wallets: you authorize the exact amount and BlindPay executes that single transaction. If a payout cannot be delivered after the stablecoins are collected, BlindPay refunds them to the quote's refund wallet, or to the sending wallet when none is set; on Pix and other non-USD local rails the refund is automatic, while USD payouts and payouts whose review times out are refunded after an operator review. Optional BlindPay-managed wallets (beta) are custodial when you choose that path. ## What to do next Paste the 16 rows into a spreadsheet, put a name in every owner cell, and rescore each row with your own volumes. Then book the first quarterly review before you send the first live payout.