This guide is written for banks, licensed issuers and the compliance teams that will sign off a tokenized asset programme. It sets out, at education level, what the MiCA framework covers, which obligations fall on the institution that issues or services a tokenized asset, and what each obligation asks of the infrastructure underneath: the questions to scope before any vendor conversation. One boundary holds throughout: a platform such as CoreFi provides the infrastructure layer; the institution holds the authorisation, and the issuance is always the institution's. If you are the internal champion, this is the page to forward before the scoping meeting. It is general information, not legal or regulatory advice.
The Markets in Crypto-Assets Regulation is the EU framework governing crypto-assets that are not already regulated as financial instruments. For an institution scoping a programme, four categories matter. Authorisation under each sits with the institution and its national competent authority, never with a technology provider. The teams this lands on first are usually the ones described on For Banks and For Compliance & Risk.
Tokens that aim to maintain a stable value by referencing one or more assets, such as currencies, commodities or other crypto-assets, other than a single official currency. MiCA requires issuers to be authorised, to maintain and segregate reserve assets, to honour redemption rights and to publish ongoing disclosures.
Tokens referencing a single official currency. Under MiCA these may be issued by credit institutions and authorised e-money institutions, with full reserve backing, redemption at par and continuing transparency obligations.
Crypto-assets outside the ART and EMT categories, where MiCA requires issuers to prepare and notify a whitepaper, follow marketing rules and meet conduct obligations toward holders.
Entities providing services such as custody, exchange or operation of a trading platform for crypto-assets. MiCA requires CASP authorisation, with prudential, conduct and reporting obligations that follow the service.
One scoping note compliance teams raise early: tokenized instruments that qualify as financial instruments, such as many tokenized funds and bonds, fall under existing EU financial services legislation rather than MiCA. The infrastructure questions in this guide apply either way; which regime applies to a given programme is a determination for the institution and its counsel.
MiCA is an obligation framework first. Each obligation that falls on a licensed issuer translates into an infrastructure capability the institution must build or buy before a supervisor, an auditor or a redemption stress tests it. Six translations recur in every programme we scope.
The obligation to issue only what is backed and to redeem on the terms disclosed becomes token lifecycle management: controlled mint, burn and redemption operations, each permissioned, approved and reconciled against the books.
The obligation to keep reserve assets segregated and sufficient becomes a real-time ledger plus reserve accounting: token supply, holder register and reserve balances reconciled continuously, with mismatches surfaced rather than discovered at audit.
The obligation to disclose to holders and report to supervisors becomes report assembly with lineage: every figure traceable from the published document back to ledger entries and chain events, on a schedule the institution does not miss.
The obligation to safeguard assets becomes custody integrations and key management: defined custody models, controlled signing, and a clear answer to who holds which keys under which approval policy.
The obligation to operate reliably and evidence it becomes monitored, recoverable infrastructure: measured availability, incident records and recovery procedures. The same discipline the DORA framework expects of the institution's critical ICT.
Underneath every category sits the audit record: an append-only account of who did what, under which approval, with which effect on the books and on chain. If the record is assembled by hand after the fact, it is not a record.
This table is the internal scoping artefact: forward it to the team that will run vendor diligence. The questions are deliberately vendor-neutral and apply to any provider, including CoreFi. A credible answer comes with artefacts, not assurances.
The sourcing decision is vendor-neutral: whichever route an institution takes, the obligations above remain the institution's, and the test is whether the resulting stack can evidence them on demand from day one.
Maximum control over the stack, paid for in engineering scope: a reconciled ledger, chain integrations, custody connectivity and report lineage are each multi-quarter builds, and the controls must be evidenced from the first issuance, not retrofitted. Realistic where digital-asset engineering is already a core competence.
Shortens time-to-evidence, but the diligence must reach past the smart contracts into the back office: register, corporate actions, reconciliation and reporting decide whether the programme can operate. Ask for the exit posture and data export path before the contract, not at its end.
Distribution through white-label channels or licensed venues can carry parts of the operational load. The institution still answers for the obligations attached to its authorisation, so the partnership must preserve one consistent record across every channel rather than fragmenting it.
CoreFi packages the capabilities in the table as platform software for licensed issuers, distributors and fund managers. Tokenized Assets Infrastructure covers issuance, distribution and servicing of tokenized funds, bonds, real estate and commodities, with token contracts that enforce eligibility and transfer rules and an issuer back office that keeps the cap-table, corporate actions, payouts and supervisory reporting in sync with the chain. Stablecoin Operations Infrastructure covers EMT and ART programmes: reserve workflows, mint and burn controls, redemption processing and the reporting feeds the MiCA framework expects, with HSM-backed key management and policy gates on every supply change.
The regulatory boundary is the one this guide opened with. Authorisation, whitepaper approval or notification, marketing-rule compliance and ongoing supervisory obligations remain with the licensed issuer, distributor or fund manager in each jurisdiction. CoreFi does not provide regulated issuance, investment services or custody of client assets, does not issue tokens and does not hold reserve assets. The platform's audit trails, transfer-rule enforcement and reporting feeds are designed to make the institution's obligations easier to evidence; they do not transfer them. How we operate the platform side of that boundary is documented in the Trust Center, and control evidence and programme-level detail are available on request.
For scale context: the CoreFi platform runs 200k+ end-customer accounts across 20+ production deployments in six geographies (Italy, Spain, France, Argentina, Chile, Bolivia), at 99.9% uptime measured against operational SLOs. These are platform-wide figures, not tokenized asset programme figures. Two companion reads continue the issuer thread: the gated playbook Stablecoin Infrastructure for Regulated Issuers and the analysis MiCA Regulation and Stablecoins.
A 30-minute working session with our solutions team: your asset class, target jurisdictions and authorisation pathway, mapped row by row against the obligations and capabilities above. Bring your compliance lead; the session is built for that audience.
This guide is part of the CoreFi Knowledge Hub. Two siblings continue the regulated-infrastructure conversation: DORA, AI governance and operational resilience, on the resilience obligations that sit alongside MiCA, and The CIO checklist for cloud core banking, for the team that will run the diligence.