A call to pragmatic action
In April 2013, the Basel Committee on Banking Supervision (BCBS), in consultation with the Committee on Payment and Settlement Systems (CPSS) published the Intraday Liquidity Monitoring Tools.
This provided a set of quantitative tools to enable banking supervisors to monitor banks’ intraday liquidity risk and their ability to meet payment and settlement obligations on a timely basis under both normal and stressed conditions. The tools require implementation of four stress scenarios (own, counterparty, customer and market stress) and monthly retrospective reporting on seven intraday liquidity measures. Each firm will report both globally and at the level of each legal entity, for all accounts and currencies where they act as a self-clearer, nostro user or vostro provider.
The official start date for BCBS reporting is set for January 2015. National supervisors are given the authority to extend the implementation timeline until January 2017 (especially for the tools related to the nostro accounts).
Swift has been running individual in-depth data assessments with financial institutions to evaluate the types of data gaps for their implementation of the BCBS tools, to quantify those gaps and to examine the best ways of closing them. These individual assessments consistently highlight the issues identified by Swift’s analyses at aggregated and global levels.
The tools bring three types of data challenges: the availability of timed data, the current lack of data centralisation and the appropriate level of aggregation required by the reports. Challenges differ according to the bank’s size and profile: whether the bank is exclusively dependent on its correspondents, or whether it is a self-clearer for its top currencies and as such provides correspondent banking services to other financial institutions.
The BCBS tools do not require real-time management of liquidity positions, but rather the availability of timed information on all individual liquidity entries. Banks need to track their position for each account on a real-time basis to build the retrospective monthly aggregated measures required for BCBS reporting (ie, top largest positive and negative net cumulative positions).
A crucial condition for the production of accurate monthly reporting is the delivery of a debit/credit confirmation by either the account servicing institution or the payments settlement system for each movement on the account.
Analyses of nostro reporting flows on Swift demonstrate that a large number of banks confirm only a very small proportion of their debit/credit entries in a timely manner. Certain types of transactions such as book transfers are not covered at all. Institutional operations remain in silos. Many liquidity applications have not yet integrated information related to securities intraday settlement confirmations (ie, delivery versus payment confirmations) managed by securities settlement applications. To date, Swift estimates that only 20 per cent of correspondent banking payments instructions exchanged on the Swift network are confirmed with an intraday confirmation message. In value however, the coverage reaches 55 per cent at global level (according to Swift Watch). Smaller institutions with fewer account relationships should be easier to service as they manage fewer accounts and data sources. A number of specific service providers are developing new reports with ready-made BCBS measures for the specific accounts they are holding for customers.
Global clearing banks, being direct participants to the RTGS system for their key currencies, should in principle be less affected by the challenge of providing timed data. However, not all payment settlement systems provide a real-time systematic debit and credit confirmation. Many of these infrastructures are revisiting their reporting methods, as they move to comply with the CPSS-Iosco rules for efficiency and operational excellence.
The time at which the debit/credit entry is posted on the account also should be reported by the servicing institutions. At present, this is not the case. Providing this information would effectively require a change both in the message standard and in the servicing institution’s legacy system; this is being assessed by the Swift community.
Beyond BCBS reporting, in countries such as the UK and the Netherlands where banks have to manage their liquidity positions in real-time, automation of margin call processes is necessary to obtain an accurate view of collateral positions and unencumbered assets. As central counterparty clearing is an evolving area in terms of regulation, the adoption of a common standard and practice across numerous systems will be essential to streamline clearing members’ real-time views of positions.
Many larger institutions have not yet centralised the management of their nostro accounts. Legal entities around the world may use different payment hubs to send their instructions and receive confirmation messages from their nostro service providers. Treasury systems have in most cases not been integrated across currencies and the internal clearing entity does not always provide timed information required for reporting at a central level. Finally, it is quite common that entities do not use their internal clearing entity for all their movements. Specifically for the USD, local offshore clearing services offered in several Asian countries are used. This will not only lead to higher liquidity costs and potential credit risk, but it will also make it more difficult for the group treasury to report centrally on their consolidated USD intraday positions.
All these issues can result in a large share of a group’s intraday liquidity flows not being visible at the central headquarters level. Calculations for specific firms based on Swift correspondent banking data show this share can reach up to 20 per cent.
Service providers will also have to report on their customers’ credit line usage at a global level. This type of data is typically managed by each country locally. Therefore, providing an aggregated view for a customer using clearing services for multiple currencies in different locations is very challenging.
Reporting on customers’ global credit line usage requires standardised and centralised data collection at global level and identification of legal entities, through their legal entity identifier (LEI), and matching with their related operational codes. The European Banking Authority has recently issued an official recommendation for the use of LEI for financial reporting, to ensure uniform reporting requirements across all EU member states, as mandated by the Capital Requirements Regulation.
A pragmatic approach
Because of the very short implementation timeframe and the strain on IT and business resources in many institutions, it is important for banks to adopt a pragmatic approach, reusing their existing data infrastructures and allowing for a consistent global approach. This should help avoid duplication of work at the entity level.
Beyond the cost of not being compliant in time, banks should look at their overall liquidity strategy and at the substantial financial benefits which can be derived from implementing real-time liquidity management. As well as lower credit line usage and lower funding costs, financial institutions will increase their trading capability and reduce the costs related to late identification of exceptions, all of which should help reduce the size of their liquidity buffer.
However, implementing real-time liquidity management is not required by the BCBS tools. Banks risk being trapped in a lengthy project and failing to achieve the mandatory short-term deliverables if they try to achieve both goals at the same time.
There is uncertainty around the exact currencies that national regulators will expect the monitoring and reporting to cover when they implement the BCBS tools: will the reporting obligation extend to all currencies or only to key currencies representing at least 5 per cent of the liquidity value at group level? Considering the short timeframe, national regulators may agree to phase in implementation, starting with the top currencies. Some regulators may take a stricter approach; the UK’s experience has demonstrated that the threshold for bank reporting may be below 5 per cent.
This suggests the need to define a global data collection model with common aggregation rules and to build a central transaction database within each institution. This would avoid multiplication of different implementations across different entities of a group. It would ensure reporting consistency at global and local levels and would reduce costs. Currency-related implementation should be phased in, starting with the largest currencies.
Banks will typically have two main questions with respect to data sourcing: which data do I need to produce to meet the requirements of the BCBS measures, and from where do I source it in the most efficient way? Many institutions are still managing intraday positions based on their internal forecasts. For the BCBS measures, a real-time confirmation of each individual credit/debit entry will be critical to track the position of each account and to build the granularity required for each monthly report. These confirmations should ideally be sent by the servicing institutions for all types of cash movements including book transfers, payment versus payment and securities settlement movements, using the specific standard message type. At the end of the day, banks will match their calculated positions with the closing balance reported by their service providers.
Importantly, the interim transaction report (MT 942) will not adequately serve the liquidity function. It has been designed to support treasury reconciliation as it provides extensive information on the underlying transaction at the origin of the movement. It can however not be used by the account owner to calculate his position on a ‘minute by minute’ basis as it is typically not sent in real time and reported transactions are batched under the same time stamp. Net position calculations at specific times of the day will therefore not represent reality as all debit and credit entries will be aggregated.
Calculations made on some individual accounts using this message type demonstrated that the impact on the liquidity usage curve calculation can be substantial, especially if the frequency of the report is low and the amounts are high.
When sourcing the data from correspondent banks and settlement agents, usually different channels will be available, including proprietary ones. In order to lower the integration costs and enable the user to aggregate data with other service providers’ reports, a provider should use standardised reporting formats. Users with a larger number of correspondents will also want to rationalise their communication channels.
The first step in the pragmatic approach should be an assessment of the bank’s current intraday liquidity flows for the top currencies. A bank should be examining the distribution of the intraday liquidity flows between its different entities and identify the top correspondents and overall reporting gaps at group level. In doing so they may also identify a lack of visibility for the group treasury for specific flows or the entities in the group using correspondent accounts instead of the internal clearing entities.
Due to its size, the nature of its business, its geographical reach, but also the efforts that have already been spent on intraday liquidity management, each bank will have a different ‘as is’ picture and will be able to compare against the currency benchmark, the country or a peer benchmark. The bank also will be looking for a consolidated view of the gap per key currency and correspondent at group level.
The bank will then run a more in-depth data gap analysis for a representative number of accounts. The aim is to measure current reporting coverage in value and volumes of all inflows and outflows, and identify the types of transactions not reported on an intraday basis, or the data not yet integrated internally. This will help the bank determine the project’s priorities and next steps very precisely.
Undertaking a data assessment exercise will provide banks with the detailed requirements for their key service providers. The view on volumes at group level cleared through each of these correspondents should also help them in defining commercial terms.
Over the past year, many banks have initiated an official RFP process or have contacted their existing correspondents with a list of new requirements to fill their data gaps. Risk departments have played a role in this as they are now involved in the intraday space and better understand the importance of these confirmations to reduce the risk in case of the default of one of their servicing institutions. The debtor remains liable for the payment until the debit on its account has been confirmed by its account servicing institution.
As a result, the usage of intraday liquidity reports exchanged on Swift between correspondents has increased by 14 per cent in volume and 16 per cent in value between Q1 2013 and Q1 2014. In the same period, the overall coverage of reporting in value terms has increased by 4 per cent to reach 55 per cent of the payments on Swift.
However, there are differences at an individual level between financial institutions and at the community level between currencies and countries. The largest growth of intraday reporting is in the Swiss franc (29 per cent) followed by the Chinese renminbi (12), the euro (11) and sterling (11). Several currencies already demonstrate a much better coverage than the global average of 55 per cent: the Japanese yen (66 per cent), the Swiss franc (63) and the euro (58). Other frequently traded currencies, such as the American and Australian dollars (53), as well as the renminbi (29), are still below the average despite progress over the past year.
At a country level, the largest growth in value is reported in Portugal, where growth exceeding 100 per cent is due to confirmations also being sent for non-Swift payments. Of the top ten largest growth countries in terms of value, nine are European and one is Asian.
Over recent years, banks have started rationalising their correspondent banking network. Combined with better internal integration, this will help resolve data centralisation issues. However, in most cases this will prove very time and resource intensive.
In the short-term, other pragmatic and cost effective solutions might be envisaged. A messaging copy mechanism enables the group liquidity or treasury service to obtain the missing reporting flows. Depending on local regulation on data privacy, the copy may only contain part of the message data.
As a next step, the normalised data stored in a central transactional database will need to be aggregated according to the different requirements defined by both the home and the host regulators. The two highest keys for data aggregation will be the legal entity (ie, with BIC to LEI matching) and the currency, which will have to be performed for both users and providers.
The industry as a whole will benefit from a collaborative approach to increase the pace at which progress is being made to resolve intraday liquidity data issues. Standardised intraday liquidity data will enable banks to ensure consistency and to reduce overall implementation costs, for themselves and for the industry.
Financial institutions have a common interest in enhancing current business practice for intraday liquidity reporting. The intraday liquidity reporting rule book developed by the Liquidity Implementation Task Force (LITF) with the support of Swift, is aimed at creating and supporting the adoption of a common industry business practice for intraday liquidity messaging. It provides common usage guidelines for the FIN message types that are most used by the industry (FIN Cat 9, complemented with Cat 5 messages). The same principles could be easily applied to ISO 20022 messages. The rules are aimed at resolving the issues related to the lack of liquidity reporting coverage, the timing and content of reporting. Over the past year, an increasing number of institutions are using the LITF rule book as a reference when issuing an RFP for intraday liquidity services from nostro service providers.
Past experience with the implementation of similar regulation in specific countries also demonstrates the importance of extending the dialogue to market infrastructures in order to obtain the required level of intraday reporting.
The industry has started to debate whether the message business practice could be extended to a standardised data approach to produce key regulatory reports, such as the liquidity and credit lines usage curves. Swift, together with a group of banks and broker dealers, has documented a first ‘best practice’ on data extraction, data matching and data aggregation to populate the intraday liquidity transactional database based on the LITF intraday reporting practice. Using a common approach at this level should help ensure consistency between the different entities of a group, between the service providers and the service users and also help establish a constructive dialogue with regulators.
Intraday liquidity is a scarce and expensive resource and is charged for accordingly by service providers. New payments services such as timed payments may develop further, giving customers (both financial institutions and corporates), a more active role to play to optimise their payments schedule, select the adequate clearing and settlement channel and indicate the criticality of specific transactions where needed. Customers may also be increasingly requested to pre-notify of very large payments close to a system’s cut-off.
In this context, and as a result of the new regulations, intraday liquidity reporting is becoming an integral and more competitive part of the service provider’s product portfolio. Large clearing banks are already adapting and are starting to promote their capabilities. Examples include new services for smaller financial institutions, including ready to use BCBS reporting offerings. Service users may look for more tools to benchmark the available service offerings on the market.
Industry practice developed for intraday liquidity could be leveraged by service providers to lower the development costs and increase the benefits for their customers, especially for those using more than one account servicing institution.
A collaborative, shared service
Collaboration could go beyond business practices and extend to the development of a shared service, hosted for the industry. All intraday liquidity reporting could be stored in a data repository at the time it is sent out by the service provider. Data collection, parsing and extraction would be done according to standard defined rules. Development related to more complex items, such as aggregation of the data collected in different time zones or related to different currencies, could be commonly defined and used at the community level. Beyond the data, ready-made reports, including the calculation of the BCBS measures, as well as daily visual monitoring tools that would allow the participants to take any necessary corrective measures where needed, could be made available. Access would of course need to be fully secured. This model could represent a highly effective way to reduce overall industry implementation costs. The data gathered could also potentially be reused for other regulations and other purposes.
The new BCBS intraday reporting obligation places banks’ existing data models under great pressure. The BCBS intraday tools are one of a number of regulations which are aimed towards achieving greater transparency at the transactional level. Precise implementation of these frameworks will vary from one country to another and will evolve over time.
Practical implementation models will have a significant impact on the scale of overall costs for the industry. This is why banks should start adopting a pragmatic approach at individual level now, and contribute to industry-wide collaborative efforts to ensure cost effective and sustainable implementation models and solutions, to achieve the necessary longer term scalability and adaptability across market segments. DNS
*This is an edited extract from Swift’s white paper, Intraday liquidity reporting – The case for a pragmatic industry solution. The white paper is available at www.swift.com and on the Swift stand in the exhibition halls