Results of PoC for Next-Generation Financial System Utilizing IOWN Technology

MUFG Bank and NTT DATA Group have been conducting a series of studies to realize a next-generation financial system utilizing IOWN (Innovative Optical and Wireless Network) technology. The three companies, including NTT West, have recently released a report on the results of technical demonstrations based on use cases and performance requirements through the IOWN Global Forum. The author, who participates in the activities of the IOWN Global Forum, explains the key points.

Index

Financial System Issues and Initiatives to Solve them with IOWN Technology
Key Points of PoC Report
Future outlook

1. Challenges faced by financial systems and initiatives toward solutions using IOWN technologies

Financial services are at the forefront of digital transformation (DX), driven by factors such as the rise of FinTech and the digitalization of markets. While maintaining high-performance, highly reliable system operations and strict regulatory compliance, financial institutions are expected to continuously innovate services and improve the customer experience. Against this backdrop, they face a wide range of challenges, including maintaining and modernizing legacy systems, effectively utilizing massive volumes of data, ensuring security, and addressing BCP (Business Continuity Plan) requirements.

Many financial institutions are moving forward with cloud adoption and the geographic distribution of data centers. However, system complexity and high implementation costs have become barriers, increasing the need for next-generation financial systems that can be expanded with agility and flexibility.

In the IOWN Global Forum's financial use case development project, stakeholders have been discussing use cases and guidelines for applying IOWN Global Forum technologies to next-generation financial systems, compiling them into white papers. To help financial institutions overcome market challenges and deliver advanced services that can be operated dynamically and resiliently, the project has been progressing through the following steps:

Define IOWN financial use cases and key requirements
Define technology evaluation criteria
Define a Reference Implementation Model
Define a Proof of Concept (PoC) Reference
Evaluate PoCs based on the Reference Implementation Model and PoC Reference

In Steps 1 and 2, the project organized the discussion framework around intra-regional and inter-regional perspectives, then presented financial use case definitions, key requirements, and technology evaluation criteria, compiling them in the July 2024 white paper (*1).

In Steps 3 and 4, the project provided concrete guidance on a Reference Implementation Model for implementing the use cases and guidelines for executing PoCs, compiling them in the February 2025 white paper (*2).

In Step 5, various users are expected to conduct PoCs based on the two previously published white papers. While the earlier two white papers were published primarily by the IOWN Global Forum's financial use case study project, Step 5 is positioned as user-led, with reports published through the IOWN Global Forum.

The PoC report published this time corresponds to Step 5. Acting as users, the participating companies conducted technical validations based on the white papers' content and presented the results.

(*1) IOWN Global Forum, "Services Infrastructure for Financial Industry Use Case", 07.2024.

(*2) IOWN Global Forum, "Reference Implementation Model and Proof-of-Concept Reference of Services Infrastructure for Financial Industry Use Case", 02.2025.

2. Key takeaways from the PoC report

In this PoC, technical validations were conducted for two use cases presented in previous white papers, in data center environments interconnected via IOWN APN. The PoC report covers the following three themes; this article focuses on (1) and (2). For (3), please refer to the PoC report published on the IOWN Global Forum website ("Inter-DC VM Migration and Long-Distance DB Replication for Financial Industry - IOWN Global Forum").

Switching the system operating location across multiple data centers
Long-distance DB replication
Long-distance support for highly reliable storage networks

2-1. PoC 1: Intra-regional use case - VM migration across multiple data centers

In PoC 1, the PoC migrated virtual machines (VMs) across multiple data centers located within the same region. The goal was to verify whether the key requirement defined in the use case-keeping downtime to no more than one second-could be satisfied.

To conduct the validation, the team deployed a virtualization platform spanning two data centers interconnected by IOWN APN and built a pseudo-online banking system composed of multiple components, including web servers, application servers, a messaging system and its cluster manager, and a database. VM migration was performed using virtualization software to migrate a system configuration unit from one data center to another. The team then measured downtime and evaluated performance under varying conditions, including differences in the distance between data centers and network load.

As a result, under normal load, the team confirmed that inter-data-center migration could generally keep downtime under one second. This outcome suggests that financial system operators may be able to flexibly change and relocate server-side application components without significantly impacting end users.

Figure. 1 System configuration of Verification 1 (Source: IOWN Global Forum, "Inter-DC VM Migration and Long-Distance DB Replication for Financial Industry")

2-2. PoC 2: Inter-regional use case - Long-distance DB sync/async replication

In PoC 2, the PoC evaluated synchronous and asynchronous (sync/async) replication of a database management system (DBMS) deployed across two data centers interconnected via IOWN APN. Under an environment simulating long distances from 250 km to 2,500 km, the PoC evaluated whether it could meet the key requirements defined in the use case documents-KR2.1 (RPO=0) and KR2.2 (RTO targets by tier) (*3) (*4). In addition, because synchronous replication was confirmed feasible at all distances defined in the inter-regional use case, the PoC report notes that RPO=0 and RTO=0 can be considered achieved solely at the DBMS layer (i.e., without relying on application-layer measures or manual operations).

Figure. 2 System configuration of Verification 2 (Source: IOWN Global Forum, "Inter-DC VM Migration and Long-Distance DB Replication for Financial Industry")

During synchronous replication validation, the team measured throughput and latency from the application's perspective as they logically extended the distance between the databases. As distance increased, throughput decreased, and latency increased. On the other hand, by increasing the number of simultaneous database connections to enhance parallel processing, the throughput degradation attributable to increased distance can be mitigated to some extent.

Historically, synchronous database replication across long distances-often cited as an anti-pattern for environments over roughly 100 km-has been avoided due to the impact of increased communication latency on response time and throughput. However, the PoC showed that, with 300 concurrent connections, synchronous replication could be completed in under 10 milliseconds from the application's perspective, even over roughly 500 km. This result suggests that, depending on system requirements, the distance conditions under which synchronous replication can be applied may be broader than conventional assumptions.

During asynchronous replication validation, application-facing latency and throughput remained stable and were unaffected by the distance between data centers. While the amount of unreplicated transactions (grey data) tended to increase with greater distance, the overall volume remained within a bounded range.

Taken together, these measurements indicate that, by leveraging IOWN APN, it may be possible to relax the geographic placement constraints for databases that use synchronous replication while meeting performance requirements. They also show that, for asynchronous replication, the impact of increased distance on database processing performance can be kept within a certain range. These outcomes are expected to contribute not only to higher system availability but also to broader Business Continuity Planning (BCP) and Disaster Recovery (DR) design options.

(*3) RPO (Recovery Point Objective): A target value for how far back in time data must be restored when a failure occurs. RPO = 0 means restoring data without loss up to immediately before the failure. Originally, RPO is not intended to be achieved solely by the DBMS; it includes the application layer and the manual operations of the financial institution. In this PoC, however, the validation examined whether RPO = 0 could be achieved solely at the DBMS layer.

(*4) RTO (Recovery Time Objective): A target value for how long restoration takes after a failure occurs. In the PoC Reference, target restoration times by system priority are as follows:

Tier 1 System: RTO < 30 minutes
Tier 2 System: RTO < 2 hours
Tier 3 System: RTO < 1 day

(*5) Turnaround time / application-perspective latency: In the PoC report, latency from the application's perspective is evaluated using the pgbench benchmark results (often referred to as "latency from an application perspective").

(*6) Grey data: Transactions that have not yet been reflected in the replication destination database and would require external recovery in a disaster scenario.

(*7) BCP: Business Continuity Plan

(*8) DR: Disaster Recovery

3. Future Outlook

This article highlighted the key points of technical validation results for next-generation financial systems, jointly conducted using IOWN technologies and published through the IOWN Global Forum.

NTT DATA will continue to drive initiatives to apply IOWN technologies in the financial domain.