SYN-DSD
A-DVP-001Series A was already closed in the opening fixture. Its EUR 1,000 principal is unaffected by B.
LOCAL_MODEL · SYN-EVIDENCE-001GENESIS ONE OS / SYSTEM MAP
A €1,000 subscription
Follow one investor’s payment through the modules that connect Test Logistics a.s., its bondholder and its accounts.
BlockID ●
Authorised employeePrepare the financing file for our warehouse equipment.
GENEI have linked the order, budget and authorised employee.
GENESIS ONE OS
Agent · model position
- Project file opened
Test Logistics a.s.
Project file
WideWeb301 / 08
Company
Prepare the project
Test Logistics a.s. plans to buy €20,000 of warehouse equipment. Its 18-step preparation file identifies the equipment, the funding and who may confirm delivery.
Interactive model of the architecture developed since 2017. All records are synthetic.
Inspect receipts and role views
GENESIS ONE OS · SYNTHETIC DEMONSTRATION
Test Logistics a.s.Follow the €1,000.
Fictional company · Series B
Test Logistics a.s. is buying €20,000 of warehouse equipment. An investor authorises a second €1,000 subscription, conditional on an employee confirming acceptance of the equipment. Follow the money, the bond and the accounting record.
01Digital euroBlockID Pro · XIXOBOX
Investor → collection provider
Provider receipt, then a separate credit to the linked bank account.
Payment confirmed
B-PAY-RECEIPT-001B-SWEEP-001B-ISSUER-CREDIT-00102Securities settlementBlockchain Genesis · Ledger Gateway
Bank money → issuerInvestor via custodian ← Series B bond
Separate UK DSS model. The security is delivered against payment in bank money.
Position allocated
B-DVP-001B-ALLOCATION-00103Company accountsXIXOTRACE · BlockID Pro
Test Logistics a.s. → accounting journal
The bank and settlement records support the issuer’s entry.
Entry accepted
B-JOURNAL-001BlockID Pro · role view
Debit bank / credit bond liability · €1,000.
SYN-PSP:B-PAY-001Modules in this transaction · select for detail
XIXOIO has developed this architecture since 2017. The module roles shown here illustrate the completed design. This synthetic case uses no live ECB or DSS connection.
XIXOIO a.s. prepared this independent proposal in response to the ECB’s public call. The demonstration uses synthetic data and does not imply selection or endorsement by the ECB.
Applicant: Czech Republic · Website: XIXOIO LTD, United Kingdom
DESIGN BASIS AND SOURCES
Nine years of design.
Since 2017, XIXOIO has been developing the Genesis One architecture around a practical question: how can a small business finance a project and show its investor and accountant exactly what happened? The design draws on a distinction familiar in financial and capital markets: payment confirmation, delivery of rights and recognition in the issuer’s accounts are separate events. Each needs its own evidence and responsible party.
The author sets out the design in Regulated Tokenomics. The companion books explain how to prepare evidence for the UK Digital Securities Sandbox and how an SME can assess a business case before choosing a token or network.
01Read excerpt ↗02Read excerpt ↗03Read excerpt ↗
Regulated Tokenomics
Chapter 16 · Five layers of enterprise readiness
From Tokenisation Rules to Governed Operations
Chapter 12 · From a DSS requirement to a test and its evidence
The Stablecoin-Ready Enterprise
Chapter 1 · Choosing a business case for payments or financing
01WHY WE START WITH SMEs
The project and the payment
must stay connected.
Our focus is the small or medium-sized company preparing to raise digital capital. Its project dossier, order, acceptance record, investment terms and accounts must remain connected. Genesis One OS brings those business records and responsible roles into one proposed workflow.
A payment to an intermediary can succeed while the investment is still incomplete. A late reply can make a completed payment look uncertain. A rejected accounting entry can leave money and rights intact.
We propose a portable evidence format that keeps the authorised intention and these distinct outcomes connected. Independent applications should interpret the same evidence consistently and offer the same permitted next action.
PRIMARY APPLICATION
Experimentation
Conditional payments
Test a precisely authorised payment released by a verified external condition.
ADDITIONAL APPLICATION
Exploration
AI in payments · Presenter
Explore how an assistant explains status and options while the user and provider retain control.
02OUR MODULES IN THIS CASE
From the prepared company
to a recorded outcome.
Explore what each part of Genesis One would contribute to this experiment: a concrete action, an evidence record and a responsible role.
The shared project reference is the thread. The payment provider, securities operator and accounting system retain their own authority.
WideWeb3
Start with a financeable project.
The 18-step preparation defines the company, equipment, budget, responsible people and accounting requirements before a payment is proposed.
Responsible roleCompany representative
PROPOSED CASE RECORD
Project dossier · equipment €20,000 · own funds €18,000 · Series A and B
Starting point → experiment
Documented preparation method. The experiment needs a dedicated synthetic dossier.
Roles in the proposed experiment, not a claim of live integration. All example records are synthetic. The external payment, settlement and accounting authorities retain control of their own outcomes.
Genesis is the company ledger in the proposed architecture. XIXOIO designed the company registers, recording roles and links to supporting documents. Besu is the open-source Ethereum client used as a technical foundation. The Genesis explorer shows a test network. In the proposed experiment, the payment provider confirms the payment result.
Explore the existing module surfaces
03THE INTERACTIVE CASE
A small company.
A concrete investment.
Test Logistics a.s., a fictional Czech company, buys warehouse equipment. One fictitious individual in the euro area funds two separate bond subscriptions. Each subscription has its own decision, payment and legal closing.
Equipment€20,000
Own funds€18,000
Series A + Series B€1,000 + €1,000
Read the exact model assumptions
Both series are fully paid at issue, unsecured, issued at par, with a 24-month maturity from their own issue and a 4% fixed annual coupon. These are synthetic fixture parameters, not an investment offer or market-price recommendation. Coupon and redemption are outside this illustration.
Series A has already closed. The company has paid a €10,000 supplier advance and has €9,000 remaining. Series B is conditional on a designated human confirming delivery and acceptance. Its proposed mandate lasts 24 hours; funds are not reserved. The validity is our test parameter, not an asserted ECB API feature. Failure of B leaves A outstanding and a €1,000 funding gap.
LOCAL SIMULATION · SYNTHETIC DATASeries B · €1,000
STEP00 / 09
A is complete. B is still conditional.
The company has €9,000 after the first financing and supplier advance. The investor now makes a separate decision for Series B. No B payment exists.
GENESIS ONE · PROPOSED MODULE ROLEWideWeb3
Prepared project dossier and responsible roles.
What is actually confirmed?
MODEL AUTHORITIES01
Digital euro payment
Not sent
02
Linked bank money
No bank receipt
03
Securities settlement
Not ready
04
Investor custody
Unallocated
05
Issuer accounting
Not yet due
B payment instructions0
No instruction allocated
Confirmed B payment effects0
Original provider reference
B client position—
No confirmed client allocation
Inspect the evidence trail 2 model records
Technical record descriptions below are in English. These are authored local-model receipts, not cryptographic proofs or responses from real providers.
SYN-BANK
PROJECT-OPEN-001EUR 18,000 own funds plus A funding, less the EUR 10,000 supplier advance, leaves EUR 9,000.
LOCAL_MODEL · SYN-EVIDENCE-002Guided illustration of selected v4.1 states. All steps are local models; buttons advance the story, not real authorisations. No live AI, ECB interface or financial service is connected. Reloading resets the simulation.
04WHAT WE WANT TO TEST
The evidence travels.
The meaning survives.
Milestone funding is an established pattern, including in the ECB’s 2025 innovation report. Our research question is what must travel with a payment so that another application can explain it correctly without re-entering the facts.
The format links intent, authority, money form, observed outcome and permitted action. It neither moves money nor transfers a provider’s authorisation.
PROPOSED EVIDENCE FORMAT
One traceable context.
Intent
Exactly €1,000 for Series B, to the named collection provider, under condition v1.
Authority
User consent, PSP authorisation and a human attestation remain separate.
Outcome
Original payment, sweep, DvP, custody and journal references retain their source.
Next action
Continue, hold or reconcile the original operation; never guess a missing result.
The proposed experiment requires two separately implemented evidence consumers. The interactive page above is one explanatory implementation and does not establish that interoperability result.
05THE RESEARCH DESIGN
A fair comparison.
An inspectable result.
The same 28 cases run across four matched profiles. This separates ordinary automation, the digital euro interface and the assistant’s explanation.
If the bank-payment profile delivers the same benefits, that is a valid finding. Unsupported capabilities and unresolved outcomes remain visible.
P1
Bank · manual
The payer initiates after the condition is met.
P2
Bank · conditional
The same application releases a pre-authorised instruction.
P3
Digital euro · conditional
The payment interface changes; downstream models stay the same.
P4
Digital euro · assisted
The same instruction as P3, with bounded AI explanation.
28 × 4112 planned runs · not completed results
What counts as success
- No unauthorised instruction or duplicate financial effect.
- No completion claim without the required authoritative evidence.
- Identical state and allowed action in both independent consumers.
- An explicit owner and next action for every unresolved case.
Scope and open questions for the platform
The initial platform scope is simulated PSP-to-backend interaction. At most 56 planned digital-euro-profile runs could use an assigned ECB interface, subject to supported capabilities. Bank, securities, custody and ERP outcomes remain local models unless separately connected and evidenced.
- Eligibility of the intermediary and investment-collection account profile.
- Non-reserved conditional initiation, authorisation lifetime and additional authentication.
- Original-status queries, idempotency, cancellation cutoff and finality semantics.
- Availability of sweep receipts and permitted metadata.
All experiment data, prompts and logs are synthetic. No user testing or processing of personal data is proposed. The web illustration does not run this experimental matrix.
PROPOSED RESEARCH OUTPUTS
What the experiment would deliver.
We would turn the SME case into material another team can inspect and reuse: a specification, reproducible checks and findings about the payment interface. The aim is to give the Eurosystem concrete evidence of what supports the business journey and what remains unresolved.
A shareable evidence specification
A versioned format linking the authorised mandate, condition, source authority and separate payment, settlement and accounting references. It would let another application interpret the evidence without manually re-entering material facts.
Independent readers and conformance cases
Two separately implemented evidence readers, checked against independently prepared expected states. The cases would test whether late, duplicate or reordered messages preserve the same state and permitted action, with unknown outcomes kept open.
Comparison findings and interface gaps
Matched bank and digital euro findings that separate automation, payment-interface behaviour and AI explanation. The report would distinguish supported, failed, unresolved and unsupported cases, showing which capabilities need clarification or further development.
These are proposed outputs subject to the applicable IP and communication terms. The browser demonstration illustrates selected states; it does not constitute the independent-consumer experiment or its results.
06ECB AND DSS
Connected evidence.
Distinct responsibilities.
The payment study and the capital-market preparation share a business case. Their legal entities, authorities and permissions remain distinct.
XIXOIO a.s.
Czech applicant · technology provider
Conditional digital euro instruction, payment evidence and an understandable payer experience. Participation would concern experimentation, not permission to offer financial services.
XIXOIO LTD
UK parent company · separate application
Preparation of the intended securities recording, maintenance and settlement activities. Admission, permissions, counterparties and a live DvP mechanism require their own assessment.
DE → BANK → DvP
Digital euro subscription prefunding and subsequent bank-money securities settlement are separate operations. The proposal does not treat digital euro as an already approved DSS settlement asset. Applicable direct-participant cash transactions require delivery versus payment; issuer cash without securities delivery is a settlement break.
Money, rights and the role of GEN
This case uses a simulated PSP and a modelled eligible collection provider. The linked bank account and its client-money treatment need a defined legal basis. No PSP, bank, custodian, distributor or waiver is represented as agreed. The individual investor is a client of a modelled regulated custodian, not a direct DSD participant.
The online business holding-limit and sweep assumptions follow the draft digital euro rulebook and must be adapted to actual specifications. Digital euro need not reside on Genesis or convert into GEN. This payment path does not resolve GEN network economics or change existing token rights.
The condition applies to the payment instruction. It does not restrict how the recipient may subsequently spend the money. Selection for the ECB platform would not approve the investment or confer a DSS permission.
07DELIVERY AND READINESS
A focused programme.
January—June 2027.
The documented architecture, selected identity and audit components, and Genesis testnet provide the starting point. The payment adapter, full mandate engine, independent consumers and accounting export are proposed development.
XIXOIO LTD’s March 2026 Appia consultation contribution is relevant group experience. It does not establish partnership, admission or access to Pontes.
January
Define
Freeze the fixture, authority map and interface assumptions.
February—March
Implement
Build the adapter, mandate logic, consumers and accounting mapping.
April—May
Compare
Execute matched cases; report local and supported ECB-interface results separately.
June
Report
Deliver reproducible evidence, interface gaps and lessons learned.
In early 2027, XIXOIO plans to help selected SMEs prepare cases for commercial tokenisation: identify the rights linked to an asset, product or service, the business reason for recording those rights digitally and the accounting evidence the company needs. This preparation is separate from live issuance or regulatory permission.
Delivery roles and contribution
The proposed team covers product, software delivery, IT architecture, business operations, integration and accounting.
XIXOIO a.s. remains responsible for delivery. The schedule will follow allocated access and specifications. External technical services require the ECB’s stipulated consent and contractual arrangements. Deliverables and shareable interface documentation must remain within rights the applicant can grant.
08APPLICATION DOCUMENTS
Experiment protocol.
The public protocol describes the 28 test cases, four comparison profiles and the evidence needed to establish each outcome. The application form, reading copy and concept note are reserved for direct email correspondence.
09QUESTIONS AN EVALUATOR MAY ASK
Clear answers.
What does the payer gain?
A precise explanation of where the money is, which right has been established, whether cancellation is still possible and which next action is safe. Fewer ambiguous decisions are the intended benefit; real-user time savings have not been measured.
Why digital euro?
A prospective common payment interface and a central-bank-money payment leg create a useful setting to investigate conditional instructions and trustworthy outcome information. The experiment asks which benefits the digital euro interface adds over an equally capable bank-payment path. Lower cost, greater speed or unique AI capabilities are not assumed.
What can the assistant decide?
It explains a checked fact bundle and helps prepare the chosen payment. It cannot select an investment, change amount or payee, attest physical delivery or override the PSP. The messages in this website are fixed explanatory templates; no live AI model or payment agent is invoked.
Does an accounting error cancel the investment?
No. A rejected export remains an open accounting task while completed money and legal events persist. A corrected export has a new version and reference; it does not create a second financing. Recognition of the acquisition follows the relevant accounting conditions. Depreciation starts when the equipment is available for its intended use, independently of Series B or invoice payment.
Is this connected to the ECB or a live financial service?
No. It is a browser-local, synthetic illustration of selected states in the proposal. No money moves, no securities are issued and no external financial system is contacted by the simulation. It is not evidence of admission, authorisation or endorsement by the ECB, Bank of England or FCA.
Primary sources and document hierarchy
The official call and its annexes govern participation. Application v4.1 defines this proposal. This web illustration explains selected states and introduces no wider operational claim.