Tag Archive for: API

Open banking and APIs: transforming the future of treasury

| 05-11-2019 | treasuryXL | BELLIN

Open banking is about much more than advanced technology. It has an impact on business models, processes and ways of thinking – and it will definitely have a huge impact on treasury.

The EU’s revised payment services directive (PSD2) has forced European banks to set up standardised interfaces, so-called APIs, to enable third parties’ technological access to bank accounts. This is an attempt to break up the banks’ monopoly and boost competition amongst payment service providers.

When it comes to payments, PSD2 APIs are currently limited to single Euro payments area (SEPA) single payments. Simply put, they are generally ill-suited for corporate payment processing. Nevertheless, open access to customer and transaction data for third parties represents a radical change that threatens traditional banking business models.

While in the past, banks reigned freely over their customers’ financial data – often keeping them in the dark about margins, fees and transaction routes – open banking makes banking fundamentally more democratic and gives companies much more freedom and flexibility.

How does a company want to handle its payment processing? With open banking, it will be of little relevance to corporates exactly how their payments are processed. As long as the payment goes from A to B, the back-end technology being used is up to the service provider. What will be more significant for corporate treasury departments when it comes to payments is how quickly this information becomes available to them.

Open banking’s impact on cash management

Today, treasurers are blind when it comes to intraday cash flow movements. Depending on the bank, they only receive balance information a few times a day at specific times. This has always been as real-time as it gets. Treasurers who would like to know their account balance at any time and in ‘real, real-time’ need to request this information. But how can you know when to best inquire about your account balance when you have no idea when money will be credited?

Some companies make use of automated requests, managed in their treasury management system (TMS). The system sends scheduled requests to the bank, for example every minute, to check if any new information is available. An analogy would be sending round a company postman to empty the letterbox every few minutes without knowing if anyone has actually posted a letter. This leads to enormous amounts of data and clogs up communication channels and systems, without really solving the issue.

A much more intelligent solution would be to not request the information until it is actually available. For that to work, there would need to be some kind of signal that data has come in – just like the signal flag on American letterboxes. New technologies, such as APIs and WebSockets, enable this kind of reversed order. The bank signals that a new balance is available as soon as money is credited to or debited from an account, and treasurers and other finance professionals can then take action. The same is true for payments, where status notifications for a transaction would be available straight away.

The future of APIs

What will the future look like for banking communication? Will APIs relegate existing technologies, such as electronic banking internet communication standard (EBICS) or SWIFT, to the sidelines? APIs’ greatest downfall is their lack of standardisation. Conversely, complete and powerful standardisation across the SEPA area is the biggest asset of these established communication channels.

In the context of PSD2, there have been various European initiatives to achieve standardisation, for example those of the Berlin Group. However, there is no comparable global initiative, and when BELLIN recently analysed the open banking offering of the ten most relevant banking groups, the discrepancies were staggering. What is needed are suitable enhancements of established technologies that could then be combined with new technologies, for example combining the EBICS protocol with API technology.

And this future is not far off. Massive changes that will impact treasurers’ day-to-day work significantly are just around the corner. Large retailers have already implemented instant payment solutions using APIs that not only enable them to transfer money, but also to receive notifications when a payment has come in as soon as it does. This has enabled them to fully connect payment processing, real-time balance information and customer service.

Direct communication of data between companies and banks is likely to have other, far-reaching consequences for treasury, for example when it comes to FX and risk management. Real-time corporate-bank communication definitely brings challenges for cash management. Banks will have to solve how cash pooling is handled in the future whilst also determining the time on which interest calculations are based. However, with new standards for speed, efficiency and data quality, open banking will continue to revolutionise treasury far beyond 2020.

Karsten Kiefer, Product Manager Solution Management, BELLIN

Karsten Kiefer

Product Manager Solution Management

 

Blockchain Smart Treasury: game-changer for treasurers?

| 19-3-2019 | Carlo de Meijer | treasuryXL

Though blockchain is not yet well understood by many treasury people, and tangible real-world applications for the corporate treasurer’s day-to-day activities are still scarce, this technology is getting increased interest in the treasury world.

In August 2016 I wrote a blog in Finextra named “The Corporate Treasurer and Blockchain”. My conclusions at that time were that blockchain had the potential to fundamentally change the treasury function at corporates. For some it would even going to be a game-changer for treasury. The change might not be here yet, but it is coming, and treasurers need to take a long view on it.

But that is changing rapidly. The focus of blockchain developers is now turning from proof of concept projects to the creation of more practical, treasury-focused blockchain solutions. Recently we have seen a number of blockchain-based treasury trials that are worthwhile looking at. Last December R3 announced the completion of testing on a new blockchain-based KYC proof-of-concept, which was facilitated in collaboration with the French Association of Corporate Treasurers and a number of French banks.

One of the solutions that triggered me most is Smart Treasury by Boston-based fintech Adjoint, that is aimed to enable real-time gross settlement and continuous reconciliation and improve the liquidity management of the corporate treasurer. Main question is, could Adjoint’s solution be a break-through for blockchain in the corporate treasury world?

It is always interesting – and I am a very curious person – to see new initiatives in the blockchain scene and what they could bring for corporates esp. the treasury department.

So let’s have a deeper dive.

Complex treasury environment

Internationally operating corporates have undergone many transformations in their finance and treasury organisations triggered by technology innovations, regulatory initiatives and changed client behaviours. As a result today’s business environment for these corporates is highly complex from a treasury point of view.

In the digital era, real-time insight into a company’s global cash positions and managing credit facilities across all bank accounts of the group and the ability to move money intraday to where and when it is needed is increasingly needed to support this changing business environment.

Key challenge is to obtain consolidated information of group-wide multi-currency positions across a fragmented banking network in a timely manner. Today’s model of international correspondent banking however does not easily facilitate the ability to manage cash in a real-time environment.

Corporate treasurers are urgently looking for new ways to provide cash management with up to date – and if possible real time – information on cash positions and cash forecasts faster and with deeper insight, allowing corporate treasurers to better react to the company’s current cash and working capital needs.

In this context, they are significantly increasing their spending on treasury technology and innovations, to speed up and streamline their company’s cash, liquidity, risk and working capital management, in order to gain greatest visibility over their business critical function and reach greater strategic control.

Adjoint’s Smart Treasury: what does it bring for corporate treasurers?

Adjoint’s Smart Treasury solution, that was launched last year, contains a number of unique specifics that makes it very interesting for corporate treasures.

Smart Treasury should be seen as a multi-bank, multi-currency virtual account platform for real-time gross settlement and continuous reconciliation. This should allow corporate treasurers to untap liquidity in their various subsidiaries’ bank account.

Adjoint has combined blockchain technology with related smart contracts and APIs (or application programming interfaces) to create a solution that aims to dramatically speed up settling intercompany transactions in a secured way while significantly reducing the costs.

Most important features of this Smart Treasury solution are the following:

Distributed ledger: Auto reconciliation

Smart Treasury uses distributed ledger technology to auto-reconcile transactions information, thereby eliminate netting processes and improve FX management to provide treasurers with streamlined efficiency and improved, real-time visibility on cash positions.

Virtual accounts

Another interesting feature is that it enables a limitless number of virtual or “sub-accounts” for reconciling customer and suppliers payments. Companies can thereby consolidate costly, physical bank accounts into a selected number of blockchain virtual accounts. Smart Treasury thereby enables “purposed drive allocation”, thereby using smart contracts to designate how much and where digitised cash can be spent from these virtual accounts.

“Money can then be debited or credited among those accounts as needed, using smart contracts and APIs to make the necessaire FX translations, apply interest on intercompany loans and similar calculations.” Somil Goyal chief operating officer at Adjoint

In-house self-service bank

Smart Treasury consists of an “always-on” in-house self-service bank with “pre-established” rules for automated intra-company transactions. Here you could think of limits on how much can be automatically borrowed by entities based on pre-established interest rates. Nowadays, intercompany transactions, often conducted via an in-house bank, have become essential for multinational corporations. They seek to leverage internal resources more effectively. However, the overnight batch systems most companies use to settle transactions, can limit the transparency into subsidiaries’ account balances.

Smart Treasury Dashboard: access

The solution allows corporate treasury departments to operate their own private distributed ledger. This may enable them to choose which internal corporate entities and third parties including customers and suppliers may have access to the network via their Smart Treasury Dashboard and settle transactions directly with them in real time, rather than overnight or even longer.

But also regulators could be added on the platform which may help notional pooling in jurisdictions with currency controls, while improving the regulatory reporting process by automatically updating records and centralising all information in the ledger.

Smart contracts

Another key feature of Smart Treasury is the use of smart contracts. The tool’s Smart Contracts System uses blockchain to help teams define and set pre-configured rules that securely enable automated, real time transactions. These may include key corporate treasury functions such as regulatory and corporate compliance requirements including KYC; account opening or transactions such as intercompany loans, FX and netting, manage liquidity in multiple currencies, transfers among any approved entities etc. so lowering the costs of booking transactions between subsidiaries.

API integration with corporate ERP and TMS systems

Smart Treasury offers a nearly real-time API-based integration with organisation’s existing systems. Instead of replacing systems such as enterprise resource planning (ERP) and Treasury management system (TMS), Smart Treasury works with current systems as an easy-to-be-integrated overlay, preventing duplicate entries. In fact Smart Treasury complement these, improving the way they interact by speeding up intercompany transaction settlement. Through using smart contracts, all transaction information is auto-reconciled and automatically posted into treasury management systems in real-time.

“With Adjoint’s solution this takes place much faster, at a much lower cost, and it will actuality accept feed from the banks using APIs, which then feed the ERP – again using API – and it carries all of the information necessaire through smart contracts”.Daniel Blumen, Partner of Treasury Alliance

API integration with banks

Smart Treasury also offers a real-time API-based integration with banks for transactions outside the organisation. The solution allows the use of APIs for real-time intra-day bank transactions processing as opposed to end of day batch processing. They enable the transfer of critical information and data between corporate entities and their banks and data providers, as well as between corporate entities within the corporate.

Read the full article of our expert Carlo de Meijer on LinkedIn

 

 

Carlo de Meijer

Economist and researcher

 

PSD2 – Fall update and new developments

| 28-11-2017 | François de Witte |

PSD2In 2018, when PSD2 comes into force, banks will lose their monopoly on payment services and customer’s account details. Bank customers will be able to use third-party providers (TPP) to administer their payments. When a customer agrees on using the services of a TPP, then their bank has to give access to TPPs to their accounts. TPPs are then able to build and offer services that compete with the existing bank services. During the summer 2017, I published a Summer Update on PSD2. Since then, a lot of things have moved, and hence I found it the right moment to provide an update to you on some developments on PSD2, in this area.

LIST OF ABBREVIATIONS USED IN THIS ARTICLE

  • 2FA: Two-factor authentication
  • API: Application Programming Interface.
  • EBA:  European Banking Authority
  • PSP: Payment Service Provider
  • PSU:   Payment Service User
  • RTS: Regulatory Technical Standards (final draft issued by the EBA on 23/2/2017)
  • SCA: Strong Customer Authentication
  • TPP:  Third Party Provider
  • OTP: One time password

Main updates on the regulatory framework

Some member states have already advised that they expect delays in the transposition of PSD2 in the national law, e.g. Belgium (by March 2018), the Netherland (by June  2018), Sweden, Poland, Spain and France.
Following countries already announced that they will be on track, e.g. Italy, Finland, Ireland, Czech Republic, Germany and Bulgaria.
By end November the EBA should publish the revised draft on the SCA (Strong Customer Authentication) and Secure Communication. We expect that a number of points, raised by the market participants, will be incorporated in the text.
With regard to the access to TPPs, article 113.4 of PSD2 explicitly states that the member states shall ensure the application of the security measures within18 months following the entry in force of the law. Hence, we might expect that this part of PSD2 needs only to be implemented by Q3 2019. However, in some countries, the authorities are pushing for an earlier implementation (e.g. in Belgium by end Q1 2018). Given the strategic importance and the IT act, I recommend starting this quite soon.

Main developments

Banks will have to implement interfaces, so they can interact with the AISPs and PISPs. This compliance with PSD2 is mandatory and all banks will have to make changes to their infrastructure deployments.
The challenge is to create standards for the APIs specifying the nomenclature, access protocols, authentication, etc.”. Banks will have to think about how their new API layers interact with their core banking systems and the data models that are implemented alongside this.

A number of working groups were constituted to further elaborate on these standards, the most important ones being the UK’s Open Banking Working Group (OBWG), the Berlin Group, and STET. Experts seem to agree that the Berlin Group Standard is the most elaborate one., as it incorporates the most relevant use cases and has been built with the latest technology standards using REST, OAuth2, JSON and HTTP-signature. It relies on ISO 20022 elements for structuring the data to be exchanged between TPPs and ASPSPs

As Marc Lainez, CEO of Ibanity, part of Isabel Group (developing API and PSD2 solutions for the XS2A and beyond) pointed out: “We can already see a fragmentation on the market. Several groups publishing specifications that are on many points different. With the RTS still being a moving target at the moment, those specifications are also incomplete as some details still need to be clarified. Some banks also choose to implement their own specifications without following closely any of those already published. In engineering, a standard is usually something that emerges through the best practices of an industry, it is not something that can be thought off entirely before it is actually used. At Ibanity, we are convinced that fragmentation will be a reality and several formats and specifications will co-exist on the market for some time. Looking at them from a pure software engineering point of view, we can say that those that seem the closest to what TPPs are actually expecting in terms of API quality are the specifications from the Open Banking Working Group and the Berlin Group. They still need, of course, to be challenged by the market with real use cases.“

The large banks have already started working on being PSD2 compliant and on building for the opening of their banking architecture to the TPPs. However, several small or medium sized banks only started recently on this project.
PSD2 has numerous interdependencies with other regulations (such as GDPR and eIDAS Regulation), promising a complex implementation with multiple stakeholders. For many banks, compliance by 2018 will be a challenge. Moreover there is a strong technology impact, adding to the complexity of the project. The following graphs of a market survey of PWC are a good illustration of the current state of the project with the European banks:

Conclusion

The PSD2 creates challenges. Several topics need to be clarified such as the RTS and the market players need also to agree on common standards for the interfaces. Moreover there are some unclarities in the text.
However, there are solutions in the market to withdraw the hassle for Banks and TPPs. The clock is ticking in the PSD race. Consequently, there is no justifiable reason for any bank to delay starting these projects.

François de Witte – Founder & Senior Consultant at FDW Consult and Senior Expert – Product, Business development and sales manager at Isabel Group

 

[button url=”https://www.treasuryxl.com/community/experts/francois-de-witte/” text=”View expert profile” size=”small” type=”primary” icon=”” external=”1″]

[separator type=”” size=”” icon=””]

The Paypers releases the Open Banking & API Report 2017

| 18-8-2017 | treasuryXL | The Paypers |

The Paypers has released the Open Banking & API Report 2017, offering important insight into the nascent landscape of Open Banking in Europe. The rise of Open Banking gives banks the opportunity to work with innovative players and technologies in the growing fintech community. Although this can lead to a wave of innovation in the banking industry, there are still many hurdles to clear.

Open Banking & API Report 2017

The Open Banking & API Report 2017 aims to provide readers with essential information for understanding the latest developments on the topic, as well as practical examples and best practices in Open Banking. First, the report elaborates on the innovations in Open Banking and the issues that still stand in the way of universal adoption. Afterwards, we will dive into the best practices and new business models in both banking and fintech.

PSD2, and XS2A in particular, are accelerating change in payments, innovative banking applications, and respective business models by leveraging payment functionality and account information. The Open Banking ecosystem is brimming with potential, but there is still much debate on the functional scope of “access to account”, effective business- and operational models, and standardisation in terms of technology, legal, and operational matters.

The Open Banking & API Report 2017 brings together contributions from key players in the market; banks, consultants, merchants, and fintech. The most pressing issues that are being discussed in the report are:

  • Harmonization and standardization – Can collaboration in the industry lead to the adoption of a single standard?
  • Access to account – To what degree will customers and Third Part Providers (TPP) have access to the account? What are the legal issues that have to be settled between PIPSs, AIPS, PSPs and ASPSPs? What are the alternative business models based upon the open interface?
  • Interaction model between bank, customer, and third party (strong customer authentication) – To what extent should bank require Strong customer authentication, and where should one make the exemptions that PSD2 offers in certain well-defined cases?
  • The customer in control – Can Open Banking bring the customer to the center of the banking industry?

The Open Banking & APIs Report 2017 does not stop at explaining the Open Banking system and the regulations that will transform it. Instead, it goes one step further and proposes solutions for dealing with the new changes. Will banks partner with fintech companies? How will consumers respond to banking services through nonbanking channels and, most importantly, how will banks deal with new security threats that may come with the entrance of new players?

The Open Banking & API Report 2017 is a valuable tool for understanding the Open Banking business model and a must-read for banks, merchants, PSPs, and other industry players that will be affected by PSD2 regulations. Download your free copy (see button) here and learn more about the banking industry of tomorrow.

Annette Gillhart – Community manager treasuryXL

[button url=”https://www.thepaypers.com/report/download/online-mobile-banking/12/open-banking-and-apis-a-new-era-of-innovation-in-banking/r769400″ text=”Download report” size=”small” type=”primary” icon=”” external=”1″]

[separator type=”” size=”” icon=””]

PSD2 – Update and new developments

| 17-8-2017 | François de Witte |

Early 2017, I published a post about PSD2, a lot of opportunities, but also big challenges. Now half a year later, I would like to update you on some developments in this area. PSD2 still needs to be transposed in the national legal system of all the member countries, and according to my knowledge several countries, including Belgium, have not yet released the draft laws. This creates quite some uncertainty in the market, as there will be several country-specific specifications. Hence one can expect that Fintech’s and other TPPs might already have started their certification application in countries that already enacted PSD2 in their local legislation.

LIST OF ABBREVIATIONS USED IN THIS ARTICLE

2FA: Two-factor authentication
API:  Application Programming Interface.
EBA: European Banking Authority
PSP: Payment Service Provider
PSU: Payment Service User
RTS: Regulatory Technical Standards (final draft issued by the EBA on 23/2/2017)
SCA: Strong Customer Authentication
TPP: Third Party Provider

Main updates on the regulatory framework

On 23 February 2017, the EBA published the final draft on the SCA (Strong Customer Authentication) and Secure Communication.
In this final draft, the EBA clarifies the new rules to be followed for customer authentication, applicable both for operations performed in traditional channels and over the new API (Application Programming Interfaces) services. The key clarifications concern the following:

The 2 factor authentication

Following systems would comply:

1. The 2-device-authentication, where the user has two independent devices:

  • one device to access the banking website or app
  • another device to authenticate himself or a payment: the authentication device, usually a hardware authentication token, a combination of a smart card and smart card reader, or a dedicated app on a mobile device.
    The authentication device generates one-time passwords (OTPs) over transaction data

2. The 2 app authentication:

This approach does rely on two different apps running on the same mobile device.

  • Banking app : when a user wants to make a payment, he opens the banking app and enters the transaction data.
  • Authentication app: When the user has submitted the transaction, the banking app opens the authentication app. After verification and confirmation of the transaction data by the user, the authentication app generates an OTP (One Time Password) linked to the transaction data and sends it back to the banking app, which submits it to the banking server for verification

The dynamic linking

In order to dynamically link the transaction, the draft RTS states the following requirements must be met:

  • the payer must be made aware at all times of the amount of the transaction and of the payee;
  • the authentication code must be specific to the amount of the transaction and the payee;
  • the underlying technology must ensure the confidentiality, authenticity and integrity of: (a) the amount of the transaction and of the payee; and (b) information displayed to the payer through all phases of the authentication procedure (the EBA hasn’t specified the nature of this “information”);
  • the authentication code must change with any change to the amount or payee;
  • the channel, device, or mobile application through which the information linking the transaction to a specific amount and payee is displayed must be independent or segregated from the channel, device or mobile application used for initiating the electronic payment transaction.

The exemptions from the SCA

The exemptions from the SCA including also:

  • Transactions between two accounts of the same customer held at the same PSP
  • Low risk transactions: Transfers within the same PSP justified by a transaction risk analysis (taking into account detailed criteria to be defined in the RTS),
  • Low value payments or contactless payments < 50 euro, provided that that the cumulative amount of previous consecutive electronic payment transactions without SCA, since the last application, of the SCA < 150 euro
  • Unattended transport and parking terminals

The draft RTS (not finalized, not approved yet) also states that Screen scraping is no longer allowed. Screen scraping is a method to take over remotely the data on the screen of the user. This creates a lot of opposition in the financial community, in particular the Fintech’s, as this complicates the interaction between the bank, the TPP, and the PSU. On the other hand, the both the EBA and the EBF (European Banking Federation) are against it. There is a power game ongoing.

Main developments

Banks will have to implement interfaces, so they can interact with the AISPs and PISPs. This compliance with PSD2 is mandatory and all banks will have to make changes to their infrastructure deployments.

Although PSD2 does not specifically mention the API (Application Programming Interfaces), most technology and finance professionals assume that APIs will be the technological standard used to allow banks to comply with the regulation.

An API is a set of commands, routines, protocols and tools which can be used to develop interfacing programs. APIs define how different applications communicate with each other, making available certain data from a particular program in a way that enables other applications to use that data. Through an API, a TPP application can make a request with standardized input towards another application and get that second application to perform an operation and deliver a standardized output back to the first application. For example, approved third parties can access your payment account information if mandated by the user and initiate payment transfer directly.

In this framework, the challenge is to create standards for the APIs specifying the nomenclature, access protocols, authentication, etc.”. Banks will have to think about how their new API layers interact with their core banking systems and the data models that are implemented alongside this.

At this stage, following working groups were constituted to further elaborate on these standards:

  • UK’s Open Banking Working Group (OBWG). This initiative of UK Treasury aims to deliver a framework for open banking and data sharing via APIs for the UK’s banking industry. The joint industry/government initiative recently released its report on establishing the framework for an Open Banking Standard for the UK alongside a timetable for implementation.
  • The Berlin Group, a-European payments interoperability coalition of banks and payment processors, is pushing for a single standard for API access to bank accounts to comply with new regulations on freeing up customer data under PSD2. The aim is to offer operational rules and implementation guidelines with detailed data definitions, message modelling and information flows based on RESTful API methodology. It will be published for consultation in Q4 2017
  • STET has also released of a RESTFUL API standard which will allow TPPs to access payment accounts. This API has been built with the latest technology standards using REST, OAuth2, JSON and HTTP-signature. It relies on ISO 20022 elements for structuring the data to be exchanged between TPPs and ASPSPs

In the meantime, several providers are developing their services, including in the Benelux Equens Worldine, Capco, Sopra Banking and Isabel.

Along with the arrival of open API banking, there is also clear momentum for providing real-time services such as “instant payments”. This requires banks to shift their entire product and service mindset towards immediate delivery and to make fundamental changes to their legacy systems. While this is a challenge, it also presents opportunities (see also my article in TreasuryXL on this topic: SEPA Instant Payments – a catalyst for new developments in the payments market (https://www.treasuryxl.com/news-articles/francois-de-witte/sepa-instant-payments-catalyst-new-developments-payments-market and https://www.treasuryxl.com/news-articles/francois-de-witte/sepa-instant-payments-a-catalyst-for-new-developments-in-the-payments-market-part-ii/).

The large banks have already started working on being PSD2 compliant and on building for the opening of their banking architecture to the TPPs. However, several small or medium sized banks only started recently on this project. Hence a lot has to be done, and I do expect some shortages in resources in the next coming months.

With regard to the access to TPPs, article 113.4 of PSD2 explicitly states that the member states shall ensure the application of the security measures with the 18 months following the entry in force of the Hence, we might expect that this part of PSD2 needs only to be implemented by mid-2019. Given the strategic importance and the IT act, I recommend starting this exercise much earlier.

Conclusion

The PSD2 creates challenges. Several topics need to be clarified such as the RTS and the market players need also to agree on common standards for the interfaces.
However, there are initiatives, such as the Berlin Group, the UK’s Open Banking Framework and the STET group, which help give further clarity and direction in the absence of specific technical detail.
Consequently, there is no justifiable reason for any bank to delay starting these projects.
The clock is ticking in the PSD race.

If you want  further update on this topic, you can join the 1 day training session on this topic, which I will give on 22/11/2017 at Febelfin Academy.

 

François de Witte – Founder & Senior Consultant at FDW Consult

[button url=”https://www.treasuryxl.com/community/experts/francois-de-witte/” text=”View expert profile” size=”small” type=”primary” icon=”” external=”1″]

[separator type=”” size=”” icon=””]

Please read my earlier articles on PSD2:

PSD 2: A lot of opportunities but also big challenges (Part I)

PSD 2: A lot of opportunities but also big challenges (Part II)

Sepa instant payments – A catalyst for new developments in the payments market (Part I)

Sepa instant payments – A catalyst for new developments in the payments market (Part II)

[separator type=”” size=”” icon=””]