M AK I N G T H I N GS R U N

WhitepaperISO 20022

targens.de

Neuer Standard im (Auslands-) Zahlungsverkehr

Technische und fachliche Details

Das Whitepaper „ISO 20022 – Technische und fachliche Details zum neuen Standard im (Auslands-) Zahlungsverkehr“ thematisiert dietechnische Vorgehensweise bei der Implementierung des Standards ISO 20022 in die IT-Landschaft. Im Fokus steht die technische Umwandlung der MT- auf MX-Nachrichten. Anhand des zugrundeliegenden Whitepapers wird beispielhaft aufgezeigt, vor welchen Herausforderungen Unternehmen bei der technischen Implementierung von ISO 20022 im Zahlungsverkehr stehen. Zugleich zeigen wir lösungsgerechte Ansätze zur erfolgreichen Implementierung von ISO 20022 auf.

Technische und fachliche Details zum neuen Standard im(Auslands-) Zahlungsverkehr

Vorstellungdes 4-Corner-Modells

TA R G E N S

Einstieg in den Zahlungsverkehr: 4-Corner-Modell für den „Simple Credit Transfer“ (SCT) mitzentralem Clearing-Mechanismus

Die beteiligten Parteien sind der Debitor, die Debitor Bank, die Kreditor Bank bzw. „Beneficiary Bank“ und der Kreditor bzw. „Beneficiary“. Mit SEPA existiert ein einheitlicher Standard für den europäischen Zahlungsver-kehr, worüber sich die wesentlichen Mengen von Konto-Konto-Transaktionen abwickeln lassen. Das Modell ist auf den Auslandszahlungsverkehr im SWIFT-Umfeld übertragbar. Im Aktivitätendiagramm (Abbildung 1) sind die Nachrichtenarten in Interbankenmarkt (sog. „on-us transactions“) und B2C-Bereich (Bank-to-Customer) unterteilt.

In diesem Zusammenhang wird „CSM“ als der Clearing-Mechanismus zwischen den Intra-Banken oder als automatisiertes Clearing-House bezeichnet². Bezogen auf den Bankenmarkt ist zu erwarten, dass mit zuneh-mender Bankengröße die Kundenbasis und der Anteil an „on-us“ Transaktionen steigen wird, da ein häufige-res Prozessieren von Nachrichten zwischen den Bankkunden erfolgt. Darüber hinaus weisen mehrere Kunden eine größere Anzahl an Konten auf (Datentyp ist „CashAccount38“ gemäß Spezifikation, wird beispielsweise für das Element <DbtrAcct> verwendet).

Das 4-Corner-Modell (auch 4-Parteien-Modell genannt) gibt einen illustrativen Überblick (siehe Abbildung 1) über die wesentlichen Be-grifflichkeiten, Akteure und Nachrichtentypen für den Kredittransfer (Zahlungsprozess). Hierfür werden die Nachrichtentypen PAIN, PACS und CAMT verwendet. Das Modell stellt ein elementares System für verschiedene Zahlungsarten dar, z. B. Kartenzahlungen, Debit-Credit, Instant Credit Transfer im SEPA¹ bzw. im globalen Raum Instant Payments.

Die initiale Nachricht im Diagramm ist eine Pain.001-Nachricht (der sog. Kundenauftrag), ausgehend vom Originator zu dessen Bank. Diese wird von der Originator Bank als sog. Bankenauftrag an die Beneficiary Bank im Pacs.008-Format weitergeleitet. Diese wiederum (sofern keine zwischengeschalteten Intermediary Banken zur Abwicklung nötig sind) validiert diesen Auftrag und sendet im Erfolgsfall eine Pacs.002.001.02 Nachricht und im Negativfall eine Pacs.002.001.03 Nachricht zurück. Die Originator Bank informiert ihren Kunden entweder mit einem umfänglich definierten Kontoauszug (Camt.052-Format) oder mit einem Konten-Report im Format Camt.054 (Debit/Credit Mitteilung) bzw. Camt.053 (B2C Statement). Der Kunde hat darüber hinaus, unabhängig von einer konkreten Transaktion, die Mög-lichkeit, eine Reportinganfrage im Camt.060-Format zu stellen (im Diagramm nicht skizziert).

Eine Recall-Nachricht wird seitens der Originator Bank mittels einer Camt.056.001.01 Nachricht ausgeführt. Diese Nachricht wird benutzt, um eine Stornierung (Cancel) der ursprünglichen Zahlungsanweisung anzufragen. Die empfangende Bank (Creditor Bank) validiert die Recall-Nachricht und sendet im Erfolgsfall entweder eine positive Antwort (Pacs.004 Nachricht) oder eine negative Antwort (Camt.029 Nachricht). Letztere informiert lediglich über die Auflösung eines Recall-Falls mit allen Details in den zehn Nachrichtenblöcken(Verwendung von Reason Codes).

01

¹ SEPA: Single European Payment Area² CSM steht kurz für „Clearing Settlement Mechanism“. Es bezeichnet nicht zwangsläufig eine Entität, sondern einen ganzen Mechanismus. In den XML Schemata gibt es hierfür das XML Element <ClrSysMmbId>, <ClrSysId> sowie <MmbId>. Beispiel eines CSM: PEACH STEP2 (“Pan European Automated Clearing House”)

TA R G E N S

Unterscheidender Nachrich-tentypen

Aktivitätendiagramm zum vorgestellten Zahlungsnachrichtenmodell

Deb

itor

(Orig

inat

or)

Deb

itor

Bank

(Orig

inat

or B

ank)

Cred

itor B

ank

(Ben

e�ci

ary

Bank

)Cr

edito

r (B

ene�

ciar

y)

Mandat(Kundenauftrag)

VerarbeitungKundenauftrag

bei Kundenbank

Validierung desInfrabankenauftrags

Erhalt der BankReports

Start

InitiatingAgent

Pain 001.001.03 (SCT)

Pain 008.001.02 (SCT)

VerarbeitungSCT

Reject

Return of CreditTransfer (Fluid Flow)

X

Pacs 002.001.03 (SCT)

Camt.052.001.02 (B2C Acct Report)

Camt.053.001.02 (B2C Statement)

Camt.054.001.02 (B2C Dr/Cr Noti�cation)

Ende

Erstellung einerRecall Nachricht

Validierung desInfrabankenauftrags

Camt. 056.001.01(Recall)

Innerhalb von10 Tagen

Positiv

Negativ

X

Verarbeitung der Recall Nachricht

Pacs 002.001.02 Camt. 029.001.03

Pacs 004.001.02

Erhalt der BankReports

Ende

Camt.054.001.02 (B2C Dr/Cr Noti�cation)

Camt.053.001.02 (B2C Statement)

Camt.052.001.02 (B2C Account Report)

Fristigkeiten für den SCT

Der in Abbildung 1 dargestellte Prozess erstreckt sich über maximal 23 Arbeitstage (BD). Zwischen D-3 und dem Settlement Datum „D“ (Abwicklungsdatum) wird die Pacs008 Nachricht zwischen den Banken ausge-tauscht. Ein Reject des SCT kann bis zu D+1 stattfinden, startend bei D-3. Der tatsächliche Geldtransfer (Return SCT) findet zwischen D und D+3 statt.

Im Falle eines Recalls muss diese Nachricht bei der zu verarbeitenden Bank bis spätestens D+10 eintreffen. Für die darauffolgende positive oder negative Antwort (Pacs004 bzw. Camt029) bleibt bis D+15 Zeit. Trifft der Recall vor dem Zeitpunkt D, dann wird der originale SCT-Auftrag bereits mit Eintreffen des Recalls gelöscht, somit findet kein Settlement statt.

Unterscheidung von FIN und GPA sowie Systemnachrichten (Message Type)

Die heute verbreiteten MT-Nachrichten sind zwischen FIN und GPA zu unterscheiden. FIN steht für finanzielle Anwendung und bezeich-net ein großes Anwendungsgebiet innerhalb des SWIFT Netzwerks³ , wohingegen GPA für „General Purpose Application“ steht, welches ein allgemeineres Rahmenwerk darstellt. Hierbei beruht FIN mit seinem „User-to-User“, „User-to-SWIFT“ und „SWIFT-to-User“ Nachrichten auf der GPA Anwendung. FIN ermöglicht einen sicheren und zuverlässigen Nachrichtenaustausch von MT-Nachrichten, welche insge-samt über alle Kategorien hinweg ca. 900 verschiedenste Attribute aufweisen.

Neben den bekannten MT-Nachrichten der Kategorie 1 und 2 werden speziell die Systemnachrichten MT096 und MT097, welche sich auf das Senden oder das Empfangen von Nachrichten beschränken, behandelt. Diese sind als FIN Arbeitsumgebung zu deklarieren und werden einer GPA Applikation zugeordnet. Die Bedeutung ist dabei folgendermaßen:

MT096FINCopy to Server Destination Message (Nachrichtenkopie zur Übermittlung an den Server)

³ SWIFT - General Terms and Conditions, S.6 referenziert den FIN Service, verfügbar unter: https://www2.swift.com/knowledgecentre/publications/sgtc

02

TA R G E N S

Klassifi zierungder Fehler-meldungen

MT097FINCopy Message Authorization/Refusal Notifi cation (Nachrichtenkopie mit Möglichkeit der Autorisierung oder Verweigerung der Nachrichtenzustellung)

Validierung einer SWIFT MT Nachricht und Kategorisierung der FIN Error Codes

Bei der Prozessierung eines Kundenauftrags, wie im 4-Corner-Modell dargestellt, gelangt jede Nachricht mindestens einmal zur Überprü-fung zur SWIFT. Sofern die MT-Nachricht keine größeren Fehler in Syntax und Semantik (falsche Informationen, Formatfehler, vergessene Pfl ichtfelder) beinhaltet, erhält die Nachricht nach dortiger positiver Validierung einen ACK ⁴ Status. Im negativen Fall erhält das absen-dende Finanzinstitut einen NAK (NACK) Status, welcher in einer MT Nachricht im Text Block (Feld 451) als 0/1 Wert zurückgesandt wird. Die Vielzahl an Fehlermeldungen werden wie folgt klassifi ziert:

Insgesamt gibt es 19 Fehlertypen bei den alphanumerischen Codes, welche sämtliche Felder aller MT-Nachrichten abdecken. Die FIN-Errors wiederum werden unterteilt in Abbruch- und Diagnostikprüfungen im Zusammenhang mit Übertragungsprotokollen, welche auf TCP/IP⁵ basieren.

Tabelle 1

⁴ ACK: acknowledged (0), NAK: not acknowledged (1). Beispiel: SWIFT ACK: {1:F21YOURCODEZABC1234567890}{4:{177:1508052359}{451:0}{108:ILOVESEPA}}⁵ Transmission Control Protocol/ Internet Protocol, zentrale Architektur (Layer)

03

Aufbau von .XML Nachrichten

TA R G E N S

Kernelemente von .XML Nachrichten

Bei der Erstellung von ISO20022 XML Dateien unterscheidet man zwischen der eigentlichen Zahlungsverkehrsnachricht im XML-Format und der dazugehörigen „Architektur“ Nachricht im .XSD Format. Allgemein formuliert, basieren .XSD-Nachrichten auf einem Template mit klaren Definitionen bzw. Regeln für die Elemente, welche innerhalb der Zahlungsverkehr-Nachrichten vorkommen. Für den Ge-schäftsfeldkatalog der .XSD- Nachrichten gibt es eine Vielzahl an Elementen.

Eine XML-Nachricht besteht aus einem eindeutig definierten Business Application Header⁶ und darauffol-gend einer ISO 20022 Message, welche an den Anforderungen des jeweiligen Geschäftsfelds (Fokus auf den Bereichen Pain, Pacs und Camt) angepasst ist. Beide Blöcke zusammen werden als Geschäftsnachricht (ISO Business Message) bezeichnet. Das <Document> Element ist das einleitende Wurzel-Element eines jeden XML Dokuments, welches im Namespace Attribut (xmlns Attribut) auf das jeweilige .xsd-Template und stan-dardmäßig auf das W3 Konsortium⁷ verweist.

Die wesentlichen Elemente innerhalb der Nachricht sind entweder den beteiligten Akteuren zuzuordnen oder den Zahlungstransaktionen und den damit beinhalteten Feldelementen wie Betrag, Währung, Bank-kennzeichner (BIC) oder Abwicklungs- bzw. Valutadaten. Für den Bereich der beteiligten Parteien (Firmen und natürliche Personen) sind folgende fachliche Elemente relevant:

InitgPty Initiating Party, welche den Zahlungsauftrag auslöst

DbtrDebitor, der Schuldner der Zahlung(en), der einen Account bei einer Bank hat

DbtrAgt Das Finanzinstitut, welches den Debitor als Kunden betreut

CdtrAgtDas Finanzinstitut, welches den Zahlungsempfänger betreut

CdtrDer Kreditor, der Begünstigter der Zahlung(en) ist

<AppHdr>...

</AppHdr> (Business Application Header)

XML Nachricht - wesentliche Blöcke

ISO 20222Message

<Document>...

</Document>

⁶ Details (z.B. Kontaktinformationen, Priorisierung) sind der ISO 20022 Vorlage head001.001.02.xsd zu entnehmen, verfügbar unter: https://www.iso20022.org/business-area/136/download⁷ Die entsprechende Attributgestaltung lautet „xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance“ 04

TA R G E N S

Transaktionen und derenMerkmale

Für all diese Elemente sind die zentralen Kennzeichner wie BIC, LEI und IBAN von größter Bedeutung. Sie treten in diesen Elementen wiederholt als Sub-Elemente auf. Zur Beschreibung von Transaktionen und deren Merkmalen, im Verlauf der Prozesskette, beschränken wir uns hier auf folgende, wesentliche Elemente⁹:

UltmtCdtr Der ultimative Kreditor einer Zahlung

UltmtDbtr Der ultimative Debitor einer Zahlung

InstgAgt Die anweisende Partei, zumeist ein Kunde eines Finanzinstituts, der Nachrichtenoriginator

InstdAgt Die instruierte Partei, zumeist ein Finanzinstitut oder eine Zweigstelle⁸ dessen, der Empfänger

IntrmyAgt1/2/3 Ein sog. Intermediary Agent, welcher als Finanzinstitut in der Zahlungskette eine Weiterleitung der Zahlungsnachricht veranlasst & durchführt, bis zu drei pro Nachricht

MsgId & CreDtTm & NbofTxs Die Kopfelemente, Teil des einleitenden Nachrichtenkopfs <GrpHdr>, die eindeutige Schlüsselung der Nachricht für eine spätere Referenzierung, das Erstellungsdatum und die Anzahl der Transaktionen

IntrBkSttlmAmt & TtlIntrBkSttlmAmt Der tatsächliche Intrabank-Transaktionsbetrag mit Währung bzw. der komplette Transaktionsbetrag – für SEPA ist es EUR

IntrBkSttlmDtDas Abwicklungsdatum der Intrabank-Transaktion im ISODate-Format

PstlAdr Die postalische Adresse des jeweiligen Akteurs (z.B. des Debitors) mit PLZ, Land im ISO Codeformat, Straßenname, Gebäude-nummer etc.

ChrgBr Sogenannter „Charge Bearer Type“ Code gibt an, wer die Gebühr der relevanten Transaktion trägt, z.B. im Falle von „CRED“ der Empfänger. Weitere mögliche Ausprägungen sind „DEBT“, „SHAR“ und „SLEV“

RmtInf Sogenannte „Remittance Information“, wird entweder unstrukturiert <UStrd> oder strukturiert gespeichert <Strd>, stellt den Bezug zum kommerziellen Beleg bzw. Rechnungsdokument her

⁸ Hierfür gibt es die beiden Ausprägungen FinancialInstitutionIdentification <FinInstnId> und BranchIdentification <BrnchId>. Beschreibungen sind verfügbar unter: https://www.iso20022.org/message/mdr/20781/download (ISO20022_MDRPart2_PaymentsClearingAndSettlement_2019_2020_v1.pdf )⁹ Elemente haben eine sog. Multiplizität, diese gibt an wie oft das jeweilige Element innerhalb der Nachricht vorkommt (z.B. [0..*] bedeutet kein Vorkommen bis beliebig oft)

05

TA R G E N S

Mapping von MX zu SWIFT MT

Die MT103-Nachricht, welche in der obigen Tabelle in den beiden rechten Spalten beschrieben ist, wird ver-wendet, um einen SCT zwischen zwei Intrabanken zu prozessieren.

Mapping von MX auf das alte SWIFT MT Format

Um den heutigen MT-Standard mit dem neuen MX-Standard besser darzustellen, wird die MT103 Nachricht für den Interbankenauftrag mit einer Pacs.008-Nachricht verglichen und dabei das Mapping der wesentlichen Elemente aufgezeigt. Hierbei spielen besonders die korrekte Abbildung der Parteien wie Debitor, Debitor Agent, Kreditor und Kreditor Agent eine zentrale Rolle. Man spricht von einer Adapterlösung bzw. einem zentralen Übersetzungsmechanismus.

Tabelle 2:Granularität der MX Nachricht mit Überset-zung auf das SWIFT-MT-Format

Der bestellende Kunde (Originator) wird mittels des Feldes 50K: beschrieben. Dort stehen insgesamt vier Zeilen mit je 35 Zeichen zur Verfügung, der SWIFT Formattyp ist: 4*35 x. Hierbei steht das ‚x‘ als Eingabemenge für das folgende, mögliche Eingabealphabet:{ a-z A-Z 0-9 / -? : ( ) . , ‚ + .}.

In ISO ist MX der <xs:string> Datentyp, restringiert mit <xs:MinLength value=4> und <xs:MaxLength value=4>.

Im MX-Format werden für das Feld 50K die Tags <Dbtr> mit granularen Informationen wie <PstlAdr> sowie <Nm> als auch der <Db-trAcct> verwendet. Die Gebühren bei einer SWIFT-Transaktion¹⁰ werden im MT Format mit den Feldern 71A (mögliche Ausprägungen sind: ‚BEN‘, ‘OUR‘, ‘SHA‘) und 71G, welches die Währung im ISO-4217-Code und den Betrag beinhaltet, ausgewiesen.

¹⁰ Transaktionsgebühren im SEPA Raum betragen zwischen 0,10 Euro und 2 Euro plus prozentualer Betrag abhängig vom Transaktionsvolumen zwischen 1% und 2-3%

06

TA R G E N S

Technische Analyse

Die entsprechenden SWIFT-MT-Nachrichten sind in einer gänzlich anderen Notation dargestellt. Die Zah-lungsverkehr Message besteht aus fünf Blöcken und mehreren darin vorkommenden Feldern, welche ge-wisse Formate oder Codes aufnehmen können.

Die fünf Nachrichtenblöcke lauten wie folgt:

Technische Analyse von XML-Nachrichten

Basic header block

Application header block

User header block (optional)

Text block (eigtl. Nachrichtenteil – SWIFT Message Body)

Trailer block (mit Checkfeld)

Übergang von SWIFT auf MX Nachrichten (Mapping)

Die nachfolgende Darstellung stellt die .XSD-Schemata den korrespondierenden älteren SWIFT-FIN MT-Nachrichten gegenüber. Hierbei sind die Schemata maßgeblich von der SWIFT-Behörde bzw. dem übergeordneten Zusammenschluss ISTH¹¹ entwickelt und wurden von der ISO abgenommen.

MX Nachricht Bedeutung im 4 Corner Modell korrespondierende FIN MT Nachricht

xsd:pain.001.001.10 CustomerCreditTransferInitiationV10 MT103 / MT103+xsd:pain.002.001.11 CustomerPaymentStatusReportV11 MT 202 (mit Feld 72)xsd:pacs.008.001.09 FIToFICustomerCreditTransferV09 MT 103xsd:pacs.002.001.11 FIToFIPaymentStatusReportV11 MT 112xsd:pacs.004.001.10 PaymentReturnV10 MT 202 (mit Feld 72)xsd:camt.029.001.10 ResolutionOfInvestigationV10 MT 110xsd:camt.056.001.09 FIToFIPaymentCancellationRequestV09 MT n92xsd:camt.052.001.08 BankToCustomerAccountReportV08 MT 941 / MT 942xsd:camt.053.001.08 BankToCustomerStatementV08 MT 940/ MT 950xsd:camt.054.001.08 BankToCustomerDebitCreditNotificationV08 MT 900 / MT 910xsd:camt.060.001.05 AccountReportingRequestV05 MT 920xsd:head.001.001.02 BusinessApplicationHeaderV02 -

Der Einsatz von XML-Nachrichten im Zahlungsverkehr ermöglicht eine technische Analyse mithilfe von speziellen Werkzeugen, auch Parser genannt. Dabei werden grundsätzlich zwei Arten unterschieden:

DOM-Parser: Document Object Model¹³Diese Analyse nutzt basierend auf der XML-Nachricht die Baumstruktur mit einem Wurzelknoten (das <Document> Element), der wiederum mehrere Subknoten ausweist. Gemäß diesem Modell befindet sich die gesamte Baumstruktur im Speicher und lässt sich somit auswerten, hat jedoch den Nachteil, eine längere „Parse“-Zeit zu haben. Jeder Knoten hat dabei einen abfragba-ren Typ z. B. Document Node, Element Node oder Text Node. Man nutzt in objektorientierten Programmiersprachen klassische get- und set-Methoden, auch neue Elemente bzw. Attribute lassen sich dadurch hinzufügen. Zur Traversierung des Baumes werden rekursive Methoden benutzt.

Tabelle 3: Korrespondenz von MX und MT Nachricht¹²

¹¹ ISTH steht für International Standards Team Harmonisation (die SWIFT Behörde ist ein Mitglied davon)¹² Die Versionsnummer (letzten 2 Stellen der MX Nachrichtendeklaration) sind dem aktuellen Veröffentlichungsstand der ISO Homepage entnommen, verfügbar unter: https://www.iso20022.org/iso-20022-message-definitions¹³ Das Document Object Model ist eine Spezifikation einer Programmierschnittstelle, welche XML Dokumente als Baumstruktur darstellt. Siehe: https://www.w3.org/TR/REC-DOM-Level-1/level-one-core.html

07

TA R G E N S

Open Bankingals Lösung

SAX ParserDieser sequentielle Parser („Simple API for XML“) liest die XML-Zahlungsverkehr-Nachricht als Datenstrom und ruft für im Standard definierte Ereignisse und Rückruffunktionen (sog. ‚Callbacks‘) auf. Ursprünglich wurde die API für JAVA entwickelt, mittlerweile gibt es den Parser in allen wesentlichen Programmiersprachen. Während der Parser das XML-Dokument liest, leitet dieser zur selben Zeit Informationen aus dem Dokument an das Anwendungsprogramm weiter. Es ist nicht mehr notwendig, das gesamte Dokument im Speicher abzulegen. Hierbei resultiert ein klarer Speichervorteil, der besonders bei großen Doku-menten, z. B. einer großen Zahl bei <NbofTxs>, relevant ist.

Open Banking als gewinnbringende, technologische Lösung für (Kunden-) Datenauswertungen

Im Bereich des Bankenwesens wird eine API¹⁴ zum Austausch von Daten genutzt, insbesondere wertvolle Kundendaten. Im Kontext von Zahlungstransaktionen können mithilfe der strukturierten XML-Nachrichten viele Informationen im zeitlichen Verlauf ausgewertet und Mittels .xml (z.B. Kundenumsätze im CAMT.052-Format) bereitgestellt werden. Der Fokus liegt aktuellen Studien zufolge eher auf den Geschäftskunden (KMU)¹⁵ als auf den Retailkunden. Im Bereich Zahlungsverkehr ermöglicht dies Zahlungsteilnehmern das Recht, Third Party Payment Provider zu nutzen und schreibt dem Account Service (meist ein Finanzinstitut) vor, der Third Party eine dedizierte Schnittstelle bereitzustellen, um Daten wie Kontoinformationen zur Verfügung zu stellen.

Unter dem Begriff „Open Banking“ subsumieren sich verschiedene Prozesse, Technologien und verwandte Services, sowie Produkte mit dem gemeinsamen Nenner, dass alle auf einer API basieren.

Unser Leistungsportfolio: Wir unterstützen Sie bei der Umsetzung!

Durch die komplexen Regularien müssen Unternehmen und Banken frühzeitige Vorkehrungen treffen, um sich auf zukünftige Änderungen effektiv vorzubereiten. Mit der Expertise der targens helfen wir Ihnen, die an-spruchsvollen Anforderungen durch zielgerichtetes Handeln erfolgreich in Ihrem Unternehmen umzusetzen:

Durchführung einer Vorstudie bzw. Betroffenheitsanalyse, inklusive der Analyse der Ausgangssituation sowie des Daten- bestands und der Schnittstellen

Fachkonzeption, Testmanagement und Testdurchführung

Unterstützung der technischen Implementierung

Durchführung von webbasierten und vor Ort Workshops

Erstellung eines Matchplans zur vollständigen Melde-Delegation

¹⁴ API: Application Interface, zentrale Programmschnittstelle mit Dokumentation, zumeist auf einem Server (Port) konfiguriert, welche Interaktionen zwischen verschiedene Softwaresystemen ermöglicht¹⁵ KMU: Kleine und mittlere Unternehmen 08

Ihre Ansprechpartnerfür fachliche Fragen:

Christian SpielerSenior Consultant

Tel.: +49 151 72140402Christian.Spieler@targens.de

Als Expertenhaus für Banking, Compliance und Digital Innovation ist targens führender Anbieter von Beratungs- und Softwarelösungen. Das Unternehmen mit Sitz in Deutschland und der Schweiz kombiniert 30 Jahre Erfahrung in der Entwicklung international bewährter Compliance Services für Finanzinstitute mit zukunftsweisenden und disruptiven Technologien. Durch den Einsatz von Künstlicher Intelligenz und Blockchain-Technologie entstehen so innovative Produkte, die unseren Kunden höchsten Mehrwert bieten. Mit dem Consul-ting-Portfolio unterstützt targens Kunden bei der Bank-und Unternehmens-steuerung, ihren Handelsaktivitäten und dem Schutz von Geschäftsprozessen.

making things run.

Gemeinsam die Herausforderungen der Umstellung meistern. Flexibel nach Ihren Ansprüchen.

Mit Hilfe unseres flexiblen Portfolios und des Fachwissens von regulatorischen Reformen, profitieren Sie von bewährten Beratungsdienstleistungen, welche sich vollkommen an die Daten und Prozesse Ihres Unternehmens anpassen. So entsteht eine optimal zugeschnittene Lösung für die erfolgreiche Umsetzung möglicher Regulationsanforderungen, ganz nach Ihren Bedürfnissen.

Kontaktieren Sie unsere Experten für mehr Details!

Fnan WoldemichaelSenior Consultant

Tel.: +49 171 3168860Fnan.Woldemichael@targens.de

David Matzanke Manager

Tel.: +49 162 2929134David.Matzanke@targens.de

©targens 2021