MiCA, DORA & mint/burn reference

Purpose: Comparative reference for designing an EMI backoffice for EMT issuance and redemption, drawing on public disclosures from Circle (EURC/USDC), SG-Forge (EURCV), Tether (USDT), and the MiCA + DORA regulatory frameworks. Status: Draft v0.2

---

1. Comparative Overview — How Major Issuers Structure Mint/Burn

1.1 Circle (EURC / USDC)

Entity & licence: Circle France SAS — licensed as an EMI by the ACPR (France). First global stablecoin issuer to achieve MiCA compliance (July 2024).

Who can mint: Only Circle Mint customers — institutional counterparties (exchanges, wallet providers, banks, fintech companies). Access requires thorough KYC/KYB onboarding including ID verification, background checks, and sanctions screening. Onboarding can take several weeks.

Minting process:

1. Circle Mint customer initiates a conversion request via Circle API or dashboard.
2. Customer transfers EUR (for EURC) or USD (for USDC) to Circle's designated bank account.
3. Circle confirms receipt of funds.
4. Equivalent amount of tokens is minted via the smart contract and credited to the customer's Circle Mint account (on-chain wallet).

Redemption process:

1. Customer initiates redemption request through Circle Mint.
2. Circle sends the customer's tokens to the burn address via the smart contract.
3. Tokens are taken out of circulation ("burned").
4. Circle transfers the equivalent fiat to the customer's linked bank account.

Key characteristics:

• 1:1 par value issuance and redemption — no fees on standard redemptions.
• Redemption right at any time and at par value per MiCA Art. 49.
• Available in 185 countries.
• Reserves: euro-denominated cash + short-term European government bonds.
• MiCA whitepaper notified to ACPR on 31 May 2024 (amended Sep 2024, Dec 2025).
• Redemption policy published separately under MiCA requirements.

Operational model: Highly automated API-driven flow. Mint and burn are programmatic for approved counterparties. The manual/human layer is concentrated in onboarding (KYB) and compliance screening, not in transaction-by-transaction approval.

---

1.2 SG-Forge (EUR CoinVertible / EURCV)

Entity & licence: Société Générale – FORGE — licensed as an EMI by the ACPR (France), effective 30 June 2024 under MiCA.

Who can mint: Exclusively qualified institutional counterparties (exchanges, market makers, institutional investors). Single onboarding process replicating banking-grade KYC/KYB standards.

Minting process:

1. Institutional investor completes onboarding with SG-Forge.
2. Investor submits a subscription request for EURCV.
3. Investor transfers EUR 1:1 to SG-Forge's segregated bank account at Société Générale.
4. If fiat is confirmed by the deposit bank before 16:00 CET on a business day, the corresponding EURCV is minted to the investor's Ethereum address by end of same business day.

Redemption process:

1. Holder submits a redemption request to SG-Forge (or via a Preferred Partner).
2. Holder transfers EURCV to the designated burn address.
3. SG-Forge burns the tokens and transfers EUR 1:1 to the holder's bank account.

Key characteristics:

• Strict institutional-only model — no retail direct access.
• Daily cut-off at 16:00 CET for same-day processing.
• Reserves held in segregated accounts at Société Générale, with daily publication of collateral composition and valuation.
• Multi-chain: Ethereum, Solana, XRP Ledger, Stellar.
• KYC/AML replicates Société Générale banking group standards.
• Continuous transaction monitoring.

Operational model: Bank-grade controls inherited from parent institution. Interaction is gated through a single onboarding checkpoint. Once onboarded, the mint/burn flow is operationally streamlined but still involves manual compliance confirmation before execution.

---

1.3 Tether (USDT)

Entity & licence: Tether Limited — incorporated in the British Virgin Islands. Not MiCA-compliant (relevant as a counter-example and for operational pattern reference).

Who can mint: Verified Tether customers. KYC registration and compliance approval required before any minting.

Minting process:

1. Customer completes KYC registration and receives compliance approval.
2. Customer transfers USD to Tether's designated bank account.
3. Tether confirms receipt and verification of funds.
4. Equivalent USDT is minted via smart contract.

Redemption process:

1. Customer submits redemption request.
2. Customer transfers USDT to Tether's treasury.
3. Tether burns the tokens.
4. USD is transferred to the customer's bank account.
5. Minimum redemption: $100,000 (historically). Fees applied on redemptions.

Key characteristics:

• Minimum redemption threshold — unlike MiCA-compliant EMTs which must allow any amount.
• Fees on redemption — not permitted under MiCA Art. 49 for EMTs.
• Quarterly reserve attestations (since 2021), not real-time.
• Large-scale burns are observable on-chain (Tether Treasury address).
• Not operating under EU regulatory framework.

Relevance: Tether's model illustrates what MiCA explicitly prohibits for EMTs: redemption thresholds and fees. It is useful as a "what not to do" reference for MiCA-compliant design.

---

2. Common Patterns Across Issuers

Aspect	Circle	SG-Forge	Tether	MiCA Requirement
Who can mint	Institutional (Circle Mint)	Institutional only	Verified customers	Not prescribed, but KYB/KYC required
Mint trigger	Fiat received → mint	Fiat received → mint	Fiat received → mint	Must issue at par on receipt of funds (Art. 49)
Redemption trigger	Customer request → burn → fiat	Customer request → burn → fiat	Customer request → burn → fiat	Must redeem at par, any time, on request (Art. 49)
Redemption fees	None	None	Yes (verification fee)	No fees permitted (Art. 49)
Minimum redemption	None	None	$100,000	No threshold permitted (Art. 49)
Cut-off time	Not publicly disclosed	16:00 CET	Not disclosed	Not prescribed, but must be "at any time" in substance
Reserve backing	Cash + short-term govt bonds	Segregated at Société Générale	Cash + equivalents + other assets	1:1, ≥30% in credit institution deposits (Art. 54)
Reserve transparency	Monthly attestation	Daily collateral publication	Quarterly attestation	Recovery & redemption plans required (Art. 46)
On-chain controls	Smart contract mint/burn	Smart contract mint/burn	Smart contract mint/burn	Not prescribed but implied by operational resilience
Interest/yield	Prohibited	Prohibited	Not offered	Strictly prohibited (Art. 50)

---

3. MiCA Regulatory Guardrails — Full Reference

3.1 Issuance Requirements

Rule	Article	Detail
Par value issuance	Art. 49	EMTs must be issued at par value (1 token = 1 unit of referenced currency). No premium or discount.
Issuance on receipt of funds	Art. 49	Tokens may only be minted after the issuer has received the corresponding fiat funds. Pre-minting is not permitted.
Issuer must be licensed	Art. 48(1)	EMTs can only be issued by a CRR credit institution or a licensed EMI under EMD2.
No interest or benefit	Art. 50	Issuers must not grant interest or any time-linked benefit to holders. This also applies to any third party acting on behalf of the issuer.

3.2 Redemption Requirements

Rule	Article	Detail
Redemption at par value	Art. 49	Holders have the right to redeem at par value at any time.
No fees on redemption	Art. 49	Redemption must be free of charge. No commissions or fees permitted. Exception only in recovery scenarios (Art. 46).
No minimum threshold	Art. 49	Redemption cannot be subject to a minimum amount.
Redemption in funds	Art. 49	Payout must be in funds (fiat bank transfer), not in other e-money or crypto-assets.
KYC/AML required	EMD2 + AMLD	Holder must be identified and verified before redemption proceeds. Origin of funds assessment required.

3.3 Reserve Requirements

Rule	Article	Detail
1:1 reserve backing	Art. 54	Every token in circulation must be backed by equivalent fiat reserves.
Minimum 30% in credit institutions	Art. 54	At least 30% of reserve funds must be held in segregated accounts at credit institutions.
Remainder in low-risk assets	Art. 54	Remaining reserves must be invested in secure, low-risk, highly liquid financial instruments.
Own funds requirement	Art. 54	Issuer must maintain own funds of at least 3% of the average amount of reserve assets.
Segregation	Art. 54	Reserve assets must be kept separate from the issuer's own assets.

3.4 Significant EMT Thresholds

If an EMT is classified as "significant" by the EBA, additional requirements apply:

Criterion	Threshold
Number of holders	More than 10 million
Market capitalisation / reserve assets	More than EUR 5 billion
Daily transactions (average)	More than 2.5 million
Daily transaction volume (average)	More than EUR 500 million
International scale	Cross-border usage assessment
Financial system interconnectedness	Qualitative assessment

If classified as significant:

• Direct supervision by the EBA (not national competent authority).
• Reserve deposit requirement increases to 60% in credit institution accounts (up from 30%).
• Enhanced interoperability, liquidity management policies, and stress testing.
• Higher capital requirements.

3.5 Recovery & Redemption Plans

Requirement	Article	Detail
Recovery plan	Art. 46	Must describe measures to restore compliance if the issuer fails to meet reserve or operational requirements. Must cover service preservation, business continuity, and restoration.
Redemption plan	Art. 46	Must describe orderly wind-down procedures including how all holders would be redeemed.
Notification	Art. 46	Both plans must be notified to the competent authority.
Emergency measures (recovery only)	Art. 46	In recovery scenarios, the plan may include: fees on refunds, limits on daily redeemable amounts, or suspension of redemptions. These are only permitted in crisis scenarios, not in normal operations.

---

4. DORA Requirements — Digital Operational Resilience (Regulation (EU) 2022/2554)

DORA applies to all financial entities in the EU, including EMIs. It entered into force on 17 January 2025. While MiCA governs what an EMT issuer must do (issue at par, redeem at par, maintain reserves), DORA governs how the technology and operations supporting those activities must be protected. For an EMI operating on-chain infrastructure, DORA is the regulation that turns principle-based security expectations into concrete, auditable obligations.

4.1 Governance (DORA Art. 5)

Requirement	Detail	Backoffice Impact
Management body responsibility	The management body must define, approve, oversee, and be responsible for the implementation of all ICT risk management arrangements.	Board or management body must formally approve the ICT risk management framework covering mint/burn infrastructure, wallet management, and key custody. Cannot be delegated entirely to IT.
Adequate budget and resources	The management body shall allocate and review at least annually the budget for ICT and digital operational resilience, including training.	Budget for HSMs, custody platforms, security audits, and penetration testing must be a board-level line item.
ICT risk awareness	Members of the management body shall actively keep up to date on ICT risk, including by undergoing specific training.	Board members need training on blockchain-specific risks (key compromise, smart contract vulnerabilities, bridge exploits).

4.2 ICT Risk Management Framework (DORA Art. 6)

Requirement	Detail	Backoffice Impact
Comprehensive framework	Financial entities shall have an ICT risk management framework including strategies, policies, procedures, protocols and tools to protect all information assets and ICT assets.	Must cover: smart contract infrastructure, wallet architecture, multisig configuration, node infrastructure, blockchain monitoring tools.
Segregation and independence	ICT risk management functions, control functions, and internal audit must be segregated per the three lines of defence model.	The team that operates on-chain (OP) cannot self-audit. Compliance (CO) acts as second line; internal audit as third line.
Annual review	Framework must be documented and reviewed at least annually, after major incidents, and after audit findings.	Annual review cycle for all on-chain operational procedures.
Continuous improvement	Framework must be continuously improved based on lessons from implementation, monitoring, and incidents.	Post-incident reviews after any failed transaction, key rotation event, or security alert must feed back into procedures.

4.3 ICT Asset Identification and Mapping (DORA Art. 8)

Requirement	Detail	Backoffice Impact
Identify all ICT assets	Financial entities shall identify, classify, and adequately document all ICT-supported business functions, information assets, and ICT assets.	Must maintain a register of: all wallet addresses (operational, redemption, treasury), smart contract addresses, multisig configurations, node endpoints, RPC providers, blockchain monitoring services, HSM devices/instances, key identifiers.
Map dependencies	Shall map configuration of ICT assets and links/interdependencies between them.	Map the full chain: backoffice system → API → signing service → HSM → multisig wallet → smart contract → blockchain. Document every dependency.
Annual review	Classification and documentation must be reviewed at least yearly.	Wallet inventory and smart contract dependency map reviewed annually minimum.
Critical asset classification	Shall identify which assets are critical.	Minting keys, the token smart contract, and the multisig wallet are unambiguously critical ICT assets.

4.4 Encryption and Cryptographic Controls (DORA RTS Art. 6)

Requirement	Detail	Backoffice Impact
Encryption policy	Financial entities shall develop, document, and implement a policy on encryption and cryptographic controls to preserve availability, authenticity, integrity, and confidentiality of data.	Must have a formal, written encryption policy covering: wallet key material, API communications between backoffice and signing infrastructure, data at rest in the backoffice database (holder PII, IBAN, transaction records).
Risk-based design	Policy must be designed on the basis of data classification and ICT risk assessment results.	Minting/burning keys = highest classification. Backoffice transaction data = high (contains PII + financial data). Policy must reflect this hierarchy.
Data in use protection	Where encryption of data in use is not possible, financial entities shall process data in a separated and protected environment.	Signing operations (where key material is "in use") must occur in an isolated environment — this is where HSMs or secure enclaves become the natural technical answer.
Network encryption	All networked traffic, internal and external, must be encrypted.	All API calls between backoffice ↔ signing service ↔ blockchain nodes must be TLS-encrypted. No plaintext RPC calls.

4.5 Cryptographic Key Management (DORA RTS Art. 7)

This is the article most directly relevant to your on-chain operations. It does not say "use an HSM" by name, but it creates obligations that effectively require one.

Requirement	Detail	Backoffice Impact
Full lifecycle management	Financial entities shall have a key management policy covering: generating, renewing, storing, backing up, archiving, retrieving, transmitting, retiring, revoking, and destroying cryptographic keys.	For each minting/signing key, you must document and implement procedures for every phase of its lifecycle. "We generated it once in MetaMask" is not compliant.
Protection controls	Shall implement controls to protect keys against loss, unauthorised access, disclosure, and modification throughout their lifecycle.	Keys must be protected against: theft (→ HSM/secure enclave), loss (→ backup/recovery procedure), unauthorised use (→ multisig/access controls), disclosure (→ keys never exported in plaintext).
Controls proportionate to risk	Controls must be designed based on data classification and ICT risk assessment.	If your risk assessment classifies minting keys as critical (which it must — they can create unbacked tokens worth millions), the controls must be proportionately strong. A software wallet on a laptop will not survive audit.
Key replacement procedures	Shall develop methods to replace keys in case of loss, compromise, or damage.	Must have a documented, tested key rotation and emergency revocation procedure. What happens if a signer's key is compromised? How quickly can the multisig be reconstituted?
Certificate register	Shall create and maintain a register for all certificates and certificate-storing devices, at least for ICT assets supporting critical functions.	Register of all HSM instances/devices, their key identifiers, certificate expiry dates, and renewal schedules.

Conclusion on HSMs: DORA RTS Art. 7 requires that keys be protected against loss, unauthorized access, disclosure, and modification — proportionate to risk. For keys that control minting of an EMT (critical function), the only technical solutions that credibly satisfy all four protection requirements simultaneously are HSMs or secure enclaves. A software wallet fails on "disclosure" (key exists in extractable form) and "unauthorized access" (anyone with file system access can copy it). DORA doesn't name HSMs, but the principle-based obligation effectively mandates them for this use case.

4.6 Protection and Detection (DORA Art. 9-10)

Requirement	Detail	Backoffice Impact
Resilience, continuity, availability	ICT security policies must ensure resilience, continuity and availability of systems supporting critical functions.	Signing infrastructure and backoffice must have high availability. If the signing service goes down, you cannot process redemptions — which violates MiCA Art. 49 ("at any time").
Network segmentation	Network infrastructure must be designed to allow instantaneous severance or segmentation to prevent contagion.	Signing infrastructure must be network-segmented from general corporate IT. A breach in email or office systems must not propagate to wallet infrastructure.
Change management	All changes to ICT systems must be recorded, tested, assessed, approved, implemented and verified in a controlled manner.	Smart contract upgrades, multisig signer changes, HSM firmware updates — all must go through formal change management with approval, testing, and rollback plans.
Anomaly detection	Must have mechanisms to promptly detect anomalous activities and identify potential single points of failure.	On-chain monitoring for: unexpected mint/burn transactions, transactions from unrecognized addresses, gas price anomalies, smart contract interaction from non-whitelisted callers.
Multi-layer controls	Detection mechanisms must enable multiple layers of control with alert thresholds.	Alerting on: mint amount exceeding daily threshold, burn without matching backoffice request, multisig proposal from unknown address.

Conclusion on infrastructure segregation: DORA Art. 9's requirement for network segmentation and contagion prevention means your multisig signers must operate from separate infrastructure. If Signer A and Signer B both use the same corporate VPN, the same endpoint management system, or the same IT admin account, a single compromise defeats the entire multisig. This is not best practice — it is a direct consequence of Art. 9's segmentation requirement applied to your critical signing infrastructure.

4.7 Business Continuity and Recovery (DORA Art. 11-12)

Requirement	Detail	Backoffice Impact
ICT business continuity plans	Shall implement dedicated arrangements to ensure continuity of critical functions and effective response to ICT incidents.	Must have a documented plan for: HSM failure, signing service outage, blockchain network congestion/outage, backoffice system failure. How do you continue processing redemptions?
Annual testing	ICT business continuity and recovery plans must be tested at least yearly, and after any major change to critical systems.	Annual drill: simulate a key compromise, test key rotation, test failover of signing infrastructure. Document results.
Backup policies	Shall develop and document backup policies specifying scope, frequency, and restoration procedures based on data criticality.	Must back up: backoffice database (transaction records, KYC records, audit trail), multisig configuration, smart contract deployment parameters, key material (via HSM backup procedures — never plaintext export).
Backup activation	Backup systems must be activatable without jeopardising security, availability, authenticity, integrity, or confidentiality.	HSM key backup/restore procedure must not expose key material. Backup HSM must be in a separate physical location.

4.8 Incident Reporting (DORA Art. 17-19)

Requirement	Detail	Backoffice Impact
Incident management process	Must implement processes to monitor, manage, log, classify and report ICT incidents by priority and severity.	Every on-chain incident (failed transaction, unexpected behaviour, attempted unauthorized access) must be logged and classified.
Major incident classification	An incident is "major" if it adversely impacts critical services, especially involving unauthorized access that may result in data loss.	A compromised signing key, unauthorized mint, or smart contract exploit = major incident requiring immediate classification and reporting.
Reporting timeline — initial	Within 4 hours of classification as major (and no later than 24 hours from awareness).	Backoffice must have a pre-drafted incident report template and a clear escalation path to submit to the competent authority within 4 hours.
Reporting timeline — intermediate	Within 72 hours of initial notification, with further updates as available.	Intermediate report must include root cause analysis progress and remediation steps taken.
Reporting timeline — final	No later than 1 month after the last intermediate report. Must include root cause analysis.	Final report with full root cause, impact assessment, and preventive measures.

4.9 Digital Operational Resilience Testing (DORA Art. 24-27)

Requirement	Detail	Backoffice Impact
Annual testing programme	All ICT systems supporting critical functions must be tested at least yearly.	Annual: vulnerability scans of signing infrastructure, penetration testing of backoffice, smart contract audit/re-audit if upgraded.
Testing scope	Includes vulnerability assessments, network security assessments, gap analyses, physical security reviews, source code reviews, end-to-end testing, penetration testing.	Smart contract source code review, penetration testing of the API layer between backoffice and signing service, physical security review of any on-premise HSMs.
Threat-Led Penetration Testing (TLPT)	Designated significant entities must undergo TLPT at least every 3 years. Uses intelligence-driven red team simulation.	If your EMT becomes significant (EBA thresholds), you will need TLPT — a red team exercise simulating real threat actors attempting to compromise your minting infrastructure. Even if not required, TLPT is strongly recommended for any entity holding high-value signing keys.
Tester requirements	TLPT testers must be certified, independent, and insured.	Cannot use internal team for TLPT. Must engage certified external red team.

4.10 Third-Party ICT Service Provider Management (DORA Art. 28-30)

This applies to every external service you use for on-chain operations: HSM providers (AWS CloudHSM, Thales), custody platforms (Fireblocks, Fordefi), node providers (Infura, Alchemy), blockchain monitoring services (Chainalysis, Elliptic), and the backoffice platform itself if SaaS.

Requirement	Detail	Backoffice Impact
Register of all ICT third-party arrangements	Must maintain and update a register of all contractual arrangements with ICT third-party providers, at entity and consolidated level.	Must register: cloud HSM provider, node/RPC provider, custody platform, blockchain analytics provider, backoffice SaaS vendor, KYC/AML provider.
Concentration risk assessment	Before contracting, must assess whether the arrangement creates concentration risk (hard to substitute, or multiple dependencies on same provider).	If you use AWS for both HSM and node hosting, that's concentration risk. If Fireblocks provides both custody and signing, that's concentration risk. Must be assessed and documented.
Exit strategies	Must have exit strategies for ICT third-party providers supporting critical functions.	What happens if your HSM provider goes down? If your node provider blocks your account? Must have documented alternatives and migration plans.
Contractual requirements	Contracts with providers supporting critical functions must include: access/audit/inspection rights for the entity and the competent authority, SLAs, data location requirements, cooperation obligations for incident handling.	Your contract with the HSM provider, custody provider, and node provider must include audit rights and regulator access. Off-the-shelf terms may not suffice — negotiate.
Critical ICT third-party designation	ESAs can designate providers as "critical" — subjecting them to direct oversight.	If your custody or HSM provider is designated critical by the ESAs, they face direct EU supervision. This is out of your control but affects your risk assessment.

---

5. DORA vs. MiCA — Interaction Summary

Topic	MiCA says	DORA says	Combined effect
Key management	Nothing specific	Must protect keys through full lifecycle, proportionate to risk (RTS Art. 7)	For minting keys (critical), HSM-grade protection is the only credible approach
Infrastructure security	Nothing specific	Network segmentation to prevent contagion (Art. 9)	Multisig signers must be on separate infrastructure
Redemption availability	"At any time" (Art. 49)	Business continuity plans for critical functions (Art. 11)	If your signing infra goes down and you can't burn/transfer, you breach both MiCA and DORA simultaneously
Incident response	Recovery/redemption plans (Art. 46)	4-hour major incident reporting (Art. 19)	A key compromise triggers both MiCA recovery plan and DORA incident reporting obligations
Testing	Nothing specific	Annual testing of critical ICT systems (Art. 25); TLPT every 3 years for significant entities (Art. 26)	Annual smart contract audit + penetration test; TLPT if you become significant
Third-party risk	Nothing specific	Register, concentration risk assessment, exit strategies (Art. 28-30)	Every provider in your on-chain stack must be registered, assessed, and contractually covered
Audit trail	Implied by AML/compliance obligations	Full incident logging and classification (Art. 17)	Complete audit trail on every mint, burn, key rotation, and access event — required from both angles

---

6. On-Chain Controls & Operational Security — Industry Best Practices

Note: The controls below are industry best practices. Section 4 above explains which of these are effectively mandated by DORA and which are purely discretionary. The column "DORA basis" maps each control to the relevant DORA obligation where applicable.

Drawing from public security research and audit standards for custodial stablecoins:

6.1 Multisig & Access Control

Control	Description	Industry Standard	DORA basis
Multisig for minting	All mint operations require M-of-N signatures	2-of-3 minimum; ideally 3-of-5 for production	RTS Art. 7 (key protection against unauthorized use)
Multisig for burning	Burn operations should also require multisig, or at minimum be initiated by an authorised operator role	At least 2-of-N	RTS Art. 7
Role-based access	Smart contract roles should be separated: MINTER, BURNER, PAUSER, ADMIN	OpenZeppelin AccessControl pattern	Art. 6 (segregation of functions)
Single-EOA prohibition	No single externally-owned account should be able to mint or burn unilaterally	Enforced by multisig wallet (e.g., Safe)	RTS Art. 7 (protection against unauthorized access)

6.2 Timelocks & Rate Limits

Control	Description	DORA basis
Timelock on minting	Sensitive operations (especially large mints) should route through a timelock contract with a revocation window	Best practice only (no direct DORA mandate)
Rate limiting	Smart contract or operational limits on maximum mintable amount per day/transaction	Best practice only
Whitelisted addresses	Minting should only be possible to pre-approved (whitelisted) wallet addresses	Best practice only
Expiry of unsigned transactions	Multisig proposals that are not fully signed within a defined window should auto-expire	Best practice only

6.3 Emergency Controls

Control	Description	DORA basis
Pause function	Ability to pause all token transfers in case of security incident	Art. 9 (network segmentation / contagion prevention) + Art. 11 (response and recovery)
Freeze function	Ability to freeze specific addresses (e.g., in response to law enforcement or sanctions)	AML/sanctions obligations (not DORA directly)
Blacklist / blocklist	Prevent specific addresses from sending or receiving tokens	AML/sanctions obligations

6.4 Key Management

Control	Description	DORA basis
HSM (Hardware Security Module)	Signing keys for mint/burn operations should be stored in HSMs, not software wallets	RTS Art. 6 (data-in-use protection) + RTS Art. 7 (protection against loss, disclosure, unauthorized access)
Infrastructure segregation	Multisig signers should operate from physically and logically separate infrastructure — if they share IT systems, multisig becomes "single-sig with extra steps"	Art. 9 (network segmentation, contagion prevention)
Key ceremony	Initial key generation and any key rotation should follow a documented ceremony with witnesses	RTS Art. 7 (key generation procedures)
No single admin	The ADMIN role (which can grant/revoke other roles) must itself be behind a multisig with timelock	RTS Art. 7 (protection against unauthorized access) + Art. 9 (change management)
Key replacement procedure	Documented, tested method to replace keys in case of loss, compromise, or damage	RTS Art. 7 (mandatory — explicit requirement)
Certificate/device register	Register of all HSM instances, key identifiers, certificate expiry dates	RTS Art. 7 (mandatory — explicit requirement)

---

7. Synthesis — Design Principles for Our Backoffice

Based on the above research, the following principles should guide backoffice design. Each is tagged with its regulatory source.

MiCA-driven principles

1. Fiat-first sequencing (MiCA Art. 49): Never mint before fiat receipt is confirmed by Treasury. This is a hard legal requirement and the universal pattern across all issuers.

2. Partner-only minting: Following the SG-Forge model — only onboarded, KYB-verified partners can request issuance. No retail minting.

3. Daily cut-off model: Adopt a defined daily cut-off (SG-Forge uses 16:00 CET). Requests received before cut-off are processed same business day; after cut-off, next business day.

4. Zero-fee, zero-threshold redemption (MiCA Art. 49): Absolute — no fees, no minimums on redemption. The backoffice fee engine must enforce this. Tether's model is explicitly non-compliant.

5. Reserve allocation at issuance time (MiCA Art. 54): At each minting event, Treasury must allocate received funds per the 30% / 70% rule (or 60% / 40% if classified as significant). This is not a monthly reconciliation — it must happen at issuance.

6. Recovery and redemption plans (MiCA Art. 46): Must exist, must be filed with the competent authority, and must describe how the backoffice would handle mass redemption events or reserve shortfalls.

DORA-driven principles

7. HSM-grade key protection (DORA RTS Art. 6-7): Minting/signing keys are critical ICT assets. They must be protected against loss, unauthorized access, disclosure, and modification throughout their lifecycle. HSMs or secure enclaves are the only technical solutions that satisfy all four requirements for this risk classification.

8. Multisig with infrastructure segregation (DORA Art. 9 + RTS Art. 7): Every mint transaction requires at minimum 2-of-N multisig approval. Signers must operate from physically and logically separate infrastructure to prevent single-point-of-failure compromise.

9. Segregation of duties (DORA Art. 6 three lines of defence): The person who approves compliance (CO) ≠ the person who confirms fiat (TR) ≠ the person who executes on-chain (OP) ≠ the person who co-signs (HO).

10. Full ICT asset register (DORA Art. 8): All wallets, smart contracts, HSMs, node providers, signing services, and their interdependencies must be inventoried, classified, and reviewed annually.

11. Third-party provider register and exit strategies (DORA Art. 28-30): Every external provider in the on-chain stack (HSM, custody, nodes, analytics, backoffice SaaS) must be registered, assessed for concentration risk, and covered by contracts with audit/inspection rights.

12. 4-hour incident reporting (DORA Art. 19): A key compromise, unauthorized mint, or smart contract exploit is a major ICT incident. Initial report to competent authority within 4 hours of classification. Pre-draft templates and escalation paths must be ready.

13. Annual resilience testing (DORA Art. 25): All critical ICT systems (signing infrastructure, backoffice, smart contracts) must be tested at least yearly — vulnerability scans, penetration tests, smart contract audits.

14. Audit trail on every state transition (MiCA AML + DORA Art. 17): Every approval, rejection, on-chain transaction, key rotation, and fiat movement must be logged with role, user, timestamp, and justification. Required from both MiCA (compliance) and DORA (incident management) angles.

15. Emergency controls on-chain (DORA Art. 9 + Art. 11 + AML): Pause, freeze, and blacklist capabilities must be implemented in the smart contract and operable from the backoffice with appropriate authorization. Pause supports DORA's contagion prevention requirement; freeze supports AML/sanctions obligations.

---

8. Sources

• Circle — MiCA EURC White Paper
• Circle — MiCA Redemption Policy
• Circle — MiCA USDC White Paper
• Circle — USDC/EURC Redemption Structure
• Circle — Walkthrough of USDC & Circle's Stablecoin Infrastructure
• SG-Forge — CoinVertible Product Page
• SG-Forge — EURCV White Paper (June 2024)
• SG-Forge — EURCV White Paper Multi-chain (Oct 2025)
• SG-Forge — Stablecoin Elevation Announcement
• FXC Intelligence — Mint and Burn: How Stablecoin Creation and Redemption Works
• Trail of Bits — The Custodial Stablecoin Rekt Test
• Hacken — Stablecoin Security: Design Choices and Vulnerabilities
• Chainlink — Stablecoin Treasury Management Guide
• EBA — Asset-Referenced and E-Money Tokens (MiCA)
• EUR-Lex — European Crypto-Assets Regulation (MiCA)
• Chainalysis — MiCA's Stablecoin Regime and Remaining Challenges
• Deloitte Legal — MiCAR: Regulation of E-Money and E-Money Tokens
• White & Case — MiCA Regulation: New Regulatory Framework
• MIT DCI — 1:1 Redemptions for Some, Not All
• EUR-Lex — DORA Regulation (EU) 2022/2554 Full Text
• European Commission — DORA RTS on ICT Risk Management Framework (2024/1532)
• Springlex — DORA RTS Art. 6: Encryption and Cryptographic Controls
• Springlex — DORA RTS Art. 7: Cryptographic Key Management
• EBA — RTS on ICT Risk Management Framework
• ESMA — Final Report on Draft RTS on ICT Risk Management Framework (Jan 2024)
• PayTechLaw — ICT Incident Reporting under DORA
• PayTechLaw — ICT Third-Party Relationships under DORA
• Noerr — Threat-Led Penetration Testing under DORA
• Cryptas — DORA and Cryptographic Requirements
• IBM — Understanding DORA and Confidential Computing
• DLA Piper — Application of DORA: Key Considerations