A worked architecture

Euro digital bond, five-year senior unsecured

Illustrative exampleSynthetic, no institutionNot an endorsement

A five-year senior unsecured bond issued directly onto a permissioned ledger operated by a market infrastructure. The ledger entry is the legally recognised record of ownership: there is no parallel register that could disagree with it. Coupons are calculated off-ledger by the paying agent and settled in central-bank money against the same ledger. Nothing crosses to another network, and no contract is upgradeable.

Everything below was produced by the same engine and rendered by the same components a member sees. Nothing here is a nicer version of the product.

The workflow

Eight steps, and the screen each one actually presents.

What follows is the member workspace, excerpted. The frames are the real controls in their real styling with the interaction removed, carrying this bond’s own answers, so what is shown here cannot drift away from what is built.

1. Step 1 of 8

   The legal claim

   What the holder actually owns, under which law, and where the token sits in relation to it.

   Almost every expensive mistake in this market starts here. A token can be the legally recognised record, a mirror of one held elsewhere, or a receipt for a claim against somebody. Those three are not variations on a theme; they place ownership in different places and fail in different ways.

   The first question, and the one every other answer depends on.

   What is the relationship between the token and the legal claim?

   Until this is explicit, nothing downstream can be checked. Whether a transfer moves ownership, whether the register or the ledger wins in a dispute, and what a holder actually has if the platform stops, all follow from this one answer.

   Your answerThe token is the legal asset▾The ledger entry is itself the legally recognised record of ownership. There is no separate register that could disagree with it.

   Nothing is pre-selected. A default here would be a guess about somebody else's legal structure, and it would be wrong more often than it was right.

2. Step 2 of 8

   Who controls what

   For each thing the design must agree about, which record is authoritative when two disagree.

   Systems do not disagree in theory, they disagree on a Tuesday afternoon. If two records are both authoritative and nothing ranks them, there is no answer to which one is right, and the reconciliation break has no owner.

   Ten things a design has to agree about. One row, and the hierarchy the answers build.

   How much exists

   Which record states the total issued, across every network it lives on? Not the amount itself, the system that is right about it.

   Which system is authoritativeThe ledger itself▾Not the value. The system that is right about it.

   If two rows conflict, which winsThird▾Position is relative to the other rows, not a score.

   The hierarchy you have described

   1. 1instrument termsA global note or physical document
   2. 2holder positionThe ledger itself
   3. 3token supplyThe ledger itself
   4. 4cashThe calculation or paying agent
   5. 5corporate actionThe calculation or paying agent

   Naming a system also gives it a place in the order. The two used to be separate controls, and a matrix could look complete while storing nothing at all.

3. Step 3 of 8

   Who does what

   The parties that operate the instrument, what they are in law, and what any of them can do alone.

   An instrument is operated by institutions and people, not by a diagram. Naming them, and naming what each can do without a second pair of eyes, is how a control gap becomes visible before somebody finds it the hard way.

   One of the 3 parties operating this bond, opened for editing.

   Who are theyPaying agentThe party, as your documents name them.

   What are they in lawAgent of the issuer for calculation and paymentTheir legal capacity, not their job title.

   How do they hold or reach positionsOperates the cash account against which coupons settleDirectly registered, through an omnibus account, by key control, or not at all.

   What approval do their actions needFour eyes on every payment instructionThe thing that stops one person acting alone. If the answer is nothing, say so.

   Rows open one at a time. A party has four fields, and five open rows is the wall of inputs this workspace exists to avoid.

4. Step 4 of 8

   The standards stack

   Which standards this architecture composes, and which job each one is doing.

   Standards fail by being asked to carry something outside their scope. A token interface is not a bond taxonomy; a message is not a settlement. Choosing deliberately is how you find that out now rather than in production.

   The catalogue proposes what this product usually needs. Every entry leads with what it does not do.

   Bond Data Taxonomy

   Remove

   ICMA · ICMA-BDT-2

   Machine-readable common language for conventional and DLT bonds across issuance, trading, settlement and distribution

   Does not: Legal issuance documents prevail; BDT is not an executable lifecycle, token interface or settlement rail

   ERC-7518: Dynamic Onchain Compliance for Security Tokens

   Does not: Emerging model with large voucher, partition, payout and bridge surface

   M3, draft or review

   Selecting two alternatives from one group is allowed. It produces a finding rather than a refusal, because sometimes the honest answer is that the choice has not been made yet.

5. Step 5 of 8

   Operating and unwinding

   How the instrument is serviced over its life, who can change what, and how it ends.

   The exit is the part nobody designs and everybody eventually needs. Detokenisation, migration, key loss and insolvency are ordinary operational events, and an architecture without answers for them is one bad day from an unrecoverable position.

   One of the 6 lifecycle steps, and the invariants the design rests on.

   Which stepissue, issuance▾Create legal/economic instrument and initial ledger representation

   Who performs itIssuerOne of the parties from the previous step.

   What starts itDrawdown under the programmeA date, an instruction, a threshold, or somebody deciding.

   How tightly is it controlledTwo people, separately▾Two authorisations by different people. The usual bar for anything irreversible.

   What proves it happenedSigned drawdown notice and ledger entryWhat you would show an auditor or a supervisor afterwards.

   What must always be true

   • The sum of ledger positions equals the issued nominal at all times.
   • A transfer to an ineligible party cannot be recorded.
   • No lifecycle state is overwritten without a superseding record.

   Step names come from a library of 82, so two institutions describing the same operation use the same word. Choosing one shows what it is for.

6. Step 6 of 8

   Settlement, network and evidence

   What settles against what, on which network, and what you will be able to prove afterwards.

   Finality is two separate things. A ledger can consider a transfer final while the law does not, and a delivery-versus-payment claim that has not distinguished them is a claim nobody has checked.

   Answering one question can reveal several others, or keep them off the screen entirely.

   Does it cross networksNo, one network▾Answering yes adds seven decisions, each a real failure mode rather than paperwork.

   Personal data on the ledgerNo, nothing personal on the ledger▾Only references, commitments or credentials go on-chain.

   ✓Yes, this is decided and written downLeave it unticked if it is still open. An honest gap is more useful than a tick nobody can stand behind.

   This bond settles free of payment, on one network, with no upgradeable contracts. So it is never asked the seven cross-network decisions, the seven on upgrade governance, or the three on finality. Different answers would add all of them.

7. Step 7 of 8

   Risks and controls

   What could go wrong, what stops it, and how far along that control actually is.

   A risk nobody wrote down is a risk nobody owns. These carry into the passport, so whoever implements, audits or supervises the design is working from the same list you were, including the parts you have not solved.

   One of the risks this design carries, with the control that answers it.

   What could go wrongThe ledger and the paying agent's records disagree about who was entitled at a record dateThe consequence, not the mechanism. What would somebody lose?

   What stops itRanked authority of record, with a daily reconciliation and a named owner for breaksThe control, and who operates it.

   How far along is that controlPlanned▾Designed, not yet built.

   Which frameworks it answers toPFMI, DASCP-2024Optional. Separate several with commas.

   The list starts seeded from what no standard adequately covers for this product, always as unresolved. The workspace must not imply somebody has dealt with something it raised on their behalf. This row is one the architects added themselves.

8. Step 8 of 8

   Review and approve

   What the rules found, what is still open, and freezing a version somebody can defend.

   An approved passport is a statement that this architecture was considered and signed off, pinned to the catalogue and rule set it was judged against. It is worth doing when the design is one you would defend, not when the form is merely full.

   Freezing writes an immutable version, stamped with the catalogue and rule set it was judged against.

   Passport iddap_example_euro_digital_bondLowercase, prefixed

   Version1.0.0Three numbers, separated by dots

   ConfidentialityConfidential▾Travels with the document and every export of it.

   Freeze this version

   A correction is a successor version. This one stays where it is, which is what makes its checksum worth anything.

9. And what is not here

   This is an excerpt, not the instrument.

   One question is shown from steps that hold several, one row from lists that hold many, and one architecture from a catalogue that supports thirteen product types. What sits behind the account is the working surface: the full question set as it adapts to your answers, the whole catalogue to compose against, the review workflow in which nobody approves their own work, and passports and exports carrying your organisation rather than a synthetic one.

   Open your workspace →

Who controls what

One record wins, and the order says which.

Two records both marked authoritative, with nothing ranking them, is the design defect that surfaces later as a reconciliation break nobody can adjudicate. Here the terms document governs what the instrument is, and the ledger governs who holds it.

This example deliberately leaves that finding standing. One of the six standards is still a draft, and the design is scoped to production, so the engine raises it as something to monitor rather than something to fix: allowed, with a recorded exception, enhanced assurance and a documented way out. An example engineered to a clean sheet would teach that findings are something to avoid, when they are the reason the tool is useful.