The Payment Messages Your Filter Never Reads

Count What Reached The Filter

Most screening management information can tell you how many alerts were raised last month. That number describes what the filter did with the messages it received. It is the far end of the process. Ask a different set of questions about what happens at the beginning and things can get a little less clear. How many payment messages did the bank process that month? How many were in-scope for payment screening (probably not screening domestic but I still find clients that do)? How many did the filter actually receive? Did it exclude any payments based on its configuration? Those are four numbers that tell a story, but only if they have been surfaced and reconciled.

What one engagement looked like

A global bank asked us for independent assurance that it was screening the payment messages in accordance with its policy. We mapped the payment systems, pulled several million historical messages out of the data warehouse, and read the bank's own screening policy. We worked out which of those messages should have been screened. Then we went to the filter logs to see which ones actually were. Where the two didn't line up, we chased the cause back through routing logic, message attributes and system configuration.

What we found was a screening gap. A cohort of cross-border payments should have been screened but were not. Simply put the logic was to not screen unless it was deemed to be a cross-border payment. Logically that is unsafe and, to my mind, the wrong way round. But even then there were nuances based on assumptions made during implementation that were not surfaced in the documentation. Certainly nobody had tested the system environment as a whole.

How does a policy, application design and its implementation go wrong? Hand-offs and not thinking through the logic. The business writes the requirement, technology builds it, operations runs it. Every hand-off is a chance for intent and implementation to drift. On day one, the tests had passed. Over time, the business and the payment flows changed but the logic that routed payments to the filter did not. Nothing surfaced the drift. Nobody rechecked that the system as a whole still worked. The policy still says what it always said. The rules still do what somebody once built them to do. But the business had moved on.

One thing I'd say plainly, because it gets misunderstood. Some payments are excluded from screening deliberately, under policy (e.g. domestic payments) or for operational efficiency (technical or mirror image copies of payments). That's a decision, not a finding. The question isn't whether everything is screened. It's whether what gets screened matches what the policy says should be.

The test you can run

1. Pick one full business day and one of your BICs. Match the windows to the minute. Filter logs and payment system logs often run on different cut-offs, and an hour of drift invents a discrepancy that isn't there.

2. From the payment systems, inspect the characteristics of the payment, such as message type, countries where the payment is routed through, currency, etc.

3. Decide whether the payment should be screened or not based on these characteristics. Count the messages that you believe should be screened.

4. At the filter, count the messages received for the same day. Reconcile the two numbers.

What throws the numbers out:

• Watch the legs on intermediary payments. A filter will often screen both the inbound and outbound leg of the same payment passing through the bank while the payment system may count one transaction. Compare your apples with your apples, not your oranges.

• The numbers probably won't match initially. You will need to drill into the differences.

  
  

Your counts will give you a feel for whether the numbers look right. To prove it, you will need to dig deeper.

What a basic reconciliation leaves out

At smaller banks and fintechs, I've seen poor MI and poor knowledge of the screening and payment environments. Systems and processes may be simpler, yet sometimes people just don't know where or how to look.

The larger the bank, the trickier the problem. Multiple countries, multiple BICs, getting the MI from payment systems and/or SWIFT, proximity of the payment systems to the filter - these are all problems that scale will make harder.

To grasp that nettle you need inquisitive minds, a good understanding of what a reconciliation is and is not (I'm still surprised at how often that gets overlooked) and some perseverance to line the numbers up.

There's also one part your own team can't fix by trying harder. A reconciliation run by the people who own the control isn't independent of it. If your board is asking, or a regulator is, a defensible answer comes from outside the function being tested, usually from people who have done it before. That's the difference between knowing and being able to show it. The FCA's Financial Crime Guide (FCG 7.2.3) expects firms to evaluate and test the effectiveness of their screening systems regularly, and to understand their automated configuration well enough to demonstrate it is appropriate. One-off screening exercises sit in its poor practice column.

Why bother?

This is the cousin of the age-old customer screening question. Did we screen all of our customers? Ask it about payments instead. If you can't show that you screened everything your policy said you should, you may have a screening gap. But what you definitely have is a control gap.

Andrew Travis — andrew.travis@opusdatum.com