How to connect with local banks in Japan?

September 2023
5 min read

Seamless and automated connectivity between a Treasury Management System (TMS) and banks has always been an arduous task to accomplish.

Treasurers dealing with multiple jurisdictions, scattered banking landscape, and local requirements face many challenges in this regard. Japan is one of the markets where bank connectivity is indeed a challenge, especially when it comes to connecting with local banks.

Traditional options

The initial reaction from treasurers not familiar with local market conventions might be to seek connection through the SWIFT network. However, in Japan only a handful of banks offer SWIFT connectivity. Second natural choice is the Host-to-Host connection (H2H). This is the classic File Transfer Protocol (FTP), or preferably the secured version (sFTP) setup. Some will say old fashioned, rather than classic, since it is as old as the internet. Nonetheless, it is still popular, and frankly quite often the best fit for the purpose. However, if there are dozens of local banks to connect to, it can be difficult to be expected to connect to each of them with a direct H2H. While this could be technically feasible, it would be nothing short of a nightmare to maintain, with the initial setup being time-consuming in the first place.

Other solutions

There is an answer, or should we rather say ANSER, to this question. ANSER, an abbreviation of ‘Automatic answer Network System for Electrical Request’, is a data transfer system provided by NTT Data Corporation since 1981, which links banks with firms.[1] ANSER then is a way to connect a corporate client to the bank. The system has been around for a while, and together with Cash Management Service (CMS) centers it is a part of the so-called Firm Banking solution in Japan. Since its inception, ANSER offered a wider range of services, through which corporates could access their banking information. Among the offered channels are telephone, fax, firm banking terminal, and personal computer. With the ever-increasing need for speedy and accurate information exchange, the more traditional ways, such as telephone and fax, gave way to the more sophisticated and automated solution, namely eBAgent.

eBAgent making use of API

The said eBAgent is a proprietary middleware platform offered by NTT Data. The solution establishes an automated connection with banks through the above-mentioned ANSER network. In short, eBAgent offers a gateway to multiple local banking partners in Japan utilizing the ANSER network. The remaining part for the corporate is then to establish a connection between the TMS and eBAgent, and secure appropriate contracts with the eBAgent provider, NTT Data, as well as the banks.

As for the connection protocol, the choice is between the classic sFTP, or Application Programming Interface (API). The latter has the real-time advantage, with less lag between the pick-and-drop sFTP connection. API seems to be a choice for an increasing number of corporates these days in this area. What is also interesting, apart from the API connection, are the supported formats for transfers and bank statements. In addition to the local Japanese ZENGIN, the protocol also offers data transmission in a proprietary XML format. This XML format is actually quite simple, with a very limited amount of tags. In addition to this, unlike the ISO 20022 standard, it contains only one level of tags, without the nesting function. Depending on the exact ERP/TMS infrastructure, eBAgent can also provide conversion services from and to the IS 20022 standard. As for the connection to eBAgent, the whole setup seems easier said than done. However, some TMS providers, in response to the demand from the market, started offering off-the-shelf solutions for a plug-and-play connection to eBAgent. Kyriba and Reval already offer it, with SAP set to roll out its solution on the S/4HANA and Multi Bank Connectivity (MBC) platform in early 2024.

Various ways to connect TMS / ERP with banks in Japan

How to connect with local banks in Japan?

It all depends on the exact landscape of banks and systems. It may just as well turn out that a hybrid solution would be best suited. There is no one-size fits all, as each corporate is unique, thus careful consideration and design will be paramount for a stable and reliable connection with banks. One thing is certain, solutions that involve obtaining bank statement information and enact payments by telephone or fax are simply no longer sufficient. In this day and age, when much sensitive information is exchanged between corporates and banks, having a reliable, automated solution is indispensable.

If you would like to know more, do not hesitate to get in touch with Michal Zelazko via or via + 81 (0) 8 3255 9966


ISO 20022 XML (Pain.001.001.09) – Introduction of the Structured Address

May 2023
5 min read

Seamless and automated connectivity between a Treasury Management System (TMS) and banks has always been an arduous task to accomplish.

However, possibly the most important point for corporates to be aware of is the planned move towards explicit use of the structured address block. In this second article in the ISO 20022 series, Zanders experts Eliane Eysackers and Mark Sutton provide some valuable insights around this industry requirement, the challenges that exists and an important update on this core topic. 

What is actually happening with the address information? 

One of the key drivers around the MT-MX migration are the significant benefits that can be achieved through the use of structured data. E.g., stronger compliance validation and support STP processing.  The SWIFT PMPG1 (Payment Market Practice Group) had advised that a number of market infrastructures2  are planning  to mandate the full structured address with the SWIFT ISO migration. The SWIFT PMPG had also planned to make the full structured address mandatory for the interbank messages – so effectively all cross-border payments. The most important point to note is that the SWIFT PMPG had also advised of the plan to reject non-compliant cross border payment messages from November 2025 in line with the end of the MT-MX migration. So, if a cross border payment did not include a full structured address, the payment instruction would be rejected. 

What are the current challenges around supporting a full structured address? 

Whilst the benefits of structured data are broadly recognised and accepted within the industry, a one size approach does not always work, and detailed analysis conducted by the Zanders team revealed mandating a full structured address would create significant friction and may ultimately be unworkable. 

Diagram 1: Challenges around the implementation of the full structured address. 

From the detailed analysis performed by the Zanders team, we have identified multiple problems that are all interconnected, and need to be addressed if the industry is to achieve its stated objective of a full structured address. These challenges are summarized below:  

  • Cost of change: The 2021 online TMI poll highlighted that 70% of respondents confirmed they currently merge the building name, building number, and street name in the same address line field. The key point to note is that the data is not currently separated within the ERP (Enterprise Resource Planning) system. Furthermore, 52% of these respondents highlighted a high impact to change this data, while 26% highlighted a medium impact. As part of Zanders’ continued research, we spoke to two major corporates to gain a better sense of their concerns. Both provided a high-level estimate of the development effort required for them to adapt to the new standard: ½ million euros. 
  • Fit for Purpose: From the ISO 20022 expert group discussions, it was recognized that the current XML Version 9 message would need a significant re-design to support the level of complexity that exists around the address structure globally.  
  • Vendor Support: Whilst we have not researched every ERP and TMS (Treasury Management System) system, if you compare the current structured address points including field length in the XML Version 9 message with the master data records currently available in the ERP and TMS systems, you will see gaps in terms of the fields that are supported and the actual field length. This means ERP and TMS software vendors will need to update the current address logic to fully align with the ISO standard for payments – but this software development cannot logically start until the ISO address block has been updated to avoid the need for multiple software upgrades.
  • Industry Guidelines: Whilst industry level implementation guidelines are always a positive step, the current published SWIFT PMPG guidelines have primarily focused on the simpler mainstream address structures for which the current address structure is fine. By correctly including the more complex local country address options, it will quickly highlight the gaps that exist, which mean compliance by the November 2025 deadline looks unrealistic at this stage. 
  • Regulatory Drivers: At this stage, there is still no evidence that any of the in-country payments regulators have actually requested a full structured address. However, we have seen some countries start to request minimum address information (but not structured due to the MT file format), such as Canada and US. 
  • Time to Implement: We must consider the above dependencies that need to be addressed first before full compliance can logically be considered, which means a new message version would be required. Whilst industry discussions are ongoing, the next ISO maintenance release is November 2023, which will result in XML version 13 being published. If we factor in time for banks to adopt this new version (XML Version 13), time for software vendors to develop the new full structured address including field length and finally, for the corporates to then implement this latest software upgrade and test with their banking partners, the November 2025 timeline looks unrealistic at this point in time.

A very important update 

Following a series of focused discussions around the potential address block changes to the XML Version 9 message, including the feedback from the GLEIF3 the ISO payment expert group questioned the need to support a significant redesign of the address block to enable the full structured address to be mandated. The Wolfsberg Group4 also raised concerns about scale of the changes required within the interbank messaging space.

Given this feedback, the SWIFT PMPG completed a survey with the corporate community in April. The survey feedback highlighted a number of the above concerns, and a change request has now been raised with the SWIFT standards working group for discussion at the end of June. The expectation is that the mandatory structured address elements will now be limited to just the Town/City, Postcode, and country, with typical address line 1 complexity continuing to be supported in the unstructured address element. This means a blended address structure will be supported.    

Is Corporate Treasury Impacted by this structured address compliance requirement? 

There are a number of aspects that need to be considered in answering this question. But at a high level, if you are currently maintaining your address data in a structured format within the ERP/TMS and you are currently providing the core structured address elements to your banking partners, then the impact should be low. However, Zanders recommends each corporate complete a more detailed review of the current address logic as soon as possible, given the current anticipated November 2025 compliance deadline. 

In Summary 

The ISO 20022 XML financial messages offer significant benefits to the corporate treasury community in terms more structured and richer data combined with a more globally standardised design. The timing is now right to commence the initial analysis so a more informed decision can be made around the key questions. 


  1. The PMPG (payment market practice group) is a SWIFT advisory group that reports into the Banking Services Committee (BSC) for all topics related to SWIFT. 
  1. A Market Infrastructure is a system that provides services to the financial industry for trading, clearing and settlement, matching of financial transactions, and depository functions. For example, in-country real-time gross settlement (RTGS) operators (FED, ECB, BoE). 
  1. Global Legal Entity Identifier Foundation (Established by the Financial Stability Board in June 2014, the GLEIF is tasked to support the implementation and use of the Legal Entity Identifier (LEI). 

SAP Advanced Payment Management

June 2021
6 min read

S/4 HANA Advanced Payment Management (APM) is SAP’s new solution for centralized payment hubs. Released in 2019, this solution operates as a centralized payment channel, consolidating payment flows from multiple payment sources. This article will serve to introduce its functionality and benefits.

Intraday Bank Statements offers a cash manager additional insight in estimated closing balances of external bank accounts and therefore provides the information to manage the cash more tightly on the company’s bank accounts.

Whilst over the previous years, many corporates have endeavoured to move towards a single ERP system. There are many corporates who operate in a multi-ERP landscape and will continue to do so. This is particularly the case amongst corporates who have grown rapidly, potentially through acquisitions, or that operate across different business areas. SAP’s Central Finance caters for centralized financial reporting for these multi-ERP businesses. SAP’s APM similarly caters for businesses with a range of payment sources, centralizing into a single payment channel.

SAP APM acts as a central payment processing engine, connecting with SAP Bank Communication Management and Multi-Bank Connectivity for sending of external payment Instructions. For internal payments & payments-on-behalf-of, data is fed to SAP In-House Cash. Whilst at the same time, data is transmitted to S/4 HANA Cash Management to give centralized cash forecast data.

Figure 1 – SAP S/4 HANA Advanced Payment Management – Credit SAP

The framework of this product was built up as SAP Payment Engine, which is used for the processing of payment instructions at banking institutions. On this basis, it is a robust product, and will cater for the key requirements of corporate payment hubs, and much more beyond.

Building a business case

When building a business case for a centralized payment hub, it is important to look at the full range of the payment sources. This can include accounts payable/receivable (AP/AR) payments, but should also consider one-off (manual) payments, Treasury payments, as well as HR payments such as payroll. Whilst payroll is often outsourced, SAP APM can be a good opportunity to integrate payroll into a corporate’s own payment landscape (with the necessary controls of course!).

Using a centralized payment hub will help to reduce implementation time for new payment sources, which may be different ERPs. In particular, the ability of SAP APMs Input Manager to consume non-standard payment file formats helps to make this a smooth implementation process.

SAP APM applies a level of consistency across all payments and allows for a common payment control framework to be applied across the full range of payment sources.

A strength of the product is its flexible payment routing, which allows for payment routing to be adjusted according to the business need. This does not require specialist IT configuration or re-routing. It enables corporates to change their payment framework according to the need of the business, without the dependency on configuration and technology changes.
A central payment hub means no more direct bank integrations. This is particularly important for those businesses that operate in a multi-ERP environment, where the burden can be particularly heavy.

Lastly, as with most SAP products, this product benefits from native integration into modules that corporates may already be using. Payment data can be transferred directly into SAP In-House Cash using standard functionality in order to reflect intercompany positions. The richest level of data is presented to S/4 HANA Cash Management to provide accurate and up-to-date cash forecast data for Treasury front office.


SAP APM accommodates four different scenarios:

Internal transferPayment from one subsidiaries internal account to the internal account of another
Payment on-behalf-ofPayment to external party from the internal account of a subsidiary
Payment in-name ofPayment to external party from the external account of a subsidiary. The derivation of the external account is performed in APM.
Payment in-name-of – forwarding onlyPayment to external party from the external account of a subsidiary. The external account is pre-determined in the incoming payment instruction.

A Working Example – Payment-on-behalf-of

An ERP sends a payment instruction to the APM system via iDoc. This is consumed by the input manager, creating a payment order that is ready to be processed.

Figure 3 – Creation of Incoming Payment Order in APM

The payment order will normally be automatically processed immediately upon receipt. First the enrichment & validation checks are executed, which validate the integrity of the payment Instruction.

The payment routing is then executed for each payment item, according to the source payment data. The Payment Routing importantly selects the appropriate house bank account for payment and can be used to determine the prioritization of payments, as well as the method of clearing.

In the case of a payment-on-behalf-of, an external route will be used for the credit payment item to the third party vendor, whilst an internal route will be used to update SAP In-House Cash for the intercompany position.

Figure 4 – Maintenance of Routes

Clearing can be executed in batches, via queues or individual processing. The internal clearing for the debit payment item must be executed into SAP In-House Cash in order to reflect the intercompany position built up. The internal clearing for the credit payment Item can be fed into the general ledger of the paying entity.

Figure 5 – Update of In-House Cash for Payment-On-Behalf or Internal Transfer Scenarios

Outgoing payment orders are created once the routing & clearing is completed. At this stage, any further enrichment & validation can be executed and the data will be delivered to the output manager. The output manager has native integration with SAP’s DMEE Payment Engine, which can be used to produce an ISO20022 payment instruction file.

Figure 6 – Payment Instruction in SAP Bank Communication Management

The outgoing payment instruction is now visible in the centralized payment status monitor in SAP Bank Communication Management.

The full processing status of the payment is visible in SAP APM, including the points of data transfer.

Figure 7 – SAP APM Process Flow

Introduction to Functionality

SAP APM is comprised of 4 key function areas:

  • Input manager & output manager
  • Enrichment and validation
  • Routing
  • Transaction clearing

Figure 2 – SAP Advanced Payment Management Framework – Credit SAP

Input Manager

The input manager can flexibly import payment instruction data into APM. Standard converters exist for iDoc Payment Instructions (PEXR2002/PEXR2003 PAYEXT), ISO20022 (Pain.001.01.03) as well as for SWIFT MT101 messages. However, it is possible to configure new input formats that would cater for systems that may only be able to produce flat file formats.

Enrichment and Validation

Enrichment and validation can be used to perform integrity checks on payment items during the processing through APM. These checks could include checks for duplicate payment instructions. This feeds an initial set of data to S/4 HANA Cash Management (prior to routing) and can be used to return payment status messages (Pain.002) to the sending payment system.


Agreement-based routing is used to determine the selection of external accounts. This payment routing is highly flexible and permits the routing of payments according to criteria such as amounts and, beneficiary countries. The routing incorporates cut-off time logic and determines the priority of the payment as well as the sending bank account. This stage is not used for “forwarding-only” scenarios, where there is no requirement to determine the subsidiaries house bank account in the APM platform.


Clearing involves the sending of payment data after routing to S/4 HANA Cash Management, in-house cash and onto the general ledger. According to selected route, payments can be cleared individually, or grouped into batches.

Further enrichment & validation can be performed, and external payments are routed via the output manager, which can re-use DMEE payment engines to produce payment files. These payment files can be monitored in SAP Bank Communication Management and delivered to the bank via SAP Multi-Bank Connectivity.

Bank connectivity – Making the right choices

July 2020
6 min read

S/4 HANA Advanced Payment Management (APM) is SAP’s new solution for centralized payment hubs. Released in 2019, this solution operates as a centralized payment channel, consolidating payment flows from multiple payment sources. This article will serve to introduce its functionality and benefits.

Bank connectivity options

Within the space of bank connectivity, there is a range of choices that corporates face when deciding the best way to integrate banks towards their ERP or treasury platforms.


The most historic option, with users logging into online banking platforms to extract bank reporting and initiate payments. Banking platforms have evolved, with some offering electronic statement download (which can be readily imported into ERPs), and payment status monitoring. Whilst a readily available, easy-to-use solution, it has issues with controls and requires separate platforms for each bank.


SWIFT provides global coverage to a wide range of banks. It is seen as the global standard in bank connectivity, and from a bank perspective we have seen the membership increase.
There are two channels available:

ChannelMessage Types
FINSWIFT MT Messages – e.g. MT101, MT940
FileACTAny Message Type – typically ISO20022

SWIFT FileAct is suited to AP Payments, as ISO20022 message standards permit high volumes of payments in files. SWIFT FIN is more commonly used for treasury integration, due to the historic use of SWIFT MT messages. As ISO20022 is more widely adopted, SWIFT FileAct will become the default choice for messaging channel.

A useful tool to identify if your partner banks are onboard is SWIFT’s Readiness Portal.


Originally developed as a financial messaging transmission vehicle for Germany, EBICS has been later extended to France and Switzerland. It provides wide coverage of banks within these countries, but is not in use outside of these countries.

It generally has a lower total cost of ownership than SWIFT. The geographic restrictions mean that this is commonly used for corporates who have strong focus in the German, French or Swiss Market. For corporates operating on a global basis, EBICS does not tend to provide the bank coverage that is required.

Host-to-host (H2H)

H2H connections are direct connections from a corporate’s integration system towards a specific bank.

H2H connections are most suitable where corporates engage with a single core bank who can support local services and branch coverage in all relevant markets. These can have a lower total cost of ownership compared to using SWIFT, but this solution has a level of bank lock-in.

Direct to clearing house (UK BACS)

Within the UK, the primary clearing house is BACS, which ensures settlements of payments between debtor and creditor banks.

It is common practice in the UK for corporates to make payment instructions & direct debit instructions directly to the local clearing house BACS, where the partner bank acts as a sponsor. This requires a BACS service bureau who can act as a gateway into the BACS network. This is commonly known as “direct transmission”.

An alternative to this transfer method is “indirect transmission” where payments and direct debits are sent to the partner bank, via any of the preceding methods before being submitted to BACS itself.

API connectivity

Triggered by the PSD2 initiative, banks are now offering API connectivity.

One of the issues with API connectivity is that modern API design is targeted towards JSON formats, whilst ISO20022 is an xml-based schema. Due to low levels of standardization across different banks and countries, this has meant that ERPs and treasury platforms may require bespoke functionality to cater for these bank-specific APIs.

It is likely that these will become the future of bank connectivity, but will require some level of standardization, which could possibly come under the SWIFT umbrella.

Access to SWIFT

Connectivity of corporates to the SWIFT network has expanded over the last years from the largest corporates with high volumes of bank connections, to small-to-medium corporates with lower volumes of bank connections. To access the global SWIFT network, there are 4 main options that corporates can leverage:

  • In-house – SAG
    SWIFT Alliance Gateway (SAG) was the standard connection offered to corporates. It requires specialist SWIFT knowledge and has high complexity. This is no longer encouraged by SWIFT.
  • Outsourced – SSB
    SWIFT Service Bureaus (SSBs) remove the complexities of establishing the connection to the SWIFT network. SSBs certified by SWIFT manage the hardware and access configuration. Nowadays approximately 50% of all corporates access SWIFT through a SSB.
  • In-house – Alliance Lite 2
    SWIFT introduced Alliance Lite2 to enable smaller corporates to connect to the network. SWIFT proprietary software, installed locally, in combination with a hard token, transfers messages to the SWIFT network. Since each transmission may require an approval, this option is not fit for corporates with high payment volumes/STP-rates.
  • Outsourced – Alliance Lite2 embedded within Business Application
    Applications (L2BA) Since 2012, SWIFT has offered Alliance Lite2 including business applications for treasury management systems, bank connectivity providers and in-house banking/payment factory providers. Even though this option is relatively new, it gained popularity very quickly, with corporates looking to externalize bank connectivity whilst keeping total cost of ownership to a minimum.

For corporates having joined SWIFT since January 2018, 64% have opted for the SWIFT Cloud Alliance Lite 2 options. It is likely that the adoption of the embedded Alliance Lite 2 is behind this trend.

SAP Multi-Bank Connectivity

SAP Multi-Bank Connectivity (MBC) is SAP’s offering of a SWIFT connection embedded within Business Applications. SAP MBC is offered as a software-as-a-service solution by SAP. This is a revived form of SAP’s Financial Services network, which was launched in 2015, but with an enhanced offering such as integrated SWIFT connection.

Embedded within the SAP Cloud Platform, it provides capability for exchange of financial messaging with partner banks. As well as connectivity to the SWIFT network through an embedded version of Alliance Lite 2, this integration platform offers connectivity to partner banks through EBICS and H2H connections.

From a technical perspective, SAP MBC can perform transmissions using SFTP, REST, SOAP and AS2. We have seen evidence of corporate group IT policies dictating preferred transmission methods, so it is important that bank connectivity tools accommodate these. The platform has 99% up-time, and various failover mechanisms in place.

SAP MBC is particularly relevant to those corporates who are looking to move towards SAP as a strategic software vendor. With many corporates embarking on S/4 HANA transformation, it is a popular consideration.

We expect to see this offering as strong competition to SWIFT Service Bureaus going forward, especially where corporates are not leveraging the value-add services that SSBs offer.

This site is registered on as a development site.