Check out our latest blogs

Stablecoin issuers carry a distinct set of custody requirements that go beyond standard digital asset safekeeping. Reserve segregation, real-time reconciliation, redemption processing, and regulatory reporting each place specific demands on the custody infrastructure underlying a stablecoin programme. Getting these right at the architecture stage is significantly cheaper than integrating them ad-hoc after launch.

Regulatory frameworks such as MiCA, VARA, and ADGM treat proof of reserves, redemption mechanics, and operational reporting as live, ongoing requirements rather than periodic filing obligations. Custody infrastructure that cannot support these functions continuously creates regulatory exposure that compounds over time.

The Three-Party Accountability Structure of a Stablecoin Issuer

A stablecoin issuer is situated at the intersection of three stakeholders: token holders, the entity maintaining the reserve, and the regulatory entity monitoring both. This triage shapes the custody requirements that stablecoin issuers must meet.

Each of these three parties places distinct yet overlapping demands on the custody system, which is why custody architecture cannot be designed around the requirements of any single stakeholder alone.

Unlike traditional digital asset platforms that hold customers’ digital assets in custody, the issuer of a stablecoin assumes direct responsibility for the reserves backing each unit of the stablecoin in circulation. What makes a stablecoin issuer accountable?

When your institution has issued 100 million units of stablecoin, your reserve account must hold 100 million in cash or approved securities at all times. Consider a timing scenario: month-end closes with 95 million in reserves and 100 million in outstanding tokens because redemptions have cleared but inbound deposits from cross-border transfers have not yet settled. Your auditor will flag a shortfall. Your regulator will want an explanation. Whether that situation is documented as a routine timing variance or escalates into a regulatory inquiry depends entirely on whether your custody system can automatically detect, record, and classify the event in real time.

Custody systems are foundational for a reason that is often understated: their primary function for stablecoin issuers is not security, though that remains essential, but control. They enforce reserve segregation to prevent operational or customer funds from being commingled with reserve assets. They ensure that transfers in and out of reserve accounts follow defined approval workflows, with no single operator able to move assets unilaterally. And they create a continuous, independently verifiable record of every event, available to external auditors at any time, not just at reporting intervals.

Reserve Attestation: Proof Over Assertion

Reserve attestation is the process of continuously proving to regulators and the public that the assets backing a stablecoin exist in the stated form and quantity. Most issuers treat it as a periodic reporting exercise, but this creates a structural gap. A monthly attestation produced 30 days after the reference date shows historical status. It does not show current status, and regulators in MiCA and ADGM jurisdictions are increasingly treating that distinction as material.

Meeting that standard requires three things from custody infrastructure:

Dedicated reserve accounts. Reserve assets must be held in accounts used exclusively for that purpose, segregated at the account level from operational and customer funds. Spreadsheet conventions are not a substitute for account-level enforcement.

Daily reconciliation. Discrepancies between the ledger and reserve accounts, whether caused by pending transfers, settlement timing, or errors, must be flagged by the custody system immediately rather than allowed to accumulate until the next attestation cycle.

Accessible audit trails. Every movement in and out of reserve accounts needs a timestamp, a counterparty record, and a settlement confirmation. External auditors should be able to retrieve this data directly, not reconstruct it from email chains.

Redemption Processing: What Custody Infrastructure Must Handle Under Stress

Redemption is when token holders exchange stablecoins for value reserves. From a custody perspective, this is not just a theoretical commitment but an active operation that must be executed consistently, even during periods of market turmoil.

Redemption is not a theoretical commitment. It is an active operational obligation that the custody system must fulfil consistently, including during periods of market stress. Three requirements follow from this:

Unconditional reserve availability. Reserves must be accessible for redemption without requiring external approvals for each individual transaction. Any approval dependency creates a chokepoint that can stall redemptions when volume spikes.

Volume scalability. The custody infrastructure must be sized to handle redemption spikes, not just normal operational volumes. A system built for average load will create backlogs precisely when fast processing matters most to holder confidence.

Per-redemption audit trails. Every redemption must generate a complete record: request timestamp, reserve movement, and settlement confirmation. This is a regulatory requirement under most frameworks and a practical necessity for dispute resolution.

Reserves must also be maintained in genuinely liquid assets. Holding reserves in instruments that are theoretically safe but practically illiquid solves the wrong problem: during a redemption spike, the question is not whether reserves exist but whether they can be converted and transferred within the timeframe holders expect. Custody infrastructure should support reserve composition reviews that account for this liquidity requirement, not just credit risk

Regulatory Reporting: Building a Single Source of Truth

Regulatory reporting requirements differ across MiCA, ADGM, MAS, and other frameworks that stablecoin issuers operate under. What they share is an expectation that issuers can produce accurate, timely reports on reserve composition, redemption volumes, and operational metrics on demand, not just at quarterly intervals. Custody infrastructure that treats reporting as a downstream export function rather than a continuous data function creates the risk of reconciliation gaps that surface only when a regulator submits a specific data request.

The operational requirement is a single system of record for reserves, redemptions, and compliance metrics. When these are tracked across separate systems, each reporting cycle becomes a reconciliation exercise, and discrepancies are typically discovered only when a regulator or auditor requests a specific data set. By that point, the correction is reactive rather than routine. Custody infrastructure that maintains a unified ledger across all reserve activity eliminates this risk structurally rather than procedurally.

Final Thoughts

Custody problems that arise for many stablecoin issuers often do not show themselves until it is too late. They tend to happen only when something goes wrong. For instance, if a compliance officer flags an attestation reconciliation discrepancy or a regulator requests a specific transaction set, issuers are usually unable to retrieve this data within 24 hours.

In addition, if a spike in redemption volume occurs but the issuers’ custody infrastructure cannot handle it within, say, 2 to 3 days, it poses serious problems for issuers of stablecoins that use custodial networks.

Stablecoin programmes that scale are built on custody architecture decisions made before the first token is issued, not after the first audit finding. They built operational processes around those constraints, not the other way around. When evaluating custody infrastructure, the questions are not about features or pricing. Ask whether the system was built for stablecoin issuer operations.

Liminal Custody has worked with stablecoin issuers across APAC and MENA through these operational decisions. The pattern is consistent: issuers that invested in purpose-built custody infrastructure early on adapted to regulatory changes and redemption spikes without resorting to emergency procedures. Those who treated custody as secondary discovered that fixing the gaps became expensive.