Settlement between counterparties who are not banks, on systems built for invoices.
Corporate treasury functions, supply chain and logistics operators, energy and utility settlement, and public registries — where the ledger is being asked to carry obligations that currently live in an ERP and a spreadsheet.
Who has to be convinced, and of what
There is no supervisor in this room, which changes the argument rather than softening it. The people deciding are an operations director and a treasurer, and what they are protecting is a process that already works well enough for nobody to want it disturbed.
The integration surface is different too. There is no payment hub to connect to, no ISO 20022 obligation to satisfy, and usually no team that has operated distributed infrastructure before. What exists is an ERP, a reconciliation that runs monthly, and a general ledger that has to keep balancing.
Two questions worth answering first
- What reconciles the ledger against your general ledger, how often, and who resolves it when they disagree? A monthly close against a ledger that finalises in seconds leaves a gap. The question is whether anything owns it.
- If you run a node, who is on call for it, and what wakes them? If the answer is that a vendor runs it and sends a status page, that is a supportable choice — but it should be a choice rather than a discovery.
What is forcing the decision
The reconciliation is monthly and the ledger is not
A settlement layer that finalises in seconds against a back office that closes monthly produces a break window measured in weeks. Somebody has to own what happens inside it.
Nobody here operates infrastructure
Running a node is not difficult. Running one with monitoring, storage planning, amendment tracking and an on-call rota is an operations function that most corporate IT departments do not currently staff.
The boundary is the whole design
Value crossing from a ledger into an ERP, a registry or another chain is where the failure modes live. The crossing needs designing before the thing on either side of it does.
The capabilities this usually turns on
All twelve are in scope. These four are where the work concentrates for an organisation of this kind, and where an assessment tends to find the thing that moves the date.
Core and payment-hub integration
Where the ledger meets the systems that already move your money: the core, the payment hub, the message broker, and the change queue everything else is already waiting in.
Reconciliation and break management
Ledger state against core state against the general ledger, on a schedule, with a documented path for the morning they disagree.
Node and validator operations
Running the infrastructure rather than depending on somebody else's: topology, peering, storage growth, and monitoring that reports a problem before a payment does.
Interoperability and multi-ledger integration
The XRPL EVM sidechain, bridges, and the ledger a business unit already runs. Where value crosses a boundary, the boundary is the part that needs designing.
Three ways in, of equal standing
There is no fixed ladder here and no engagement you have to buy before another one becomes available. If you already know what your estate does, an assessment is a formality you can skip. If you do not, four weeks of measurement costs less than the first wrong assumption.
Handover is part of the scope. An integration only your supplier can operate is a dependency you bought without pricing it.