PSD2 Spring Update

| 18-06-2018 | François de Witte | TreasuryXL

During the fall of 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 you on some developments PSD2 and open banking.

LIST OF ABBREVIATIONS USED IN THIS ARTICLE

AISP:            Account Information Service Provider
API:              Application Programming Interface
ASPSP:         Account Servicing Payment Service Provider
EBA:             European Banking Authority
PISP:            Payment Initiation Service Provider
PSP:             Payment Service Provider
PSU:             Payment Service User
RTS:             Regulatory Technical Standards
SCA:             Strong Customer Authentication
TPP:             Third Party Provider

Main updates on the regulatory framework

Several member states have experienced in the transposition of PSD2 in the national law. The current status (27/5/2018) is as follows:

• Full transposition measures communicated: Austria, Bulgaria, Cyprus, Czech Republik, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Slovakia, Slovenia, Sweden, United Kingdom
• Partial transposition measures communicated: Belgium, Lithuania, Malta, Poland
• No transposition measures communicated: Croatia, Latvia, Luxembourg, Netherlands, Portugal, Romania, Spain

Source : https://ec.europa.eu/info/publications/payment-services-directive-transposition-status_en

The EC has launched an infringement proceeding is against the states who did not or only partially transposed PSD2 in their national law.

The Regulatory Technical Standards on strong customer authentication and secure open standards of communication have been published on 13/3/2018 in the Official Journal of the European Union. They will apply in as from September 13, 2019, leaving 18 months to the payment industry to get ready for this new state of play.

The EBA has decided to maintain the obligation for the ASPSPs to offer at least one interface for AISPs and PISPs to access payment account information. As of 13/9/2019, the existing practice of third party access without identification (at times referred to as ‘screen scraping’) will no longer be allowed. In order to address the concerns raised by a few respondents, the final RTS now also require that ASPSPs that use a dedicated interface will have to provide the same level of availability and performance as the interface offered to, and used by, their own customers, provide the same level of contingency measures in case of unplanned unavailability, and provide an immediate response to PISPs on whether or not the customer has funds available to make a payment.

The banks need already to prepare some steps as from early 2019 onwards. The following timetable illustrates the deadlines:

The finalization of the RTS is an important milestone which will give banks and TPPs much more clarity and certainty on how to push forward their PSD2 compliance and strategic programs.

13/1/2018, the date of implementation of PSD2 appeared to be nonevent. Over one third of the member states failed to implement PSD2. Only very few banks had published their APIs. We observe that banks are much slower in opening up their APIs to TPPs, and this for various reasons, e.g. APIs are not yet ready technically, chicken and egg situation with other banks, etc. As a result, the API aggregators need to use screen scraping or reverse engineering to enable to provide for the TPPs (including banks) access to the accounts held at the ASPSPs.

Furthermore, the standards are not yet harmonized throughout Europe. 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 ones, 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 However the UK Open Banking standards also provide interesting insights. The UK has already a much larger experience in open banking. In my view it’s essential to create a set of common, industry standard APIs that can be used by all.

Another challenge is the implementation of the multi-factor authentication. There also some interesting initiatives took place. Gemalto the world leader in digital security, has enabled Belgian mobile ID scheme ITSME to enroll 350,000 users and securely process one million transactions per month for both private and public online services – making it one of the most successful mobile ID applications in Europe within one year of launch.

Real-time payments can be the catalyst for a new wave of innovative corporate banking, payments and cash management services. The SEPA Instant Credit Transfer, will offer in combination with PSD2 interesting new use cases for Open Banking. However, it will take time to take off, as it requires huge investment from the banks, and also a change in the mentality of the consumers.

Conclusion

Although PSD2 should have been enacted by the member states, some states are still lagging behind. The banks are slow in opening their APIs, and open banking is not taking off as quickly as expected. Market players need also to agree on common standards for the interfaces.

However, there the deadline of 13/9/2019 is approaching and there is no way back. The clock is ticking in the PSD race. “If you cannot beat them, then you better join them”.

Open banking is a new way of approaching the delivery of financial services for customers, and as such, it requires a new way of thinking and new ways of working. This will also require a new mindset and a different team set up. Teams are going to be more agile and have a mix of skills and people. This is a big challenge for several institutions.

For your information, I will give a one-day training on the subject at Febelfin Academy on 21/11/2018. For more information, please go to: https://www.febelfin-academy.be/nl/opleidingen/detail/psd2-and-the-open-banking-architecture-addressing-.

François de Witte – Founder & Senior Consultant at FDW Consult; Managing Director and CFO at SafeTrade Holding S.A.

 

[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=””]

Best read articles of all time – PSD 2: a lot of opportunities but also big challenges (Part II)

| 16-05-2018 | François de Witte |

After having examined the detailed measures of the PSD2 in my first article, in the 2nd part we will examine the impact of PSD 2 on the market. In order to help you read the text we will once more start with a list of abbreviations.

LIST OF ABBREVIATIONS USED IN THIS ARTICLE

2FA    :   Two-factor authentication
AISP  :    Account Information Service Provider
API :       Application Programming Interface
ASPSP : Account Servicing Payment Service Provider
EBA :     European Banking Authority
PISP :    Payment Initiation Service Provider
PSD1:    Payment Services Directive 2007/64/EC
PSD2  :  Revised Payment Services Directive (EU) 2015/2366
PSP :     Payment Service Provider
PSU:      Payment Service User
RTS :     Regulatory Technical Standards (to be issued by the EBA)
SCA :     Strong Customer Authentication
TPP :     Third Party Provider

Impact on the market

A major implementation journey:

The ASPSP (mostly banks) will have to make large investments in order to comply with the PSD2, in the following fields:

  • Implementing  the infrastructure enabling the application of the PSD2 scheme to the currency transaction in the EU/EEA area, and to the one leg transactions.
  • Ensuring that they can respond to requests for payment initiation and account information from authorized and registered TPPs (third party providers), who have received the explicit consent of their customer for to this. They will have to develop interfaces that enable third party developers to build applications and services around a bank. Internal banking IT systems might need to be able to cope with huge volumes of requests for information and transactions, more than they were originally designed for.
  • Ensuring their security meets the requirements of the SCA (strong customer authentication). This will be a big challenge both for the banks and for the other payment service providers).

PSD2 will make significant demands on the IT infrastructures of banks. On the one hand the IT infrastructure has to be able to be interact with applications developed by the TPPs (PISP and AISP). On the other hand, banks have to develop their systems in such a way that they don’t have to do this from scratch every time a TPP approaches them. This will require a very flexible IT architecture. The banks have to have a middleware that can be used by their internal systems, but also by the applications of the PSP’s.

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 third party 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 real challenge is to create standards for the APIs specifying the  nomenclature, access protocols and 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. The EBA (European Banking Authority) will develop RTS (Regulatory Technical Standard) with more detailed requirements regarding the interface between ASPSPs and TPPs. While these are expected to be published early 2017, based on the EBA’s recent draft RTS, the question is whether they will define the interface’s technical specifications.

Emergence of new players and business models

By integrating the role of new third party payment service providers (TPPs) such as the PISP and the AISP, the PSD2 creates a level playing field in the market. Several market experts expect that this will foster innovation and creating new services. For this reason PSD2 should increase competition.

This might lead to a unique open race between traditional players, such as the banks and newcomers for new services and a possible disintermediation of banking services, as illustrated in the figure down below:

Source: Catalyst or threat? The strategic implications of PSD2 for Europe’s banks, by Jörg Sandrock, Alexandra Firnges – http://www.strategyand.pwc.com/reports/catalyst-or-threat

PSD2 is likely to give a boost to the ongoing innovation boom and bring customers more user-friendly services through digital integration. One can expect that the automation, efficiency and competition will also keep the service pricing reasonable. PSD2 will foster improved service offerings to all customer types, especially those operating in the e-commerce area for payment collection. It will enable a simpler management of accounts and transactions. New offerings may also provide deeper integration of ERP functions with financial services, including of their multibank account details under a single portal, and smart dashboards.

PSD2 also enables a simplified processing chain in which the card network can be  disintermediated. The payment can be initiated by the PISP directly from the customer’s bank account through an interface with the ASPSP. In  this scheme, all interchange fees and acquirer fees as well as all the fees received by the processor and card network could be avoided. The market expects that new PISPs will be able to replace partly the transactions of the classic card schemes. A large internet retailer could for example ask permission to the consumers permitting direct account access for payment. They could propose incentive to encourage customers do so. Once permission is granted then the third-parties could bypass existing card schemes and push payments directly to their own accounts.

On the reporting side, the AISP can aggregate consumer financial data and provide consumers with direct money management services. They can be used as multi-bank online electronic banking channel. One can easily imagine that these services will be able to disintermediate existing financial services providers to identify consumer requirements and directly offer them additional products, such as loans and mortgages.

The PSD2 is for banks a compliance subject, but also an opportunity to develop their next generation digital strategy. New TPPs can provide their innovative service offerings and agility to adopt new technologies, enabling to create winning payments propositions for the customer. In turn, traditional players like banks can bring their large customer bases, their reach and credibility. Banks have also broad and deep proven data handling and holding capabilities. This can create winning payments propositions for the customer, the bank and the TPP.

Banks will have to decide whether to merely stick to a compliance approach, or to leverage on the PSD2 to develop these new services. The second approach will require to leave behind the rigid legacy structures and to change their mindset to ensure  quicker adaption to the dynamic customer and market conditions. A first mover strategy can prove to be beneficial.  Consumers and businesses will be confronted with the increased complexity linked to the multitude of disparate offerings. There also, the incumbent banks who will develop new services  can bring added value as trusted partners

Essentially, PSD2 drives down the barriers to entry for new competitors in the banking industry and gives new service providers the potential to attack the banks and disintermediate in one of their primary customer contact points. New players backed by strong investors are ready to give incumbents a serious run for their business. This is an important battle that the incumbent banks are not willing to lose.

The biggest potential benefits will be for the customers, who can access new value propositions, services and solutions that result from banks and new entrants combining their individual strengths or from banks becoming more innovative in the face of increased competition. Market experts also foresee an increased use of online shopping and e-procurement.

Several challenges to overcome

The PSD2 will be transposed in the national legal system of all the member countries. The involved market participants will have to examine the local legislation of their country of incorporation, as there might be some country-based deviations.

The authentication procedure is also an important hot topic. PISPs and AISPs can rely on the authentication procedures provided by the ASPSP (e.g. the banks)  to the customer but there are customer protection rules in place. Hence, they must ensure that the personalized security credentials are not shared with other parties. They also may not store sensitive payment data, and they are obliged to identify themselves to the ASPSP each time a payment is initiated or data is exchanged.

ASPSPs are required according to PS2 to treat payment orders and data requests transmitted via a PISP or AISP “without any discrimination other than for objective reasons”. A practical consequence for credit institutions will be that they must carry out risk assessments prior to granting payment institutions access – taking into account settlement risk, operational risk and business risk. One of  the main issue is the handling of the customer’s bank credentials by third party payment service providers. The bank needs to be able to perform strong authentication to ensure that the authorized account user is behind the initiation message

There are concerns about security aspects related to PSD2. An example hereof is the secure authentication. All the PSPs will have to ensure that they can demonstrate compliance with the new security requirements. How it will be achieved and monitored ? How will TPPs  interact with banks, since there is no need for a contract to be signed?

If something does not work correctly, there will also be discussions on the liability side. The PSD2 states that the TPP has to reimburse customers quickly enough that they are not bearing undue risk, but one will have to determine which TPP had the problem and work with them to resolve it. This will require further clarifications from the regulators.

In addition the PISP and the AISP vulnerable for to potential frauds. Web and mobile applications could become easy target for cybercriminals for various reasons, including the inherent vulnerabilities in the APIs that transfer data and communicate with back-end systems. The openness of the web could allow hackers to view source code and data and learn how to attack it. APIs have been compromised in several high-profile attacks that have caused significant losses and embarrassment for well-known players and their customers. The PSD2’s ‘access to account’  increases not only the number of APIs, but adds layers of complexity to the online banking/payments environment, adding to the risk of fraudulent attacks.

The market is waiting for the RTS (Regulatory Technical Standards) to give guidance on how some remaining security issues will be solved. These include:

  • Treatment of PSU’s (payment service user)security credentials
  • Requirements for secure communication between the PSP and banks
  • Full details and definition of strong authentication
  • Safety of the PSU funds and personal data
  • Availability of license registry for real-time identification of the PSP (PISP or AISP)

It is important that the required clarifications are published soon, in order to avoid a time lag between the implementation of PSD 2 in the national legislations and the real move in the market.

Conclusion

The PSD2 creates challenges, such as the huge investments to be made by the banks, compliance issues and protection against fraud and cybercrime. However several topics need to be clarified such as the RTS and the market players need also to agree on common standards for the interfaces. The clock is ticking in the PSD race.

Traditional players such as the banks appear to have a competitive disadvantage vis-à-vis the new emerging third party payment service providers. However, the Directive opens up new forms of a collaborative approach that can overcome this. New players can provide their innovation and resilience, whilst banks can add value thanks to their large customer base, credibility, reach and ability to cope with high volumes.

The biggest potential benefits might be for customers, who will benefit from new value propositions, services and solutions from new entrants, from banks and new entrants combining their individual strengths, or from banks becoming more innovative in the face of increased and agile competition.

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=””]

Best read articles of all time – PSD 2: a lot of opportunities but also big challenges (Part I)

| 15-05-2018 | François de Witte |

The Directive 2015/2366 on payment services in the internal market (hereinafter PSD2) was adopted by the European Parliament on October 8, 2015, and by the European Union (EU) Council of Ministers on November 16, 2015. The PSD2 updates the first EU Payment Services Directive published in 2007 (PSD1), which laid the legal foundation for the creation of an EU-wide single market for payments. PSD2 came into force on January 13, 2016, and is applicable from January 13, 2018 onwards. By that date the member states must have adopted and published the measures necessary to implement it into their national law.

PSD 2

PSD2 will cause important changes in the market and requires a thorough preparation. In this article, we are summarizing the measures and highlighting the impact on the market participants. In today’s Part I we will focus on abbreviations and main measurers introduced by PSD2.

List of abbreviations used in this article

2FA    : Two-factor authentication

AISP  :  Account Information Service Provider

API : Application Programming Interface

ASPSP : Account Servicing Payment Service Provider

EBA :  European Banking Authority

EBF :  European Banking Federation

EEA :  European Economic Area

PISP :  Payment Initiation Service Provider

PSD1:  Payment Services Directive 2007/64/EC

PSD2  :  Revised Payment Services Directive (EU) 2015/2366

PSP : Payment Service Provider

PSU:   Payment Service User

RTS : Regulatory Technical Standards (to be issued by the EBA)

SCA : Strong Customer Authentication

TPP :  Third Party Provider

Main Measures introduced by PSD2:

The  PSD2 expands the reach of PSD1, to the following payments:

  • Payments in all currencies (beyond EU/EEA), provided that the two PSP (Payment Service Provider) are located in the EU /EEA (two legs)
  • Payments where at least one PSP (and not both anymore)  is located within EU borders for the part of the payment transaction carried out in the EU/EEA (one leg transactions)

A second important measure is the creation of the Third Party Providers (TPP). One of the main aims of the PSD2 is to encourage new players to enter the payment market and to provide their services to the PSU (Payment Service Users). To this end, it creates the obligation for the ASPSP (Account Servicing Payment Service Provider – mainly the banks) to “open up the bank account” to external parties, the so-called, third-party account access. These TPP (Third Party Providers) are divided in two types:

·        AISP (Account Information Service Provider) : In order to be authorized, an AISP is required to hold professional indemnity insurance and be registered by their member state and by the EBA. There is no requirement for any initial capital or own funds. The EBA (European Banking Authority) will publish guidelines on conditions to be included in the indemnity insurance (e.g. the minimum sum to be insured), although it is as yet unknown what further conditions insurers will impose.

·        PISP (Payment Initiation Service Providers): PISPs are players that can initiate payment transactions. This is an important change, as currently there are not many payment options that can take money from one’s account and send them elsewhere. The minimum requirements for authorization as a PISP are significantly higher. In addition to being registered, a PISP must also be licensed by the competent authority, and it must have an initial and on-going minimum capital of EUR 50,000.

Banks will have to implement interfaces, so they can interact with the AISPs and PISPs. However, payment initiation service providers will only be able to receive information from the payer’s bank on the availability of the funds on the account which results in a simple yes or no answer before initiating the payment, with the explicit consent of the payer. Account information service providers will only receive the information explicitly consented by the payer and only to the extent the information is necessary for the service provided to the payer. This compliance with PSD2 is mandatory and all banks will have to make changes to their infrastructure deployments.

A third important change is the obligation for the Payment Service Providers to place the SCA (Strong Customer Authentication) for electronic payment transactions based in at least 2 different sources (2FA: Two-factor authentication) :

  • Something which only the client knows (e.g. password)
  • A device (e.g. card reader, authentication code generating device, token)
  • Inherence (e.g. fingerprint or voice recognition)

 

The EBA (European Banking Authority will provide further guidance on this notion in a later stage. It remains to be seen whether the current bank card with pin code is sufficient to qualify as “strong customer authentication”. This “strong customer authentication” needs to take place with every payment transaction. EBA will also be able to provide exemptions based on the risk/amount/recurrence/payment channel involved in the payment service (e.g. for paying the toll on the motorway or the parking).

PSD2 also introduces some other measures:

  • Retailers will be authorized to ask to the consumers for permission to use their contact details, so as to receive the payment directly from the bank without intermediaries
  • There will be a ban on surcharges on card payments
  • There will be new limitations on the customer liability for unauthorized payment transactions

In a second article soon to be published on treasuryXL, François de Witte will focus on the impact PSD2 has on market participants. 

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=””]

 

Universwiftnet Paris – March 2018

| 30-04-2018 | François de Witte |

On 13/3/2018, I attended the 15th Universwiftnet Paris event, a one-day conference day to discover the recent tendencies in payments, banking connectivity and the relationship between corporates and banks. There were over 1.000 participants, and this was a good opportunity to have an immersion in the latest tendencies in treasury. Down below, you will find some hot topics and takeaways,

KYC (Know Your Customer)

KYC remains high on the attention of banks. There is a new initiative of the KYC – SWIFT registry, which aims to provide an efficient, shared platform for managing and exchanging standardized Know Your Customer (KYC) data. SWIFT has worked with the world’s largest correspondent banks to define a set of data and documentation that addresses KYC requirements across multiple jurisdictions.

SWIFT takes on the task of validating the information and keeping it up to date. That means banks are relieved of this task, while remaining sure that their data is reliable and up to date. The KYC registry also offers a useful set of tools to simplify and enhance risk management procedures. This includes a KYC Advanced Notifications feature that can trigger alerts, if the profile of one of their counterparties changes.

Institutions can upload completely free documentation to the Registry and share it with the institutions you select. SWIFT validates the data rigorously, informs the counterparty if it is incomplete or needs updating, and alerts your correspondents whenever your data changes. The KYC Registry is currently only open for banks, but it this would be opened to corporates to corporates this year, enabling them to deposit documents there. This is welcomed development.

eBAM – management of the bank mandates

eBAM is the SWIFT initiative aiming at rationalizing the bank mandates. This provides standardized messages, which can be used between corporates and banks. BNP Paribas is already using this extensively, but other banks, like Sociét Générale, Citibank and Natixis are also joining the initiative. The further extension of eBAM to other banks would enable to rationalize an area, which remains a pain point for many corporates. One of the projects is to enable to sign digitally bank agreements.

Fraud & cybersecurity

Fraud & cybersecurity also remain high on the agenda. According to a study of Euler Hermes, 80 %, of the corporates have at least experience & fraud attempts, and 25 % over 10 fraud attempts. According to a study of the EU, 80 % of the European corporates have been victim of cyberattacks.

Corporates need to invest in the risk assessment, the browser & app protection, onboarding and password management. The challenge is to payments as frictionless as possible, in a context of increasing authentication cost.

It is important to embed this in processes, which should include whenever possible measures enabling to prevent:

  • Internal fraud: through the secure import of the files and other internal fraud prevention measures (black and white list of beneficiaries, limits on the amounts, banks and countries, check on abnormal transactions, verification of the account of the beneficiaries, etc.)
  • External fraud: through a secure digital signature (multifactor authentication using One time passwords, certificates, etc.) and a secure transfer of the payment files to the banks

PSD2, instant payments and open banking

We are moving to a paradigm whereby we need to combine:

  • The real time of the transaction
  • The request for user-friendly and frictionless payment initiation
  • The controlled opening of the payments landscape to third parties through PSD2
  • The protection of the PSU (Payment Service User) through PSD2 and GDPR

This will also create opportunities, both for the new players and the incumbent banks, who are prepared to develop an active open banking strategy. The retailers look at reducing the collecting costs of the card schemes and are looking at alternative more cost efficient collection methods. The SEPA Instant Payment Scheme could become in the future an interesting alternative.

New multibank solutions will come up. They will provide a more cost efficient technology using APIs. In a first stage, I expect that they will mainly extend to smaller corporates. Larger corporates might stick to the proven SWIFTNET or Host-to-Host solutions, due to the bank independency, the proven track record and the high integration with the existing processes.

There has been an interesting testimony of EDF, who is currently daily retrieving its bank statements through APIs. These are easier to implement, and have enabled a more efficient and quicker process. This new way of working also has a lower impact on the IT environment, identified as a bottleneck in the organization.

In fact, we are currently moving to a real time and digital treasury. This will require new profiles, such as IT developers and AI specialists for the operational tasks and the dash boarding.

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=””]

 

 

Cash Pooling – where is the money

| 01-02-2018 | François de Witte |

The main objectives of the cash & liquidity management are to:

  • Have the cash funds available to meet all known and unknown commitments
    • In the right currency
    • In the right place
    • At the right time
  • Optimize the return of the cash and/or minimize the cost of the short term financing
  • Minimize external financing by using internal funding

One of the most important techniques to achieve a better utilization of the available cash is the “cash pooling” or, in other words, the concentration of the cash to make it centrally available. The commonly used techniques in the market are the following:

  • Manual cash concentration: Intercompany payments
  • Automated Cash Concentration: requires physical movement of funds
  • Notional Pooling: without movement of funds

In the present article, we will outline the current types of cash management tools, their advantages and the attention points.

Manual cash concentration: Intercompany payments

For companies, who have only a limited number of accounts to overview, it is recommended to set up a manual cash pooling. In this case, the treasurer overviews daily or weekly the balances of the different accounts, and when there are important debit or credit positions, he will initiate manual payments to balance the positions, and or to concentrate them on the central treasury account. If during the day, important movements take place, the treasurer can make some additional intra-company payments to balance the debit and credit positions. In order to avoid float, it is recommended to use the urgent payments clearing.

The main advantages of the manual cash balancing are the following:

  • The easy set up
  • The possibility take into account the cash forecasting
  • You do not always make daily movements, which facilitates the intercompany loan administration.

However there are some drawbacks / attention points:

  • There is a daily / weekly need to make manual interventions. However some treasury software packages provide a solution to automate this process (bank independent cash pooling)
  • The banks take additional charges for use of the urgent payments clearing, except if the payments are processed within the same bank
  • The overdraft credit lines of the participants are qualified as full lending limits, and hence for the banks there is a higher capital weighting
  • When different legal entities are involved, you create a lending /borrowing relationship between the participants. Hence there are legal and tax issues:
    • You need to foresee a intra-group lending agreement
    • There are possibly withholding tax, transfer pricing and thin capitalization issues
    • Within your group, you need to manager the intercompany loan administration.

Automated cash concentration

The automated cash concentration, also called cash balancing, is a pooling technique requiring a physical transfer of funds to or from the participating accounts to concentrator account. The pooling movements are operated automatically by the bank

The most commonly used cash concentration is the zero balance cash balancing, as illustrated in the drawing down below. In this solution, the balances of the participants are daily or weekly swept to a concentrating account.

Figure 1: Outline of the zero balance cash balancing

Automated cash concentrationThere are also other forms of cash concentration:

  • Target cash balancing, to keep a specific amount in each account
  • Threshold cash balancing, to move funds only when an account moves in excess of a figure
  • Trigger cash balancing, whereby the movements are only initiated if the balance of an account (debit or credit) exceeds a certain amount
  • End-of-day or intraday cash balancing
  • Domestic or cross-border cash balancing.

There are several advantages to this system, such as:

  • There are no manual interventions, as the system is automated
  • Several features are possible (multi-layer, domestic and cross-border, target balancing, …)
  • There exist a possibility to integrate accounts from third banks
  • The system discipline to participants
  • With several banks, the intra-day lines, and the intra-day debit positions do not require a capital weighting.

However there are also drawbacks / attention points:

  • For value-based cash balancing, there can occur reconciliation issues with ERP systems or treasury management systems, as they usually work on accounting balances
  • The cash balancing works only within the same currency. When you manage different currencies, different physical cash balancing structures need to be set up for each currency
  • When different legal entities are involved, you create a lending /borrowing relationship between the participants – see also point 2 hereabove
  • The automated cash balancing can only work within the same currency (mono-currency).

Notional cash pooling

The Notional cash Pooling is a cash pooling where there is no movement of funds. In such a pooling the credit balances of the participants are offset against debit balances of the participants. Hence the net balance of the group is used to calculate the debit or credit interest paid or received.

The system has a flat structure, which means that all the participating Accounts are basically equal to each other. However usually corporates designate one account as the treasury Account, which is then used to manage the system.

Figure 2:  Outline of the notional cash pooling

Notional cash pooling

 

 

 

 

 

 

 

 

The main advantages of the notional pooling are the following:

  • The notional pooling does not require to move funds, and hence:
    • No intercompany loan administration
    • Less legal and tax issues
  • In some jurisdictions (e.g. the UK and NL) the notional pooling can, under certain conditions improve the balance sheet by offsetting surplus balances against group debt
  • The notional pooling can include different currencies.

However there are also attention points:

  • The full legal offset of debit and credit positions of different legal entities is an issue in several countries
  • In some countries notional pooling is not allowed
  • Basel III does not always allow that liquidity ratios are calculated by means of netting the outstanding balances of accounts in the notional pool. This means that banks must calculate their ratios based on the gross balances of the individual accounts. Hence they will also look to translate this cost in the pricing of the notional cash pooling.

Legal and tax aspects of cash pooling

Setting up a pooling requires some preparation, and some legal and tax issues need to be addressed, such as:

  • Is automated cash pooling (cash balancing or notional) authorized ?
  • For cash balancing with different entities
    • Transfer pricing issues – Arm’s length rule
    • Is debit interest an allowable deduction?
    • Withholding tax issues
    • Is thin capitalization an issue?

When setting up such structures, in particular when different countries are involved, you need to foresee a due diligence with legal/tax advisors and banks

For cash balancing with different legal entities, a requirement is also to be able to manage intercompany loan administration. There are banks and providers who come up with solutions in this area.

 

François de Witte

Founder & Senior Consultant at FDW Consult and Senior Expert – Product, Business development and sales manager at Isabel Group

 

Update Fintech Belgium Summit 2017

| 29-12-2017 | François de Witte |

On 14/12/2017, Fintech Belgium organized the 2nd Fintech Belgium Summit, a one-day conference to discover the deep innovation, technological and societal impact FinTechs have on our world.  There were over 500 participants, and this was a good opportunity to meet all the stakeholders in the Belgian Fintech ecosystem.

Main messages gathered from the workshops

The first stream has been focusing on the regulatory side. PSD2 and GDPR will have in 2018 a high impact on the market. There has been a request to better harmonize the legislation in this areas. Even in the PSD2 domain, the latest version of the RTS on SCA and Secure Communication still contains some blind spots. Another recommendation is that the authorities would set up a competence center to assist the FinTechs in the myriad of the regulatory framework.

The 2nd stream has been focusing on the innovation impact: How has the financial industry reacted to innovation? Make, Buy, Join or Break…. One of the main issues encountered by the banks is that the profiles of their people are not adapted to the innovation, and hence large HR and educational efforts will be required. Banks will have to adopt flat and member centric organizations to become more agile and data driven.

The testimony of Resolut clearly demonstrated the power of new entrants in the arena, enabling companies to drastically reduce the cost to access banks. However, some banks start also interesting initiatives in this area, with forefront runners such as BBVA, Nordea, Deutsche Bank, Hello Bank, ING (ylot) and Fidor.

In the afternoon, there was an interesting workshop on open banking with BNP Paribas Fortis, Baker McKenzie and Ibanity focusing on the new ecosystem, where some banks will position themselves as API Producers, focusing on their unique value propositions, whilst some others will position themselves as API consumers, offering aggregated services and acting as “matchmakers”. Marc Lainez, CEO of Ibanity, mentioned that FinTechs are not a threat to banks. The real competition for the banks are the GAFA. Hence  Banks and Fintechs need need to work hand in hand together to develop new solutions.

The conference finished with a stream dedicated to the technological impact. Blockchain and cryptocurrencies were high on the agenda. There was a clear consensus that Blockchain technology will be leading, also for Regulators. A lot of use cases were mentioned, e.g. in the area of trade finance and the document handling. Regulation will be key to further increase the adoption of this new technology. On the ICO (Initial Coin Offering) the opinions were more mixed, as there are quite some challenges to overcome, such as the setup of supervisory controlling institutions and the volatility of the cryptocurrencies.

Conclusion

This conference was a good forum to get an insight in the Belgian FinTech market. I saw a lot of interesting initiatives, and am a strongly believer of the increased cooperation between banks and FinTechs, the so-called Fin-Integration. 2018 will be challenging for all of them.

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=””]

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=””]

How to connect to your bank electronically

| 26-10-2017 | François de Witte |

One of the main challenges in treasury is ensuring the connectivity with your banking partners. Currently corporates use the e-banking, or “electronic banking” channels. ‘Electronic banking’ can be defined as the way in which a company can transmit transactions and obtain reporting instructions to a bank remotely and electronically.

In the present article about bank connectivity, we will outline the current types of e-banking channels in the market, their advantages and the attention points.

Interactive banking channels

For interactive e-banking channels, typically the communication is initiated by the corporate client from a PC within the finance department and the instructions are transmitted to the bank through the internet.

Banks are developing their portals more and more: ING Business Payment, Connexis, KBC-Online, IT Line, RABO Corporate Connect, etc. They also provide a full range of services through them.

Illustration of the interactive electronic banking channel:

 

 

 

 

 

 

 

Currently the interactive- banking channels are widely used by corporates and other organizations, because they are easy to implement, user-friendly, enable to work on a standalone basis and less expensive. However, the drawbacks are that they are not always that suited for mass payments, and that each bank has its own system. Consequently, if you work with different banks, you will have different electronic banking channels for each bank, which adds to the complexity.

In some countries, the banks have put their efforts together to create a multibank interactive electronic banking channels (e.g. Isabel 6 in Belgium and Multiline in Luxembourg).

In my view, the interactive e-banking channel is best suited for corporates having not too high volumes of transactions and working with only few banks, or in countries were multibank electronic banking channels are available.

Host to host electronic banking channels

Some corporates or public institutions have very high volumes to treat, and will need for this a specific direct connection with their bank, a so-called “host to host” (H2H) connection. This is an automated solution for high volume data transfer between banks and their corporate clients.

Sophisticated H2H connectivity solutions give banks the flexibility to exchange information with their corporate clients in preferred file formats, agreeing on network protocols, and security standards.

The following figure illustrates this type of e-channel:

 

 

 

 

 

 

 

H2H e-banking channels allows for automated payments and collections, attended (where the client needs to take an action) or unattended (directly initiated by the IT system) connection / authorization. They can treat very high volumes, and to integrate the data into ERP systems.

However, they are also more expensive, because they require a specific IT set-up and usually the services of a middleware provider to ensure the connectivity between your ERP or IT system and the bank.

Up to some years ago, corporates had to set up H2H connections with each of their banks, but now several multibank H2H solutions have been developed by the TMS (Treasury Management Systems) providers or by other multibank providers such as TIS, MultiCash and Power2Pay.

In some countries, the banks have set up common interbank protocols enabling an easier and standardized connection. The best know is EBICS, which is currently in use in Germany and France.

In my view, the host to host banking e-channel is best suited for corporates having very large volumes of transactions and requiring a high level of integration with their ERP or IT systems.

SWIFT e-banking

SWIFT has extended from a bank-to-bank platform to a corporate-to-bank platform, and has also launched its own bank connectivity solution, SCORE (Standardized Corporate Environment). SWIFT enables hence to replace the various e-banking systems with a single, bank-neutral multibank e-channel. This means that treasurers and finance managers can connect with their banks worldwide in a consistent way using industry-recognized standards.

Outline of a SWIFTNET Multibank set-up (source SWIFT):

Companies can connect to SWIFT in many ways. One option is to establish a direct connection to SWIFT, but this can be a technically complex exercise. As a result, many of the companies connecting to SWIFT do so via a SWIFT service bureau. In such a set-up, most of the technical challenges are resolved by the service bureau

The third SWIFT connectivity option is Alliance Lite2. This solution enables corporates to connect to SWIFT in a quicker and less expensive way.

The SWIFT channel offers, beside the multibank character, many other advantages, such as the SWIFT standards, services beyond payments, such as FX and deposit confirmation and securities transactions, and an improved security / reliability compared to the classic e-banking systems

However, the Swift e-banking solution is not easy to implement, and can be quite expensive (in particular for the direct connection and the connection through a service bureau. Hence this solution is more suite for very large corporates and institutions, working with many banks.

Conclusion:

When looking at setting up the e-banking connectivity, several factors need to be taken into consideration, such as the number of banks and transactions, the complexity of the organization and the treasury. Smaller organization can perfectly work with the interactive e-banking channels, whilst larger and more complex organizations need to consider the multibank H2H connections or a SWIFT setup.

In the framework of PSD2, with the XS2A (access to accounts), banks in the EU/EEA will have to provide access to authorized third parties. I expect that thanks to PSD2 the cost of multibank e-banking platforms will go down, which is good news for corporates.

 

François de Witte

Founder & Senior Consultant at FDW Consult

World Payments Report 2017

| 21-9-2017 | François de Witte |

Each year, during the summer, Cap Gemini publishes with BNP Paribas the World Payments Report, aiming at providing a preview of the global payments landscape. In the following I present you a short summary with what I consider the main findings. If you want to access the full report please click on this link.      

Introduction

2017 is a quite exciting year, with new regulatory initiatives having a big impact on the payments industry. In the EU, the most important one being PSD2, which  opens the market to new players (third party providers), and which needs to be transposed on the national legislation of the EU member states by 13/1/2018. We also have the AML Directive, which had to be transposed in the legislation of the different member states and the GDPR Directive which needs to be transposed by  6/5/2018. The report is giving attention to these new developments, in particular the ones linked to PSD2.

Main findings

The World Payments Report reported that global non cash transaction volumes grew 11.2% during 2014-15 to reach 433.1 billion transactions, the highest growth of the past decade, and slightly above last year’s prediction. Overall global non cash transaction volumes are expected to continue to grow, due to the rising adoption of these payment instruments, the growing inclusion, the increasing financial literacy and the enhance payments infrastructure, in particular ion the developing markets.

Source: World Payments Report 2017, page 6

 

When looking at the breakdown of the non-cash transaction (see following chart), we see some interesting trends:

Source: World Payments Report 2017, page 11

Debit cards and credit transfers were the leading digital instruments in 2015, while the check usage continues to decline globally.
Despite the increased adoption of digital payments, cash continues to keep an important role, in particular for low value transactions. Key factors contributing to the persistency of cash include the anonymity associated with cash transactions, lack of a modern payments infrastructure, and limited or no access to the banking system in developing markets. However in some countries (e.g. Scandinavia), the usage of cash was reduced drastically.

When looking at Europe, during the coming years credit card transaction volumes are expected to be affected by the interchange fee cap in Europe and by the less proactive policy of banks in this respect.

Conclusion

The ongoing increase of the non-cash transactions and the reduction of the checks is encouraging. We move towards more efficient payment instruments. The next years will bring new challenging new regulatory and industry initiatives, which will have to be implemented by the banks. This will require huge investments, and in my view, some more regulatory coordination will be needed.

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=””]

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=””]