Internal controls for stablecoin payments
The control framework auditors are already asking for, written in the language of a disbursement cycle rather than a blockchain.
Controls over stablecoin payments serve the same objectives as controls over wires — authorisation, accuracy, safeguarding of assets — but they must be preventive rather than detective, because settlement cannot be reversed. In practice that means whitelisted destinations, segregation of duties, an approval quorum sized to value, screening before release, and an evidence record that ties policy, approvers and transaction hash together.
The control matrix
| Risk | Control | Evidence produced |
|---|---|---|
| Payment to an attacker-supplied address | Destination whitelist on the counterparty record; changes re-approved | Change log with requester, approver, timestamp |
| Unauthorised disbursement | Segregation of duties: preparer cannot release | Distinct requester and approver identities on the payment |
| Single compromised device | MPC quorum signing — m-of-n approvals | Signature set stored with the transaction |
| Sanctions breach | Screening at intent, blocking release on a hit | Screening result timestamped before the hash |
| Value beyond delegated authority | Tiered limits by amount, asset and counterparty | Policy version applied to the payment |
| Silent weakening of controls | Admin-only policy edits requiring full quorum | Immutable policy change history |
| Vendor lock-in / continuity | Self-custody with documented key export | Tested recovery procedure |
Segregation of duties in a small team
The objection we hear most is that a four-person finance team cannot segregate anything. It can — the split is by action, not by department. One person prepares payment runs and maintains the counterparty register. Two others hold signing keys and approve. An administrator owns policy but does not prepare payments. Nobody holds both the preparation right and a majority of signing keys, and that is the whole requirement.
- Preparer: builds payment runs, cannot release.
- Approvers: two or more signers, cannot create a payee.
- Administrator: owns policy and roles, changes require quorum.
- Observer: read-only access for the auditor and the CFO.
Building the evidence pack
- 01The current policy document: limits, approvers, quorum, whitelisted destinations.
- 02The policy change log for the period, showing who requested and who approved each change.
- 03A sample of payments with requester, approver, policy version, screening result and hash.
- 04The list of blocked payment attempts — proof the preventive control fires.
- 05The counterparty register with dates each destination was added and verified.
- 06Key custody documentation, including the recovery procedure and when it was last tested.
- 07Reconciliation of on-chain balances to the ledger at period end.
Common deficiencies
| What we see | Why it fails | Fix |
|---|---|---|
| One shared hardware wallet | No segregation, no recovery, no attribution | Quorum signing with per-person keys |
| Screening run weekly | Not preventive; the payment already settled | Screen at intent, block on hit |
| Addresses pasted per payment | Address substitution is the top loss cause | Whitelist on the counterparty record |
| Approvals in a chat thread | Not tied to the transaction, easy to forge | Approval captured cryptographically at signing |
| Policy edited by any operator | Control can be removed before misuse | Admin-only, quorum-approved policy changes |
How Stablerail enforces this
Roles, limits and approval quorums are configured once at organisation level and apply to every vault automatically. Only administrators can edit policy, and a change requires the same signing quorum as a payment. Screening runs before release, and each payment exports with its policy version, approvers, screening result and hash — the evidence pack above, generated rather than assembled.
Frequently asked questions
What internal controls do auditors expect over stablecoin payments?
Segregation of duties between preparer and approver, an approval quorum sized to value, a whitelist of permitted destinations, sanctions screening evidenced before execution, documented key custody with a recovery path, and an immutable log of every policy or signer change.
Is SOX applicable to crypto payments?
If you are a US public filer, controls over stablecoin payments sit inside the same ICFR scope as any other disbursement process. The control objectives do not change — authorisation, completeness, accuracy, safeguarding of assets — only the evidence format does.
What is the minimum viable control set for a small finance team?
Four things: destinations must be whitelisted and changes re-approved, no single person can both create and release a payment, screening runs before release, and keys require a quorum. A two-person team can run all four; below that you should not be moving material value.
How do you evidence a control that runs on-chain?
Store the policy version, the requester, the approver identities, the screening result and the transaction hash as one record, timestamped in that order. The auditor can verify the hash independently, which is stronger evidence than a bank statement.
Should controls be preventive or detective?
Preventive, because on-chain payments cannot be recalled. Detective controls still matter for reconciliation and investigation, but a framework built only on after-the-fact review will be graded as a deficiency for an irreversible payment rail.
Who should be allowed to change a payment policy?
Only administrators, and a change should require the same signing quorum as a payment. Policy is organisation-level, so a change affects every vault at once — treating it as a routine setting is the most common gap we see.
Keep reading
One account for stablecoin treasury, cards and payouts.
Receive, approve, screen, pay, card-spend and off-ramp — with audit evidence on every transaction.