Most people selling ledger integration have never operated a payment estate.
Ripple Systems exists on the other side of that: we build and operate the connection between the XRP Ledger and the systems a payment business already runs, and we treat the second half of that sentence as the hard one.
Two kinds of supplier, and a gap between them
Platform vendors know their own product in genuine detail. They own what happens inside it, they document that boundary carefully, and they stop there — correctly, because what lies beyond it is your core, your hub, your reconciliation and your general ledger, none of which they can see.
Systems integrators know the estate. They have moved payment traffic between core systems for two decades and they read a cut-off schedule fluently. What they tend to do with a ledger is treat it as one more API — which works until an amendment activates, a node falls behind, or somebody asks what finality means for a payment that has already been posted.
Neither is a criticism. They are different disciplines and each does its own competently. But the questions that decide whether an integration reaches production sit precisely between them: what posts when, what reconciles against what, what happens during the maintenance window, and who is on call when a node stops keeping up at three in the morning.
Those questions have measurable answers. Somebody has to be fluent in both vocabularies to ask them properly, and it should be somebody you are paying rather than somebody selling you a platform.
The ledger is the part that works on day one. Everything it has to connect to is the part that decides the outcome.
Three commitments that cost us revenue
Independence is easy to claim and expensive to hold, and it is harder to hold as a builder than as an adviser: a firm that both recommends and implements has an obvious reason to recommend more implementation.
These are the specific things it commits us to. Each forecloses work we could otherwise take. They are stated here so a vendor risk function can hold us to them, and so a client can ask at any point whether we have kept them.
What we will not do
- We do not sell a platform. A builder with a platform to place has a reason to prefer the design that needs it. Removing the platform removes the reason, and you can stop discounting the advice.
- We take no fees from vendors. A negative finding about a vendor has to be able to cost us nothing. Otherwise the finding you most need is the one we are least able to write.
- We hand over what we build. An integration only your supplier can operate is a dependency you bought without pricing it. Your exit position should be the same on the day we finish as it was before we started.
Four commitments, and they hold whether or not you like the finding
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.
Who does the work
A bank's vendor risk function will verify what is written here, and it should. This matters more for a firm that builds than for one that only advises: you are being asked to let us write code that moves money.
Nothing in this section will be published until it is accurate and checkable.
[Two to three sentences of real background. Concrete and verifiable: the institutions and systems worked on, the payment estates operated, and what makes the engineering judgement credible to a bank. No adjectives that cannot be checked.]
[If the firm is one person, say so plainly here. A stated principal reads better to a vendor risk committee than an unexplained collective voice.]
We are not connected to the similarly named payment company
The name invites a question, and the question is sharper now that this site names the XRP Ledger on every page. So we answer it here formally, in full, rather than waiting to be asked.
The name is not a claim of association. Ripple Systems is not a Ripple Labs partner, reseller, referral recipient or certified implementer, and holds no commercial relationship with Ripple Labs, Inc. or with any vendor whose platform we integrate or assess. We work on the XRP Ledger because it is open-source infrastructure our clients are deciding about, and that is a technical competence rather than a commercial arrangement.
The name refers to what the work is about: a change in one part of a payment system reaches every other part, and the second-order effects are where programmes are decided. We use the two-word form everywhere, and we do not shorten it.
If you are checking
- We take no fees, referrals or margin from any vendor, protocol or issuer, and we will confirm that in writing on request.
- We sell no platform of our own. What we build runs on your infrastructure, in your repositories, under your change control.
- We hold no digital assets, express no view on their value, and do not advise on whether to hold, trade or price any of them.
- We do not name clients or reference engagements in any material, including this site.