Gateway capabilities
- Corridor settlement rail
- Finality & exception policy
- Cross-network adapters
Payments · Design record
Cross-border settlement corridors
Connect an originating institution, a governed settlement rail, and beneficiary payout through corridor-specific policy and liquidity.
01Originating institution→
02Sending customer→
03Settlement operator→
04Liquidity provider
Target business outcome
A target for shorter, observable settlement flows designed to support additional corridors without redesigning the full platform.
Gateway implementation layer
Translate the workflow into a deployable operating boundary.
The record defines the financial problem. Gateway then maps the relevant Platform capabilities, privacy fit, deployment, specialist dependencies, and validation path.
Open Privacy Suite applicability
Scopes visibility per corridor: participants see their leg, oversight sees the whole.
Deployment
One domain per jurisdiction, with the authoritative money record named per leg.
Partner dependencies
- FX & liquidity
- Local fiat rails
- Corridor compliance
Implementation path01 · Map the flow02 · Validate the hardest assumption03 · Define the production boundary
Actors
- Originating institution
- Sending customer
- Settlement operator
- Liquidity provider
- Off-ramp
- Beneficiary institution
- Supervisor
Confidential data
- Customer identity and purpose
- Payment amount and FX instruction
- Liquidity position
- Screening decisions
- Beneficiary details
Public or shared evidence
- Settlement identifier and state
- Signed FX quote reference
- Policy decision receipt
- Finality and payout confirmation
Regulator and auditor access
Authorised compliance and supervisory roles receive purpose-bound access to payment evidence; broader participants receive only their workflow view.
Institutional constraints
- Licensing and safeguarding vary by corridor
- No universal claim of zero pre-funding
- FX, finality, and payout SLAs must be explicit
- ISO 20022 and core-banking mappings differ by institution
Viable approaches
Stablecoin settlement rail
Use regulated fiat entry and exit with programmable settlement and corridor policy.
Private institutional domain
Keep workflow state in a controlled network and expose minimum settlement evidence externally.
Heterogeneous route
Use domain adapters when the corridor crosses EVM, non-EVM, or conventional payment systems.
Questions to resolve during discovery
- Who is the regulated issuer or payment provider?
- Where is liquidity held and who bears FX risk?
- What constitutes legal finality in each leg?
- Which exceptions require manual approval?
Relevant standards and frameworks
- ISO 20022
- FATF Travel Rule
- Local payment-services regulation
- Sanctions and transaction-monitoring policy
Related cases
Continue through the adjacent operating questions.
Financial workflows rarely stand alone. These records cover the closest dependencies and alternatives.
PaymentsDesign record
Institutional stablecoin payments
Design digital cash issuance or integration under a defined brand, reserve, distribution, and transaction-policy model.
Open use-case record →TradingDesign record
Private FX and PvP settlement
Coordinate two currency legs without exposing trading intent, balances, quotes, or counterparty limits to unrelated parties.
Open use-case record →Data & OraclesDesign record
Evidence and audit rails
Produce a durable chain of identity, policy, transaction, deployment, and operational evidence for assurance and supervision.
Open use-case record →Start with the architecture
Turn cross-border settlement corridors into an institution-specific architecture.
A workshop maps the actors, authoritative records, disclosure requirements, operating boundary, and highest-risk assumptions into a proposed architecture.