IXOS · THE ONBOARDING STANDARD

PLANNED

One path on. Not a deal each time.

Every asset that reaches the register today does so through work done by hand. That does not scale, and it is the reason most registers only ever hold what their operator originated. ixOS is the template that makes onboarding a defined path — so IX does not have to originate everything that sits on it.

Planned. The path is defined; the tooling that makes it self-serve is not built.

HOW IT WILL WORK

Four steps, the same every time.

The asset class changes. The path does not — that is the entire point of writing it down.

  1. 01

    Reviewed

    The asset and whoever operates it are checked before anything is recorded. Admission is a process, not an open form.

  2. 02

    Recorded

    The asset joins the register with its own ID and an identity that does not drift as it changes hands.

  3. 03

    Reporting

    A signed feed of what the asset actually earns, on a published valuation method for its category. The mark is fed, not typed.

  4. 04

    Issued

    A claim against that ID. Optionally it joins a book by published weighting rules, and later can be posted as collateral.

FIG.101 / TEMPLATE
ADMISSIONREPORTINGVALUATIONELIGIBILITYCOMPUTECREDITPROPERTYANSWER ONCE PER CLASS
A template, not a bespoke deal
01

A template, not a bespoke deal

Four things have to be settled for any asset: how it is admitted, how it reports what it earns, how its category is valued, and whether it is eligible for a book. Answer them once per category and every later asset of that kind is a form to fill, not a project to run.

  • Admission rules, written per category
  • One reporting interface for the mark
  • A valuation method per asset class, published
FIG.202 / ONBOARD
ASSETREVIEWGATEDADMITTEDON RECORDASSET AASSET BASSET CEACH KEEPS ITS OWN RESULT
Reviewed, then recorded
02

Reviewed, then recorded

Onboarding is deliberately gated. Diligence screens out what should not be here at all — but it does not screen out a bad quarter, so what follows is built to survive an honest asset that underperforms.

  • Not open to anyone; admission is reviewed
  • The asset's own record, isolated from the rest
  • One operator's bad month is not everyone's
FIG.303 / LEVERAGE
WITHOUTONE BOOKWE BUY ITWITH ixOSMANY BOOKSTHEY BRING THEMTHE REGISTER OTHERS ORIGINATE THROUGH
The register others originate through
03

The register others originate through

This is the difference between a register that holds what one operator bought and one that holds what a market brought. We do not need to own a data centre, a loan book and a building — we need each of their owners to have a path on.

  • IX need not originate what it records
  • A new asset class is a filled template
  • The books fill from outside, not from us

SPECIFICATION

What has to be defined per asset class.

None of this is built. It is written down so an operator can argue with the path before committing to it.

ADMISSION
Reviewed — not an open form
IDENTITY
An ID on the register that does not drift
REPORTING
A signed feed of what the asset earns
VALUATION
A published method, per category
ELIGIBILITY
Rules-based weighting into a book
ISOLATION
One asset's performance stays its own
STATUS
Planned — the path is defined, the tooling is not

QUESTIONS

The obvious ones.

Can I put an asset on the register today?

Not through a self-serve route — that is what ixOS will be. Today it is a conversation, and the first book was onboarded by hand. If you operate something that earns and want it recorded, that conversation is still the way in.

Is onboarding open to anyone?

No, and it is not meant to be. The asset and its operator are reviewed before anything is recorded. A register whose admissions nobody checked is not worth being on.

If my asset has a bad quarter, does it hurt other holders?

It should not, and that is a design constraint rather than a nicety. Review can screen out bad actors; it cannot screen out ordinary variance, so an asset's performance is kept to that asset rather than pooled across everyone.

Why publish this before it exists?

Because an operator deciding whether to put a real asset on a register should be able to read the path first. If something in it is wrong, we would rather be told now than after someone has committed.

The books fill from outside, or they do not fill.

The register and the first book run today. ixOS is what lets the second one arrive without us buying it.

IXOSPLANNED