Safety first: Integrating denied party checks into the payment process

Integrating denied party checks into payment process

A guest-article of Gregor Opgen-Rhein, Key Account Manager, Omikron Systemhaus

Related content

FTM-Bildwelt: Eiswand

Especially when there is money at stake, it is important to be on the safe side. The security requirements placed on companies' payment transaction applications are growing all the time, and recent developments have prompted all stakeholders to pay even more attention to this crucial issue. Yet even in high-security applications, it still happens that payments are transferred but never reach their intended recipient. Originating, intermediary or recipient banks sometimes freeze payments.

Why? Because when screening the payments initiated, they find a recipient of the same name on a black list. When that happens, getting the money back can be a huge challenge. The process is arduous, time-consuming and protracted. In many cases, it leads to consequential costs because payment terms are not met. By no means least, there is also the threat of a serious loss of reputation if such incidents come to public attention.

So what preventive measures can a company take? Well, it can integrate what are known as "denied party checks" in its own corporate universe to enable irregular transactions to be detected and filtered out before bank transfers are initiated in the first place.

That may sound simple. On closer inspection, however, it is a complex challenge in its own right. Which denied party lists should you refer to? In the event of irregularities, should payments be cancelled automatically, filtered out or first subjected to a further manual screening process? And how is the irregularity reported back to the source system? How do such checks affect processing performance and compliance with cut-off times? How do you organise the integration of HR payments? Should direct debit transactions be treated less strictly than bank transfers? What regulatory requirements do auditors impose on logging mechanisms?

If you want to introduce a suitable prevention system that takes due account of organisational circumstances, these and other questions require answers. The design adopted must always be subject to the key assumption that payment transactions in general should continue to be automated wherever possible, with no manual intervention, in the spirit of straight-through processing (STP).

Accordingly, the application must be able to send “clean payments” to banks without further intervention, while “hits” should trigger a separate workflow for further processing. This is the context in which we also encounter the topic of automated exception treatment in the form of a white list set against the black list. This enables even more efficient STP processing by avoiding post-processing scenarios that are recurrent but unnecessary.

Every company must also face up to the key question of where denied party checks are to be slotted into the system landscape. In principle, the right thing to do would be to incorporate these checks in the system that initiates payment in each case. However, doing that in heterogeneous ERP, TMS and HR system environments would be such an extensive, complex and expensive project that more practicable alternatives are needed. From a procedural perspective, denied party checks should ideally take place at the central interface where the processing chains from the ERP, HR, treasury and other billing systems converge.

Companies that operate centralised payment processing thus have a clear advantage. They can simply integrate checks once in their existing electronic banking hub or their payment factory (PAF) and denied party checks will then be centrally conducted for all supplying systems and manual payments alike.

In addition to low implementation and maintenance costs, the checks performed in this scenario can be integrated seamlessly into existing workflows. That guarantees the same high performance and unchanged availability across the entire payment factory, with existing components such as data backup and archiving used implicitly. An integrated solution can be adapted both flexibly and in line with the specific needs of customers. This in turn ensures that operation is optimised from end to end.

Source: KPMG Corporate Treasury News, Edition 56, June 2016
Guest-Article of Gregor Opgen-Rhein, Key Account Manager, Omikron Systemhaus
Contact KPMG: Thomas Mehlkopf, Manager,

Corporate Treasury

The KPMG team of experts knows the right way for finance and treasury management.

Read more

© 2016 KPMG AG Wirtschaftsprüfungsgesellschaft, ein Mitglied des KPMG-Netzwerks unabhängiger Mitgliedsfirmen, die KPMG International Cooperative (“KPMG International”), einer juristischen Person schweizerischen Rechts, angeschlossen sind. Alle Rechte vorbehalten.

Connect with us


Request for proposal



KPMG's new digital platform

KPMG's new digital platform