A stablecoin payments risk register is a table that lists every way a payment flow can fail, scored for likelihood and impact before and after controls, with the control in place, an early indicator and one named owner. The template below gives 20 starter rows in six categories, including four tied to specific local rails.
Most registers stop at the blockchain, but a payout also crosses a deposit rail, a conversion, a stablecoin corridor and a bank, and each leg fails differently. Copy the rows into a spreadsheet and rescore them.
What columns should the register have?
Seven. Fewer and an auditor cannot follow it; more and it goes stale.
The seven columns used in every table below, and what goes in each.
Column | What goes in it |
ID | A short code per row, such as FX-01 |
Risk and cause | What happens and why, in one sentence |
Inherent | Likelihood times impact, no controls |
Control | What you do, phrased so someone can verify it |
Residual | Likelihood times impact, control working |
Indicator | A number that rises before the risk lands |
Owner | One named person, never a team |
A row whose residual equals its inherent score is a control that exists on paper.
Score each risk twice, on a scale you define
Rate likelihood and impact from 1 to 5 and multiply, so every row lands between 1 and 25. Write the scale in your own amounts first.
An example scale. Replace the impact column with amounts that matter to your business.
Score | Likelihood | Impact (example definitions) |
1 | Less than once in five years | A few payments delayed |
2 | Once in two to five years | A payout run delayed by a day |
3 | About once a year | A corridor paused for a day |
4 | Several times a year | A loss above your tolerance |
5 | Monthly or more | A loss that threatens a banking relationship |
At 15 or above a row needs a control plan and a sponsor. From 8 to 14 it needs an owner and an indicator. Below 8, record it and revisit quarterly.
What are the 20 starter risks?
Six categories, from the asset to the rail. After each table, a short note says what the matching mechanism looks like on Lumx, from the docs read on November 1, 2026.
Issuer and network
Three risks that come with holding a stablecoin on a blockchain.
ID | Risk and cause | Inherent | Control | Residual | Indicator | Owner |
IN-01 | The coin you hold trades below one dollar after a reserve problem at the issuer | 3x4 = 12 | Hold balances only as long as payouts need; cap each wallet | 2x2 = 4 | Hours between funding and payout; market price of each coin held | Treasury |
IN-02 | The issuer freezes an address you send to or receive from | 2x4 = 8 | Screen counterparties before the first transfer | 1x3 = 3 | Screening alerts per month | Compliance lead |
IN-03 | A transfer to an external wallet goes to the wrong blockchain or address | 2x5 = 10 | Allowlist addresses; send a small first transfer | 1x3 = 3 | Failed or disputed external transfers per month | Operations |
The depeg row is real: the Federal Reserve's FEDS Note on the 2023 Silicon Valley Bank failure records USDC at 86 cents, so holding time is the indicator. Network choice, such as USDT on Tron, belongs to the corridor, not the sender.
On Lumx, every customer gets a wallet on each supported blockchain, holding USDC and USDT between operations. Reading the customer returns each balance with an updatedAt time, the raw data for IN-01. A transfer names the blockchain on the request and falls back to the default only when you omit it.
FX and liquidity
Three risks between the price you quote and the money that lands.
ID | Risk and cause | Inherent | Control | Residual | Indicator | Owner |
FX-01 | The rate moves between the price you showed and the payout | 4x2 = 8 | Quote with a locked rate and execute inside its window | 2x2 = 4 | Share of locked quotes that expire unused | Treasury |
FX-02 | No liquidity at an acceptable price for a large payout | 3x3 = 9 | Quote at several sizes; split large payouts | 2x2 = 4 | Executed rate against the floating rate, by payout size | Treasury |
FX-03 | A standing conversion executes at a rate nobody reviewed | 3x3 = 9 | Use a standing rule only where market rate is acceptable; lock a one-off quote for fixed prices | 2x2 = 4 | Gap between expected and executed rate per deposit | Finance |
Liquidity has its own depth in liquidity risk in global payouts.
On Lumx, a locked rate holds for 30 seconds, one minute or five minutes; the 30-second lock has no fee and the longer ones include one. An expired lock returns EXCHANGE_RATE_EXPIRED and a pair with no depth returns NO_LIQUIDITY_PROVIDER, so both are countable. An autoconversion rule always converts at market, and a locked rate exists only on a one-off transaction.
Counterparty and funds held
Three risks about who holds the money while it is in motion.
ID | Risk and cause | Inherent | Control | Residual | Indicator | Owner |
CP-01 | The provider fails, loses a banking partner or freezes operations | 2x5 = 10 | Keep idle balances low; document an exit path; qualify a second provider | 1x4 = 4 | Balance at the provider against the next seven days of payouts | Finance |
CP-02 | The party holding your stablecoin cannot release it | 2x5 = 10 | Get written answers on who holds the keys, how balances are segregated and how withdrawals are authorized | 1x4 = 4 | Days since the last written confirmation; result of a small test withdrawal | Finance |
CP-03 | A payout fails after the stablecoin was already spent | 3x3 = 9 | Write down what happens to funds per rail; log failure events | 2x2 = 4 | Payouts in a failed state per week; days to resolve each | Operations |
For CP-01, using two stablecoin providers is the control with a cost. For CP-02, read what a custodial wallet is, and custodial and non-custodial wallets for businesses if you are choosing a model.
On Lumx, wallets are custodial, held by BitGo, which carries insurance, one per customer per blockchain, with every client fully segregated and no omnibus account. A payout debits the customer's own wallet to a destination registered under that customer. An off-ramp counts as complete once the funds leave the banking partner, and a failed one emits offramp.failed, so CP-03 is a webhook you can store. A held transaction left unanswered for 24 hours may be refunded to the sender.
Sanctions and holds
Three risks that stop a payment or put the account at stake.
ID | Risk and cause | Inherent | Control | Residual | Indicator | Owner |
CO-01 | A payment reaches a sanctioned person | 2x5 = 10 | Verify every payer and payee; rescreen on list updates; screen wallets with analytics, since OFAC says its address listings are not likely to be exhaustive | 1x5 = 5 | Screening hits; days since the last rescreen | Compliance lead |
CO-02 | A transaction is held and the request for information goes unanswered | 3x3 = 9 | Name who answers; keep purpose and relationship documents ready | 2x2 = 4 | Open requests and their age in hours | Compliance lead |
CO-03 | Funds belong to a party the provider cannot see | 2x5 = 10 | Disclose the relationship on every destination; ask whose money it is | 1x4 = 4 | Destinations by relationship type; payouts with no disclosed relationship | Compliance lead |
On Lumx, KYB (know your business, the verification of a company and its owners) and KYC (know your customer, the verification of an individual) run through Sumsub, blockchain monitoring runs through Chainalysis, and fiat flows are monitored with Lumx's own systems plus the banking partners' oversight. A held transaction becomes an RFI (request for information, a compliance hold that asks for a document before a transaction clears). Every destination carries a holder relationship such as SUPPLIER or EMPLOYEE, and the nested payments rule asks whose money it is and whose business it pays for.
Operations and technology
Four risks that live in your own code and processes.
ID | Risk and cause | Inherent | Control | Residual | Indicator | Owner |
OP-01 | The same obligation is paid twice after a retry | 3x4 = 12 | One idempotency key and one internal ID per obligation | 1x3 = 3 | Duplicates found in the daily match | Engineering |
OP-02 | A webhook is missed, replayed or forged, and the ledger drifts | 3x3 = 9 | Verify signatures; deduplicate on event ID; read the transaction when an event is late | 2x2 = 4 | Events not received inside the expected window | Engineering |
OP-03 | Beneficiary data does not match the bank account | 4x3 = 12 | Check tax ID against holder name at onboarding; send a small first payout | 2x2 = 4 | Rail rejections per 1,000 payouts | Operations |
OP-04 | A payout run stops halfway because a limit is reached | 3x3 = 9 | Read the remaining limit first; split runs; request increases early | 2x2 = 4 | Remaining daily limit at the start of each run | Operations |
OP-01 is the cheapest row to remove: see idempotency keys, and stablecoin API webhooks for OP-02. The codes behind OP-03 are in why stablecoin payouts get rejected, and the numbers behind OP-04 in payout limits and cut-offs by rail.
On Lumx, an Idempotency-Key header (a UUID v4) returns the cached response for 24 hours, and the same key with a different body returns a 409. Webhooks are signed with HMAC-SHA256, the docs advise rejecting messages older than five minutes, and a failed delivery is retried up to eight times before you can retry it from the Dashboard. Reading a customer with includeTransactionLimits=true returns used and remaining amounts per transaction type, and an over-limit transaction returns 422 with TRANSACTION_LIMIT_EXCEEDED.
Local rails
The rows cover Pix (Brazil's instant payment system, run by the Central Bank), SPEI (Mexico's interbank transfer system, run by Banxico), PSE (Colombia's online bank-transfer network) and ACH. A wrong CLABE (the 18-digit Mexican bank account number) is the SPEI payout failure.
Four risks that a generic register misses because they belong to one rail each.
ID | Risk and cause | Inherent | Control | Residual | Indicator | Owner |
RL-01 | A Pix deposit is pulled back through its special return mechanism (MED) after you treated it as final | 2x4 = 8 | Treat a new payer's first large deposit as unsettled until your review window passes | 1x3 = 3 | Returned deposits per 1,000 | Risk lead |
RL-02 | A SPEI deposit arrives without its reference, or a payout goes to a wrong CLABE | 3x3 = 9 | Show the reference beside the CLABE; check the check digit before saving a destination | 1x3 = 3 | Unmatched deposits per week; CLABE rejections | Operations |
RL-03 | A PSE collection lapses because the payer's bank fails mid-authorization | 3x2 = 6 | Offer a second collection method; retry before expiry | 2x2 = 4 | Share of PSE collections that expire | Product |
RL-04 | An ACH payout misses the 2:00 PM ET cut-off, or comes back after it showed complete | 3x3 = 9 | Put cut-offs in the scheduler; read complete as left the sender's bank, not credited | 2x2 = 4 | Payouts credited later than promised; returns per 1,000 | Operations |
On Lumx, Pix and SPEI run all day every day with no cut-off, and the cut-off page notes that Brazilian holidays can still affect dispute windows. With several autoconversion rules, a SPEI deposit is matched by its memo; with no memo it converts at the floating rate and no rule applies. COP collection runs over Bre-B (Colombia's instant payment system) and PSE, and a Bre-B payout above the 1,000 UVB cap is refused, never split. ACH has a 2:00 PM ET cut-off and takes one to two business days. A request after a cut-off goes out the next business day, and the beneficiary's bank can still hold funds for its own review.
Who should own each risk?
A named person, because shared ownership means nobody checks. Treasury owns the coin and rate rows, the compliance lead owns sanctions and holds, engineering owns retries and events, operations owns beneficiary data and cut-offs, and finance owns the provider rows. The owner reports on the control and the indicator at every review.
I would rather run a register with fewer rows that somebody owns than a long list copied from a template. My recommendation is one named person per row and a residual score that is allowed to stay high when the honest answer is that the control is weak. The first rows I would delete are the ones whose indicator nobody can read from a system, because a number remembered from a meeting is not an indicator.
On Lumx, the indicators map to things you can read: balances and limits on the customer, status events on each transaction and error codes on each refused request. Every error carries a request identifier, and that is what the owner quotes to support.
When to review the register
Review it every quarter and after an incident, a new corridor or rail, a provider change or a rule change in a country you pay into.
When a risk register is the wrong tool
It will not help before you have a flow to describe: scoring a payment that never ran produces numbers with no evidence. Run a few small payouts first, then score what you saw. A row whose control nobody built is an unmanaged risk with an official-looking cell. When something is already breaking, use an incident process, starting with when a blockchain payment goes wrong.
What this looks like on a Lumx payout run
Lumx is stablecoin payments infrastructure for businesses that move money between Latin America and the rest of the world: one API to collect, hold, convert, and pay out in BRL, MXN, COP, USD, EUR, and GBP or in USDC and USDT, over local rails such as PIX, SPEI, PSE, Bre-B, ACH, FEDWIRE, SEPA, and Faster Payments, with SWIFT and on-behalf-of payments and collections (POBO and COBO) in USD, EUR, and GBP, plus named virtual accounts, custodial wallets, and KYB/KYC built in.
Take a weekly supplier run. A standing rule converts the deposit, the run quotes each payout, and each one debits the customer's wallet to a registered destination. The rule maps to FX-03, the quote to FX-01, the destination to CO-03 and OP-03, the retry key to OP-01 and the events to OP-02 and CP-03. Rail availability is on the coverage page, and the pieces per country in global payments.
Methodology and sources
Product mechanisms come from the Lumx docs read on November 1, 2026: cut-off times, transactions, exchange rates, wallets, destinations, request for information, nested payments, limits, webhooks, idempotency, errors and autoconversion.
The USDC price in March 2023 comes from the Federal Reserve's FEDS Note on the Silicon Valley Bank failure and stablecoins, and the point on wallet screening from OFAC FAQ 562, both read on November 1, 2026. Every score is an illustrative starting point, not a measurement.
Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.
Cover photo: Vladimir Wang on Unsplash.
What is a stablecoin payments risk register?
It is a table of the ways a stablecoin payment flow can fail, each with a likelihood and impact score, a control, an early indicator and an owner. Banking partners ask for it because it shows the risks were thought through before money moved. On Lumx, most rows map to balances, status events and error codes you can read.
How do you score risks in the register?
Rate likelihood and impact from 1 to 5 and multiply, once with no controls and once with the control working, and write down what each number means in your own amounts. On Lumx, limits that cap impact are published per transaction type, and reading a customer with includeTransactionLimits=true shows how much of each remains.
Who should own each risk in a stablecoin payment flow?
One named person per row. Treasury takes the coin and rate rows, the compliance lead takes sanctions and holds, and engineering takes retries and events. On Lumx, the owner of a held transaction is whoever answers the request for information by email or Slack, so name them before the first live payment.
How often should the register be reviewed?
Quarterly, and after an incident, a new corridor or rail, a provider change or a rule change in a country you pay into. On Lumx, each rail has its own cut-off and settlement window in the docs, so a review is also the moment to check that your scheduler still matches them.
