Auf Nummer Sicher: Denied Party Checks in den Zahlungsprozess integrieren

Denied Party Checks in Zahlungsprozess integrieren

Ein Gastbeitrag von Gregor Opgen-Rhein, Key Account Manager, Omikron Systemhaus

Verwandte Inhalte

FTM Bildwelt: Eiskletterer

Sicherheit ist wichtig – besonders wenn es um Geld geht. Sicherheitsanforderungen an Zahlungsverkehrsanwendungen in Unternehmen wachsen stetig. Jüngste Ereignisse sorgen für eine erhöhte Aufmerksamkeit bei allen Beteiligten.

Selbst in hochsicheren Applikationen kommt es vor, dass Zahlungen versendet werden, aber ihren Empfänger nie erreichen. Ausführende, zwischengeschaltete oder empfangende Banken frieren die Zahlungen ein. Der Grund: Banken überprüfen die Zahlungen und finden einen namensgleichen Zahlungsempfänger auf einer Blacklist. Der Aufwand, das Geld in solchen Fällen zurückzuholen, ist enorm. Der Prozess ist zäh, zeitaufwendig und langwierig. Häufig entstehen Folgekosten durch Nichteinhalten von Zahlungszielen und nicht zuletzt besteht die Gefahr massiver Reputationsverluste, sollten diese Fälle in den Fokus der Öffentlichkeit gelangen.

Wie kann man als Unternehmen vorbeugen? Indem ein Denied Party Check bereits in den Unternehmenskosmos integriert wird, sodass auffällige Transaktionen noch vor dem Versand an die Bank identifiziert und herausgefiltert werden können.

Was sich zunächst einfach anhört, gewinnt bei detaillierter Betrachtung an Komplexität. Gegen welche Denied Party-Listen soll geprüft werden? Sollen Zahlungen bei Auffälligkeiten direkt gelöscht, ausgesteuert oder zuvor einer weiteren manuellen Sichtprüfung unterzogen werden? Wie findet die Rückmeldung an Quellsysteme statt? Wie wirken sich Prüfungen auf die Performance der Verarbeitung und die Einhaltung von Cut-Off-Zeiten aus? Wie werden HR-Zahlungen organisatorisch eingebunden? Unterliegen Lastschrift-Einzüge einer weniger strikten Behandlung als Überweisungen? Welche regulatorischen Anforderungen formulieren die Wirtschaftsprüfer an Protokollierungsmechanismen?

Diese und weitere Fragestellungen müssen bei der Einführung eines geeigneten Präventionssystems, unter Berücksichtigung der organisatorischen Gegebenheiten, beantwortet werden. Das Design unterliegt dabei stets der maßgeblichen Prämisse, dass der Zahlungsverkehr im Allgemeinen weiterhin möglichst automatisiert und ohne manuelle Eingriffe fortgesetzt wird (Straight-Through-Processing (STP)).

Daher muss die Anwendung in der Lage sein, „saubere Zahlungen“ ohne weitere Eingriffe an die Banken zu versenden, während „Treffer“ zur weiteren Behandlung einen separaten Workflow anstoßen müssen. In diesem Kontext befindet sich auch die Thematik der automatisierten Ausnahmebehandlung in Form einer White-List der Black-List. Diese ermöglicht eine noch effizientere STP-Abwicklung durch Vermeidung von wiederkehrenden, aber unnötigen Nachbearbeitungs-Szenarien.

Jedes Unternehmen muss sich außerdem die unverzichtbare Frage stellen, wo der Denied Party Check in der Systemlandschaft verortet werden soll. Grundsätzlich wäre es richtig, die Prüfung in das jeweilige zahlungserstellende System zu integrieren. Da dies aber in heterogenen ERP-, TMS- und HR-Systemumgebungen ein äußerst umfangreiches, komplexes und kostspieliges Projekt bedeuten würde, sind praktikable Alternativen gefragt. Aus prozessualer Sicht erfolgt der Denied Party Check idealerweise in der zentralen Schnittstelle, in der die verschiedenen Verarbeitungsketten aus ERP-Systemen, HR-Systemen, Treasury- und sonstigen Billing-Systemen konvergieren. Unternehmen mit einer zentralisierten Zahlungsverarbeitung sind daher klar im Vorteil. Sie integrieren die Prüfung einmalig in das bestehende Electronic Banking Hub oder ihre Payment Factory (PAF) und wickeln damit den Denied Party Check zentral für alle anliefernden Systeme und gleichermaßen auch für manuelle Zahlungen ab.

Neben den geringen Einführungs- und Wartungsaufwänden kann die Prüfung in diesem Szenario nahtlos in die bestehenden Workflows integriert werden. Das garantiert eine unverändert hohe Performance bei gleichbleibender Verfügbarkeit der gesamten PAF bei impliziter Nutzung vorhandener Komponenten, wie zum Beispiel Datensicherung und Archivierung.

Eine integrierte Lösung kann zugleich flexibel und bedarfsgerecht an die Anforderungen der Kunden angepasst werden. Dadurch wird durchgängig der optimale Betrieb sichergestellt.

Schematischer Ablauf der Embargo-Prüfung in der Payment Factory

Quelle: Omikron Systemhaus

Quelle: KPMG Corporate Treasury News, Ausgabe 56, Juni 2016
Ansprechpartner KPMG: Thomas Mehlkopf, Manager, tmehlkopf@kpmg.com

 

Die Ansichten und Meinungen in Gastbeiträgen sind die des Verfassers und entsprechen nicht unbedingt den Ansichten

und Meinungen der KPMG AG Wirtschaftsprüfungsgesellschaft.

Finanz- & Treasury Management

Das Expertenteam vom KPMG weist Ihnen den richtigen Weg im Finanz- und Treasury-Management.

 
Lesen Sie mehr

KPMG Corporate Treasury News

So kontaktieren Sie uns

 

Angebotsanfrage (RFP)

 

Absenden

KPMG's neue digitale Plattform

KPMG's neue digitale Plattform