Ripple Systems Payments Infrastructure Engineering
Engagements

Three ways in, and none of them comes first.

Most firms in this position sell a study you have to buy before they will build anything. We do not, because an organisation that already knows what its estate does should not have to pay somebody to tell it.

Entry point 1 of 3

Integration assessment

Fixed scope · four to five weeks

What your payment estate can carry today, measured against the twelve capabilities, and what closing each gap costs before anything is committed.

Four to five weeks, on a fixed scope. Twelve capabilities established against configuration, architecture, runbooks and observed behaviour, then a delivery plan with the dependencies named — including the ones that sit outside anything we would do.

This is the right way in when the programme has a date but no measured basis for it, or when three people in the building give three different answers to the same question about the payment path. It is the wrong way in when you already have that baseline, and we will say so rather than sell it to you anyway.

What it covers

  • Twelve capabilities established against evidence — configuration, architecture, runbooks, observed behaviour.
  • A sequenced delivery plan with the dependencies named, including the ones that sit outside this work.
  • A written recommendation, drafted so it can be handed to an examiner or an internal auditor without an editing pass.
Entry point 2 of 3

Design and build

Fixed scope per phase

The integration itself: message mapping, settlement path, reconciliation, node operations, and the runbooks that let your own people operate it.

Fixed scope per phase, agreed in writing before that phase starts. The work lands in your repositories under your change control and is reviewed by your engineers while it is being written. There is no phase at the end where the code arrives.

We build against the systems you actually run rather than against a reference architecture, which usually means the first fortnight is spent reading configuration rather than writing anything. That is deliberate: an interface designed against a description of your core is an interface that gets rewritten during integration testing.

Runbooks, instrumentation and a rehearsed handover are in scope from the start. They are the first things cut when a date moves, and they are the reason an integration is still operable two years later.

What it covers

  • Code in your repositories, under your change control, reviewed by your engineers as it is written.
  • Interfaces designed against the systems you actually run rather than against a reference architecture.
  • Runbooks, instrumentation and a rehearsed handover, in scope from the start rather than added as a change order.
Entry point 3 of 3

Operate and hold

Retained monthly

Running the infrastructure with you or for you — node operations, amendment governance, incident response, and the evidence a supervisor asks for afterwards.

Retained monthly, once something is running. Node and validator operations with monitoring your own team can see into, amendments tracked and tested against your integration before they activate, and incident response that produces timestamped evidence rather than a reconstruction.

This is a choice rather than a consequence. Everything we build is handed over in a state your operators have exercised, so a retained arrangement should be something you take because it suits you — not because the build left you unable to run what you own.

It also works on infrastructure we did not build. If somebody else delivered the integration and nobody has owned it since, that is a common and fixable position.

What it covers

  • Node and validator operations with monitoring your team can see into, not a status page.
  • Amendments tracked and tested against your integration before they activate.
  • Incident response with timestamped evidence, and the supervisory-reporting path exercised before it is needed.
Shape

How an engagement runs, whichever door you came through

Deliberately not stated in weeks. The same shape has to hold for a four-week assessment and for a nine-month build, and a calendar that pretends otherwise is a calendar that gets quietly abandoned in month two.

First

Framing and access

Agreement on what is genuinely in scope, and access to the systems, runbooks and people the evidence lives in. We execute your NDA before the first call rather than asking you to sign ours.

Then

Measurement before design

Capabilities are measured rather than discussed. Where a number is claimed, it is observed. Where behaviour is documented, the documentation is tested against what the system does.

Early

The unwelcome part, early

An interim read-out delivered privately to the sponsor, while there is still time to argue with it and still time to change the plan if we have measured something wrongly.

Through

Built in the open

Work lands in your repositories under your change control, reviewed by your engineers as it is written. There is no phase at the end where the code arrives.

Last

Handover and rehearsal

Runbooks, instrumentation and a rehearsed handover: your operators run a failover and resolve a break before sign-off. Retained operations is a choice you make afterwards, not a dependency the build creates.

Boundaries

What we don't do, and what that protects

These are positioning commitments rather than preferences. Each one costs us revenue we could otherwise book, and each exists because the alternative would quietly damage the thing you are buying.

We do not sell a platform

There is no proprietary middleware here that you have to keep licensing. What we build runs on your infrastructure, in your repositories, under your change control.

What it protects

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

No referral fees, no revenue share, no reseller margin, no partner tier, no sponsored placement. There is no vendor we are paid to reach for.

What it protects

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

Documentation, runbooks and a rehearsed handover are in scope from the start rather than added later as a change order. Your operators exercise the system before sign-off.

What it protects

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.