Analytics on payment data: liquidity, fraud and customer insight

Payment analytics starts with the question, and the question determines the data. A treasurer asks how much liquidity will be needed tomorrow, and the answer comes from the forecast of incoming and outgoing payments. A fraud analyst asks which payments are suspicious, and the answer comes from the pattern of past fraud. A product manager asks which customers are most valuable, and the answer comes from the volume, the value, and the frequency of their payments. Each question needs different data, different aggregation, and different visualisation, and the analytics must be built around the question, not around the data. Liquidity analytics is the most valuable, because it saves real money. A bank that can forecast its payment flows can hold less liquidity in its nostro accounts, and can earn more on the money it does not need to hold. The forecast uses the history of payments by corridor, by customer, and by time of day, and predicts the net position for the next day. A forecast that is accurate to within 5 percent allows the bank to reduce its nostro balance by millions, and the interest saved is the business case. The analytics must be back-tested, because a forecast that is wrong is worse than no forecast. Fraud analytics is the most urgent, because fraud happens in real time. A fraud model scores each payment as it arrives, using the amount, the beneficiary, the time, the device, and the customer's history, and decides whether to allow it, hold it, or block it. The model must be trained on labelled data, where past payments are marked as fraud or legitimate, and must be tested on data it has not seen, to prove it generalises. The model must also be explainable, because the fraud analyst must be able to say why a payment was blocked, and the customer must be given a reason. Customer analytics in payments is about behaviour, not demographics. A customer who makes 50 small payments a month is a different customer from one who makes 2 large payments a month, even if they have the same balance. The analytics must segment by behaviour: the frequency, the value, the corridors, the payment types, and the exception rate. The segments inform the product: the high-frequency customer needs speed, the high-value customer needs certainty, and the high-exception customer needs help. The analytics must be refreshed regularly, because behaviour changes. The data pipeline is the engineering behind the analytics. Payment data flows from the payment hub to a streaming platform, usually Kafka, then to a data lake, then to a warehouse, then to the analytics tool. Each stage has a purpose: the stream is for real-time scoring, the lake is for raw storage, the warehouse is for structured queries, and the tool is for visualisation. The pipeline must handle the volume, which can be millions of payments a day, and must handle the latency, because a fraud score that arrives after the payment has settled is useless. The requirements must state the volume, the latency, and the retention for each stage. Data quality is the foundation, and it is the part most often neglected. A payment record with a missing purpose code, a wrong currency, or a malformed IBAN will corrupt the analytics, and the corruption will not be visible until a decision is made on the wrong data. The pipeline must therefore validate the data at each stage, must reject or quarantine the records that fail, and must report the quality metrics: the percentage of records that are complete, the percentage that are valid, and the percentage that are timely. A dashboard that shows the analytics without showing the quality is a dashboard that hides the problem. For a business analyst, the analytics are requirements with a question, a data source, a calculation, and a visualisation. The acceptance criteria must include a test where the question is asked, the answer is produced, and the answer is verified against the raw data. Last reviewed 7 November 2026. Further reading: the Bank for International Settlements work on payment data; the SWIFT gpi data and analytics; the McKinsey Global Payments Report 2024; the ISO 20022 data model documentation.