# Sampo: Q&A for Banks

*This answers the questions banks have raised in early discussions and describes the
intended operating model for Sampo's first production cohort. Deeper cryptographic,
economic and regulatory detail is available in the due-diligence pack for banks.*

*Sequenced for a treasury audience: the economics and the decision first, then
control and operations, then confidentiality, technology and regulatory posture. A
separate technical session covers security and engineering.*

---

## Economics and the decision

**1. What is this worth to our bank, and how would we know?**

On a Fedwire-referenced synthetic model of a five-bank core, Sampo's payment schedule
delivers a **49.3% reduction in the cohort monthly peak net debit, about $55.4bn**
on the modeled book. That figure is synthetic: it demonstrates the mechanism and is not
a forecast for your bank. The production precedent
for the mechanism class is CHAPS, where the liquidity-saving mechanism cut settlement
banks' intraday liquidity requirement by roughly 20%, about £4bn a day, with no loss of
throughput; the gridlock-resolution algorithm underlying that class of mechanism was
formalized by Bech and Soramäki (2001).

What you get in a pilot is your own bank's figure across the sample, including the
days coordination helps least, not a network average and not our number applied to
you. If it is not material for you, you learn that early and cheaply. The saving is a
network property (incoming payments that, submitted in a better order, fund your
outgoing ones instead of your own balances and collateral), so no single bank can
measure it alone.

**2. How does a modeled peak reduction become money in our numbers?**

Through your methodology, not ours:

`annual value = modeled in-scope peak reduction × recognition factor × your cost of liquidity`

We supply the first term. You own the other two. The **recognition factor** (0–100%)
is how much of the modeled reduction your approved methodology recognizes. The
**cost of liquidity** is an annual rate: what holding one unit of liquidity for a year
costs your bank. It may include reserve opportunity cost, collateral encumbrance,
intraday credit and internal stress-buffer charges. We compute the annual value for each
bank at its own factor and rate, then sum over the banks. Any figure we show at 100%
recognition and 1% a year is a sensitivity point, not a forecast and not booked P&L.

A lower modeled peak does **not** automatically release a regulatory buffer, HQLA or
capital, and we make no such claim. Regulation YY requires tailored intraday-liquidity
monitoring ([12 CFR 252.34](https://www.federalreserve.gov/frrs/regulations/section-25234-liquidity-risk-management-requirements.htm))
and, separately, stress testing that sizes a buffer of unencumbered highly liquid
assets ([12 CFR 252.35](https://www.federalreserve.gov/frrs/regulations/section-25235-liquidity-stress-testing-and-buffer-requirements.htm));
parallel provisions apply to covered foreign banking organizations under
[12 CFR 252.156](https://www.federalreserve.gov/frrs/regulations/section-252156-liquidity-risk-management-requirements-for-foreign-banking-organizations.htm)
and [252.157](https://www.federalreserve.gov/frrs/regulations/section-252157-liquidity-stress-testing-and-buffer-requirements-for-foreign-banking-organizations.htm).
No public rule publishes a peak-to-buffer conversion. Only your liquidity-risk and
regulatory teams can say whether the modeled reduction is recognized in liquidity,
HQLA, collateral or intraday-credit capacity. The pilot applies your
internal liquidity stress testing (ILST), funds-transfer-pricing and balance-sheet
methodology to the result before anyone assigns value to it.

**3. What is the measurement compared against, and can we end up worse off?**

The comparison is your **peak without Sampo for the same in-scope payments**: every
payment submitted at its own time, against your peak with Sampo. In a replay, each
payment's own time is the time you settled it. Sampo may advise a payment earlier than
its own time, never later. The measure is your modeled in-scope peak net debit
at the agreed measurement instants, not actual funding drawn and not your total
liquidity requirement.

Sampo's no-worse-off guard aims to reduce the risk that a bank is worse off: that its
realised peak net debit with Sampo ends above its peak without Sampo. It is not a
guarantee.
That is retrospective, liquidity-specific evidence, not a live guarantee. A further
risk is adherence: advice is non-binding, so realized savings depend on banks following
it rather than overdrawing through it, and a large bank that does not follow its advice
can degrade the result for everyone. Measuring the acceptable range of peer conduct on
real data is the point of the pilot. We report the effect of advice you did not follow
separately from the effect of advice your peers did not follow. We also report the worst
single bank alongside the cohort figure, because minimizing a total can shift burden onto
one bank.

**4. What does each phase cost us, and what are we committing to?**

| Phase | What you get | What you commit | Commercial |
|---|---|---|---|
| Evidence pilot (shadow) | Your own measured saving on your historical or shadow flows | Data sharing under NDA and third-party-risk approval; **no operational change** | Paid pilot fee |
| Advisory production | Private advice via API, adherence monitoring | API integration; treasury desk consumes advice | Subscription per bank, sized to your measured opportunity |
| Governed pre-processing (later) | Binding payment schedule under an agreed rulebook | Rulebook accession | Subscription plus value-share, once measurement and attribution rules are agreed |

Advisory participation is an API feed of payment intents and submission feedback. No
balances, no liquidity positions, no change to how you settle. Value-share pricing is
a later-phase conversation and requires attribution rules the cohort has not built
yet; we do not offer it in the pilot.

**5. What would make you stop?**

A no at any point, in order: savings not material; realized savings not positive under
realistic adherence; banks unwilling to send payment intents under the MPC model; MPC
too slow across compute parties; feeds not timely enough; or no credible sponsor or
regulator-comfortable rulebook for the later binding phase. We would rather find a no
early.

---

## Control and operations

**6. How often does Sampo update the payment schedule, and what are the operational rules?**

Sampo runs beside the existing RTGS. Each bank
sends its upcoming large-value payment intents through an API from its own
payment system or intraday-liquidity system. A payment intent gives the payment's
amount, counterparty bank, priority, earliest time and own time. It is not a queued
payment or a payment instruction. Each bank sends Sampo only payments above its value
threshold. In Sampo's design, independent compute parties compute the payment schedule
together, and each sees only shares of the amounts. Each bank receives advice for its own
payments only, and Fedwire settles every payment gross and in full. Each minute, Sampo
updates the payment schedule 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. Throughout, you decide when to submit: Sampo never submits
or holds a payment.

**7. Can we amend the list of payments we send to Sampo, and does the advice change?**

Yes. Amending the list you've sent, and getting updated advice back, is a
standard operation, done through the same bank console and API you use to send
payment intents.
Only the bank that sent a payment intent can amend or cancel it. An amendment may
change amount, timing or priority; to change a counterparty, the bank cancels the
payment intent and creates a new one. Any accepted amendment or cancellation enters the next update of
the payment schedule, and the affected banks receive updated advice. A bank can always
cancel a payment it has not yet submitted. Each amendment carries an
increasing version: Sampo refuses an amend with an older version, and acknowledges an
exact repeat without applying it twice. Sampo logs every change for audit.

The update behavior for the first cohort is a fixed design contract, not a
tuning parameter:

- **One-minute updates.** Each minute, Sampo updates the payment schedule and publishes advice.
  Advice is valid for one minute.
- **Advice expiry.** Each advice tells a bank to submit a payment now. It expires at
  the end of its minute. Each advice carries its publication time, so a bank can always
  tell whether what it holds is current. Sampo never presents expired advice as
  current.
- **Notification.** Updated advice reaches the bank through the same API and console
  used to send payment intents, so the bank's payment system or treasury system can act
  on it or not, under existing controls.
- **Missed update.** If an update does not complete in time, Sampo issues no new
  advice and the fallback in Q11 applies. There is no state in which a
  bank cannot submit a payment: absent current advice, the bank submits
  under its own process exactly as it does today.

The time limit for an update is a pilot acceptance threshold rather than a
published figure; see Q14.

**8. Can we have queue visibility: what is in the payment schedule, what has been
submitted for settlement and its status, plus counterparty and position?**

Yes. Through the Sampo API and bank console you see every in-scope payment your bank
sent to Sampo: its current payment state, counterparty, latest advice and
its validity, and the settlement status confirmed by your own systems. You also see
your net debit among payments in Sampo, the funding checkpoint in each advice (the
largest net debit the payment schedule expects for your bank over the advice minute and
the next 60 minutes, fixed when Sampo publishes the advice, and zero if none), and exceptions such as a missing receipt or
expired advice. You never see another
bank's queue, status or net debit. Reconciliation stays inside each bank; central
Monitoring receives only value-free operational aggregates.

**9. Don't change the rails we've already chosen; optimise within them. Does Sampo
re-route payments?**

No. The initial service operates within Fedwire. Sampo advises on the timing of
submissions on the rail you have already chosen for each payment; it never
moves a payment between rails, and never changes an amount, counterparty or settlement
finality. Any future CHIPS service would be configured and validated separately.

**10. How does Sampo avoid settlement blockage when erroneous submissions disrupt a
clearing cycle?**

Sampo cannot block settlement or create a system-wide clearing dependency. It does not
perform atomic netting and takes no part in settlement: there is no cycle that must
clear as a group, every payment settles gross and in full on the RTGS independently,
and Sampo advises only timing.

What Sampo's advice can do is tell a bank to submit a payment now, before its own
time. The bank submits a payment that Sampo does not advise early at its own time.
Advice places no hold on a payment: the bank need not follow it, under its own
controls.

An erroneous payment intent *inside* Sampo is a separate matter, and we don't claim
immunity to it. A bad payment intent can degrade advice or raise a bank's peak net debit, but it cannot move money
or block the RTGS. Several controls limit its effect. First, payment intent
screening builds on FNA's existing payment-system monitoring and anomaly-detection
capabilities: Sampo checks incoming payment intents for outliers (unusual amounts, likely
fat-finger errors, off-pattern timing) and flags them to the bank that sent them, to
confirm before they affect the payment schedule. Beyond that, after an amend or cancel,
Sampo issues corrected advice at the next update, without the bad payment intent,
and each bank's Bank node reconciles advice against its own submission, settlement
and receipt confirmations. The RTGS settlement record stays the authoritative evidence for any
dispute.

**11. What is the impact on resilience, and how is this hosted for disaster recovery?**

If Sampo fails, each bank returns to its existing process; a failure never affects
settlement.
In the production design, the three compute parties operate independently in
separate failure domains, and Sampo needs all three to produce advice. If a party is
unavailable or a computation exceeds its time limit, Sampo issues no new advice, logs
the event and raises an alert, and banks submit under their existing procedures. Durable records of payment intents and a
signed, append-only event log let the service restart and reconstruct its state
deterministically. Detailed hosting topology, recovery objectives and recovery-test
commitments are agreed through technical due diligence.

**12. How do you enforce that advice is followed, and handle misbehaviour
under stress?**

Sampo does not enforce its advice in the advisory phase (the bank always
decides when to submit), so the service operator manages advice that is not followed
operationally rather than preventing it. Advice is valid for one minute, and Sampo
updates the payment schedule each minute from the payment intents sent so far. Sampo separates the
effect of a bank's own actions from effects imported from peers and reports the
interaction explicitly. Sampo's no-worse-off guard aims to reduce the risk that a
bank is worse off: that its realised peak net debit with Sampo ends above its peak
without Sampo. It is not a guarantee, including against advice that peers do not follow.
The service operator treats deliberate protocol abuse separately from advice not
followed: Sampo authenticates payment intents and applies limits on open payment
intents, rates and amendments, and the service operator isolates a bank that exceeds
them. Rewarding good behaviour, not just coping with advice not followed, is a
deliberate part of the design, and FNA is designing it with the cohort: subject to the
cohort's agreed measurement and attribution rules, value-share pricing can reward
realized savings attributable to adherence without charging a bank for losses imported
from peers. Cohorts requiring binding enforcement would
move to a separately governed rulebook phase.

---

## Confidentiality and technology

**13. How does the multi-party computation keep our amounts secret?**

In Sampo's design, independent compute parties compute the payment schedule together,
and each sees only shares of the amounts. The mechanism is secure multi-party computation
(MPC), not hashing. In the production design, your Bank node splits each amount into
random shares before it leaves your bank and sends them to three independent compute
parties, which compute the payment schedule on the shares. Under the honest-majority Rep3
design, a single compute party holds only a replicated share pair, never enough to
reconstruct the amount. In the first-cohort design, the confidentiality guarantee
assumes no more than one compute party is compromised or colluding and that the
parties follow the protocol; authentication, consistency checks and operational
controls address attempted deviation separately. That is why the three parties are
operated by genuinely independent institutions, and the banks approve the
compute-party operators before any data flows. Amounts, and the liquidity positions derived
from them, are protected; the compute-party operators receive the public fields (sender
bank, receiver bank, time window and priority), which Sampo's rule needs, and the resulting payment
schedule, never an amount. Each bank receives only its own advice, and Monitoring
receives only value-free operational aggregates.

**14. Is it fast enough?**

The target service is designed to update its payment schedule each minute within the agreed
operating window. In the production design, compute parties operate independently in
separate failure domains within one region, which keeps round-trip latency (the main
driver of runtime) low. The first-cohort protocol requires all three parties: loss of
one pauses new advice and triggers the fallback described in Q11, without affecting
settlement.

We do not yet assert a measured performance margin for the cohort's workload. The
timings published so far do not cover Sampo's current rule under MPC or a real
cross-region placement, so they are not evidence of a performance margin either way.
FNA acceptance-tests latency, throughput, recovery behavior and network assumptions
during the pilot against a threshold agreed with the banks in advance, and documents
them in the technical due-diligence pack. When measured results are available we
publish the workload, the environment, percentile latency and the acceptance
threshold, rather than a single indicative number.

**15. Is this built on distributed ledger technology (DLT) or blockchain?**

No. Sampo is not a distributed ledger or blockchain system. Confidentiality is designed
to come from secure multi-party computation over secret-shared inputs, and settlement
stays on the existing RTGS. There is no shared ledger, token, consensus protocol or on-chain
settlement; Sampo holds no funds and settles nothing, and the RTGS provides finality
in central-bank money exactly as today.

---

## Regulatory posture

**16. Are you a financial market utility or infrastructure (FMU/FMI)?**

Sampo is designed and contracted as a non-binding compute-and-advice service. It does
not operate the rail, transfer or settle funds, net obligations, or control settlement
finality: each bank remains responsible for submitting its payments and the RTGS settles unchanged.
Those features support the working position that Sampo is a service provider rather
than an FMU/FMI. Final classification is assessed in each jurisdiction with counsel and
discussed early with the relevant supervisors.