Bridging financial messaging systems to digital asset settlement 

Tokenization, the representation of ownership or claims on real-world assets and securities as digital tokens on distributed ledgers, is modernizing how financial institutions handle settlement and asset transfer. The token itself is not the asset, but a digitally native representation deriving enforceability from legal frameworks, issuance models, and smart contract logic. Tokenization doesn’t replace existing financial infrastructure; it extends it onto programmable settlement rails delivering benefits such as near-instant settlement, 24/7 availability, reduced intermediaries, lower cost, and atomic transactions.

In this post, we examine the interoperability challenge organizations building tokenization workloads face and propose a solution bridging financial messages to on-chain settlement. The sample implementation is available in our GitHub repository.

The interoperability challenge

Traditional financial systems are coordinated through message-based infrastructure. Structured messages drive internal ledgers, clearing workflows, and interbank settlement processes, often across multiple institutions and systems. Distributed ledger technologies introduce a different model – a shared system of record where transactions can be validated, finalized, and exposed to authorized participants under common rules. In this model, on-chain actions are executed and recorded directly on the ledger itself, including token issuance, transfer, and settlement.

This presents an opportunity to extend financial messages into a settlement layer providing faster and more transparent finality. However, blockchains cannot directly interpret traditional financial messages, enforce off-chain approvals, or integrate with regulated custody, compliance, and operational control systems. This presents a challenge: “how do you bridge message-based finance to programmable settlement rails?” while preserving institutional requirements for security, auditability, and governance.

For tokenized funds, on-chain money market instruments, and digital cash products to operate at institutional scale, the underlying technology must meet the security and auditability requirements of regulated institutions, including capabilities such as confidential compute, typed structured signing standards such as EIP-712, and secure integration patterns bridging private enterprise systems with public or permissioned settlement networks.

Solution overview: from financial message to on-chain settlement

To bridge traditional financial messages (SWIFT, ISO 20022, etc.) with blockchain token operations, we propose a hybrid off-chain/on-chain settlement system depicted in Figure 1 below. The system separates responsibilities across three trust domains: 1/ Off-chain control plane, 2/ Orchestration layer, and 3/ Distributed ledger. In the repository, we walk through the steps to deploy and use the solution.

Figure 1: Reference Architecture for integrating off-chain messaging systems with on-chain settlement

The above system is designed so institutions can preserve familiar approval workflows and operational controls off-chain while using blockchain infrastructure for final settlement. We will now dive deeper into the critical aspects of the three different trust domains.

Off-chain control plane

The off-chain control plane handles enterprise-side message ingestion, normalization, storage, signing, and operational governance. Rather than exposing proprietary or regulated message content directly to a blockchain network, institutions can convert it into a compact, signed settlement artifact: a Canonical Settlement Instruction (CSI). A CSI is the minimal, deterministic, signed payload encoding the data required for settlement, such as the asset definition, amount, counterparties, value time, settlement intent, and target chain. It provides a stable instruction identifier for auditability, supports idempotent retries (so the same instruction can be safely resubmitted without creating duplicate on-chain action) and acts as the common instruction format across off-chain and on-chain domains.

Orchestration layer

Once a CSI has been created and signed in the solution, it must be delivered to the appropriate on-chain contract. An orchestration layer can be implemented to accomplish this. Two representative approaches are outlined below:

1. AWS Lambda and KMS-based transaction gateway

In the simplest pattern, an AWS Lambda based transaction gateway is triggered by newly created CSIs or a scheduled process and submits them on-chain. AWS Key Management Service (KMS) protects the operational key used to submit transactions. Lambda assembles the transaction and broadcasts it through a remote procedure call (RPC) service that provides network access to the blockchain and records the result.

2. Chainlink Runtime Environment (CRE)

The Chainlink Runtime Environment (CRE) offers a broader interoperability path. CRE retrieves already signed CSIs from AWS systems and coordinates their execution on-chain. CRE does not create, approve, or modify settlement instructions. Authority remains with the user on AWS through institutional workflows and KMS-backed signing. CRE is responsible for workflow orchestration: reacting to triggers, calling external APIs, submitting transactions, waiting for confirmations, and returning execution status.

A centralized relay consisting of AWS Lambda and AWS KMS is sufficient if the goal is to settle approved instructions onto a single network. The CRE-based alternative is better suited to operating models that expand toward multi-network, multi-party, or cross-domain orchestration. This implementation is particularly useful when existing messaging infrastructure acts as a single access point to multiple public and private networks rather than a point-to-point integration into each one.

On-chain settlement

A blockchain serves as the shared execution and settlement environment where instructions are validated and finalized. Smart contracts, deployed using Foundry, verify each CSI and execute the corresponding settlement action only after all required checks succeed. This allows institutions to retain governance and security controls in familiar off-chain systems while using a blockchain network for shared, programmable settlement.

The pattern is message-format agnostic. SWIFT MT, ISO 20022, and proprietary bank formats can all be fed into the same off-chain control plane. While this reference architecture uses Ethereum, the identical approach can be applied to permissioned ledgers or hybrid environments combining public chains with identity, access, or privacy overlays.

Tokenization Flow

The following depicts the process flow of the sample application as shown in Figure 1.

Govern authorized signers on-chain

1. An on-chain allowlist contract stores approved signer addresses derived from AWS KMS keys. Only CSIs signed by approved keys are considered valid. This gives institutions explicit signer governance, hardware-backed key custody, and a clear path for key rotation without redeploying settlement contracts.

Ingest and normalize financial messages on AWS

2. A financial message enters the system through Amazon API Gateway.
3. An AWS Lambda function normalizes the incoming message into a CSI.
4. The raw message is stored in Amazon S3, while the CSI is signed using AWS KMS and recorded in Amazon DynamoDB with a pending status.

This establishes the CSI as the system’s authoritative settlement artifact. It is normalized, signed, auditable, and ready to move across off-chain and on-chain systems without exposing the original financial message.

Coordinate submission through the orchestration layer

The following focuses on the flow utilizing the Chainlink Runtime Environment (CRE) as the decentralized orchestration layer for on-chain submission and status reconciliation.

5. A CRE workflow, running on a cron schedule, fetches pending CSIs by invoking the API. For each instruction, it validates the target chain and converts the CSI and its AWS KMS signature into an application binary interface (ABI) encoded settlement report. The workflow submits the report to the on-chain forwarder, and reads the transaction receipt to confirm settlement execution. It reports the outcome back to the AWS API, preserving an end-to-end audit trail across both domains.

Verify and Execute Settlement on-chain

6. The settlement consumer smart contract verifies each CSI before execution by confirming the signature is valid and belongs to an approved signer, rejecting duplicate or expired instructions, ensuring the instruction targets the correct chain.
7. Only after all checks pass does the contract execute, completing a cryptographic chain of custody from the original financial message to the on-chain state transition.

Settlement intents

The solution supports three reusable instruction types:

MINT_ONLY: New value enters the system, such as an issuance or fiat-backed deposit. Tokens are minted to the recipient. The supply of the asset increases.
BURN_AND_MINT: Value moves within or across systems, such as a transfer, reallocation, or cross-chain movement. Tokens are burned from one party or environment and minted to another. Total supply remains unchanged.
BURN_ONLY: Value exits the tokenized system, such as a redemption or withdrawal. Tokens are burned. Total supply decreases.

Conclusion

In our solution, AWS provides a secure off-chain control plane for message ingestion, normalization, signing, and recordkeeping. Smart contracts provide the final enforcement layer by verifying authorized instructions and executing settlement only when policy checks pass. The orchestration layer sitting between them can be implemented with AWS-native components or Chainlink Runtime Environment (CRE) because it provides a more natural path toward the broader interoperability model institutions are now exploring. Together, these components create a practical bridge between traditional financial systems and blockchain-based settlement.

Check out the complete sample implementation on GitHub and start building your own bridge between traditional financial messaging and digital assets on AWS.

About the authors