Abstract
The payments industry has undergone significant change in the past five years, driven by a major overhaul of the payments infrastructure in the UK[1], a flurry of pan-European legislative and regulatory changes[2] and the rapid growth in payments volumes[3].

One area of the industry, however, has failed to keep pace with these developments. Despite a number of initiatives, data analytics remains the weak link in the payments process. 

This article examines the reasons for this and highlights the difficulty of achieving a single synchronous view of payments data across an organisation. It concludes by reviewing Experian Payments Gateway Management Information, the first serious attempt to address the need for intelligent analysis of the payments data across the payments value chain.

Drivers for analytics 
The demand for payments analytics is a function of process complexity and payment volumes. Research suggests that within the average billion-dollar company there are 48 disparate financial systems and 2.7 ERP systems[4]. Of the information contained within these systems 85% of it is unstructured data, leading people to spend 30% of their time searching for relevant data.

In general, the more complex the payment process and/or the larger the number of payments processed, the greater the challenge faced by organisations wishing to adopt an holistic approach to understanding the performance of their payment processes.

The core drivers in favour of payments analytics are identical to many commercial business propositions. They include the need to:

1. drive efficiency in order to reduce rejections and therefore reduce costs
2. drive accuracy in order to mitigate risk
3. access high quality information in order to make more effective decisions about payment processes
4. ensure the traceability of actions and data in order to (a) meet audit and compliance requirements (eg Sarbanes-Oxley), and (b) reduce the opportunity for fraud
5. identify trends in payment processes over extended periods of time

At the root of each of these drivers is a desire to improve company performance by reducing costs, improving revenue streams, and customer service.

Specific examples of existing poor performance might include:

• high average transaction costs arising from high levels of rejected payments and the associated repair costs and charges
• inability to identify speedily the source of rejected payments
• customer dissatisfaction arising from failed payments
• inability to explain to customers why or when a payment failed
• lack of a common or consistent customer experience
• lack of transaction visibility internally
• the inability to answer business specific questions to internal customers (such as the inability to provide an analysis of payments by marketing channel)
• lack of internal invoicing (and therefore accountability) for the payments function

Current options
Organisations that wish to analyse their payments data are currently limited to three options:

(a)   rely upon the information available within existing Bacs reports

(b)   import data from multiple payments applications into a third party analytics tool and then build bespoke data warehouse views and custom reports

(c)   commission additional bespoke reports payment infrastructure provider 

Each approach has its limitations, either in terms of level of output detail available (a) or in terms of additional costs (b and c).

These options are considered below and are followed by an assessment of a further option: a new management information module for Experian Payments Gateway from Experian Payments.

Bacs reporting
Many organisations retain a narrow mindset with regard to payments reporting and the benefits of achieving a ‘single view’ of their payments processes.

For example, ARUDD[5] reports are still considered by some to be the beginning and end of payments reporting. ARUDD reports explain why Direct Debits or Direct Credits are rejected or unpaid. By analysing this data it is possible to understand why payments are being rejected, make whatever changes are required and improve the overall payment process.

However, ARUDD reports only cover a short period of time so, to understand the underlying trends, all ARUDD reports need to be analysed over an extended period. Aggregating these individual reports or merging ARUDD reports originating from multiple host systems is problematic.  Hence, it is not easy to gain a single view and the cost can appear prohibitive. In reality, organisations that restrict payment reporting to ARUDD reports rarely understand the performance of their payment processes.

Similarly, it should not be assumed that Bacs reports are automatically fed back into the originating payment applications to generate a single view.

Where report writing is an established in-house activity there is often insufficient attention paid to the true cost of report generation given the time involved. There may be issues regarding accuracy when reports are manually – as opposed to automatically - generated. There may also be issues relating to the time lapse generated through internal report writing. The usefulness of reports can decline rapidly as the time taken to generate them increases, distancing decision makers from the events to which the report relates.

Calculating the true cost of any individual approach to payments analytics is clearly problematic. A small percentage rejection in failed payments has a significant impact on the bottom line because the cost of failed payments is so high. With the cost to a business of a failed payment typically running between £20 and £40, addressing the issue of poor payments reporting can be justified on cost grounds even where the proportion of failed payments seems low.

Bacstel-IP promised to automate the process of creating, processing and analysing electronic reports.  However, many companies have not made best use of the data available due to the cost and complexity of creating reports to interpret it. To many users the promise of electronic reports implicitly offered the promise of easy data analysis. The reality is that, although the reports are available electronically, they are still difficult to manage in terms of being able to analyse the data properly. This is because each individual report only covers a short period of time and is only specific to certain Service User Numbers. To identify trends there is additional level of analysis processing required which, for many companies, would be too costly and complex to justify.

Third party solution
Given the penetration of the corporate market by third party business intelligence (BI) and analytics tools such as Business Objects and Cognos, many organisations will understandably consider the bespoke route to payment analytics.

These tools have their advantages subject to the availability of in-house skills to create and manage the data analysis and report generation processes. Advantages include design GUIs that speed report writing, report scheduling, format options and distribution flexibility.

The inherent weakness of these off-the-shelf BI tools relates not to their reporting capabilities, which are significant, but to the ease with which they can be integrated into complex payment processes (see diagram below).

To generate a single report from multiple hosts systems requires the complex matching of data across different reports. This is made more complex given the different data parameters of different host systems. The process of integration is achieved through the extraction of data into a separate data repository or data warehouse. This ensures that source data is protected and the performance of both core system and data warehouse optimised according to their different operational requirements.

However, the cost (largely time) involved in generating reports across diverse systems, particularly legacy mainframes, may prove prohibitive. Even when achieved, the time lag from data event to report generation may be too great for the reports to be of practical use. Finally, there is the inherent ongoing cost of investing in data analytics whenever a host system is added, replaced or removed from the report configuration.

A further bespoke option is to commission specific reports from the infrastructure provider. However, these can only be produced on an ad-hoc basis making them expensive, inflexible and slow to produce. They are also limited to Bacs processes and cannot report on future Faster Payments or cross border transactions.

Experian Payments Gateway Management Information
Since its launch in 2004, Experian Payments Gateway has become the payments processing platform for over a third of all UK Direct Debits and Direct Credits. Given its central role in the payments processing cycle, Experian Payments Gateway is a potentially rich source of intelligence about the payments it processes for it holds within it all the consolidated data required. To enable Experian Payments Gateway users to take advantage of this information, Experian Payments has developed Management Information (MI) [6]. This creates an Experian Payments Gateway data warehouse, optimised for reporting, and fed from the platform’s multiple data sources. Experian Payments Gateway is, therefore, both the ideal source for management information about payments and the most cost-effective means by which to access it.

Experian Payments Gateway MI reporting functionality facilitates:

1. Bacs Direct Debit and Direct Credit payments reports
2. Experian Payments Gateway-specific reports (user actions, payment data, audit log) in summary or line-by-line format
3. custom report design facility
4. scheduled extension to incorporate reporting on Faster Payments and cross border transactions

Trying to access the Experian Payments Gateway data sources directly would be complex or impossible due to the need to understand the different types of data and the different formats in which it is shown (e.g. Standard 18 files vs. ADDACS report format vs. EPG live database format).

Experian Payments Gateway MI provides an invaluable intelligence interface between Experian Payments Gateway and third party reporting tools of the user’s choice. This might sound like a ‘double investment’ but this is to overlook the central role of Experian Payments Gateway in consolidating data streams from multiple payments applications. Achieving this from the analytics tool rather than from the data is considerably more time-consuming and technically problematic.

Unlike the payment infrastructure provider, which can only provide Bacs payment reports, Experian Payments Gateway MI will soon be able to provide reports on other data including Faster Payments and International payments.

Live data is “streamed” from the current Experian Payments Gateway data sources to a new Data Warehouse.  This is a specifically designed database outside the live system database and file store. This is important as running large “look up” queries on live databases is not good practice as it can reduce the performance of the live system. Also, access by more than one system to a live database risks database corruption. Experian Payments Gateway offers the added protection of password protection and all its files are encrypted.

The live database is designed for high processing performance in daily operation.  The data warehouse is designed for high reporting performance. The data warehouse inevitably has old data in it as the Experian Payments Gateway data sources only go back to the point when the last archive ran.

The advantage of this approach is that the reports that can be generated by Experian Payments Gateway MI are comprehensive in their scope and detailed in their granularity.

They include:

• Bacs cash flow reports by value and period
• rejection reports by Service User Number, host system, period and reason code
• ad hoc queries regarding particular suppliers or customers
• customer service reports for commercial and internal bureaux including SLA monitoring reports and transaction history reports
• fraud and compliance reports for internal or external auditors by file, individual and period
• systems maintenance reports
• identification of dormant SUNs, accounts and users

Conclusion
This article has explored the different models that can be used to provide payments analytics. Whilst each has their advantages and disadvantages, Experian Payments Gateway MI is clearly the most comprehensive solution, and, when the total cost of ownership is considered, a very cost effective method of deriving payments analytics across complex payment processes. Above all, its speed of implementation and, therefore, return on investment enables organisations to improve their operational efficiency and strategic decisions surrounding payments and collections.

Learn more about Experian Payments Gateway Management Information