Published on 12 January 2019

The EU’s second Payment Services Directive, with live date January 2018, has had as a main objective to foster the emergence of non-bank intermediaries called Third Party Providers or “TPPs”.

The purposes of a TPP’s offering would be to:

  1. Create a single view for the customer of the balances on payment accounts at whatever institution in the EU/EEA the accounts were held with, the institution being referred to as an Account Servicing Payment Service Provider or “ASPSP”;
  2. To enable payments in between these accounts to make maximum use of available cash without first recourse to borrowing, then to access the cheapest source of borrowing; and
  3. To make external payments without having to log into the proprietary eBanking system of each ASPSP.

The role of such TPPs is integral to the Open Banking environment desired by authorities at EU and UK level amongst others, the UK’s Open Banking initiative already being in production.

In passing this Directive, the European authorities wanted to ensure the security of communications between customers and the institutions serving them, be they TPPs or ASPSPs.

The task of defining the detail was referred to the European Banking Authority, who have issued their Regulatory Technical Standards on Strong Customer Authentication and Common and Secure Communication – to come into force in September 2019.

These standards require at least 2-dimensional security on all electronic payments as the benchmark of Strong Customer Authentication (“SCA”), and for that security process to be gone through again on the 6th payment if there have been 5 electronic payments since the last time SCA was applied. This is primarily aimed at contactless payments, where the card can be used in contact mode with CHIP+PIN, and it is the CHIP+PIN process that should be forced into operation after 5 successive payments have been made in contactless mode. SCA requires the amount of the specific payment to be known to which it is being applied.

These rules could backfire badly on the main service used by corporate customers when managing the balances on different accounts held at ASPSPs – Zero-Balancing, also known as sweeping.

Many types of operation are dubbed as sweeps by the institutions offering them, but the textbook definition is a “fully automated and computer-programmed operation to alter the balance on a ‘slave’ account at an ASPSP to zero and transfer that balance to the ‘master’ account”.

Because the balances to be moved are almost without exception the available balances, this figure must be known, and it can only be known after all of the debits and credits from the day’s operations have been posted to the respective accounts. That only happens after the first round of the ASPSP’s nightpass. The ‘master’ and ‘slave’ accounts can be at different ASPSPs if detailed arrangements are made between the ASPSPs to support a Zero-balancing experience as if the accounts were at the same ASPSP, and on the same computer.

This is not about so-called “multi-banking sweeps” that are triggered by the identification of an intraday balance on a ‘slave’ account thanks to a SWIFT MT941 or MT942, causing a SWIFT MT101 Request for Transfer to be sent to the ASPSP for that account, which then sends an MT103 Customer Payment to the ASPSP where the ‘master’ account is held.

The MT103 operation is then just a regular third-party payment, subject to cut-off times and charges, and can fail to reach its endpoint in a timely manner and without loss of value dates.

A Zero-Balancing is a self-contained operation that cannot go wrong in this way, although the UK Open Banking solution has already defied this, by offering a “sweep” option that does not have a ‘master’ account locked into the arrangement when the customer needs to borrow.

A Zero-Balancing can be configured to move just credit balances, or both credit and debit balances – the latter being subject to the respective ‘master’ account having either sufficient available funds in it or having an adequate lending line attached to it. The need for a lending line to be available is the minor detail that has not been assured in the Open Banking definition of Zero-balancing.

But the EBA’s Regulatory Technical Standards promise worse, namely to blow up all existing implementations of Zero-balancing. Zero-balancing moves the balance to zero, usually daily, and in the middle of the night. It is non-attended on the ASPSP and customer side and the amount is not known until shortly before it is carried out. Nevertheless, all possible outcomes are catered for, up to and including the failure to cover a debit balance on a ‘slave’ account due to insufficient funds/lending lines available on the ‘master’ account. This eventuality is dealt with by all credit balances first being swept up into the ‘master’ account, after which ‘slave’ accounts in debit are topped off in an order determined by the customer, with any residual deficit remaining on its ‘slave’ account at a penalty rate of interest.

It is also exceedingly common for the Zero-balancing carried out as the last function on D to be reversed, exactly in every detail, as the first function of D+1. This is called the “Cinderella” sweep.

In the course of a business week, there could be 5 payments off each ‘slave’ account to the ‘master’ account, under a set-up with and without the “Cinderella”:

  • Without “Cinderella”, a sweep out every night if the ‘slave’ account is in credit;
  • With “Cinderella”, a sweep out of the ‘slave’ account every morning to reverse the sweep in from the night before, if the ‘slave’ account had finished the day in debit.

Looking at the ‘master’ account and if it has 10 ‘slave’ accounts attached to it, it would just be by chance if there were not 5 payments out on any one day to top off debit balances on ‘slave’ accounts. If the “Cinderella” function was used, there would for sure be 10 payments out every day, either topping off debit balances, or returning credit balances previously swept in.

Under EBA rules the organisation running the Zero-balancing – be it a TPP or an ASPSP – should stop at the 6th payment and obtain Strong Customer Authentication before carrying on. This is totally impossible given the intention of the service and when/how it works.

There is an exemption where the slave and master accounts have the same owner, but this will be of limited value in the Cash Management business where the master account is commonly owned by the in-house Treasury company, and the slave accounts by the operational subsidiaries.

So the European authorities could kill two birds with one stone here:

  • Kill off a mainstream, successful and widely used Cash Management service; and
  • So inhibit the operation of a TPP and Open Banking as to preclude a TPP from having a workable business proposition for any type of end-user.

High-Fives all round then.

[First published by]