Twelve capabilities, and eleven of them are not about the ledger.
Six of connecting a ledger to a payment estate that already has a core, a hub, cut-offs, reporting obligations and an operations team. Six of running the result afterwards, on the assumption that it stays up, stays current, and can prove what it did.
One spine, used three ways
These twelve are the scope of an integration assessment, the scope of a build, and the twelve questions of the diagnostic. Keeping them identical is deliberate: an assessment that measures one set of things and a build that delivers another is how a programme ends up with a document nobody can act on.
Each is established against configuration, architecture, runbooks and observed behaviour rather than against what a vendor or a team believes to be true. Where the two differ, the difference is the finding, and it is usually the most useful thing in the document.
Two of the twelve are ledger-specific. The other ten are the same engineering wherever value settles, which is why they transfer directly to whatever else your business already runs.
Two questions before you engage anyone
- Where does a ledger transaction enter your payment estate today, and who owns that interface? If the answer is a point-to-point integration somebody stood up for the pilot, the production question is already open, whoever ends up doing the work.
- If ledger state and core state disagree tomorrow morning, who reconciles them, on what frequency, and what is the documented path for resolving the break? Most institutions find the answer is a person rather than a process. That holds at pilot volumes and stops holding shortly afterwards.
Settlement and payment integration
Connecting a ledger to a payment estate that already has a core, a hub, cut-offs, reporting obligations and an operations team.
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.
ISO 20022 message mapping
pacs.008, pacs.009 and camt reporting mapped to ledger transactions and back, including the fields that have no counterpart on either side and have to be carried somewhere.
Settlement and posting model
Continuous or batch posting, cut-off behaviour, and what settles outside business hours without an operator present.
Corridor design and liquidity orchestration
Funding, quoting and slippage across a corridor at the volumes you actually expect, and the behaviour when one side is short at the wrong hour.
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.
Payment lifecycle and exception handling
Returns, reversals, partial legs and stuck payments — the paths that carry no volume at all until the day they carry everything.
Ledger operations and interoperability
Running the infrastructure afterwards, on the assumption that it has to stay up, stay current, and prove what it did.
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.
Amendment and upgrade governance
Tracking amendments, testing them against your integration before they activate, and holding a documented position when one is contested or arrives on a timetable you did not choose.
Availability, failover and continuous operation
What happens during the maintenance window, during a failover, and during the week of the core upgrade — measured against a standard that assumes payments do not stop.
Observability, SLOs and incident evidence
Instrumentation that produces the timestamps an incident report needs, rather than a reconstruction assembled afterwards out of four teams' recollections.
Throughput, latency and load behaviour
Measured at the worst hour of the week rather than the advertised one, across every leg including the ones a correspondent or a vendor owns.
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.
A sequenced plan with the dependencies named
An assessment states what the estate carries today, what each gap costs to close, and the order the work has to happen in. Where a dependency sits outside this engagement — a core change your team owns, a vendor contract that has to move first — it is named as a dependency rather than absorbed silently into an estimate.
That matters more than the findings themselves. A plan whose critical path runs through somebody else's change queue is a plan with a date that nobody in the room controls, and it is better to know that in week three than in month seven.
The document is written to be defended: drafted for a reader who will disagree with it, and structured so it can be handed to an examiner or an internal auditor without an editing pass first.
Illustrative structure only. Phases shown are examples of the form the plan takes, not commitments, and not drawn from any engagement.
Four commitments, agreed before anything starts
Measured, not asserted
A capability is established against configuration, architecture, runbooks and observed behaviour. What the vendor believes and what the team believes are recorded as claims, then tested.
Bad news early
The interim read-out arrives while there is still time to act on it, privately to the sponsor. A finding that arrives with the final document has been withheld.
Scope agreed before work begins
A written scope and a fee for each phase, agreed in advance. No severity-based pricing, and no change order for something we should have found in the first fortnight.
Written to be defended
Documents are drafted for a reader who will disagree with them — an examiner, an internal auditor, a vendor's counsel. That is a different document from a slide deck.
The ones we are actually asked
Do you only build on the XRP Ledger?
It is where the practice is deepest, and it is what most people arrive asking about. But ten of the twelve capabilities are not ledger-specific at all — message mapping, posting models, reconciliation, exception handling, availability, observability and measured latency are the same engineering wherever the value settles.
Where a business unit already runs another ledger, that is capability twelve rather than a different engagement. The boundary between the two is the part that needs designing.
We have already selected a vendor platform. What is left to build?
The boundary between their platform and your estate, which is usually the part neither side has scoped. A platform owns what happens inside it. What happens between it and your core, your hub, your reconciliation and your general ledger is yours, and it is where integration programmes lose their timelines.
We are not a substitute for the platform and we do not compete with it. We also take no fees from it, which means we can say plainly which side of the boundary a given problem falls on.
Is this a crypto engagement?
No. Nothing in the twelve capabilities requires a view on any asset, any token or any price. Two of them concern node operations and amendment governance because your integration will touch a ledger; the other ten are settlement, message mapping, reconciliation, exceptions, availability, observability, latency and interoperability.
This is payments integration carrying unfamiliar vocabulary. The unfamiliar vocabulary is why it is often being sold by people who have never operated a payment estate.
Do you take fees from any of the vendors you work alongside?
No. No referral fees, no revenue share, no reseller margin, no partner tier and no sponsored placement.
This is a positioning commitment rather than a courtesy. If a negative finding about a vendor could cost us money, the finding you most need is the one we would be least able to write.
What access do you need, and from whom?
Read access to the payment path architecture end to end; message specifications and any existing mappings; runbooks for maintenance, failover and incident response; existing vendor contracts and SLAs for the critical providers; and whatever reconciliation procedures exist between ledger state and core state.
In people: two to three hours each with payments engineering, core operations, treasury operations, and whoever currently owns the vendor relationships. We work under your NDA and your access controls, and we execute your paper before the first call.
What do we own at the end?
Everything. Code in your repositories, under your change control, reviewed by your engineers while it was written rather than delivered in a block at the end. Runbooks, instrumentation and architecture documentation are part of the scope, not a phase that gets cut when the date moves.
Handover includes rehearsal: your operators run a failover and resolve a reconciliation break before sign-off. If you then choose a retained arrangement, it should be because it suits you rather than because the build left you unable to operate what you own.
Answer the twelve for yourself first
The diagnostic asks one question per capability and scores it in your browser tab. Nothing is stored, and no benchmark is invented. If it comes back stronger than you expected, that is worth knowing before anyone quotes you for anything.