How it works

From payment intent to measured saving

Each bank sends Sampo a payment intent for each of its upcoming large-value payments. Sampo computes a payment schedule and gives each bank advice for its own payments. The bank submits each payment to the RTGS through its own systems, and the RTGS settles it as it does today.

Diagram of Sampo's design, with banks, three compute parties and monitoring. Each bank sends payment intents to the compute parties. They compute the payment schedule together and send each bank its advice.

Bank sends payment intents

The bank's payment system or intraday liquidity system sends payment intents for its upcoming large-value payments to Sampo's Bank node at the bank, through an API. Each record is a payment intent, with the earliest time the bank can submit the payment and the payment's own time. It is not a payment instruction, and Sampo cannot submit it to the RTGS.

The bank sends Sampo only payments above its value threshold. It submits everything else under its existing process.

Bank console setting: value threshold of USD 500m, the minimum payment value that takes part in Sampo, with a range of USD 500m to USD 5.1bn. — The bank sets its value threshold. Here, payments of USD 500m and above take part.

POST /intents

[
  {
    "sampo_payment_id": 8,
    "sender_bank_id": 1,
    "receiver_bank_id": 4,
    "amount": 87250000000,
    "instruction_version": 1,
    "currency": 0,
    "rail": 0,
    "value_date": 20641,
    "submission_ts": 1783425130000,
    "queue_enter_ts": 1783425130000,
    "earliest_ms": 1783425600000,
    "latest_ms": 1783448281000,
    "priority_class": 2,
    "intent_status": 0
  }
]

Response 202

{ "outcomes": [[8, "applied"]], "changes": 1 }

A new payment intent (status 0, create) for USD 872.5m from Bank 1 to Bank 4. The bank can submit it from 08:00 (its earliest time, earliest_ms), and its own time (latest_ms) is 14:18:01. Currency 0 is USD, rail 0 is Fedwire, priority 2 is normal. If the bank sends the same payment intent again, Sampo returns "noop" and changes nothing.

Sampo computes the payment schedule

Sampo computes a payment schedule for the payments of all banks in the cohort. It uses Sampo's rule, parts of which are patent pending. Today Sampo runs on payment data in the clear. In Sampo's design, independent compute parties compute the payment schedule together, and each sees only shares of the amounts.

In that design, which uses multi-party computation, Sampo's Bank node splits each amount into shares before it leaves the bank. Each compute party receives only its own shares, which are not enough to recover the amount. The compute parties receive sender, receiver, timing and priority in the clear.

Bank console privacy setting: disclosure horizon of 60 minutes, with options of 15, 30 and 60 minutes. — The bank sets its disclosure horizon: how far ahead its funding checkpoint reveals the payment schedule (60 minutes by default).

What one compute party receives, in the production design

{
  "sampo_payment_id": 8,
  "sender_bank_id": 1,
  "receiver_bank_id": 4,
  "amount": {
    "party_id": 0,
    "share_a": 1529384710293847561,
    "share_b": 9182736450912837465,
    "reconstruction": "additive-mod-2^64"
  },
  "earliest_ms": 1783425600000,
  "latest_ms": 1783448281000,
  "priority_class": 2,
  "intent_status": 0
}

In the production design, the Bank node sends each compute party a separate record carrying only that party's pair of shares. Recovering the amount needs shares from a majority of parties. This example shortens the other fields.

Sampo sends each bank its own advice

Sampo sends each bank advice for its own payments only, matched to its own references. No bank receives another bank's advice or payment data.

Each advice tells the bank to submit a payment now, before its own time, and gives the bank's funding checkpoint (see step 04). Advice is valid for one minute. The bank submits a payment that Sampo does not advise early at its own time.

Bank console list of upcoming advice: Payment 27 at 13:37; Payments 8, 11, 21 and 29 at 14:05; and later payments, each with its funding checkpoint. — What to submit next. Sampo does not advise Payment 27 early, so the bank submits it at its own time, 13:37. At 14:05 Sampo advises the bank to submit Payment 8 now, 13 minutes before its own time of 14:18:01.

GET /advice/1

[
  {
    "sampo_payment_id": 8,
    "action": "submit_now",
    "step_ms": 1783447500000,
    "recommended_submission_ms": 1783447500000,
    "not_after_ms": 1783448281000,
    "valid_until": 1783447560000,
    "expected_lnncp_checkpoint": 174000000000
  }
]

At 14:05 Sampo advises the bank to submit Payment 8 now (submit_now), 13 minutes before its own time of 14:18:01 (not_after_ms). The advice is valid until 14:06 (valid_until). The funding checkpoint is expected_lnncp_checkpoint: USD 1.74bn. Sampo gives no advice for Payment 27, so the bank submits it at its own time, 13:37. This example shortens the other fields.

Bank submits payments; the RTGS settles them

The bank submits each payment to the RTGS when Sampo advises it, or at its own time, using its existing systems. If the bank does not follow the advice, the advice lapses at the end of its minute, and Sampo's next update of the payment schedule takes that into account (see step 05). The RTGS settles each payment gross, in full and unchanged. Sampo never submits or holds a payment.

Each advice carries a funding checkpoint: the largest net debit that Sampo's payment schedule expects for the bank over the advice minute and the next 60 minutes. Sampo fixes it when it publishes the advice, and it is zero if the bank is not expected to go into net debit. Before it submits a payment, the bank can check its headroom after the payment: the funding checkpoint less its net debit and the payment's amount. If there is a shortfall, the bank may hold the payment until expected receipts settle, or fund the payment itself.

Bank console positions: net debit USD 4.65bn, funding checkpoint USD 4.86bn, headroom USD 211m, 27 payments submitted and 14 upcoming, and a table of advice with each payment's advised time, status, own time and funding checkpoint. — Net debit USD 4.65bn against a funding checkpoint of USD 4.86bn, with USD 211m headroom. Each line gives the payment's status.

Sampo updates the payment schedule every minute

Sampo updates the payment schedule every minute from the payment intents sent so far and advises which payments to submit now. Advice is valid for one minute. The bank submits a payment that Sampo does not advise early at its own time.

New payment intents, amendments and cancellations enter the next update of the payment schedule. So does advice the bank did not follow, which lapses at the end of its minute.

Bank console figures: net debit USD 4.65bn, funding checkpoint USD 4.86bn, headroom USD 211m, 27 payments submitted, 14 upcoming, last payment intent and update at 13:07. — Sampo computed the advice on screen at 13:07, after the last payment intent arrived.

POST /intents (amendment)

[
  {
    "sampo_payment_id": 8,
    "sender_bank_id": 1,
    "receiver_bank_id": 4,
    "amount": 87250000000,
    "instruction_version": 2,
    "earliest_ms": 1783425600000,
    "latest_ms": 1783448400000,
    "priority_class": 2,
    "intent_status": 1
  }
]

Response 202

{ "outcomes": [[8, "applied"]], "changes": 1 }

The bank moves Payment 8's own time to 14:20 (status 1, amend). Sampo accepts the amendment only if its version is higher than the last accepted one. The next update of the payment schedule includes the amendment, and Sampo publishes new advice. This example shortens the other fields.

Sampo monitors submissions and reports the saving

Sampo compares the actual submission times with its advice and reports the liquidity saved: the bank's peak without Sampo less its peak with Sampo. The bank reports when it submitted each payment. The report uses submission and receipt times, not amounts.

The bank's own RTGS settlement record remains the authoritative record for any dispute.

Bank console: liquidity saving today of 48%, net debit USD 4.65bn of a USD 4.86bn funding checkpoint, next submission at 13:37, advice 16 minutes old. — The saving so far today, with the bank's net debit against its funding checkpoint.

POST /feedback

{
  "batch_id": "13:07-EVT",
  "payment_id": "8",
  "actual_release_ms": 1783447572000,
  "status": "settled"
}

Response 204

The bank submitted Payment 8 at 14:06:12 (actual_release_ms), after its advice minute (followed later), and the RTGS settled it.

What the bank keeps

Submission authority

Every submission to the RTGS is the bank's own act, through its existing systems. Advice is never later than the payment's own time.

Customer data

Sampo receives each payment's amount, counterparty bank, priority and time window. Customer data and personal information stay with the bank.

The settlement relationship

Finality stays in central bank money on the existing rail. Sampo holds no funds.

The ability to bypass

A bank need not follow any advice, and can stop sending payment intents at any time. If Sampo is unavailable, banks submit payments as they do today.

Who runs Sampo

The service operator runs Sampo for a cohort. Today FNA is the service operator; an FMI or a bank consortium could be. Each bank decides when it submits its payments, and the existing RTGS settles them.

Who receives what

Party	Receives	Does not receive
Each bank	Advice and funding checkpoints for its own payments	Any other bank's payments, advice or net debit
Service operator (today, with payment data in the clear)	All payment intents, including amounts	Customer data and personal information
Compute parties (production design, with multi-party computation)	Sender, receiver, timing and priority of each payment; one share of each amount	Payment amounts and the liquidity positions derived from them
Monitoring	Health, counts and timings; submission and receipt times for measurement	Payment amounts
The RTGS	Each payment, submitted by the bank as today	Anything from Sampo

Become a design partner · The evidence