A settlement project crosses several teams before it crosses a network. Payments defines the service, treasury supplies the liquidity, technology connects the systems, and risk establishes the conditions under which money can move.
This report gives that buying group a shared way to make the decision. It connects current institutional developments to the questions that determine an implementation: what changes, what stays, who authorizes release, and how the outcome is recorded.
01
The Settlement Blueprint
The operating case
01 / Perspective
The decision in brief
Modernize a measurable settlement workflow around the infrastructure you already operate.
New payment mechanisms are increasing the choices available to institutions. Turning those choices into a reliable service requires a common operating discipline across funding, permissions, execution, exceptions and reconciliation.
The strongest first project has a named owner and a specific outcome. It might reduce the balances needed for an intragroup cycle, apply the same release policy across payment routes, or give a counterparty a record it can verify. Each starts with a workflow the institution already understands.
01
Measure completion
Track when the recipient can use the funds and when both sides can reconcile the transaction. Network arrival is one milestone in that sequence.
02
Retain execution control
Identify the ledgers, accounts, keys and payment platforms that will remain responsible for moving and recording funds.
03
Put controls at release
Agree the policy decision, authorization and evidence required before execution. Define what happens when a check fails or a system is unavailable.
04
Prove the business case
Compare current and proposed costs for the same flow. Count usable funding released and observed operating effort, with all delivery costs included.
02 / Perspective
Measure the whole settlement journey
The relevant clock stops when the funds are usable and the records agree.
A payment can reach the receiving institution quickly and still require work before the beneficiary can use the money. Local processing, account restrictions, operating hours and data quality all sit inside the customer experience.
That distinction should shape an evaluation. Improving one system response is useful only when the team can show how it changes the complete workflow. Define the starting instruction, the cash movement and the accounting record before choosing a performance measure.
01
Instruction accepted
The receiving system has accepted a valid instruction. Acceptance alone does not establish that a beneficiary has been credited.
02
Funds available
The relevant account or instrument can be used under the agreed service and legal terms.
03
Records reconciled
The parties can connect the instruction, execution response and ledger record, including any exception.
A useful speed benchmark identifies both its population and its endpoint.
The FSB’s latest annual monitoring report, published in October 2025, shows the difference between network delivery and beneficiary credit. In its Q1 2025 wholesale sample, 88.5% completed the Swift inflight leg within one hour; 54.6% were credited to the beneficiary within one hour.
The G20 target is for 75% of wholesale payments to be credited within one hour by end-2027, with the remainder within one business day. Swift’s separate Spotlight on Speed study examines why receiving-bank processing can delay the last part of the journey.
For your own flow, timestamp instruction acceptance, each release decision, the execution response, beneficiary availability and reconciliation. Compare a representative set of normal and exception cases, including weekends and the relevant local operating windows.
01
Choose the endpoint first
A treasury availability target and a payment-message delivery target answer different questions.
02
Measure the difficult cases
Include incomplete data, changed instructions, held funds, unavailable services and ambiguous responses in the sample.
Within one hour: network delivery and beneficiary credit
Reached beneficiary bank88.5%
Credited to beneficiary54.6%
75% G20 end-2027 target for beneficiary credit
FSB, October 2025; Q1 2025 wholesale payments of at least USD 100,000. Swift data; non-business days excluded. Credited measure excludes forward-dated payments. Annex C, tables 1–2.
Public-sector programmes are testing how money, assets and controls work together.
Institutional programmes are exploring several ways to coordinate settlement. Some connect an existing central-bank-money system with an external asset platform; others test tokenized commercial-bank and central-bank money together.
Agorá’s testing shows the operating work that sits around the technology. A payment mechanism needs defined authority, participant procedures and recovery arrangements. These should be part of the design from the start.
01
Project Agorá: controlled real-value testing
July 2026 testing covered 17 scenarios using tokenized deposits and reserves. Contractual responsibilities, runbooks, maker-checker controls and fallback procedures accompanied the prototype’s payment mechanisms.
A corporate cash-management adoption and a live interbank transaction show where coordination sits.
The operating arrangements matter as much as the technology label. These two bank-reported examples retain defined account and execution systems while adding a mechanism to coordinate movement.
01
HSBC and Standard Chartered / August 2026
HSBC announced the first live cross-border tokenized-deposit transaction on Swift’s blockchain-based ledger on 20 August 2026. Each bank recorded obligations on its own tokenized-deposit infrastructure. Swift matched and netted them before final settlement through existing systems.
The design connects separately operated bank platforms rather than requiring a single replacement account system. For a buyer, the next questions concern the participating accounts, settlement timing and responsibilities when a step cannot complete.
On 31 March 2026, J.P. Morgan reported Mitsubishi’s adoption of programmable intragroup USD transfers across Singapore, London and New York, using Blockchain Deposit Accounts.
Treasury can define conditions that trigger near-real-time transfers between those accounts. The operational benefit is the ability to respond to cash needs across the named locations without manually initiating each qualifying transfer. Evaluate the funding and account arrangement behind that service, as well as the payment trigger.
Agree the endpoints, execution authority, controls and reconciliation records at each institution.
Every workflow remains available in the report below.
01 / Perspective
Choose the money and the route together
The form of money, its issuer and its redemption terms affect the workflow.
An institution may use ordinary bank accounts, tokenized deposits, stablecoins or central-bank money in different contexts. Similar-looking interfaces can sit on different claims, access rules and operating arrangements.
Document what the receiver will actually hold and how it becomes spendable for the next purpose. A transfer that creates a conversion or redemption step may change both the cost and the time to completion.
01
Make the dependency visible
Include any funding, FX, redemption and off-ramp step in the workflow diagram and cost model.
Choose the money and the route together
Settlement form
Questions to resolve
Commercial-bank account balances
Which legal entities hold the accounts? Which bank executes each leg? What are the access, cutoff and reconciliation arrangements?
Tokenized commercial-bank deposits
What is the claim on the issuing bank? Who can hold or transfer it? How does it convert to an ordinary account balance?
Stablecoins
Who is the issuer? What supports redemption, through which counterparty, in what currency and under what eligibility conditions?
Central-bank money
Which participants have access? How is the cash movement coordinated with any separately operated asset or payment system?
Choose one flow with an observable problem and an accountable sponsor.
A first workflow should be narrow enough to measure and important enough for someone to fund. Define the participating legal entities, currency or asset, systems, normal volume and recurring exception before discussing a wider rollout.
01
Bank settlement
Coordinate a defined corridor through configured bank connections. Establish each institution's endpoints, execution authority, control requirements and reconciliation records.
02
Group treasury
Examine recurring obligations between group entities. Test whether eligible obligations can be netted and whether the resulting funding is usable at the right place and time.
03
Payment controls
Apply consistent release conditions to a payment workflow. Measure manual intervention, policy exceptions and the time required to explain a release decision.
04
Issuer and counterparty evidence
Define the transaction record another party needs to verify. Agree the disclosed fields, trusted signing keys and relationship to source-system records.
03
The Settlement Blueprint
Your existing infrastructure
01 / Perspective
Modern settlement.
Your existing infrastructure.
Build the workflow around the systems your institution already trusts.
The core ledger, payment platform and treasury system embody years of operating controls and business knowledge. A settlement project should identify their continuing responsibilities explicitly.
Frame is software that coordinates settlement workflows, applies policy checks and produces verifiable evidence. Your institution retains its books, execution systems and signing keys. Your banks and payment providers execute through the configured arrangements.
Cross-bank corridors work through configured connections. Scope the endpoints, controls and execution responsibilities at both institutions before treating a particular corridor as available.
01
Keep the authority clear
Name the system that authorizes, the system that executes and the record that establishes the resulting balance.
02
Connect the handoffs
Carry a common instruction reference and a consistent understanding of states through the workflow.
02 / Perspective
One workflow, clear responsibilities
Frame coordinates the steps. Your institutions operate the money and the books.
Start from a valid instruction in the customer platform. The configured policy and authorization requirements govern release. Customer systems then execute and report their responses. Frame records the workflow and supplies signed evidence that can be checked within its agreed scope.
For the chosen flow, agree the endpoints, data contract and execution arrangements. Carry the same instruction reference through each handoff so the operating teams can establish what happened.
01
Instruction and approval
Your business systems define the transaction and the authority to initiate it.
02
Checks and coordination
Frame applies configured release requirements and coordinates the workflow.
03
Execution and accounting
Your banks, payment systems and ledgers execute and record the money movement.
04
Evidence and reconciliation
Frame supplies the workflow record and signed evidence; the institution reconciles it with its execution and ledger records.
03 / Perspective
Four products around the workflow
Use the capabilities the flow needs, with a shared understanding of the result.
The product roles are easiest to evaluate against a real instruction, an actual control decision and the record the receiving team will need. Use the same example across a demonstration so that the handoffs remain visible.
01
Frame Settle
Coordinates instructions across configured systems and records the reported outcomes. Define the execution endpoints and the response expected from each participant.
02
Frame Rules
Applies policy at the release step. Your risk management controls supply signed verdicts; a failed check stops release and an unavailable required gate pauses settlement.
03
Frame Proof
Produces signed records that can be verified independently against trusted keys. Agree what is disclosed and how the record relates to the source systems.
04
Frame Netting
Computes residual obligations for an eligible set while retaining the gross obligations and arithmetic. Legal eligibility and funding arrangements belong in the design.
04 / Perspective
Make the release decision explicit
A control is useful when its authority, inputs and failure behavior are understood.
A release policy can incorporate transaction limits, approvals, risk decisions and other conditions required for the workflow. Agree which system supplies each input, how that input is authenticated and how long it remains valid.
A risk-management decision and its enforcement are different responsibilities. The source control determines its verdict; the release step acts on that verdict under the configured policy. Preserve enough context to explain the result later.
01
Conditions satisfied
The workflow may proceed under the configured authorization and policy.
02
Check failed
Stop release. Record the decision and route the exception to its owner.
03
Required gate unavailable
Pause. Make the outstanding dependency visible and define the recovery procedure.
05 / Perspective
Design for the response you cannot assume
Ambiguous outcomes need a controlled operating procedure.
An execution timeout can mean that nothing happened, that a request is still processing, or that a response was lost. Retrying without establishing the state can create a second payment. Every design needs a way to distinguish a request from an observed outcome.
The operating procedure should connect an exception to an owner, a source of truth and a permitted next action. Demonstrate it with the systems that will participate in the actual workflow.
01
No definitive execution response
Reconcile with the executing system before deciding whether a retry is safe. Preserve the original instruction reference.
02
One leg reports completion
Identify the state of every remaining obligation and the approved recovery action. Do not infer completion from a single response.
03
The evidence and ledger differ
Retain the underlying records, investigate the discrepancy and restrict subsequent action according to the agreed control procedure.
06 / Perspective
Give the next team a record it can use
A signed record is most useful when its meaning and trust basis are clear.
An operations team may need to reconcile the movement. A counterparty may need to check what was reported. An auditor may need to connect a release decision to the policy and authority in force at that time. Define these needs before choosing the evidence fields.
Frame Proof supports independent checking of signed records against trusted keys. The result establishes the integrity and signing origin of the supplied record within its disclosure scope. Reconcile the reported outcome with the executing system and the legal terms of settlement.
Give the next team a record it can use
Record element
Purpose
Instruction and participant references
Connect the evidence to the transaction and the participating systems.
Policy and authorization context
Explain the conditions under which release was permitted or refused.
Execution responses and timestamps
Distinguish what was requested from what each executing system reported.
Signing and verification information
Establish which key signed the record and how the receiver trusts it.
Gross obligations and net calculation, where used
Allow the residual amount to be traced back to the eligible obligation set.
04
The Settlement Blueprint
Build the business case
01 / Perspective
Build the case from your own flow
Use observed costs and explicit assumptions for the same population of transactions.
Measure the current funding tied to the workflow, the fees paid, the cost of handling exceptions and the effort required for reconciliation. Then model the proposed process with its implementation and recurring costs included.
A reduction in obligations does not automatically release the same amount of usable cash. Test account locations, currencies, cutoffs, minimum balances and legal restrictions. Credit only the funding that the treasury team can actually redeploy.
Separate cash released from annual funding-cost benefit. One is a balance-sheet amount; the other depends on a funding rate and the period for which the balance would otherwise remain committed.
Separate capacity from cash savings. Hours avoided may free a team to do more work without reducing payroll; record an actual cost saving only when spending falls.
01
Funding benefit
Usable balance released multiplied by the annual funding rate and the proportion of the year affected.
02
Operating benefit
Observed hours avoided multiplied by the fully loaded hourly cost, plus validated fee changes.
03
Net recurring benefit
Funding and operating benefits, less recurring service and control costs. Show implementation costs separately.
Your working estimate
Put your assumptions on the page.
Use one currency throughout. Enter every field, using zero where a cost or benefit does not apply. No industry defaults are applied.
Complete the fields to calculate an estimate.
Annual funding-cost benefit
Annual operating and fee benefit
Annual net recurring benefit
First-year benefit after implementation
Show the calculation
Funding benefit = usable balance released × annual funding rate ÷ 100 × days affected ÷ 365.
Net recurring benefit = funding benefit + operating and fee benefit − additional recurring costs.
First-year benefit = net recurring benefit − one-time implementation costs.
This is a simple estimate using your assumptions. It does not model tax, discounting, timing within the year or an implementation ramp-up.
Keep a copy of your business case
Your inputs and the calculation will be included.
Your business case is ready.
02 / Perspective
Trace the net amount back to the gross obligations
A small example shows the arithmetic and the questions that remain.
Assume three participants have eligible obligations in one currency at a single agreed cutoff. A owes B $12 million, B owes C $9 million, and C owes A $7 million. The gross obligations total $28 million.
The net positions are A paying $5 million, B receiving $3 million and C receiving $2 million. A could discharge the agreed net positions with two transfers totaling $5 million. Under this assumed arrangement, $23 million of the original gross amount does not need to move.
Actual funding benefit depends on the legal netting arrangement, settlement design, account balances, timing and the ability to use the resulting liquidity. Preserve the gross obligations and the calculation so the participants can reconcile the result.
Illustrative obligations / One currency, one cutoff
Gross obligations$28million
→
Residual transfers$5million
A pays $5m
B receives $3m
C receives $2m
05
The Settlement Blueprint
Resolve the boundaries
01 / Perspective
Resolve the operating and legal boundaries
Make the parties, claims and authorities part of the design.
A settlement architecture needs legal and risk review for the actual entities, instruments and jurisdictions involved. A technology choice does not settle questions about access, authority, finality, netting enforceability or redemption.
Bring the relevant teams into the workflow discussion early enough to change the design. Tie each requirement to a system control, a contractual arrangement or an operating procedure, with a named owner.
01
Parties and money
Identify the legal entities, account holders, instrument issuers and execution providers. Establish the claim the receiver will hold.
02
Authority and finality
Define who can instruct and approve each leg, and the point at which the relevant legal arrangements treat an obligation as discharged.
03
Netting and liquidity
Confirm the eligible obligations, enforceability, treatment of participant failure and location of usable funding.
04
Information and evidence
Agree what counterparties may see, who can access operational records and how evidence is retained for the relevant purpose.
Compare like-for-like flows and include the work around execution.
Headline transaction pricing can omit the resources needed to fund, operate and reconcile the service. Compare proposals against the same currency, volumes, counterparties, operating windows and exception assumptions.
Separate one-time delivery work from recurring costs. A lower quoted payment fee can be outweighed by funding, conversion, infrastructure or control requirements elsewhere in the flow.
Price the complete operating model
Cost component
What to establish
Implementation and change
Integration, testing, legal work, control design, training and parallel operation.
Recurring technology and service
Platform or usage charges, infrastructure, support and maintenance responsibilities.
Execution and conversion
Bank or provider charges, FX, redemption and any required route to the final usable balance.
Funding
Committed balances, collateral or other liquidity needed at each point in the workflow.
Operations and evidence
Exception handling, reconciliation, control review and records administration.
Exit and continuity
Portability of records, transition effort and operating procedures if a service is unavailable.
07
The Settlement Blueprint
Plan the evaluation
01 / Perspective
Run an evaluation with a decision at the end
Set the evidence and acceptance criteria before the implementation begins.
The aim of an evaluation is to establish whether a defined workflow is worth operating under agreed conditions. Keep the participant set and scope small enough that a failed assumption can be understood and corrected.
Progress depends on the participating institutions, endpoints, controls and approvals. Agree milestones around evidence and readiness rather than assuming a universal go-live timetable.
01
1 / Define
Name the owner, flow, baseline, participating systems and decision criteria. Record the dependencies that could prevent the evaluation.
02
2 / Connect and demonstrate
Validate the interfaces and data contract. Follow the same instruction through control, execution response and evidence.
03
3 / Rehearse operations
Run the exception cases, reconciliation, key and policy procedures, and the handoff to the operating team.
04
4 / Decide
Compare the observed outcome with the agreed baseline. Proceed, revise the design or stop, with the evidence and owners recorded.
02 / Perspective
Give every handoff an owner
The delivery plan should be as explicit about people as it is about systems.
A workflow often spans a payments owner, treasury, technology, operations, risk and legal. The sponsor needs a single view of the unresolved decisions and the evidence required to close them.
Start with the team that experiences the problem. Assign a technical and operating counterpart, then involve control and legal owners at the points where their decisions affect the design.
01
Business and treasury
Own the use case, baseline, funding assumptions and economic decision.
02
Technology and execution providers
Own endpoint readiness, data contracts, authority boundaries and response semantics.
03
Operations
Own reconciliation, exception handling, escalation and continuity procedures.
04
Risk and legal
Own policy requirements, approvals, information boundaries and the applicable legal arrangements.
08
The Settlement Blueprint
Make the next decision
01 / Perspective
Test the workflow under real operating conditions
A useful demonstration includes the cases the operating team will have to resolve.
Select tests with the owners of the executing systems and control functions. For every case, record the expected state, the observed record and the person who can authorize recovery.
Test the workflow under real operating conditions
Test
Evidence to request
Valid instruction
The same transaction reference connects the instruction, decision, execution responses and final record.
Policy refusal
Release is stopped and the decision can be explained from the applicable inputs.
Unavailable required control
The flow pauses; the missing dependency and recovery owner are clear.
Duplicate or repeated request
The permitted retry behavior is demonstrated against the executing system.
Ambiguous execution response
The operating team can establish the state without assuming success or repeating a payment.
Changed instruction or expired approval
The revised information is subject to the relevant authorization and policy process.
Independent evidence check
A receiving team verifies a sample record against trusted keys and its source-system references.
Reconciliation and continuity
The teams resolve an exception and demonstrate the procedure for an unavailable dependency.
02 / Perspective
Define your first workflow
Use this page to prepare a discussion with the teams who own it.
Use these fields to prepare your discussion. Your notes stay in this page and are not included in the download forms. This page does not save them for a later visit.
Questions before you begin
Does Frame replace our ledger or hold our funds?+
No. Frame does not replace your existing infrastructure or hold your funds. Your institution retains its books, signing keys and execution systems. Frame coordinates the workflow, applies policy checks and records the evidence.
Can Frame support a cross-bank corridor?+
Yes. Frame supports cross-bank corridors through configured connections. The scope depends on both institutions' endpoints, controls and execution arrangements.
Does the netting example forecast our liquidity savings?+
No. It shows arithmetic on illustrative eligible obligations. Usable funding benefit depends on the actual legal arrangement, timing, accounts and ability to redeploy liquidity.
What should we bring to an initial discussion?+
Bring one workflow, its owner, the participating systems and the current operating constraint. The next step is to agree what a useful evaluation would need to demonstrate.
September 2026
Take the report to your team.
Keep a copy of the settlement blueprint, including the evaluation criteria and workflow brief.
Review mode. Your details stay in this browser. Nothing is sent to Frame or HubSpot.
Research notes
Sources and further reading
Market observations and institutional initiatives are cited at the point of use. Follow these links for the original data, operating models and publication details.
We will work through the systems, controls and evidence needed to evaluate it.
Frame is the settlement layer for modern finance. It helps institutions modernize settlement using their existing infrastructure, with policy checks before release and verifiable records of the reported outcome.
Start with a bank corridor, a recurring treasury cycle, a payment-control requirement or an evidence need. The discussion should establish the participating systems, the desired improvement and the criteria for a useful evaluation.
Tell us what you’re working on.
Fields marked *with an asterisk are required.
ENQUIRY RECEIVED
Thank you. Let’s talk.
Your enquiry has been submitted. The team will get back to you using the email you provided.
