There are risks in undertaking any big treasury transformation project, but the risks of not adjusting to the changing world around you can be far bigger. Recognizing the potential pitfalls of relying on an outdated (and soon to be unsupported) SAP ECC system, Alliander embarked on a large-scale, business-wide transition to SAP S/4HANA. Zanders advised on the Central Payments and Treasury phase of this project, which completed in May 2024.

A future-focused perspective

Network company, Alliander, is the Netherlands’ biggest decentralized grid operator, responsible for transporting energy to households and businesses, 24 hours a day, 7 days a week. As a driving force behind the energy transition, the business is committed to investing in innovation - and this extends to how they are future-proofing their business operations as well as their contribution to shaping the sustainable energy agenda.

With their SAP ECC system approaching end of life, Alliander embarked on a company-wide switch to SAP S/4HANA. However, transitioning to SAP’s newest ERP platform is not just another simple upgrade, it’s a completely new system built on top of the software company’s own in-memory database HANA. For a business of Alliander’s size and complexity, this is a huge undertaking and a lengthy process. In order to minimize the disruption and potential risks to mission-critical business systems, Alliander has started the transition early, breaking down the implementation into a series of logically ordered phases. This means individual business areas are migrated to S/4HANA as separate projects.

“In finance, this transition started about four years ago with the transition of Central Finance to S/4—that was the first stepping stone,” says Thijs Lender, Financial Controller and Alliander’s Project Owner for SAP S/4HANA in Finance. “The second major project was Central Payments and Treasury. From a business point of view, this was the first real business finance process that we implemented on S/4.”

Central Payments and Treasury was selected as a critical gateway to moving other business areas to the new target infrastructure, for example, purchasing. It was also an ideal test ground for the migration process from ECC to S/4HANA as Alliander’s cash management processes operate in relative isolation, therefore presenting a lower risk of collateral damage across other business operations when the department moved to the new system. ''Treasury and Central Payments is at end of the of the source-to-pay and order-to-cash process—it’s paying our invoices and collecting money,” explains Guido Tabor, Digital Lead Finance at Alliander. “This means it could be moved to the target architecture without impacting other areas.”

Greenfield or brownfield?

The two most common pathways to SAP S/4HANA are a greenfield approach and a brownfield approach. For a brownfield migration a company’s existing processes are converted into the new architecture. In contrast, the greenfield alternative involves abandoning all existing architecture and starting from scratch. The second is a far more extensive process, requiring a business to often make wide-ranging changes to work practices, reengineering processes in order to optimally standardize their workflows. As Alliander’s business had changed significantly over the period of running SAP ECC, they recognized the benefit of starting from a clean slate, building their new ERP system from scratch to meet their future business needs rather than trying to retro fit their existing system into a new environment.

“We really wanted to bring it back to best practices, challenging them and standardizing our processes in the new system,” adds Thijs. “In the old way, we had some ways of working that were not standard. So, there were sometimes tough discussions, and we had to make choices in order to achieve standard processes.”

A collaborative approach

While the potential benefits of greenfield migrations are substantial, untangling legacy processes and building a new S/4HANA system from scratch is a complex undertaking. Success hinges on the collaboration of various stakeholders, including experts with understanding of the inner workings of the SAP architecture.

“From the very beginning, we didn't see this as an IT project,” Guido says. “IT was involved but also the business - in this case, finance from a functional perspective, and also Zanders and the Alliander technical team. It was really a joint collaboration.”

Zanders worked alongside Alliander right from the early stages of the Central Payments and Treasury project. ­From helping them to strategically assess their treasury processes through to planning and implementing the transition to SAP S/4HANA. Having worked with the business previously on the ECC implementation for Central Payments and Treasury, Zanders’ knowledge of Alliander’s current environments combined with their specialist knowledge of both treasury and SAP S/4HANA meant the team were well placed to guide the team through the migration process. The strength of the partnership was particularly important when the timing of the deployment was brought forward.  

“Initially we wanted to go live shortly before quarter close” Guido recalls “Then at the beginning of January, we had a discussion with our CFO about the deployment. With June 1 being very close to June 30 half year close, we decided we didn't want to take the risk of going live on this date, and he challenged us to move it back to the middle of May.”

What became really important was having a partner [Zanders] who helps you think out of the box. What's the possibility? How can you deal with it? While also being agile in supporting on fast changes and even faster solutions.

Guido Tabor, Digital Lead Finance at Alliander.

Adopting a 'Fix It' mindset

With the new deadline set, the team were encouraged by the CFO to adopt a ‘fix it’ mindset. This empowered them to take a bold, no compromises approach to implementation. For example, they were resolute in insisting on a week-long payment freeze ahead of the transition, despite pleas for leniency from some areas of the business. This confident, no exceptions approach (driven by the ‘fix it’ mentality) ensured the transition was concluded on time leading to a seamless transition of Central Payments and Treasury to the new S/4HANA system.

“This was a totally new perspective for us,” says Guido. “With go live processes or transitions like this, there will be some issues. But it didn't matter what, it didn't matter how, we just had to fix it. What became really important was having a partner [Zanders] who helps you think out of the box. What's the possibility? How can you deal with it? While also being agile in supporting on fast changes and even faster solutions.”

Central Payments and Treasury project went live on S/4HANA in May 2024, on time and with a smooth transition to the new system.

“I was really happy on the first Monday after go-live and in that early week that there weren't big issues,” Guido says. “We had some hiccups, that's normal, but it was manageable and that's what is important.”

This project represented an important milestone in Alliander’s transition to SAP S/4HANA. Successfully and smoothly shifting a core business process into the new architecture clearly progressed the company past the point of turning back. This reinforced momentum for the wider project, laying robust foundations for future phases.

To find out how Zanders could help your treasury make the transition from SAP ECC to SAP S/4HANA, contact our Director Marieke Spenkelink.

In countries worldwide, associations of credit information providers play a crucial role in registering consumer-related credits. They are mandated by regulation, operate under local law and their primary aim is consumer protection. The Dutch Central Credit Registration Agency, Stichting Bureau Krediet Registratie (BKR), has reviewed the validity of the credit registration period, especially with regards to the recurrence of payment problems after the completion of debt restructuring and counseling. Since 2017, Zanders and BKR are cooperating in quantitative research and modeling projects and they joined forces for this specific research.

In the current Dutch public discourse, diverse opinions regarding the retention period after finishing debt settlements exist and discussions have started to reduce the duration of such registrations. In December 2022, the four biggest municipalities in the Netherlands announced their independent initiative to prematurely remove registrations of debt restructuring and/or counseling from BKR six months after finalization. Secondly, on 21 June 2023, the Minister of Finance of the Netherlands published a proposal for a Credit Registration System Act for consultation, including a proposition to shorten the retention period in the credit register from five to three years. This proposition will also apply to credit registrations that have undergone a debt rescheduling.

The Dutch Central Credit Registration Agency, Stichting Bureau Krediet Registratie (BKR) receives and manages credit registrations and payment arrears of individuals in the Netherlands. By law, a lender in the Netherlands must verify whether an applicant already has an existing loan when applying for a new one. Additionally, lenders are obligated to report every loan granted to a credit registration agency, necessitating a connection with BKR. Besides managing credit data, BKR is dedicated to gathering information to prevent problematic debt situations, prevent fraud, and minimize financial risks associated with credit provision. As a non-profit foundation, BKR operates with a focus on keeping the Dutch credit market transparent and available for all.

BKR recognizes that the matter concerning the retention period of registrations for debt restructuring and counseling is fundamentally of societal nature. Many stakeholders are concerned with the current discussions, including municipalities, lenders and policymakers. To foster public debate on this matter, BKR is committed to conducting an objective investigation using credit registration data and literature sources and has thus engaged Zanders for this purpose. By combining expertise in financial credit risk with data analysis, Zanders offers unbiased insights into this issue. These data-driven insights are valuable for BKR, lawmakers, lenders, and municipalities concerning retention periods, payment issues, and debt settlements.

Problem Statement

The Dutch Central Credit Registration Agency, Stichting Bureau Krediet Registratie (BKR) receives and manages credit registrations and payment arrears of individuals in the Netherlands. By law, a lender in the Netherlands must verify whether an applicant already has an existing loan when applying for a new one. Additionally, lenders are obligated to report every loan granted to a credit registration agency, necessitating a connection with BKR. Besides managing credit data, BKR is dedicated to gathering information to prevent problematic debt situations, prevent fraud, and minimize financial risks associated with credit provision. As a non-profit foundation, BKR operates with a focus on keeping the Dutch credit market transparent and available for all.

The research aims to gain a deeper understanding of the recurrence of payment issues following the completion of restructuring credits (recidivism). The information gathered will aid in shaping thoughts about an appropriate retention period for the registration of finished debt settlements. The research includes both qualitative and quantitative investigations. The qualitative aspect involves a literature study, leading to an overview of benchmarking, key findings and conclusions from prior studies on this subject. The quantitative research comprises data analyses on information from BKR's credit register.

External International Qualitative Research

The literature review encompassed several Dutch and international sources that discuss debt settlements, credit registrations, and recidivism. There is limited research published on recidivism, but there are some actual cases where retention period are materially shortened or credit information is deleted to increase access to financial markets for borrowers. Removing information increases information asymmetry, meaning that borrower and lender do not have the same insights limiting lenders to make well-informed decisions during the credit application process. The cases in which the retention period was shortened or negative credit registrations were removed demonstrate significant consequences for both consumers and lenders. Such actions led to higher default rates, reduced credit availability, and increased credit costs, also for private individuals without any prior payment issues.

In the literature it is described that historical credit information serves as predictive variable for payment issues, emphasizing the added value of credit registrations in credit reports, showing that this mitigates the risk of overindebtedness for both borrowers and lenders.

Quantitative Research with Challenges and Solutions

BKR maintains a large data set with information regarding credits, payment issues, and debt settlements. For this research, data from over 2.5 million individuals spanning over 14 years were analyzed. Transforming this vast amount of data into a usable format to understand the payment and credit behavior of individuals posed a challenge.

The historical credit registration data has been assessed to (i) gain deeper insights into the relationship between the length of retention periods after debt restructuring and counseling and new payment issues and (ii) determine whether a shorter retention period after the resolution of payment issues negatively impacts the prevention of new payment issues, thus contributing to debt prevention to a lesser extent.

The premature removal of individuals from the system of BKR presented an additional challenge. Once a person’s information is removed from the system, their future payment behavior can no longer be studied. Additionally, the group subject to premature removal (e.g. six months to a year) after a debt settlement registration constitutes only a small portion of the population, making research on this group challenging. To overcome these challenges, the methodology was adapted to assess the outflow of individuals over time, such that conclusions about this group could still be made.

Conclusion

The research provided BKR with several interesting conclusions. The data supported the literature that there is difference in risk for payment issues between lenders with and without debt settlement history. Literature shows that reducing the retention period increases the access to the financial markets for those finishing a debt restructuring or counseling. It also increases the risk in the financial system due to the increased information asymmetry between lender and borrower, with several real-life occasions with

increased costs and reduced access to lending for all private individuals. The main observation of the quantitative research is that individuals who have completed a debt rescheduling or debt counseling face a higher risk of relapsing into payment issues compared to those without debt restructuring or counseling history. An outline of the research report is available on the website of BKR.

The collaboration between BKR and Zanders has fostered a synergy between BKR's knowledge, data, and commitment to research and Zanders' business experience and quantitative data analytical skills. The research provides an objective view and quantitative and qualitative insights to come to a well informed decision about the optimal registration period for the credit register. It is up to the stakeholders to discuss and decide on the way forward.

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 m.zelazko@zandersgroup.com or via + 81 (0) 8 3255 9966

[1] https://www.boj.or.jp/en/paym/outline/pay_boj/pss0305a.pdf

A transfer to a new system is usually a complicated and time-consuming process. This particularly rings true for a company like GlobalCollect, which processes hundreds of thousands of online transactions for banks all over the world on a daily basis. How did this payment service provider (PSP) tackle the complicated challenge of adopting SWIFT as its new system?

In 1994, the current GlobalCollect was set up as a division within the old TPG Post company to ensure a well-organized payment system for parcel deliveries. Back then it was dealing with offline payments, such as cash on delivery, but when digitalization took off, the postal company decided to go online with its payment services. Now, GlobalCollect is a fast-growing company, independent of TPG Post, which processes worldwide online payments for retailers operating internationally. This PSP offers them one platform so that they do not have to deal with the complexity of various foreign banks and their payment systems.

Connections and conversions

Michael Roos, vice president of merchant boarding at GlobalCollect, says that the market for PSPs has quickly become ‘professionalized’. “The industry has developed enormously over the past 10 years, also as far as legal and statutory regulations are concerned. We fall under the supervision of the Dutch central bank, De Nederlandsche Bank, and are affected by the EU’s Payment Services Directive (PSD). Companies who conduct business abroad, such as airlines or online retailers, need to receive payments from abroad. That adds to the complexity as it is a huge challenge setting up all the connections. You not only have to deal with the local banker, but also with all sorts of foreign banks.” A PSP not only has all those necessary local connections but is able to offer the client various payment methods via one point of access. “As a company you then have not only the local payment method, such as iDeal in the Netherlands, but also those in other countries where you have customers.”

Since GlobalCollect processes many millions of transactions each month, it is able to compete on price – something a single company cannot do with only several hundred transactions. Customers enjoy a more favorable rate – despite working with an intermediary – than they would with a bank. Besides dealing with the complexity of connections, GlobalCollect’s clients enjoy large-scale benefits for other services, such as currency conversion. “Collection of foreign currency can be outsourced,” Roos adds. “If you get paid in Brazilian real, which is not freely convertible, we do the conversion. Clients then have quicker access to their money in their own currency.”

New for corporates

 When GlobalCollect was starting up, it began with a few bank interfaces. “But after about 15 years we had more than 50 interfaces within an out-of-date infrastructure. In order to bring this infrastructure up to a technological standard that was market compliant, we decided that SWIFT was the best solution. But to get started we didn’t have the required know-how and manpower. So when we looked around for a company with plenty of expertise we hit on Zanders. I had spoken to Sander van Tol about three or four years ago and remembered that Zanders knew a lot about SWIFT. In the spring of 2012 I met Jill Tosi and in October the project kicked off.” Zanders taught GlobalCollect about the possibilities and impossibilities of SWIFT. “And Zanders was the right choice,” says Roos. Originally, SWIFT was a connectivity channel for banks, and since 2000 it has also become available to corporates. When GlobalCollect decided to start using SWIFT’s Alliance Lite2, a new cloud-based SWIFT communication tool, it was new to the market. Roos says: “As one of the first adopters, we were working with a completely new SWIFT system.

The interfaces particularly were new and unknown.” GlobalCollect’s reason for acquiring SWIFT was twofold. On the technical side, the number of interfaces had to be reduced. On the other hand, SWIFT had to standardize formats and the provision of information. Roos adds: “In order to be able to profit from the systems we had to have good information. Good information is standardized in IT, and so we ended up with SWIFT. The way information was shared with banks had to be standardized as much as possible. This was our starting point with a kick-off on various workflows.”

Fully-fledged tool

The challenge for GlobalCollect was mainly in connecting to banks. The old interfaces had to be replaced with new ones. Whereas SWIFT has everything standardized, it appeared that the banks did not. Roos explains: “Banks who want to connect via SWIFT each send their own technical implementation document; where one sends a single Excel-sheet with technical details, another sends a 20-page contract.” Roos noticed that SWIFT, banks, and corporations were not necessarily used to dealing with each other in this context. “Particularly outside of developed markets, the banks have not come that far yet and there is a good deal of indifference. This makes project-based work and estimation of turnaround times difficult. We approached a number of banks and looked to see which ones reacted the fastest and in the most professional way, and we started with them. This is not what you would normally do. I think we got off to a good start, but the migration path will take a number of months to complete.” The time required for testing individual connections and carrying out test cases can be very long. Roos says: “SWIFT is a fully-fledged tool and the parties used to working with it are large financial institutions. For us as a young, upcoming, dynamic industry, we really have to adapt to the banks – it’s a completely different culture.”

Change of format

With the huge amount of transactions involved, a transfer to another system is risky. “Therefore we ran the two systems in parallel during the migration,” he explains. “We also deliberately decided to link the largest parties first, leaving the legacy system running as we integrated SWIFT into the organization.” This means that a back-up is not necessary. “SWIFT is a unique system, with relatively large numbers of redundancy channels and recovery scenarios, so that it can guarantee unique processing.”

According to Zanders consultant Jill Tosi, this is because SWIFT is owned by the banks: “They have so much trust in their system that they assume responsibility for payments. SWIFT has such a robust system with minimal failure percentages, that customers can put complete trust in its information process.”

At the time of transferring to the new system, GlobalCollect had a lot of IT projects on the go. The SWIFT implementation was also part of a much larger project, Process Excellence, where several systems had to be modernized in order to meet market standards. “There was a lot of pressure on the IT department at GlobalCollect,” Tosi says. “The electronic banking systems were all stand-alone, i.e. not integrated into the daily processes. There were about 50 electronic banking systems, and someone had to log into each one separately with a different token each day. For one or two that is feasible, but 50 is too many.” And Roos adds: “The whole idea was to continue with significantly fewer interfaces – preferably one. And we are still very busy with that.”

While GlobalCollect was carrying out the migration to the new system, the banks were right in the middle of the SEPA migration. “That had consequences for the introduction of new formats within SWIFT,” Roos says. “We had to make a decision: do we go for MT940, the old standard for bank statements, or do we go for CAMT 053, the XML-successor of MT940? XML is a future-proof format but is not offered by all banks. As a consequence of SEPA, some banks will have to be migrated twice: firstly to MT940 and then to XML. An interesting aside is that where SWIFT offers the version 2.0 solution to corporations, many banks are just not ready for SWIFT connectivity with businesses. A number of large Anglo-Saxon banks have indicated that MT940 interfaces are not yet available for a direct connection to SWIFT Alliance Lite2 with corporates.”

Business as usual

The SWIFT migration to large banks is over and this year other banks will follow. After the first three banks, Zanders withdrew from the process. "It is now more like business as usual,” says Roos. "Zanders not only did the implementation, but was also responsible for the learning curve in our company. We have become self-supporting as far as SWIFT is concerned.” After the SWIFT project, Zanders also helped GlobalCollect with the selection and implementation of a new treasury management system (TMS) and a reconciliation tool. "Messages coming from SWIFT could be uploaded to our TMS straight away,” Roos says. "The same goes for our reconciliation system. If we didn’t have the standardization of the SWIFT system, it would have been much harder. In the banks’ own technical file formats there is a degree of standardization, but it’s not complete. It is clear to us that getting the standard functionality working would not have been possible without the successful implementation of SWIFT Alliance Lite2.”