This paper states Sampo's regulatory and assurance posture for the current phase. It is a summary for general distribution, not a legal opinion or a compliance attestation. A detailed control-by-control mapping is maintained separately and is available to a prospective bank, under NDA, as a dated diligence pack.
Working classification, no safe-harbour claim
The working classification is that Sampo operates as a compute-and-advice service rather than a payment scheme or financial market infrastructure: it issues advice, each bank decides and submits through its own systems, and the RTGS settles every payment gross and in full, unchanged. This makes Sampo less like an FMI but does not by itself determine its legal classification, and we make no safe-harbour claim. Payments-regulatory, outsourcing, data-protection, competition-law and supervisory analysis is required in each jurisdiction, and the classification remains subject to counsel and supervisory confirmation.
Assurance status and conditions for live data
The prototype demonstrates the mechanism and the economics on synthetic data. Running on live bank data needs separate approval and is not yet in place. The conditions are:
- authentication of every payment intent and report;
- mutually-authenticated, encrypted transport on every channel (the prototype transport is cleartext);
- an independent security audit;
- compute-party operator agreements and governance across the independent compute-party operators;
- key management (generation, custody, rotation, compromise response);
- assurance sign-off against these conditions.
Until these are met, Sampo is a measurement and demonstration tool, not a live operational dependency.
Customer third-party-risk support
The service operator supports a bank's own third-party / outsourcing risk process: it provides the diligence pack (control mapping, data-flow description, and the prototype-vs-target distinctions), supports the bank's risk assessment and questionnaires, and identifies which obligations are the bank's and which are the service operator's and the compute-party operators'.
Service operator, compute-party operator and subprocessor transparency, audit and incident support
The identities and roles of the service operator and the compute-party operators (and any subprocessors) are disclosed to the banks. The arrangement supports audit rights and incident notification and support, and each compute-party operator is expected to have its own periodic independent security audit. In the production design, no compute-party operator receives a cleartext amount; compute-party operators do receive the public fields (sender bank, receiver bank, time window and priority) and the payment schedule.
Operational bypass and managed exit
Because advice is non-binding and Sampo takes no part in settlement, a bank can bypass Sampo at any time (simply submit payments as it does today) with no settlement impact. A managed exit returns the bank to submitting at its own times; nothing in settlement ties the bank to Sampo.
Privacy, cross-border and competition screening
- Privacy. In Sampo's design, independent compute parties compute the payment schedule together, and each sees only shares of the amounts. In that design, no single party receives an amount in the clear. Monitoring receives no amounts. The current monitoring data is value-free but not graph-free; a graph-free target (bank-side reconciliation) is planned. The MPC built so far assumes semi-honest compute parties with an honest majority. The current rule is designed for MPC; its security model is still to be defined.
- Cross-border. Where compute-party operators or data span jurisdictions, cross-border data-handling and transfer implications are screened per jurisdiction.
- Competition. The arrangement among the banks, the service operator and the compute-party operators is screened for competition-law implications; coordination is advisory and each bank acts independently on its own systems.