PSD2 ante portas: Mehr Wettbewerb und mehr IT-Sicherheit im elektronischen Zahlungsverkehr

Neue Anforderungen an die Organisation der IT-Sicherheit im elektronischen Zahlungsverkehr.

Dr. Markus Escher, Rechtsanwalt GSK Stockmann, München, Bankaufsichtsrecht, Zahlungsregulierung.

I. Übersicht zur PSD2-Umsetzung

Die Zweite EU-Zahlungsdiensterichtlinie 2015/2366 vom 25.11.2015 („PSD2“) wird Banken nicht nur bei der IT-Sicherheit im elektronischen Zahlungsverkehr, sondern auch im Wettbewerb um den elektronischen Kontakt zum Bankkunden operationell, rechtlich und strategisch fordern. Hierzu ist das Zahlungsdiensteumsetzungsgesetz vom 17.07.2017[1] („ZDUG“) mit einer Neufassung des Zahlungsdiensteaufsichtsgesetzes („ZAG“) und Änderungen im BGB erlassen worden. Mit dem ZDUG werden die meisten Aspekte der PSD2 am 13.01.2018 in deutsches Recht umgesetzt und damit ein neuer Rechtsrahmen für mehr Wettbewerb um den Bankkunden bei elektronischen Zahlungen und „Banking as a Service“ geschaffen. Die Regelungen mit den stärksten IT-organisatorischen Anforderungen für Banken in der Interaktion mit Zahlungsauslöse- und Kontoinformationsdienstleistern („ZAD“, § 1 (2) Nr. 7; (33) ZAG und „KID“, § 1 (2) Nr. 8; (34) ZAG; zusammen „Drittdienstleister“), v. a. aber neue Anforderungen an die starke Kundenauthentifizierung im elektronischen Zahlungsverkehr, werden wohl erst im Sommer 2019 in Kraft treten, werfen aber heute bereits ihr Licht für Implementierungsprojekte und strategische Entscheidungen, insbesondere zu Auswirkungen auf das elektronische Kundenverhältnis voraus. Die Aufsichtspraxis der BaFin nach den MaSI[2] wird schrittweise durch das neue ZAG ersetzt.

II. Einführung zur PSD2

  1. Betroffene Institute

Für eine Bewertung der Auswirkungen der PSD2 und die gebotene Projektorganisation ist zunächst nach den betroffenen Instituten zu unterscheiden:

Klassische „CRR-Institute“ nach § 1 (3d) KWG (hier „Banken“) werden stärker von der PSD2 betroffen sein als seinerzeit von der PSD1. Ein Ausblenden des ZAG ist für Banken ab 13.01.2018 nicht mehr denkbar, da auch für diese gesteigerte aufsichtliche Anforderungen aus dem ZAG zur IT-Sicherheit bei electronic payments gelten, da für Banken alle Regelungen für Zahlungsdienstleister greifen. Zivilrechtliche Änderungen im Kundenverhältnis, aber auch zu anderen Zahlungsdienstleistern werden sich ebenfalls auf alle Banken auswirken. Hierzu gehören v. a. die rechtlich, aber auch strategisch neu zu bewertenden Regelungen im BGB zur Interaktion mit neuen Drittdienstleistern.

Teil-Banken nach § 1 (1) KWG ohne CRR-Institutsstatus unterliegen bereits heute einer Doppelaufsicht nach ZAG-alt als Kredit- und Zahlungsinstitut. Dies betrifft insbesondere Spezialbanken, die z. B. im Wertpapier- oder Bürgschaftsbereich Banktätigkeiten ohne Universalbankerlaubnis, aber mit Zahlungsdiensten erbringen. Für Spezialbanken besteht mit der PSD2 ein erhöhter Handlungsbedarf, da spätestens zum 13.07.2018 eine neue Erlaubnis als Zahlungsinstitut vorliegen muss (vgl. II.5.).

Betroffen werden ggf. auch Unternehmen der Telekommunikationsbranche sein, da die branchentypische Bereichsausnahme in § 2 (1) Nr. 11 ZAG erheblich beschränkt wurde. Zusätzlich wurde betont, dass auch bei Zahlungsabwicklungen mittels Forderungskäufen ein Zahlungsdienst nicht vermieden werden kann[3], so dass auch TK-Unternehmen ihre Zahlungsabwicklungsaktivitäten nach dem ZAG neu bewerten und fallabhängig ggf. eine Erlaubnis nach § 10 ZAG beantragen müssen. Gleiches gilt ggf. auch für Abrechnungsdienste von Zahlungsvorgängen für Händler, die unter das neue „Akquisitionsgeschäft“ fallen können, auch wenn diese nicht durch Karteneinsatz, sondern durch Lastschrift oder Überweisung ausgelöst werden. Auch dies erweitert das ZAG-Aufsichtsspektrum der BaFin.

2. Betroffene Zahlungsprodukte

Die PSD2 erfasst alle Zahlungsprodukte, also Überweisungs-, Lastschrift-, Karten- und E-Geldgeschäft, aber auch innovative Zahlungsprodukte im e-commerce wie Zahlungen über Drittdienstleister. Hierbei ist leider auf die gleiche Schwäche wie bei PSD1 hinzuweisen, da zahlreiche Vorschriften aus einer Überweisungsperspektive entstanden sind und in ihrer Anwendung auf das Kartengeschäft viele Unklarheiten aufwerfen. Für KID ist auch bemerkenswert, dass nicht nur Zahlungen, sondern gerade auch der transaktionsfreie Zugang zu Kontoinformationen nach PSD2 relevant sind.

3. Betroffene Kunden und internationale Erstreckung

Neben einer Stärkung des Verbraucherschutzes ist auch zu beachten, dass die PSD2 gerade in der Zahlungssicherheit erhebliche Auswirkungen auf das Firmenkundengeschäft haben kann, da auch bei Unternehmen die Pflicht zur starken Kundenauthentifizierung nach § 55 ZAG nicht vertraglich abbedungen werden kann. Anders als die PSD1 erstreckt sich die PSD2 international weiter und umfasst nun auch sog. „One-Leg-Transaktionen“, bei denen nur ein Zahlungsdienstleister in der EU ansässig ist, wie z. B. eine Auslandsüberweisung in die USA oder auch Zahlungen zwischen zwei EU- Banken in Nicht-EU Währungen, § 675d (6) BGB.

4. Vollharmonisierte Umsetzung und EBA-Mandate

Wie die PSD1 ist auch die PSD2 eine vollharmonisierte EU-Richtlinie. Das heißt, dass sie grundsätzlich EU-weit einheitlich umzusetzen ist und Mitgliedstaaten für Abweichungen nur einen begrenzten Spielraum haben, soweit ausdrücklich zugelassen. Zum anderen – und hier unter-scheidet sich PSD2 von PSD1 erheblich – erhält die European Banking Authority („EBA“) zur EU- Harmonisierung elf Mandate[4] zum Erlass aufsichtsrechtlicher Leitlinien („EBA Guidelines“) und Entwurf von Regulatory Technical Standards („EBA RTS“), die letztlich in unmittelbar geltende EU-Verordnungen der EU-Kommission münden, wie dies bereits nach der CRD-IV bzw. in der Wertpapieraufsicht nach MiFID II bekannt ist. Diese EBA-Maßnahmen werden sich erheblich auf den elektronischen Zahlungsverkehr und dessen IT-Organisation auswirken. Auch wenn das ZDUG in Deutschland bereits erlassen ist, sind einige EBA-Maßnahmen noch in der Konsultation und werden wohl erst vor Jahresende in finaler Fassung vorliegen. Beim EBA-RTS nach Art. 98 PSD2 zur starken Kundenauthentifizierung („SKA“) und zu sicheren Schnittstellen kommt es zu einer späteren Implementierung, wobei bei Redaktionsschluss dieses umstrittene RTS-Verfahren noch nicht abgeschlossen ist. Nach einem ersten Entwurf der EBA (EBA Final Report vom 23.02.2017, EBA/RTS/2017/02) hat die EU-Kommission diesen am 24.05.2017 zurückgewiesen, worauf die EBA einen zweiten Entwurf[5] („EBA RTS-E“) vorlegte. Die Annahme durch die Kommission sowie die erforderliche Mitwirkung des EU-Parlaments und des EU-Ministerrats, die bis zu drei Monate dauern kann[6], sind noch abzuwarten, so dass der RTS als EU-Verordnung vermutlich erst zum Jahreswechsel 17/18 veröffentlicht wird, dann allerdings erst 18 Monate später, also wohl erst im Sommer 2019 in Kraft tritt, Art. 37 EBA RTS-E.

5. Übergangsvorschriften und Zweistufige Implementierung

Für ZAG-Institute – und damit auch für Teil-Banken – ist die Beantragung einer neuen ZAG- Erlaubnis der BaFin nach § 66 (2) ZAG spätestens zum 27.01.2018 im Rahmen eines erleichterten Verfahrens anzuzeigen. Gleiches gilt für heutige E-Geld-Institute nach § 67 ZAG. Diese belastende Übergangsregelung wirkt ungewöhnlich, sie war allerdings durch Art. 109 PSD2 ohne Spielraum für den nationalen Gesetzgeber vorgegeben. Die Projekt- und Fristenverwaltung für diese Häuser hat daher akkurat § 66 ZAG zu beachten, da sonst zum 13.07.2018 die heutige ZAG-alt-Erlaubnis erlischt. Bei versäumten Anzeigefristen droht ein vollständig neues ZAG-Erlaubnisverfahren, ohne Erleichterungen. Dieses erleichterte Erlaubnisverfahren bedeutet, dass durch heute aktive ZAG-Institute nur die neuen PSD2-Erlaubnisvoraussetzungen zu IT-Sicherheits-, organisatorischen und strategischen Fragen der BaFin nachzuweisen sind, § 10 (2) S. 1 Nr. 6 bis 10 ZAG i. V. m. § 66 (2) ZAG. Antragsteller haben daher hierfür teilweise die bereits finalen EBA-Guidelines zum Erlaubnisverfahren[7] und zum Störfallmeldewesen[8], sowie den Entwurf der Guidelines zum IT-Sicherheitsmanagement[9] und zu jährlichen Betrugsberichten[10] zu beachten.

Für Drittdienstleister wie ZAD oder KID gilt bemerkenswerterweise nach Art. 115 Abs. 5 PSD2 eine liberalere Übergangsvorschrift. Soweit diese Dienste vor dem 12.01.2016 erbracht wurden, dürfen sie bis zum Wirksamwerden des EBA RTS, also ca. bis Sommer 2019, ohne ausdrücklich erteilte Erlaubnis tätig werden, § 68 (1), (2) ZAG. In dieser Übergangszeit bis zur zweiten Stufe der PSD2 sind Banken gleichwohl nicht berechtigt, Drittdienstleistern den Zugang zu ihren Zahlungskonten zu verweigern, § 68 (3) ZAG. Diese besondere Übergangsvorschrift für ZAD und KID führt zu einer Sondersituation, da alle PSD2-Änderungen im BGB sofort am 13.01.2018 in Kraft treten, auch wenn bereits aktive ZAD und KID noch keine ausdrücklich erteilte ZAG-Erlaubnis haben sollten.

Die PSD2 wird zweistufig nach Art. 15 (1) ZDUG umgesetzt, da die wichtigen Vorschriften zu den Schnittstellen zwischen ZAD, KID und Banken nach § 45 bis 52 ZAG sowie zur SKA nach § 55 ZAG erst mit Inkrafttreten des RTS SKA, also vermutlich Sommer 2019, greifen. Bis dahin hat die SKA weiterhin nach Maßgabe der MaSI zu erfolgen, § 68 (4) ZAG.

Die für alle Zahlungsdienstleister, also auch für Banken, relevanten Vorgaben an die IT- Sicherheitsorganisation und die Störfallanzeigen nach §§ 53, 54 ZAG werden allerdings sofort ab 13.01.2018 gelten. Die diesbezüglichen Anforderungen der BaFin aus den MaSI werden also bereits in Stufe 1 durch die neue gesetzliche Regelung verdrängt und wiederum durch neue Leitlinien der EBA in wichtigen Detailfragen ergänzt[11], die später durch die BaFin anzuwenden sind.

III. Verstärkter Wettbewerb um den Kundenkontakt mit Zahlungsauslöse- und Kontoinformationsdienstleistern

Nach langen Rechtstreitigkeiten zwischen der Deutschen Kreditwirtschaft (DK) und dem ZAD bzgl. der berechtigten Durchleitung von persönlichen Sicherheitsmerkmalen wie PIN und TAN im Online-Zahlungsauslöseverfahren bzw. in wettbewerbsrechtlicher Hinsicht bzgl. des Zugangs zu Zahlungskonten[12] erklärt nun die PSD2 die Tätigkeit von ZAD und KID, wie beispielsweise Sofortüberweisung, iDeal, Trustly und Figo, ausdrücklich für gesetzlich zulässig. Banken ist es daher nicht gestattet, diesen Drittdienstleistern den Zugang zu ihren Zahlungskonten zu verweigern, § 68 Abs. 3 ZAG. Diese Zulassung von ZAD und KID wird Banken rechtlich, technisch und strategisch fordern.

1. Aufsichtlicher Rahmen für Drittdienstleister und Banken

a) Aufsichtspflichtige Drittdienstleister

Die Erbringung von ZA-Diensten wird eine Erlaubnis der BaFin nach § 10 ZAG als Zahlungsinstitut erfordern. KID wiederum werden als Zahlungsinstitute nur im Institutsregister registriert – ohne ausdrückliche Erlaubnis, §§ 34, 43 ZAG. ZAD und KID unterliegen zwar den allgemeinen ZAG-Organisations- und Sicherheitsvorschriften, einschließlich der grundsätzlichen Anforderung an mindestens zwei zuverlässige und fachlich geeignete Geschäftsleiter. Sie unterliegen aber keinen Anforderungen an laufende Eigenmittel oder (Insolvenz-)Sicherungsanforderungen nach §§ 15, 17 ZAG, müssen hingegen eine spezifische Berufshaftpflichtversicherung oder eine andere gleichwertige Garantie zur Absicherung Ihrer Haftung nach §§ 16, 36 ZAG[13] nachweisen. Sie profitieren wie alle Zahlungsinstitute vom EU-Pass mit Niederlassungs- und Dienstleistungsrecht, so dass sie zu europaweiten Diensten befugt sind, § 38 ZAG. Banken müssen sich daher nicht nur auf deutsche, sondern auch auf EU-Drittdienstleister vorbereiten.

b) IT-Schnittstellen zu Banken

Abweichend von den allgemeinen Bestimmungen für ZAD und KID (vgl. a), werden die für diese spezifischen Aufsichtsvorgaben nach § 49 und 51 ZAG erst mit der zweiten PSD2-Stufe gelten (vgl. oben, II.5.). ZAD und KID sind hiernach nicht berechtigt, Gelder von Nutzern zu halten. Sie sind verpflichtet, sich bei jeder Zahlungsauslösung oder Kommunikation gegenüber der Bank des Zahlers zu identifizieren und ausschließlich über sichere Kanäle zu kommunizieren, § 49 (2), (3) bzw. 51 (2), (3) ZAG. Der hierfür geltende, politisch stark umstrittene RTS SKA ist von der Kommission noch zu verabschieden, aber nach aktuellem Entwurfsstand ist zu erwarten, dass die Identifizierung von ZAD und KID nach der eIDAS-VO zu erfolgen hat. Nach Art. 33 EBA RTS-E werden hierfür qualifizierte Zertifikate für elektronische Siegel bzw. für die Website-Authentifizierung nach Art. 3 (30) bzw. (39) der eIDAS-VO (910/2014) gefordert sein. Aktuell strittig ist noch, ob und wie ZAD und KID auf die allgemeine oder nur auf eine dedizierte Kundenschnittstelle (API) bei Banken zugreifen dürfen. Ein für Banken nicht erkennbares „screen scraping“ nur unter Nutzung der allgemeinen Schnittstelle wie bisher wird künftig nicht mehr zulässig sein[14]. Nach der EBA sollen Banken die Wahl haben, den diskriminierungsfreien Zugang zu ihren Konten über eine dedizierte Schnittstelle oder über eine modifizierte allgemeine Kundenschnittstelle zu gewähren, Art. 30, 31 EBA RTS-E. Hiermit hat die EBA insbesondere den Vorschlag der Kommission zurückgewiesen, bei Nichtverfügbarkeit der dedizierten ZAD-/KID-Schnittstelle zwingend eine modifizierte allgemeine Schnittstelle bereit zu halten (keine „fall-back-Lösung“). Zur Vermeidung von Diskriminierungen auf Seiten der Drittdienstleister werden Banken aber wohl zu hoher Transparenz, Überwachung von KPI und Öffnung von Testzugängen spätestens drei Monate vor Wirksamwerden des RTS verpflichtet sein, vgl. Art. 29 (3)–(5), 30, 31, 32 EBA RTS-E. Unabhängig von den Details des finalen RTS steht jedoch fest, dass sich Banken rechtzeitig in rechtlicher und technischer Sicht mit den Anforderungen an die Schnittstellen für sichere Kommunikation mit ZAD und KID und deren Zugang zu online zugänglichen Zahlungskonten gemeinsam mit ihren technischen Dienstleistern/Rechenzentren vorzubereiten haben. Hierzu wird auch die Veröffentlichung von Verfügbarkeitsstatistiken bzw. von Kommunikationsplänen gehören, wie Drittdienstleister bei Störfällen zu informieren sind, Art. 31 (3); 32 EBA RTS-E. Die aufsichtsrechtlichen Pflichten der Drittdienstleister und Banken nach den §§ 45–52 und 55 ZAG sowie dem RTS werden aber wie gesagt erst im Sommer 2019 wirksam werden.

2. Zivilrechtliche Besonderheiten zwischen Drittdienstleistern und Banken

Zeitlich nicht konsistent zum Aufsichtsrecht werden Änderungen des BGB bereits in der ersten PSD2-Phase ab 13.01.2018 zivilrechtliche Besonderheiten begründen. So legt § 675f (3) BGB ein Recht des Bankkunden fest, ZAD und KID zu nutzen, auch ohne, dass diese einen Vertrag mit der Bank unterhalten müssen, es sei denn, das Zahlungskonto ist nicht online zugänglich. Wichtig und haftungsträchtig wird § 675p (2) BGB sein, der den Widerruf eines Zahlungsauftrags des Kunden ausschließt, sobald der Zahlungsvorgang über einen ZAD ausgelöst wurde. Eine Bank darf daher in diesem Fall einen Widerruf nicht mehr zulassen, da anderenfalls Haftungsrisiken gegenüber dem ZAD, der ggf. auf Grund der ihm zuvor erteilten Zustimmung bereits einem Akzeptanten gegenüber im Risiko ist, bestehen können. Andererseits wird ein Ausgleichsanspruch der Bank gegen den ZAD nach § 676a (1) BGB bestehen, falls die Ursache für eine Haftung der Bank gegenüber dem Bankkunden im Verantwortungsbereich des ZAD liegt. In Streitfällen hat der ZAD die Beweislast dafür, ob ein über ihn ausgelöster Zahlungsvorgang autorisiert oder ordnungsgemäß ausgeführt wurde, § 676a (2) und (3) BGB.

3. Strategische Bedeutung der Zulassung von Drittdiensten

Strategisch dürfen Banken die Bedeutung von Drittdiensten nicht unterschätzen. Sollte eine Bank in der Kundenwahrnehmung zunehmend hinter „Drittdienstleistern“ im elektronischen Zahlungsverkehr „verschwinden“, wird dies erhebliche Auswirkungen auf die Kundenbindung und -kommunikation haben, da der Kunde zunehmend den ZAD oder KID als „face-to-the-customer“ wahrnehmen wird. Die Zulassung von Drittdiensten durch die PSD 2 sollte durch Banken aber nicht nur als Bedrohung, sondern strategisch auch als Geschäftschance verstanden werden. Da jede Bank selbst berechtigt ist, Drittdienste anzubieten, kann auch sie im Wettbewerb um die Kundenkommunikation aktiv sein und passende Mehrwertdienste und innovative digitale Produkte wie ein „Personal Finance Management“ anbieten. Hierzu können sich auch Kooperationen mit FinTech-Unternehmen anbieten, die ggf. technologisch flexibler als bankeigene Ressourcen sein können. Soweit ein kooperierendes FinTech-Unternehmen selbst nur als technischer Dienstleister im Hintergrund bleibt, wird es auch ohne ZAG-Erlaubnis oder Registrierung technische Ressourcen anbieten können, um wiederum Banken bei der Erbringung von ZA- oder KI-Diensten zu unterstützen[15]. Mit Spannung ist also zu beobachten, wie die die Drittdienste liberalisierende PSD2 den elektronischen Wettbewerb um den Bankkunden befeuern wird.

IV. Neue aufsichtsrechtliche Organisationspflichten

1. Sicherheitsrisiken und Störfallmeldungen – § 53, 54 ZAG

Unabhängig von der Zulassung von Drittdiensten sieht die PSD2 bereits ab 13.01.2018 neue aufsichtsrechtliche Organisationspflichten für Banken vor. Die MaSI begründeten bereits für Internetzahlungen und AT 7.2 MaRisk ganz allgemein Risiko- und Sicherheitsmanagementvorgaben für Banken. Nach § 53 ZAG werden Banken nun speziell für alle Zahlungsdienste angemessene Risikomanagement- und Kontrollmechanismen zur Beherrschung operationeller und sicherheitsrelevanter Risiken anwenden müssen. Im Hinblick auf die in Konsultation befindliche Novellierung der MaRisk mit einer Verschärfung der Aufsicht über IT-Auslagerungen[16] sowie die in Ergänzung hierzu konsultierten BAIT[17], aber auch im Hinblick auf die neuen EBA-ICT SREP Guidelines[18] wird es nicht einfach sein den Überblick zu behalten, da die EBA auch nach PSD2 noch den Entwurf von Guidelines zu operationellen und Sicherheitsrisiken sowie zu statistischen Berichten über Betrugsfälle bei Zahlungsdiensten konsultiert[19], die die künftige aufsichtliche Praxis zu § 53 und 54 ZAG konkretisieren werden. Hier bleibt abzuwarten, ob die finalen EBA GL Security Risks tatsächlich einen für das IT-Risikomanagement noch nicht durch gängig verbreiteten „three-lines-of-defense“ Ansatz fordern wird (EBA Draft GL 1.5 Security Risks), der bisher eher aus der allgemeinen Compliancepraxis bekannt ist, und wie stark eine Erstreckung des IT-Risiko- und Sicherheitsmanagements auf Auslagerungsdienstleister betont wird. Bemerkenswert für Banken ist, dass diese – anlassunabhängig und über die bisherige MaSI-Praxis hinausgehend – zur Übermittlung einer (mindestens) jährlichen Bewertung der operationellen und sicherheitsrelevanten Risiken bei Zahlungsdiensten an die BaFin nach § 53 (2) ZAG verpflichtet sein werden.

Darüber hinaus liegen bereits finale EBA Guidelines zur Aufsichtspraxis bei schwerwiegenden Betriebs- oder Sicherheitsvorfällen vor, bei denen Banken nach § 53 ZAG – wie bisher bereits aus den MaSI bekannt – zur Meldung an die BaFin verpflichtet sind, die wiederum die EBA und die EZB hiervon unverzüglich unterrichten wird. Diese EBA GL Incident Reportings greifen nicht nur bei Störfällen im Verantwortungsbereich der Banken, sondern gerade auch bei einer Störwirkung aus der Sicht der Kunden, wenn für diese – ungeachtet einer Verantwortung der Bank – Zahlungskanäle oder -instrumente nicht mehr elektronisch verfügbar oder gestört sind. Da die aufsichtsrechtliche Meldepflicht auch bei Auslagerungslösungen stets bei der Bank verbleibt, hat diese bei Auslagerungsdienstleistern mindestens den Melde- und Informationsfluss an die Bank oder – vermutlich häufig – eine unmittelbare Meldung des Dienstleisters (unter Verantwortung) der Bank an die BaFin sicherzustellen[20]. Hier ist die finale deutsche Praxis der BaFin abzuwarten, ob dann ggf. auch Banken die Delegation von Störfallmeldungen stets vorab unter Vorlage des Auslagerungsvertrages der BaFin anzuzeigen haben, wovon die EBA auszugehen scheint, vgl. EBA GL 3.1 Incident Reporting. In jedem Fall werden Banken künftig auch gesetzlich nach § 54 (4) ZAG verpflichtet sein, deren Kunden über den Störfall und etwaige Reaktionsmaßnahmen zu unterrichten, soweit sich dieser auf die finanziellen Interessen des Kunden auswirken kann.

2. Starke Kundenauthentifizierung – § 55 ZAG

Die starke Kundenauthentifizierung („SKA“), mit mindestens zwei der drei Faktoren Wissen, Besitz oder Biometrie („Zwei-Faktor-Authentifizierung“) (§ 1 (24) ZAG), ist der Bankpraxis bereits nach den MaSI für Internetzahlungen bekannt. § 55 ZAG wird in Phase 2 der PSD2-Umsetzung ab ca. Sommer 2019 darüber hinausgehen und eine SKA fordern, wenn der „Zahler“ (i) online auf sein Zahlungskonto zugreift, (ii) einen elektronischen Zahlungsvorgang auslöst oder (iii) über einen Fernzugang eine sonstige Handlung mit Betrugs- oder Missbrauchsrisiko im Zahlungsverkehr vornimmt. Die gesetzlichen Pflichten zur Anwendung der SKA werden teilweise empfindlich in die Vertragsfreiheit, v. a. zwischen Banken und Kunden, aber auch internationaler Kartenzahlungssysteme eingreifen, ohne dass diese aufsichtlichen Pflichten im Kundenverhältnis – auch nicht gegenüber Unternehmen – abbedungen werden können. Da die verpflichtende SKA auch massiven Einfluss auf die Zahlungsabwicklung im Internethandel haben wird, sind die RTS-Entwürfe der EBA nach Art. 98 (2) PSD 2 umstritten und lösten viele Marktinterventionen aus. Aus dem zweiten EBA RTS-E werden manche Eckpunkte bereits heute der Projektorganisation einer Bank zu Grunde gelegt werden können:

a) Veränderungen zu den MaSI bei der Starken Kundenauthentifizierung

Im Vergleich zur bisherigen Praxis nach den MaSI wird sich Folgendes ändern:

  •  SKA greift nicht nur bei Internetzahlungen (so die MaSI), sondern für alle elektronischen Zahlungen, also auch elektronische Kartenzahlungen am POS-Terminal,
  •  auch der Online-Zugang eines Kunden zu seinem Konto wird eine SKA und damit in der Praxis neben der Eingabe der PIN noch ein Besitzelement (z. B. SMS-/Chip-TAN) oder ein biometrisches Merkmal erfordern,
  •  bei elektronischen Fernzahlungsvorgängen hat die SKA auch ein „dynamic linking“ zum Zahlungsbetrag und -empfänger zu umfassen, § 55 (2) ZAG,
  •  Banken sind zur Akzeptanz der gleichen Authentifizierungsmechanismen verpflichtet, auch wenn der Kunde über einen KID auf sein Konto zugreift oder über einen ZAD eine elektronische Zahlung auslöst, § 55 (3), (4) ZAG.

In welchem Umfang für den Kunden der Online-Zugang zu seiner „Bank-Plattform“ ggf. mit Zahlungs- und Wertpapierkonten und -depots nach Art. 10 EBA-RTS-E eine Ausnahme für Zugriffe 90 Tage nach einem ersten SKA-Zugriff gewähren wird, ist nach der finalen RTS-Fassung noch abzuklären. Wichtig für eine PSD2-Vorbereitung einer Bank ist, dass diese berechtigt, aber nicht verpflichtet ist, die im RTS zugelassenen Ausnahmen von der SKA anzuwenden, rec. 16 EBA RTS-E.

b) Ausnahmen nach EBA RTS und Überweisungsverkehr

Zunächst ist anzumerken, dass die EBA kein Mandat hat, die Fälle zu definieren, in denen die SKA verbindlich anzuwenden ist. Dies ist abschließend durch Art. 97 PSD2 bzw. § 55 ZAG erfolgt. Bei einer nach § 55 ZAG gegebenen Pflicht zur SKA ist die EBA nur berechtigt, die technische Art und Weise der SKA bzw. Ausnahmefälle hierzu zu bestimmen. Im Online-Überweisungsverkehr mit Verbrauchern werden die praktischen Auswirkungen für Banken, die bereits mobile TAN- Verfahren mit einem „Besitzinstrument“ (z. B. Smartphone, Tablet) einsetzen, überschaubar bleiben. Im Firmenkundenbereich hingegen wird es eine Einzelfallfrage sein, ob die jeweils eingesetzten Verfahren den SKA-Anforderungen entsprechen. Gerade der unternehmerische Zahlungsverkehr ist bei den Ausnahmen im RTS zwischen Kommission und EBA noch umstritten. Während die Kommission noch eine eigenständige, von bestimmten Betrugs- raten unabhängige Ausnahme für unternehmerische Zahlungen vorgesehen hat (vgl. Art. 18 Kommissionsvorschlag 24.05.2017), hat die EBA abweichend hiervon nur eine Corporate- Ausnahme in Art. 17 (2) (b) EBA RTS-E vorgeschlagen, falls eine durchschnittliche Betrugsrate von 0,005 % nicht überschritten wird. Für wiederkehrende Zahlungen und inhouse Zahlungen zwischen Konten des gleichen Kunden werden Ausnahmemöglichkeiten für Banken bestehen, Art. 14, 15 EBA RTS-E.

c) Starke Kundenauthentifizierung und Kartenzahlungen

Die größte Herausforderung kommt auf Banken bei elektronischen Kartenzahlungen[21] zu. Kreditkartenzahlungen im Internet haben eine große Bedeutung, werden aber im Regelfall noch ohne dedizierte SKA eingesetzt, was wiederum zur Zeit noch den Markterwartungen an einfache Verfahren entspricht. Eine verpflichtende SKA in e-commerce Transaktionen wird weder bei Kunden noch bei Händlern auf Gegenliebe stoßen, so dass sich gerade Banken als Issuer auf Anfragen zu Ausnahmen einstellen müssen. Für kontaktlose POS-Zahlungen ist eine Kleinbetragsausnahme bis max. 50,00 €, aber kumulativ nicht mehr als 150,00 € oder fünf Transaktionen zu erwarten, Art. 11 EBA RTS-E. Gleiches gilt für die elektronische Bezahlung an automatisierten Parkplatzterminals und bei Mautzahlungen, Art. 12 RTS-E. Für Kartenzahlungen ist noch zu beobachten, ob im finalen RTS die „trusted beneficiary“-Ausnahme (Art. 13 EBA RTS-E) gilt, da dies für die Issuing-Praxis bedeutsam ist. Bei Zulässigkeit müssen sich Banken darauf einstellen, dass Kunden „glaubwürdige“ Internet-Händler auf eine „white list“ setzen möchten, so dass die Bank auf eine SKA im Einzelfall bei diesen verzichten darf. Dies ist für die Kartenpraxis der Bank i. d. R. noch neu, sie muss aber bei e-commerce aktiven Bankkunden auf entsprechende Anfragen vorbereitet sein.

d) Risikobasierte Ausnahme

Auf Druck der e-commerce Wirtschaft wurde für elektronische Fernzahlungen eine risikobasierte Ausnahme geschaffen, Art. 17 EBA RTS-E. Anspruchsvoll hierbei ist, dass Banken auch vorheriges und atypisches Zahlungsverhalten sowie Betrugsanzeichen als Risikofaktoren berücksichtigen sollen, Art. 17 (2)(d); (3) EBA RTS-E. Hierbei dürfen die individuellen Gesamtbetrugsraten eines Issuers für Fern-Kartenzahlungen bestimmte, nach Betragsgrößen gestaffelte Schwellenwerte nicht überschreiten, wobei die Faustformel gilt „je geringer die Betrugsrate – desto höher der einsetzbare Schwellenwert“. Der Annex zu Art. 17, 18 EBA RTS-E legt für Fern-Kartenzahlungen Schwellenwerte von 100 € bei einer Gesamtbetrugsrate von 0,13 % bzw. 250 € bei 0,06 % oder 500 € bei 0,01 % fest. Bei der Entscheidung der Bank, ob diese risikobasierte Ausnahme eingesetzt wird, ist zu berücksichtigen, dass sie nach Art. 3 (2) EBA RTS-E eine mindestens jährliche Prüfung des Konzepts und der ermittelten Betrugsraten vorzunehmen hat, deren Bericht auf Anforderung der BaFin vorzulegen ist. Wird die risikobasierte Ausnahme nicht eingesetzt, ist eine allgemeine Revisionspflicht zur Compliance mit dem RTS nur nach allgemein gebotenen Zeitabständen gegeben, Art. 3 (1) (2)1. UA. EBA RTS-E. Umstritten ist noch, ob die gebotene unabhängige Prüfung durch erfahrene Innenrevisoren oder nur durch externe Prüfer erfolgen darf. Wie bei den anderen RTS-Ausnahmen muss sich auch hier die Bank auf entsprechende Kundenanfragen gefasst machen.

e) Internationaler Karteneinsatz

Wichtig für die Bankpraxis ist auch, dass geklärt werden konnte, dass es für den Einsatz einer deutschen Karte im Nicht-EWR-Ausland (z. B. Einsatz einer deutschen Kreditkarte bei Hotelreservierung und Kreditkartenacquirer in den USA,) aufsichtlich genügen wird, allgemeine Authentifizierungsstandards ohne SKA nach § 55 ZAG einzusetzen[22]. Gleiches gilt für den Einsatz von Nicht-EWR-Karten im Inland.

3. Neue Verfahren zur Streitbeilegung

Neu ist auch, dass Banken Beschwerde- und Streitbeilegungsverfahren zu den BGB-Vorschriften der PSD2 anzuwenden haben, wobei dies für jeden EWR-Staat gilt, in dem die Bank Zahlungsdienste anbietet – also auch im Cross- Border Angebot, § 62 (1), (2) ZAG. Beschwerden sind spätestens innerhalb von 15 Arbeitstagen zu beantworten, soweit nicht eine vorläufige Antwort mit Angabe der Gründe auf eine spätere Beantwortung hinweist, die nicht später als 35 Arbeitstage nach Beschwerdeeingang erfolgen darf, § 62 (3) ZAG. Bemerkenswert ist, dass nach § 62 (4) ZAG Informationspflichten über zuständige Verbraucherschlichtungsstellen bestehen, selbst wenn keine Websites oder AGB verwendet werden bzw. auch, falls es sich um einen unternehmerischen Kunden handelt, § 62 (4) ZAG.

V. Zivilrechtliche Änderungen im klassischen Bankkundenverhältnis

1. Beschränktes Entgelt bei Kartenverlust

Der neue § 675l S.3 BGB beschränkt nun eine Entgeltvereinbarung für den Ersatz verlorener oder missbräuchlich verwendeter Karten auf die ausschließlich und unmittelbar mit dem Ersatz verbundenen Kosten. Nach dem jüngsten BGH-Urteil, das bisher bereits Entgeltvereinbarungen für die Ablehnung von Aufträgen nach § 675o (1) S. 4 BGB streng an den angemessenen und tatsächlichen Kosten ausrichtet[23], dürfte dies keine neue materielle Wirkung entfalten.

2. Unverzügliche Gutschrift bei nicht autorisierten Zahlungsvorgängen, § 675u BGB

Eine wichtige praktische Auswirkung hat die neue Pflicht einer Bank bei Anzeige nicht autorisierter Zahlungsvorgänge spätestens bis zum folgenden Geschäftstag dem Zahler den streitigen Zahlungsbetrag zu erstatten, § 675u S. 3–5 BGB. Einzige Ausnahme ist ein begründeter Betrugsverdacht beim Zahler und eine schriftliche Mitteilung der Bank dazu an eine zuständige Behörde, z. B. die lokal zuständige Staatsanwaltschaft. Nur in diesem Fall beschränkt sich die Pflicht auf eine unverzügliche Prüfung und Erstattung erst dann, wenn sich der Betrugsverdacht nicht bestätigt. Diese Pflicht trifft die Bank auch, wenn der Zahlungsvorgang über einen ZAD ausgelöst wird. Bei streitigen Onlinezahlungen kann der neue § 675u BGB empfindlich in die Kette des Kreditkartenclearings eingreifen, da sich die Acquirer und Akzeptanten auf kurzfristige Chargebacks einzustellen haben und Issuer ohne stark motivierte Karteninhaber (nach Gelderhalt) in Schwierigkeiten kommen, Zweifelsfälle aufzuklären.

3. Verschärfte Haftung, § 675v BGB

Bei verlorenen oder sonst abhanden gekommenen Karten kann die Regelhaftung des Zahlers nur noch bis zu einem Betrag von 50 € durchgesetzt werden. Dies gilt allerdings nicht, wenn es ihm nicht möglich war, den Verlust oder sonstigen Missbrauch rechtzeitig zu bemerken. Die abweichende Haftung des Zahlers nach § 675v (3) BGB bei vorsätzlicher oder grob fahrlässiger Pflichtverletzung (wie bisher) steht in Spannung zu Abs. 4, wonach der Zahler auch in diesen Fällen nicht zum Schadensersatz verpflichtet ist, wenn seine Bank eine SKA nicht verlangt oder der Zahlungsempfänger oder dessen Acquirer eine SKA nicht akzeptiert, es sei denn der Zahler hat in betrügerischer Absicht gehandelt. Dieses Haftungskonzept steht in evidentem Widerspruch zu den kommenden EBA RTS Ausnahmen zur SKA nach § 55 ZAG. Ist es denkbar, dass sich eine Bank aufsichtskonform mit Praktizierung einer SKA-Ausnahme verhält, dadurch aber dennoch ein gesteigertes Haftungsrisiko nach § 675v (4) BGB eingeht? Wohl kaum, auch wenn die Wortlaute der PSD2 sowie des ZDUG hierzu schweigen. Europarechtlich ist allerdings vorrangig die zweckgerichtete Auslegungsmethode heranzuziehen[24]. Richtigerweise sollte in richtlinienkonformer Auslegung der PSD2 mit dem ausdrücklichen EBA Mandat zur Bestimmung zulässiger SKA-Ausnahmen nach Art. 98 PSD2 die verschärfte Haftung nach § 675u (4) BGB nur greifen, wenn ein Issuer oder ein Acquirer „rechtswidrig“ die SKA nicht anwendet, also unter Verstoß gegen geltendes Aufsichtsrecht.

4. Erstattungen bei Lastschriften und surcharging-Verbot

Die PSD2 räumt Bankkunden bei Lastschriften nun schon ein gesetzliches Erstattungsrecht ein, ohne dass dies künftig (wie heute) gesondert vereinbart werden muss, § 675x (2) BGB. Dies gilt für alle auf Euro lautenden SEPA-Basis- als auch SEPA-Firmenlastschriften[25]. Abweichend von PSD1 regelt § 270a BGB nun für Zahlungsempfänger ein ausdrückliches surcharging-Verbot für die Nutzung von SEPA- Lastschriften oder SEPA-Überweisungen. Bei einer Zahlungskarte gilt dies nur bei Zahlungsvorgängen mit Verbrauchern, wenn auf diese die Entgeltbegrenzung nach der Interchange-Verordnung (EU/751/2015) anwendbar ist.

PRAXISTIPPS

  • Bei Implementierung der PSD2 muss das zweistufige Wirksamwerden des ZAG zum 13.01.2018 sowie mit dem RTS zum Sommer 2019 beachtet werden. Teilbanken mit ZAG -Erlaubnis müssen rasch eine neue ZAG -Erlaubnis nach PSD2 beantragen, um die alte ZAG -Erlaubnis nicht ab 13.07.2018 zu verlieren.
  • Das neue ZAG wird Banken stärker betreffen als das ZAG nach PSD1, da bei der Ausrichtung der IT-Sicherheitsorganisation nach den künftigen MaRisk und BAIT auch die neuen EBA-Guidelines zum Störfallmanagement, zu den IT-Sicherheitsrisiken und zum fraud reporting im Zahlungsverkehr nach PSD2 umgesetzt werden müssen. Hierzu gehören auch die rechtzeitige Einbindung von Auslagerungsdienstleistern und die Sicherstellung statistischen Materials für das Betrugsreporting an die BaFin.
  • Strategisch sollte die Auswirkung der Drittdienstleistungen auf die elektronische Kommunikation der Bank mit ihren Kunden bewertet werden. Rechtlich muss hierbei das Haftungsrisiko im Umgang mit widerrufenen Aufträgen durch Kunden nach § 675p (2) BGB beachtet werden.
  • Eine Bank sollte sich rechtzeitig auf die Behandlung von Kundenanfragen zum Umgang mit RTS-Ausnahmen zur starken Kundenauthentifizierung vorbereiten und die Auswirkungen im Firmenkundengeschäft frühzeitig beachten. Hierbei sollten Prüfaufwände nach Ar t. 3 EBA RTS-E bei Anwendung der risikobasierten Ausnahme nach Ar t. 17 EBA RTS-E berücksichtigt werden.
  1. BGBl. 2017, 2.446.
  2. BaFin Rundschreiben 5/2015, „Mindestanforderungen an die Sicherheit von Internetzahlungen“.
  3. Vgl. Amtl. Begründung ZDUG, BT-Drs. 18/11495, S. 104.
  4. Artt. 10, 16 EU-Verordnung 1093/2010.
  5. EBA-Op-2017-09 vom 29.06.2017.
  6. Vgl. Art. 13 Abs. 1 EU-Verordnung 1093/2010.
  7. Final EBA GL Authorization v. 11.07.2017, EBA/ GL/2017/09.
  8. Final EBA GL Incident Reporting vom 27.07.2017,

    EBA/GL/2017/10.

  9. EBA Draft GL Security Risks vom 05.05.2017,

    EBA/CP/2017/04.

  10. EBA Draft GL Fraud Reporting vom 02.08.2017,

    EBA/CP/2017/13.

  11. Vgl. EBA GL/2017/10 Incident Reporting, EBA Draft GL Security Risks und EBA Draft GL Fraud Reporting.
  12. Vgl. nrk Beschl. des Bundekartellamt vom 29. 06.2016 (B 4-71/10).
  13. Vgl. zusätzlich Final EBA GL Professional Indemnity Insurance vom 07.07.2017, EBA/GL/2017/07.
  14. Vgl. EBA-Op-2017-09 vom 29.06.2017, S. 8; Schmidt/Reinshagen/BaFin, GSK PSD2 Konferenz 17.05.2017, S. 26, https://www.gsk.de/de/veranstaltungen/veranstaltungsarchiv
  15. Vgl. hierzu Eschenlohr und Bernau, GSK PSD2- Konferenz 17.05.2017 (Fn. 14), Drittdienstleister und FinTech-Kooperationen.
  16. BaFin-Konsultation MaRisk 1/2016, AT 9.
  17. BaFin-Konsultation Bankaufaufsichtliche Anforderungen an die IT (BAIT) 02/2017.
  18. EBA Final Guidelines on ICT Risk Assessment under SREP vom 11.05.2017, EBA/GL/2017/05.
  19. Vgl. EBA Draft GL Security Risks (Fn. 9) und EBA Draft GL Fraud Reporting (Fn. 10).
  20. EBA GL/2017/10 Incident Reporting GL 3.1.
  21. Für handschriftlich bestätigte Kartenzahlungen konnte geklärt werden, dass diese nicht der SKA unterfallen (vgl. Bericht des Finanzausschusses, BT-Drs. 18/12568, S. 153).
  22. Vgl. Bericht des Finanzausschusses , BT-Drucksache 18/12568, S. 153, 154.
  23. Vgl. BGH-Urt. v. 12.09.2017 – XI ZR 590/15.
  24. EuGH-Urt. v. 18.03.2017 („Martini”) (C-211/12).
  25. Vgl. vgl. Amtl. Begründung ZDUG, BT-Drs. 18/11495, S. 82.

 

Beitragsnummer: 89256

Vereinfachte Bewertung von Auslagerungen durch definierte Negativliste

Ina Märzluft, Senior Consultant/Prokuristin, FCH Consult GmbH

Mit der Veröffentlichung der umfangreichen Leitlinien der European Banking Authority (EBA) zur Bewertung von Auslagerungsvereinbarungen wurde ein einheitliches Rahmenwerk für Auslagerungen geschaffen. Für alle ab dem 30.09.2019 abgeschlossenen Auslagerungsverträge müssen die neuen Vorgaben beachtet werden, was in der Umsetzung nicht immer einfach ist.

SEMINARTIPPS

PraxisFalle IT Dienstleistungen: Sonstiger Fremdbezug vs. Auslagerung, 22.06.2020, Frankfurt/Offenbach.

Risikoanalysen bei Auslagerungen, 02.11.2019, Hamburg.

Unter einer Auslagerung ist dabei jede Vereinbarung zu verstehen, nach der ein Service Provider einen Prozess, eine Dienstleistung oder eine Aktivität übernimmt, die sonst durch das Institut selbst vorgenommen würde.

INHOUSETIPP

Auslagerungsmanagement.

 

 

Zur kleinen Vereinfachung wurde eine Negativ-Liste (Whitelist) in der Textziffer 28 der EBA-Leitlinien zu Auslagerungen EBA/GL/2019/02 mit Funktionen aufgenommen, deren Übertragung auf Dritte, als Fremdbezug betrachtet wird.

Grundsätzlich werden damit folgende Fälle nicht als Auslagerung betrachten:

  • eine Funktion, die aufgrund von Rechtsvorschriften von einem Dienstleister wahrzunehmen ist, z. B. Abschlussprüfungen;
  • Marktinformationsdienste (z. B. Bereitstellung von Daten durch Bloomberg, Moody’s, Standard & Poor’s, Fitch);
  • globale Netzinfrastrukturen (z. B. Visa, MasterCard);
  • Clearing- und Abwicklungsvereinbarungen zwischen Clearingstellen, zentralen Gegenparteien und Abwicklungsstellen sowie ihren Mitgliedern;
  • globale Nachrichteninfrastrukturen zur Übermittlung von Zahlungsverkehrsdaten, die der Aufsicht durch einschlägige Behörden unterliegen;
  • Korrespondenzbankdienstleistungen und
  • der Erwerb von Dienstleistungen, die anderenfalls nicht vom Institut oder Zahlungsinstitut erbracht würden (z. B. Beratung durch einen Architekten, Bereitstellung eines Rechtsgutachtens und Vertretung vor Gericht und Verwaltungsbehörden, Reinigung, Gartenarbeiten und Instandhaltung der Räumlichkeiten des Instituts oder Zahlungsinstituts, medizinische Dienstleistungen, Wartung von Firmenwagen, Verpflegungsdienste, Automatenservices, Bürodienstleistungen, Reisedienstleistungen, Poststellendienste, Rezeptionskräfte, Sekretariatskräfte und Telefonisten), von Waren (z. B. Plastikkarten, Kartenlesegeräte, Büromaterial, Computer, Möbel) oder Versorgungsleistungen (z. B. Strom, Gas, Wasser, Telefon).

Es ist wichtig, dass die Verträge mit den Auslagerungsunternehmen, ob es sich um eine Auslagerung oder einen Fremdbezug handelt, vor Vertragsabschluss überprüft werden. Denn sowohl bei Auslagerungen als auch Fremdbezügen muss vorab eine Risikoanalyse durchgeführt werden.

BERATUNGSTIPP

Implementierung eines effizienten & wirksamen Auslagerungsmanagements.

 

Für die risikoorientierte Überprüfung bestehender wesentlicher Auslagerungsverträge gibt es eine verlängerte Umsetzungsfrist bis zum 31.12.2021.

Eine regelmäßige Überwachung und Kontrolle der Auslagerung muss aufgrund der aufsichtsrechtlichen Vorgaben durch einen definierten Prozess und in Vereinbarung mit dem Service Provider durchgeführt und sichergestellt werden.

PRAXISTIPPS

Mit der Durchführung der Risikoanalyse nach den Anforderungen der EBA-Leitlinien und gemäß der institutsindividuellen OpRisk-Methode erfüllen Sie die aufsichtsrechtlichen Vorgaben für jede Auslagerung in Ihrem Institut.

Wir empfehlen Ihnen, sich frühzeitig mit den neu anstehenden Pflichten der EBA-Leitlinie im Auslagerungsmanagement auseinanderzusetzen. Bitte prüfen Sie kritisch Ihren Einkaufsprozess und überwachen Sie die Bewertung und Pflege der Dienstleistungen von Ihren Service Providern in einem Auslagerungsregister.

Beitragsnummer: 86904

Prozessprüfung und agree21Vorgang



Michael Claaßen, Bereichsleiter, Interne Revision, Volksbank Marl-Recklinghausen eG.

I. Grundlagen

Innerhalb des genossenschaftlichen Bereiches werden seit einiger Zeit die Banken, die in der Vergangenheit das Kernbankverfahren bank21 genutzt haben, auf das Kernbankverfahren agree21 migriert. Das Kernbankverfahren führt zur Implementierung neuer Prozesse. Die risikomanagementgestaltenden Softwarelösungen für die aufsichtsrechtlichen Anforderungen werden in den betroffenen Banken somit neugestaltet. So werden nach AT 4.3.1 Tz. 2 der MaRisk die Prozesse und die damit verbundenen Aufgaben, Kompetenzen, Kontrollen und teils auch Kommunikationswege softwarebasiert neu geordnet. Berechtigungen und Kompetenzen sind dabei nach dem Sparsamkeitsgrundsatz (Need-to-know-Prinzip) in agree21 neu zu vergeben. Zur Administration gehört weiterhin der Institutskennsatz (IKESA), der die Parametrisierung wesentlicher Vorgaben beinhaltet.

Eine der wesentlichen Stärken des Kernbankverfahrens stellt die Vorgangssteuerung dar. Für die einzelnen Geschäftsaktivitäten können Vorgänge genutzt werden. Diese können einen Standard definieren. Es ergibt sich ein Workflow, der die einzelnen Prozessschritte mit teils unterschiedlichen Aufgabenträgern, der Nutzung von Formularen und Checklisten sowie systembasierten Kontrollroutinen beinhalten kann. Notwendige Aufgaben können in der Aufgabenliste eines Mitarbeiters erzeugt werden. Ein Eskalationsverfahren und ein Prozesscontrolling sind wichtige Komponenten im Rahmen dieses Prozessmanagements. Vorgänge werden über eine bankindividuelle Menüstruktur (BIM) aufgerufen. Diese BIM kann für unterschiedliche Verteiler, wie Markt oder Marktfolge ...


Weiterlesen?


Dies ist ein kostenpflichtiger Beitrag aus unseren Fachzeitschriften.

Um alle Beiträge lesen zu können, müssen Sie sich bei meinFCH anmelden oder registrieren und danach eines unserer Abonnements abschließen!

Anmeldung/Registrierung

Wenn Sie angemeldet oder registriert sind, können Sie unter dem Menüpunkt "meinABO" Ihr aktives Abonnement anschauen oder ein neues Abonnement abschließen.

Wozu braucht man einen IKS-Beauftragten?

Michael Helfer, Geschäftsführer, FCH Consult GmbH

I. Noch ein Beauftragter: Sinn oder Unsinn?

Es vergeht keine Woche, in der nicht eine wesentliche aufsichtsrechtliche Neuerung die Institute erreicht. Diese wird dann zumeist intern verteilt und im besten Fall einem Prozessverantwortlichen zugeordnet. Darüber hinaus müssen für wesentliche Prozessänderungen bestimmte Mechanismen vorhanden sein (z. B. MaRisk AT 8.2: Einbindung der diversen Compliance-Beauftragten, des Risikocontrollings und der Internen Revision). Oftmals funktionieren diese Prozeduren nur auf dem Papier (welches als Umlaufzettel durch die Bank geleitet wird), nicht aber materiell. In der Praxis ist auch zu beobachten, dass vielfach (auch aus der schieren Not der Vielzahl der Neuerungen) sogenannte Potemkinsche Dörfer errichtet werden (d. h. es werden Arbeitsrichtlinien und Arbeitsanweisungen erstellt, die jedoch materiell nicht greifen bzw. gelebt werden).

Ferner ist seit Einführung der MaRisk im Jahre 2005 eine wahre Inflation von entstandenen Kontrollen zu beobachten. Eine klassische Regionalbank hat in der Regel ca. 600–1.000 manuelle Kontrollen, welche mehr oder weniger regelmäßig ausgeführt werden. Da es keine zentrale Verantwortung für dieses Thema gibt, versuchen die verantwortlichen Fachbereiche die ihnen zugeordneten Kontrollen nach besten Wissen und Gewissen (in der zur Verfügung stehenden Zeit) zu managen. Die Problematik bei manuellen Kontrollen ist, dass diese händig ausgeführt werden müssen und damit Zeit (und Geld) kosten. Zudem ist die Fehleranfälligkeit für diese Kontrollprozesse, durch den Faktor Mensch bedingt, recht hoch. Bei in der Praxis durchgeführten Projekten ist regelmäßig zu beobachten, dass Hunderte von Kontrollen bestehen, welche nicht auf Risiken oder konkrete gesetzliche Vorgaben einzahlen (im Ergebnis also abgeschafft werden könnten).

SEMINARTIPPS

Zertifizierung

Zertifizierter IKS-Beauftragter, 04.–07.05.2020, Berlin.

IKS-Seminare

IKS KOMPAKT: Aufbau & Management einer IKS-Organisation, 04.05.2020, Berlin.

Praktische Vorgehensweisen zur Implementierung eines IKS, 05.05.2020, Berlin.

Der (zukünftige) IKS-Beauftragte, 06.05.2020, Berlin.

IKS-Bewertung & Festlegung wesentlicher Prozesse, 07.05.2020, Berlin.

(Neue) IKS-Kontrolltests im (LSI-)SREP, 25.06.2020, Frankfurt/M.

IKS Kompakt: Aufbau & Prüfung von Schlüsselkontrollen, 07.10.2020, Frankfurt/M.

Weitere Seminarempfehlungen

Prozesse/Orga-Handbuch & IKS, 25.–26.03.2020, Köln.

Schlüsselkontrollen Spezial: Kreditprozesse, 18.06.2020, Frankfurt/M.

Im Prüfungsfokus: Wesentliche Prozesse & AT 8.2, 08.10.2020, Frankfurt/M.

Erschwerend kommt hinzu, dass es zahlreiche Bereiche in einer Bank gibt, die am Design und Test von Kontrollen bis hin zur Berichterstattung mitwirken, aber jeder aus seinem eigenen Blickwinkel bzw. auf der Basis seines Aufgabenprofils (z. B. Compliance-MaRisk, Compliance-WpHG, Geldwäschebeauftragter/Zentrale Stelle, Auslagerungsbeauftragter, Informationssicherheitsbeauftragter, Datenschutzbeauftragter etc.). Und hier besteht eine weitere Herausforderung: Im Kern geht es darum, welche Funktion (Rolle) innerhalb eines Instituts welche konkreten Aufgaben insbesondere innerhalb des IKS wahrnimmt und das dies auf einer transparenten Basis passiert (als wesentliche Voraussetzung dafür, dass keine Doppelarbeiten oder gar Kontrolllücken entstehen).

Neben einer ohnehin sinnvollen Überlegung, das Beauftragtenwesen besser zu koordinieren bzw. sogar zu zentralisieren, kann hier die Funktion des IKS-Beauftragten einen wesentlichen Mehrwert leisten, um sicherzustellen, dass für die Geschäftsleitung und den Aufsichtsrat eine proaktive Steuerung des internen Kontrollsystems (und damit des Managements der prozessinhärenten Risiken erfolgt).

II. Zentrale Koordinierung & Steuerung der IKS-Anforderungen

Grundvoraussetzung für eine schlanke Umsetzung der Regulatorik ist, wie zuvor ausgeführt, ein abgestimmtes und dokumentiertes Rollenverständnis aller Beteiligten der sog. „ersten, zweiten und dritten Verteidigungslinie“ (sog. „Three-Lines-of-Defence-Modell“ oder auch „3 LoD“). Die Bereiche der ersten Verteidigungslinie sind nach den MaRisk für die Implementierung und Durchführung des IKS im zugeordneten Prozess verantwortlich. Dazu gehören u. a. die Bewertung der operationellen Risiken, das Sicherstellen einer angemessenen Implementierung von Kontrollen im Prozess (diese müssen auf die Risiken „einzahlen“) nebst der erforderlichen aufbauorganisatorischen Kontrollen, die Verantwortung für Durchführung und Qualität der der angewiesenen Kontrollen, die Verantwortung für die Richtigkeit und Vollständigkeit der Daten, das Initiieren und Mitwirken an Verbesserungen der Kontrollen sowie die Verantwortung für die Umsetzung von regulatorischen Änderungen und Neuerungen (insbesondere der wesentlichen) in der Aufbau- und Ablauforganisation (inkl. IT). Zu den Bereichen der zweiten Verteidigungslinie gehören u. a. Compliance, Geldwäsche, Organisation, Prozessmanagement, IKS-Steuerung, Auslagerungsstelle, IT-Sicherheit, Datenschutz, FRAUD-Prävention, Marktfolge aktiv (risikorelevantes Kreditgeschäft), Risikocontrolling. Ihre Aufgabe besteht im Wesentlichen darin, die ordnungsgemäße Aufgabenwahrnehmung der ersten Verteidigungslinie zu überwachen sowie gegebenenfalls qualitätssichernden Maßnahmen durchzuführen. Die dritte Verteidigungslinie wird durch die Interne Revision wahrgenommen, welche das IKS risikoorientiert zu prüfen hat.

FILMTIPPS

IKS 2.0 Schlüsselkontrollkonzept

Auswirkungen der neuen Fit & Proper-Anforderungen

Film: OpRisk – Neue MaRisk & Neuer Standardansatz

Neuer AT 9 – Handlungsbedarf für die Orga

Risikokultur & Unternehmensethik

Vorstandshaftung

Der IKS-Beauftragte hat in diesem System die Aufgabe, die internen Kontrollen zu managen, d. h. einen wirksamen Managementkreislauf zu implementieren, angefangen bei einer vollständigen Kontrollinventarisierung, der Initiierung regelmäßiger Kontrolltests bis hin zur Berichterstattung an die Geschäftsleitung und gegebenenfalls das Monitoren etwaiger Verbesserungspotenziale (vgl. Schaubild).

3. Fachliches Know-how für den IKS-Beauftragten

Die mittlerweile zahlreichen IKS-Vorgaben, wie z. B. eine geforderte IKS-Wirksamkeits-Überwachung und drohende Konsequenzen, wie z. B. Kapitalzuschläge bei IKS-Mängeln, erfordern daher eine Systematisierung und Dokumentation des IKS, damit die Geschäftsleitung in regelmäßigen Abständen einen Bericht über den Zustand des internen Kontrollsystems erhalten kann. Diesbezüglich wird eine Koordinierungsfunktion im Institut benötigt, welche sich um die zuvor beschriebenen Erfordernisse kümmert. Je nach Größe des Hauses kann diese Funktion als separate Stelle oder auch angedockt an andere Beauftragten-Funktionen (oder auch dem Organisations-/Prozessmanagementbereich) zugeordnet werden.

Damit der IKS-Beauftragte die zugeordneten Aufgaben angemessen (und pragmatisch) umsetzen kann, empfiehlt sich der Erwerb bzw. das Update zu folgenden Themenbereichen:

  • Aufbau & Management einer IKS-Organisation (regulatorische Grundlagen, praxiserprobte Modelle, Aufgaben und Kompetenzen der jeweiligen Beauftragten, etc.)
  • Praktische Vorgehensweisen zur Implementierung eines professionalisierten IKS (prozessorientierte Ausrichtung, Verschlankung des Anweisungswesens, Schärfung der unterschiedlichen Rollenprofile im Institut)
  • Aufgaben, Kompetenzen und Verantwortlichkeiten eines IKS-Beauftragten (regelmäßige Aktivitäten und Abstimmungen mit anderen Beauftragten, Einbindung in interne Entscheidungsprozesse, Berichterstattung an die Geschäftsleitung)
  • Modelle zur IKS-Bewertung und Festlegung wesentlicher Prozesse (Einbindung der Methodik operationeller Risiken, Initiierung der Vereinheitlichung der im Institut unterschiedlichen Risikoanalysen).

BERATUNGSANGEBOTE

IKS Kompakt: Aufbau & Prüfung von Schlüsselkontrollen

Prozessmanagement im Fokus von MaRisk & BAIT: Aufbau/Bewertung & Auditierung

Quick Check „Entschlacktes Organisationshandbuch“

Starter-Kit Risikokultur

Fit für die Sonderprüfung nach § 44 KWG

Fit für MaRisk-Prüfung Gesamtbanksteuerung

Fit für die BAIT und die Sonderprüfung-IT

Quality Assessment & Performance-Analyse der Internen Revision

Effektives & effizientes Zusammenspiel von Compliance & Interner Revision

Implementierung eines effizienten & wirksamen Auslagerungsmanagements

Quick-Check Beauftragtenwesen

Prüfung MaRisk-Compliance

Sie haben Fragen? Sprechen Sie mich gerne an:

Michael Helfer, Geschäftsführer

Tel.: +49 6221 99 89 8 – 0

E-Mail: Michael.Helfer@FC-Heidelberg.de

www.fchconsult.de

FCH Consult GmbH

Im Bosseldorn 30

D-69126 Heidelberg

Beitragsnummer: 84063

Fremdbezug softwarebezogener IT-Dienstleistungen

Aufsichtsrechtliche Einstufung und resultierende Anforderungen

Prof. Dr. Dirk Heithecker, Professur für Quantitative Methoden und Corporate Finance, Hochschule Hannover, und Fachreferent, Kredit- und Restwertrisikomanagement, Volkswagen Bank GmbH (Der Beitrag gibt ausschließlich die persönliche Auffassung und Einschätzung des Autors wieder)

Die Neuerungen und Konkretisierungen im Umgang mit Auslagerungen sind eine der wesentlichen inhaltlichen Anpassungen der 5. Novelle der Mindestanforderungen an das Risikomanagement (MaRisk), deren Frist zur Umsetzung im Oktober endet. Im Zusammenhang mit dem Bezug von Software gelten zudem seit November 2017 die Bankaufsichtlichen Anforderungen an die IT (BAIT). Im vorliegenden Beitrag wird die inhaltliche Abhängigkeit beider Vorgaben erörtert.

Software als Fremdbezug von IT-Dienstleistungen

Vor dem Hintergrund der Vorgaben des § 25a (1) und § 25b KWG gelten besondere Anforderungen im Umgang mit dem Fremdbezug von Leistungen in Kreditinstituten. Zu diesen Leistungen zählen auch IT-Dienstleistungen, die besondere, auf die IT bezogene Aktivitäten darstellen. Dies schließt die Bereitstellung von IT-Systemen, von Projekten und Gewerken oder auch die Personalgestellung im IT-Bereich ein. Die Implementierung von Software dürfte aufsichtsrechtlich auch als Fremdbezug von IT-Dienstleistungen einzustufen sein (vgl. MaRisk, AT 9, Tz. 1, Erläuterungen und auch BAIT, Tz. 52, Satz 3), wenngleich durch Bankenverbände während der Konsultation andere Auffassungen vertreten wurden (vgl. DK, Konsultation des Rundschreibens BAIT, S. 15 und DK, Stellungnahme 5. MaRisk-Novelle, S. 28 ff.). Sogar der isolierte Bezug von Software, aber auch softwarebezogener IT-Dienstleistungen im Rahmen der Implementierung und Nutzung – so genannte Unterstützungstätigkeiten, vgl. Tabelle – gelten per se als Fremdbezug.

 

 

 

 

 

 

Software und Unterstützungsleistung als Auslagerung oder sonstigem Fremdbezug

Die MaRisk unterscheiden beim Fremdbezug von Leistungen zwischen Auslagerungen und sonstigem Fremdbezug (vgl. MaRisk, AT 9, Tz. 1), entsprechend gilt diese Unterscheidung auch für den Fremdbezug von Software. Nach Wortlaut der MaRisk können in der Regel aber nur Unterstützungstätigkeiten beim Fremdbezug von Software den Tatbestand der Auslagerung erfüllen. Im Fokus stehen dabei nur Leistungen für Software, die im Rahmen von Kontrollfunktionen (Risikocontrolling etc.) oder in Kernbankbereichen eingesetzt werden (vgl. MaRisk, AT 9, Tz. 1, Erläuterungen). Liegt eine Auslagerung vor, so sind umfassende MaRisk-Vorgaben an die Organisation, Risikoanalyse und Risikosteuerung, Kontinuität der Geschäftsprozesse und Vertragsgestaltungen zu erfüllen (vgl. Heithecker, Risikokonzentrationen bei Auslagerungen, BankPraktiker, demnächst). Der isolierte Bezug von Software (und deren Implementierung, Testen und Freigabe durch das Kreditinstitut selbst) sollte hingegen nicht als Auslagerung eingestuft werden – unabhängig vom Einsatz.

 SEMINARTIPPS:

Auslagerungsverträge auf dem Prüfstand, 15.11.2018, Frankfurt/M.

Prüfung Auslagerungsprozesse, 22.11.2018, Köln.

Auslagerungen im Fokus neuer MaRisk & BAIT, 10.12.–11.12.2018, Frankfurt/M.

 

Entsprechend der bisherigen Abgrenzung ist der isolierte Fremdbezug von Software einschließlich der Unterstützungsleistungen, die nicht den Tatbestand der Auslagerung erfüllen, ein sonstiger Fremdbezug. Hier sind „lediglich“ die allgemeinen Anforderungen an die Ordnungsmäßigkeit der Geschäftsorganisation zu erfüllen, die jedoch in den BAIT konkretisiert werden (vgl. BAIT, Tz. 53 bis 56). So muss vorab eine Risikobewertung vorgenommen werden, zudem ist der Fremdbezug risikoorientiert zu steuern und die Leistungserfüllung zu überwachen. Ferner sind Vereinbarungen zum Notfallmanagement einschließlich von Exit- und Alternativstrategien festzulegen. So mögen diese Vorgaben in regelmäßig üblichen Fällen, etwa beim Bezug von Standardsoftware, durch übliche Vorkehrungen eines Instituts (Programmeinsatzverfahren einschließlich Costumizing, Testdurchführung, Freigabe), einfach umzusetzen sein. Dennoch ergeben sich strukturell zur Auslagerung gleiche Anforderungen, die jedoch inhaltlich weniger anspruchsvoll und umfassend einzustufen sind.

 BUCHTIPPS:

Auslagerung nach MaRisk, 2018.

Riediger (Hrsg.): Auslagerungen & Dienstleister-Steuerung, 2018.

 

 

Fazit

Durch die augenscheinliche Einstufung als Fremdbezug und aufgrund der zusätzlich in den BAIT formulierten Vorgaben zur Umsetzung einer ordnungsgemäßen Geschäftsorganisation gleichen sich die Umsetzungsbedarfe bei softwarebasierten IT-Dienstleistungen unabhängig einer weiteren Kategorisierung als Auslagerung oder sonstiger Fremdbezug an. Die Vorgaben an den sonstigen Fremdbezug sind unter Proportionalitätsgesichtspunkten im Vergleich zur Auslagerung sicherlich weniger umfassend, müssen jedoch weitestgehend gleiche Themenstellung abdecken. Es empfiehlt sich somit, die Erfüllung der Vorgaben an den sonstigen Fremdbezug und an die Auslagerung bei softwarenahen IT-Dienstleistungen (Softwarebezug einschließlich Unterstützungstätigkeiten) aus einer Hand zu steuern.

PRAXISTIPPS

  • Erstellen Sie eine vollständige, strukturierte Vertragsübersicht ihrer eingesetzten Software und damit zusammenhängender Unterstützungsleistungen.
  • Legen Sie für die Steuerung fest, welche dieser Leistungen gebündelt und identisch betrachtet werden können.
  • Nutzen Sie Ihre Prozesse und Kenntnisse des Auslagerungsmanagements zur adäquaten Einstufung und vereinfachten Steuerung softwarebezogenen IT-Dienstleistungen im sonstigen Fremdbezug.

Beitragsnummer: 43384

Datenqualität: Herausforderungen für die Interne Revision

Andreas Freßmann, Leiter Produktions- und Steuerungsrevision, Sparkasse Münsterland Ost

Externe und interne Motivation zur Gewährleistung einer hohen Datenqualität

Die stetige Weiterentwicklung der bankaufsichtlichen Anforderungen im Bereich der quantitativen Regulierung sowie auch die immer anspruchsvolleren Rahmenbedingungen im Wettbewerb fordern die Institute im Bereich der Datenqualität weiterhin an mehreren Fronten zu erheblichen Anstrengungen heraus:

Eine hohe Qualität der melderelevanten Daten ist zu gewährleisten, um anforderungskonforme Meldungen abgeben zu können.
Mangelhafte Datenqualität führt zu ungenauem Berichtswesen, Fehlentscheidungen, Sanktionierung, Minderung der Effizienz und Wirtschaftlichkeit (Fehlerbereinigung), Vertrauens- und Imageverlust. Datenqualität ist deshalb ein wichtiger Wettbewerbsfaktor. Die Datenerfassungs- und Qualitätssicherungsprozesse sind regelmäßig zu evaluieren. Die Kontrollen sind proportional zur Bedeutung des Prozessschrittes bzw. Datenfeldes so auszugestalten, dass Fehler vermieden bzw. identifiziert werden (Risiko-Kontroll-Matrix). Dabei wird seitens der Aufsicht die Einrichtung eines Systems von Kontrollen und Plausibilitätsprüfungen sowohl innerhalb des Datenkranzes einer Meldung als auch Kontrollen und Plausibilitätsprüfungen zwischen den verschiedenen Meldungen erwartet.

Das Zusammenspiel von Finanz- und Risikofunktionen, insbesondere in den Bereichen Risikosteuerung, Risikocontrolling, Rechnungswesen und Meldewesen muss immer wieder hinsichtlich der Effizienz justiert werden. Dabei schaffen immer komplexere Datenaggregationen und verschärfte zeitliche Anforderungen Einfallstore für Qualitätsmängel und erhöhen das Fehlerrisiko.

Beiträge der Internen Revision zur Gewährleistung und Sicherung der Datenqualität

Die Interne Revision kann durch ihr Prüfungshandeln und die Prozesskompetenz Mehrwerte zur Gewährleistung und dauerhaften Sicherung der Datenqualität liefern. Dabei sind in einem ersten Schritt Aufbau- und Prozessprüfungen im Zuge der Etablierung bzw. Optimierung der Datenerfassungs- und Qualitätssicherungsprozesse angezeigt, bevor zeitlich danach durch Funktionsprüfungen und Datenchecks Feinsteuerungsbedarf identifiziert werden kann. Ein aus den gesetzlichen Regelungen auf das Institut angepasster und dauerhaft wirksamer Ordnungsrahmen incl. IKS ist wiederholten „Datenbereinigungsaktionen“ vorzuziehen.

In den folgenden Handlungsfeldern ist die Interne Revision besonders herausgefordert:

Prozesstransparenz und Organisationsrichtlinien

Die Erstellung effizienter Organisationsrichtlinien setzt in der Regel Prozesstransparenz voraus. Diese ist häufig noch zu erhöhen. Basis für die Erstellung einer Organisationsrichtlinie mit entsprechendem Nutzwert ist eine Prozesslandkarte, die alle in die Prozesse involvierten Stellen einschließlich der dabei eingesetzten DV-Anwendungen aufzeigt. Zudem müssen die an der jeweiligen Meldung beteiligten Stellen und ihre Verantwortlichkeiten im Sinne einer Schnittstellenmatrix bekannt sein. Auf dieser Basis können dann zügig mögliche Fehlerquellen sowohl im Zusammenhang mit der Datenbasis als auch mit der Datenverarbeitung identifiziert werden. Daneben ist zur Fundierung einer ausreichenden Prozessstabilität besonderes Augenmerk auf die angemessene (inhaltliche) Ausgestaltung und Aktualität der Organisationsrichtlinien zu legen.

BUCHTIPPS

Bearbeitungs- und Prüfungsleitfaden: Meldewesen, 2017.

IT im Fokus der Bankenaufsicht, 2. Aufl. 2015.

 

 

Abstimm- und Plausibilisierungshandlungen

Im Vorfeld der Meldungsabgabe kommt den verschiedenen Abstimm- und Plausibilisierungshandlungen hohe Bedeutung zu. Revisionsseitig ist neben der Auswahl sinnvoller Abstimmgrößen sowohl innerhalb der Meldung als auch meldungsübergreifend und der konsequenten Durchführung auch die geeignete Dokumentation dieser Arbeitsschritte zur Nachverfolgung von Differenzen zu bewerten.

Kontrollen und Kontrollqualität

Die prozessintegrierten Kontrollhandlungen sollten so effizient wie möglich gestaltet werden. Hierzu sind vom Fachbereich unter Berücksichtigung der inhärenten Risiken und der Kontrollrisiken auch die notwendigen Schlüsselkontrollen und deren erforderliche qualitative Ausgestaltung nachvollziehbar abzuleiten. Um durchzuführende Kontrollhandlungen einerseits zu rechtfertigen und andererseits ausreichend zu operationalisieren, sollten zu jeder Kontrolle ein Kontrollverantwortlicher, ein eindeutiges Kontrollkriterium, das Kontrollintervall und das verfolgte Kontrollziel festgelegt werden. Diese sind dann im Prüfungsverlauf auf ihr Vorhandensein bzw. ihre Wirksamkeit hin zu überprüfen.

SEMINARTIPPS

Externe Daten & Ratings nach neuen MaRisk: eigene Plausibilisierungen – Dokumentation – Verwendung, 16.10.2018, Frankfurt/M.

Verlustdaten & Erlösquoten, 17.10.2018, Frankfurt/M.

§ 44er Sonderprüfungen im Meldewesen, 03.12.2018, Frankfurt/M.

Neues einheitliches Schema der Aufsicht zur Prüfung der Institute, 04.12.2018, Frankfurt/M.

Aktuelle Offenlegung von Finanz- & Risikodaten, 06.12.2018, Frankfurt/M.

Technische Anforderungen

Insbesondere vor dem Hintergrund der weiter steigenden Anforderungen an die Qualität und Stabilität der in den Prozessen und insbesondere zu Abstimm- und Kontrollzwecken eingesetzten IT-Anwendungen ist die Einhaltung der diesbezüglichen, betrieblichen Anforderungen (Durchführung einer sachgerechten Schutzbedarfsanalyse; ggf. Durchführung eines Programmeinsatzverfahrens) selbstverständlich.

PRAXISTIPPS

  • Die Gewährleistung einer hohen Datenqualität liegt sowohl im institutsinternen als auch im bankaufsichtlichen Interesse.
  • Folgende Handlungsfelder können von der Internen Revision im Rahmen von Prozess- und Funktionsprüfungen beleuchtet werden:
    • Prozesstransparenz und Organisationsrichtlinien
    • Abstimm- und Plausibilisierungshandlungen
    • Kontrollen und Kontrollqualität
    • Technische Anforderungen.

Beitragsnummer: 42597

Die „Regulatory Sandbox“ – Ein Modell auch für das deutsche Bankaufsichtsrecht?

Tobias Gronemann, Rechtsanwalt, Thümmel, Schütze & Partner, Berlin

Die Anforderungen an Kreditinstitute und Finanzinstitute im Rahmen der aufsichtsrechtlichen Regulierung durch gesetzgeberische Vorgaben auf nationaler wie auch auf Ebene der EU wachsen täglich. Alleine die MiFID II hat mit ihren delegierten Verordnungen sowie unterschiedlichen Leitlinien einen Umfang von mehreren tausend Seiten. Dementsprechend kompliziert ist die Anwendung aufsichtsrechtlicher Regelung in der Praxis bereits schon für große Banken. Ungleich größer ist die Herausforderung aber für Unternehmen aus der Fintech-Branche, die meist über keine eigene Rechtsabteilung verfügen, die die für das Unternehmen relevanten aufsichtsrechtlichen Regelungen und Entwicklungen im Blick behält. Diese Unternehmen stehen meist am Anfang ihrer Entwicklung, die durch zu hohe aufsichtsrechtliche Anforderungen im Keim erstickt werden kann. Um dies zu verhindern, hat die Aufsichtsbehörde in Großbritannien, die Financial Conduct Authority (FCA), das Konzept der „Regulatory Sandbox“ entwickelt.

Bei der „Regulatory Sandbox“ handelt es sich um eine Konstruktion, die es einem Unternehmen der Fintech-Branche ermöglicht, sein Geschäftsmodell zunächst für einen begrenzten Zeitraum und einen begrenzten Kundenkreis unter der Aufsicht und Anleitung der FCA zu testen, ohne bereits sämtliche aufsichtsrechtliche Anforderungen erfüllen zu müssen.

Ein Fintech muss sich um einen Platz in der „Regulatory Sandbox“ bewerben und dazu bestimmte Voraussetzungen aufweisen. So muss das Unternehmen nachweisen, dass es sich bei dem Geschäftsmodell um eine echte Innovation handelt und Vorteile für die Verbraucher bietet. Darüber hinaus muss das Unternehmen auch darlegen, dass es auf die „Regulatory Sandbox“ überhaupt angewiesen ist und einen Testplan einreichen. Der Testplan muss Einzelheiten zur Dauer, Leistungskennzahlen, geplante Etappenziele, eine Risikoanalyse, Hinweise zu den Auswirkungen auf die Verbraucher sowie einen Ausstiegsplan enthalten.

Sobald ein Fintech diese Voraussetzungen erfüllt und von der FCA in der „Regulatory Sandbox“ angenommen worden ist, stehen der Behörde unterschiedliche Instrumente zur praktischen Umsetzung der „Regulatory Sandbox“ zur Verfügung. So kann die FCA eine begrenzte Zulassung erteilen, die ausreichend ist, damit das Unternehmen sein Geschäftsmodell testen kann. Das Unternehmen erhält eine individuelle Anleitung durch die FCA, die so weitgehend sein kann, dass die FCA erklärt, wie es bestimmte Regelungen auslegen würde.

Das Fintech muss in der Regel nun wöchentlich über erreichte Ziele, gewonnene Erkenntnisse und das Risikomanagement berichten. Am Ende der vorher vereinbarten Laufzeit muss ein schriftlicher Abschlussbericht vorgelegt werden.

Kritik hat das Modell der „Regulatory Sandbox“ insbesondere vor dem Hintergrund der freien Marktwirtschaft erfahren. So sei zu befürchten, dass Verbraucher diejenigen Fintechs bevorzugen, die im Rahmen der „Regulatory Sandbox“ tätig sind. Problematisch sei dies, da die Plätze begrenzt seien und auch nicht immer nachvollzogen werden kann, warum andere Unternehmen nicht die Voraussetzungen erfüllen und dementsprechend nicht die Vorzüge der „Regulatory Sanbox“ nutzen können.

Überwiegend gab es national und international aber positive Rückmeldungen an die FCA für das Konzept der „Regulatory Sandbox“, sodass Nachahmer nicht lange auf sich warten lassen werden. So findet sich das Konzept in den Fintech-Strategien der EZB und EBA wieder.

In Deutschland steht die BaFin der „Regulatory Sandbox“ dem Vernehmen nach eher skeptisch gegenüber, da die Wirtschaftsförderung nicht vom Mandat der BaFin umfasst sei. Darüber hinaus hätten Fintechs bereits jetzt die Möglichkeit, mittels unverbindlicher Anfragen an die BaFin Anhaltspunkte hinsichtlich aufsichtsrechtlicher Fragen im Zusammenhang mit dem jeweiligen Geschäftsmodell zu erhalten.

Dies kann man – nicht nur aus der Perspektive der Fintechs – kritisch sehen. Mit der ablehnenden Haltung nimmt man sich die Möglichkeit, den Standort Deutschland für Fintechs weiterhin attraktiv und zukunftsorientiert zu gestalten. Auch wäre der rechtliche Rahmen für eine deutsche regulatorische Sandkiste gegeben, da der Verbraucherschutz vom Mandat der BaFin umfasst ist. An diesem Punkt könnte eine regulatorische Sandkiste ansetzen und Verbraucherschutz sowie die Förderung von Fintechs miteinander verbinden.

Fazit:

Solange es in Deutschland keine „Regulatory Sandbox“ gibt, sind Fintechs gehalten, sämtliche aufsichtsrechtlichen Anforderungen zu erfüllen, da ansonsten neben der Einstellung der Geschäftstätigkeit auch strafrechtliche Sanktionen drohen. Ggf. sollten sich Fintechs von Anfang an zu Fragen des Bankaufsichtsrecht rechtlich beraten lassen, um hier Probleme frühzeitig zu erkennen und beheben zu können. Sinnvoll kann es auch sein – sollte es für das Fintech auf den Standort nicht ankommen – seinen Sitz in einem Land mit einer „Regulatory Sandabox“ zu wählen.

 

 

Beitragsnummer: 41315

Outsourcing im Zuge der neuen Regulierung

Was bedeuten die neuen Anforderungen der MaRisk / BAIT für das Outsourcing

Thomas Wildenauer, IT-Auditor, AWADO Deutsche Audit GmbH Wirtschaftsprüfungsgesellschaft Steuerberatungsgesellschaft

I. Grundsätzliches zum Outsourcing

Der Begriff Outsourcing ist ein Kunstwort, der sich ausgehend vom Wortstamm, aus den drei englischen Wörtern „Outside“, „Ressource“ und „Using“ zusammensetzt. Wörtlich übersetzt bedeutet er in erster Linie „Nutzung externer Ressourcen“. Eine IT-Auslagerung (Outsourcing) liegt vor, wenn ein anderes Unternehmen mit der Wahrnehmung solcher IT-Aktivitäten und IT-Prozesse im Zusammenhang mit der Durchführung von Bankgeschäften, Finanzdienstleistungen oder sonstigen institutstypischen Dienstleistungen beauftragt wird, die ansonsten vom Institut selbst erbracht würden. Im Sprachgebrauch der Aufsicht des Kreditgewerbes handelt es sich dabei um den Begriff der „Auslagerung“ (AT 9 MaRisk). Der sonstige Fremdbezug von Leistungen wird sich aber mit der Novellierung der MaRisk und der Neueinführung der BAIT in 2017 ändern. Aus dem Konsultationsentwurf zur Überarbeitung der Mindestanforderungen an das Risikomanagement (MaRisk) ergibt sich eine Reihe von bislang noch nicht normierten Organisationspflichten, die die Institute je nach Komplexität und Umfang der Auslagerung in unterschiedlichem Ausmaß betreffen. Die Überarbeitung zielt zum einen auf die Umsetzung weiterentwickelter internationaler und europäischer Vorgaben ab. Zudem sind Erkenntnisse der vergangenen Jahre aus der Aufsichtspraxis eingeflossen. Derartige bisher nicht normierte Organisationspflichten sind dabei vielfach bereits in der Vergangenheit als Prüfungsfeststellungen in Prüfungen etwa nach § 44 KWG ausgesprochen worden. Es handelt sich also vielfach um Klarstellungen aufsichtsrechtlicher Sichtweisen, nicht um Neuregelungen im engeren Sinn. Der Begriff der Auslagerung wird in den MaRisk näher definiert. Die BaFin verschärft die Regeln für das Auslagerungswesen deutscher Banken. Kreditinstitute müssen künftig ausgelagerte Aktivitäten und Prozesse stärker überwachen. Dies geht einher mit einem einheitlichen Risikobewusstsein, das die Aufsicht von Finanzunternehmen auch für diese Tätigkeiten erwartet. Viele Banken müssen deshalb umdenken.

Eine Auslagerung liegt dann vor, wenn ein Institut einen Dienstleister mit der Wahrnehmung von Prozessen im Zusammenhang mit der Durchführung von Bankgeschäften, Finanzdienstleistungen oder sonstigen institutstypischen Dienstleistungen beauftragt, die ansonsten vom Institut selbst erbracht würden. Das Risiko besteht eindeutig in der Abhängigkeit zu einem Drittunternehmen. Im Rahmen ihrer Aufgaben ist auch zwingend die Interne Revision zu beteiligen. Soweit sich wesentliche Änderungen der Risikosituation ergeben, ist die Risikoanalyse anzupassen (MaRisk AT 9 Tz. 2). Neu ist, dass die Risikoanalyse auf der Grundlage von institutsweit oder gruppenweit einheitlichen Vorgaben sowohl regelmäßig als auch anlassbezogen durchgeführt werden muss. Dies betrifft Risikocontrolling, Compliance und Interne Revision. Bereits bei der Risikoanalyse sollen mögliche Risiken aus Weiterverlagerungen berücksichtigt werden. Es stellt sich die Frage, wie dies sichergestellt werden soll, ohne bereits vor Auslagerung eine vollständige Transparenz über alle Subauslagerungen des Dienstleisters zu haben. Insbesondere vor dem Hintergrund, dass bei wesentlichen Auslagerungen im Auslagerungsvertrag auch Regelungen über die Möglichkeit und über die Modalitäten einer Weiterverlagerung zu vereinbaren sind. Eine Vollauslagerungen der Risikocontrolling-Funktion ist gar nicht, Vollauslagerungen der Compliance-Funktion und der Internen Revision sind nur bei kleinen Instituten möglich, bei denen die Einrichtung letztgenannter Funktionen vor dem Hintergrund der Institutsgröße und der betriebenen Geschäfte unverhältnismäßig wäre. Eine Vergabe von bisher im eigenen Haus durchgeführten Prozessen kann die Geschäftstätigkeit eines Kreditinstituts grundlegend verändern. Die MaRisk schließen dies nicht aus – sofern nicht die Geschäftsleitung und die Ordnungsmäßigkeit der Geschäftsorganisation gem. § 25a Abs. 1 KWG davon betroffen sind bzw. beeinträchtigt werden. Festgehalten werden muss, dass die Leistungsverlagerungen nie zu einer Übertragung der Risikoverantwortung führen dürfen (AT 9 Tz. 4 MaRisk). Das vergebende Unternehmen trägt immer die Gesamtverantwortung. Eine verbesserte Risikokultur in Finanzunternehmen zu schaffen, ist eines der erklärten Ziele für die aktuelle Regulierungswelle im Bereich Risikomanagement. Tatsächlich übernimmt der Gesetzgeber dabei zahlreiche Vorgaben aus internationalen Vereinbarungen, die das deutsche Aufsichtsrecht seit der letzten MaRisk-Novelle 2012 noch nicht explizit abdeckt. Beispielsweise schreibt die Europäische Union den Instituten vor, Grundsätze und Standards einzuführen, die eine wirksame Kontrolle von Risiken durch Leitungsorgane gewährleisten (vgl. Bankenrichtlinie 2013/36/EU, CRD IV). Zudem bezieht sich die BaFin auf das Baseler Papier BCBS 239, das die Risikoberichterstattung und die Risikodatenaggregation behandelt. Damit rücken auch IT-technische Aspekte und mögliche Auslagerungen in den Fokus der Aufsicht.

II. Vertragsgestaltung und Service Level Agreements

1. Vertragliche Grundlagen

Hat man sich für ein IT-Outsourcing mit geeignetem IT-Dienstleister entschieden, müssen die bei der Partnerwahl in einem Pflichtenheft beschriebenen Anforderungen in einem nächsten Schritt vertraglich festgehalten werden. Für den Outsourcing-Vertrag gibt es keine gesetzlichen Vorgaben. Es gibt aber aufsichtsrechtliche Anforderungen (§ 25a KWG, MaRisk usw.). Für die Vereinbarung der Leistungen gibt es Dienstleistungsverträge, Werkverträge, Werklieferverträge usw., die sich an den Grundtypen im BGB orientieren und auch bestimmte Regelungen z.B. § 613a BGB, die zu beachten sind. Dadurch gibt es auch keine verbindlichen Regeln, wie der Vertrag aufgebaut sein und welchen Inhalt er haben soll. Durch die Komplexität, die ein Outsourcing-Projekt annehmen kann, ist eine möglichst klare Abgrenzung von Rechten und Pflichten zwischen den Vertragsparteien wichtig. Ein eindeutiges und kontrollierbares Verhalten der Vertragspartner kann erst dadurch gewährleistet werden. Eine detaillierte Regelung im Vorhinein kann darüber hinaus auf beiden Seiten Klarheit schaffen, welche Voraussetzungen erfüllt werden müssen, um die Zusammenarbeit zum Erfolg zu führen. In diesem Zusammenhang ist die Gestaltung der Service-Level- Agreements (SLA) im Auslagerungsprozess essenziell. Die in AT 9 Tz. 6 MaRisk genannten Mindestanforderungen sollten hierbei wirklich nur den unteren Level darstellen. Je genauer die Auftragsinhalte und deren gewünschte Durchführung vereinbart wurden, umso genauer lassen sich quantitative sowie qualitative Abweichungen feststellen. Hierzu bedarf es, ähnlich wie in den Übernahmeverträgen zu Beginn des Outsourcing-Vorhabens, vertraglicher Vereinbarungen über die (Rück)Übertragung bestimmter Vermögensgegenstände (Hard- und Software) und Verträge vom Auftragnehmer auf den Auftraggeber, wobei in manchen Fällen sogar Personalübernahme stattfindet. Regelungen über das Change Management finden sich in der Regel im Rahmenvertrag. Sie betreffen die Behandlung von Änderungswünschen (Change Requests) des Auftraggebers oder des Auftragnehmers gegenüber den ursprünglich vereinbarten Leistungen. Hier muss ein Prozess definiert werden, der sicherstellt, dass solche Änderungswünsche kurzfristig bearbeitet und gegebenenfalls auch umgesetzt werden können. Dabei ist insbesondere auch eine Regelung über die Anpassung der für die betreffenden Leistungen vereinbarten Vergütung aufzunehmen.

Die Leistungsverpflichtungen und Rahmenbedingungen werden schließlich im Vertrag konkretisiert und ausgestaltet. Der Vertrag sollte deshalb sowohl flexible Variablen (z.B. Einführung neuer Technologien, verschlechterte wirtschaftliche Lage) zulassen, als auch stabile Vorgaben aufweisen. Ein Punkt, der bei der Gestaltung von einem Rahmenvertrag zum IT-Outsourcing ebenfalls berücksichtigt werden muss, ist die Informationssicherheit. Durch das Outsourcing können sich Verantwortlichkeiten im Unternehmen verschieben und ändern. Auch können zusätzliche Schnittstellen entstehen. Jedes Institut muss für die Steuerung und Überwachung wesentlicher Auslagerungen klare Verantwortlichkeiten festlegen. Bei Vollauslagerungen hat die Bank ohnehin jeweils einen Beauftragten zu benennen, der eine ordnungsgemäße Durchführung der jeweiligen Aufgaben gewährleistet. Zusätzlich fordert der Gesetzgeber bei Instituten mit umfangreichen Auslagerungslösungen ein zentrales Auslagerungsmanagement. Dieses stellt sicher, dass eine Stelle im Institut einen Gesamtüberblick über ausgelagerte Prozesse und Aktivitäten hat und so ein möglichst einheitlicher Umgang mit den besonderen Risiken aus Auslagerungen und deren Überwachung sichergestellt wird. Unter solchen Voraussetzungen sollte der Sicherheit von Daten und Informationen auch im Rahmenvertrag eine hohe Aufmerksamkeit gewidmet werden. Auf diese Weise kann ein Rahmenvertrag so gestaltet sein, dass Aufgaben, Kompetenzen und Verantwortlichkeiten für beispielsweise Zutritts- und Zugriffssicherheit, Berichterstattung und Releaseplanung mitberücksichtigt werden. Der Leitungsebene kommt eine hohe Verantwortung für die Informationssicherheit zu. Fehlende Steuerung, eine ungeeignete Sicherheitsstrategie oder falsche Entscheidungen können durch Sicherheitsvorfälle weitreichende negative Auswirkungen haben.

2. Service Level Management

Die nachfolgend beschriebenen Aspekte werden im Service Level Management (SLM) gesteuert. Das SLM beschreibt den Prozess von der Erstellung und Verhandlung der Service Levels, über das Monitoring der Leistungserfüllung, das Reporting an zuständige Personen, bis hin zum kontinuierlichen Verbessern der Vertragsbestandteile und der Leistungsbeziehung. Oftmals kommuniziert ein Dienstleistungsgeber mit dem Auftraggeber nur über zwei Wege: die SLA-Reports und die Rechnungsstellung. Die Service Level sind vertraglich vereinbart. Der Dienstleistungsgeber kann in der Regelkommunikation, wie sie heute mehrheitlich praktiziert wird, überdurchschnittliche Leistungen nicht darstellen. Damit gerät er schnell in einen Jo-Jo-Effekt: Das Topmanagement des Kunden wird immer nur im Eskalationsfall – bei größerer SLA-Verletzung – einbezogen. Der Name des Dienstleisters fällt auf dieser Ebene stets zusammen mit “Negativschlagzeilen”. Dabei gründen auf den Reports wichtige Entscheidungen zum Controlling, zur Anpassung der Qualitätsanforderungen (etwa an neue Geschäftsprozesse und
-modelle) sowie im schlimmsten Fall über die Nutzung von Exit-Klauseln bei Schlechtleistung. Was sollte ein Reporting leisten, das einerseits den Kunden zufrieden stimmt, andererseits dem Dienstleister die Chance eröffnet, seinen Beitrag in der Outsourcing-Beziehung angemessen darzustellen? Zunächst muss es eine grundlegende Anforderung erfüllen: Die Berichte müssen alle Governance-Ebenen des Kunden – operativ, taktisch und strategisch – mit den für sie jeweils relevanten Informationen versorgen, und zwar durchgängig. Das heißt: Die Daten, die diese verschiedenen Sichten unterstützen, müssen von unten nach oben generiert werden. Die operative Ebene erhält technische Informationen. Erfüllt das Reporting die Governance-Anforderungen, sollte es außerdem drei Inhalte abdecken. Erstens: Die Leistung transparent machen. Zum “Pflichtteil” des Reportings gehört es, den Zusammenhang zwischen den Servicebeschreibungen und Qualitätsvereinbarungen, den erbrachten Leistungen sowie der Rechnung herzustellen. Dazu ist es sinnvoll, nochmals die verschiedenen Etappen einer Beziehung beim Outsourcing anzuschauen. Ausgangspunkt ist die Sourcing-Strategie. Aus ihr werden die Serviceschritte abgeleitet, und auf dieser Grundlage wird die Qualität der einzelnen Services festgelegt. Beides hat Einfluss auf das Preismodell, das zusammen mit dem Verbrauch des Kunden im betrachteten Zeitraum die Rechnungsstellung bestimmt. Das Reporting muss diesen Prozess spiegeln. Zweitens muss man dem Kunden weitere Perspektiven aufzeigen. Neben dem “Pflichtteil” sollte ein Report darüber informieren, inwieweit die Ziele, die ursprünglich die Outsourcing-Entscheidung bestimmt haben, erreicht wurden. Für eine Auslagerung kann es viele Gründe geben. Neben Kostensenkung und Qualitätssteigerung sind dies oft strategische Ziele: beispielsweise zufriedenere Anwender, technische Weiterentwicklung oder ein höherer Wertbeitrag der IT, indem diese Business-Prozesse optimiert oder die Voraussetzungen für neue Geschäftsmodelle schafft. Sie sind meist in der Präambel der Outsourcing-Verträge beschrieben. Dort ruhen sie, geraten oft in Vergessenheit und fehlen in den Berichten der Dienstleister. Ein nachhaltiges Reporting sollte die Entwicklung dieser Größen dokumentieren. Dazu müssen geeignete KPI (Key Performance Indicators / Leistungskennzahlen) entwickelt werden. Als Drittes sollte die Zielerreichung dokumentiert werden. Diese Messgröße ist für den Kunden vor allem in der Anfangszeit der Vertragsbeziehung sehr wichtig. Das Reporting sollte dokumentieren, ob der vertragliche Übergang wie geplant voranschreitet, ob die Kosten den Erwartungen entsprechen und die Qualität beim Wechsel vom alten auf den neuen Provider (oder aus der unternehmensintern in die externe Verantwortung) gehalten wird. Ein nachhaltiges Reporting hängt nicht nur vom Dienstleister ab, sondern auch von der Vorgehensweise des Kunden. Der Auftraggeber sollte zunächst seine Anforderungen klar und verbindlich definieren und sie dem Dienstleister mitteilen. Gemeinsam sollten beide Parteien dann festlegen, wie diese Ziele gemessen werden. Auf dieser Grundlage können sie das Reporting aufbauen und in der Governance verankern. In den SLA wird die Leistung definiert. Beispielsweise wird Verfügbarkeit in einem SLA definiert (Messung, Ausfallzeiten, Bezugsgrößen z.B. übliche Geschäftszeiten, Toleranzgrenzen usw.). Die Messung selbst ist ein Report. Dazu werden die Serviceleistungen des Outsourcingnehmers in Bezug gesetzt zu den Anforderungen des Auftraggebers. Zielsetzung bei der Beschreibung von SLAs ist es, eine Kosten-, Leistungs- und Qualitätstransparenz zu schaffen. Im Allgemeinen wird zwischen Rahmen-SLAs und Leistungsscheinen unterschieden. Dies wird in der Praxis sehr unterschiedlich gehandhabt. SLA sind nicht normiert, können auch Teile von Leistungsscheinen sein oder in Verträge eingearbeitet sein. Rahmen-SLAs treffen dabei Aussagen zu den qualitativen und quantitativen Aspekten der ausgelagerten Leistungen, Leistungsscheine bestimmen detailliert die bereits oben dargestellten Merkmale der Leistungen. Bei Rahmen-SLAs, die durch eine Mehrzahl an Leistungsscheinen spezifiziert werden, vereinbaren die Parteien üblicherweise einheitliche Bewertungsmaßstäbe für alle Leistungen, anhand derer die Qualität der Dienstleistung gemessen werden kann. Leistungsstörungen können einerseits vom Dienstleistungsnehmer gemeldet werden, wenn sich Ungereimtheiten im Abgleich der erbrachten Leistungen gegen die entsprechenden Soll-Werte zeigen, andererseits durch den Dienstleister, indem er nach MaRisk AT 9 auf Verfehlungen hinweist, die in seinem Verschulden oder in mangelhafter Qualität der Vorleistung des Dienstleistungsnehmers liegen.

III. Dienstleistersteuerung

Es lässt sich die Notwendigkeit der Anwendung eines ganzheitlichen integrierten Risikomanagementansatzes ableiten, welcher die mit der Auslagerung in Verbindung stehenden Risiken in der Bank adressieren muss. Dies kann durch die adäquate Einbindung des Outsourcing-Managements in das bankweite Risikomanagement gelingen und stellt die vielfältigen Gestaltungsmöglichkeiten für einen ganzheitlichen wert- und risikoorientierten Managementansatz (Outsourcing Governance) vor. Viele der dargestellten Erkenntnisse ergaben sich im Rahmen der externen IT-Revision. Besonders wichtig ist im Rahmen der Beziehungspflege, dass alle Informationen, die zur Auftragserfüllung nötig oder hilfreich sind, dem Dienstleister zeitnah zur Verfügung gestellt werden. Notwendige interne Erklärungen müssen vorgenommen werden. Eine vertrauensvolle Zusammenarbeit ist die Basis des Outsourcings. Nicht zuletzt ist es Ziel aller Beteiligten, den Kunden (Mitarbeitern und Führungskräften) eine Dienstleistung anzubieten, die einen geräuschlosen Wechsel zwischen Bank und Dienstleister ermöglicht. Es ist insbesondere über die Problemfälle ausführlich quartalsweise zu berichten. Der Dienstleister erstellt hierfür eine detaillierte Fehlerstatistik. Gemeinsam werden Risiken vermieden. Die erfolgreiche Umsetzung der Outsourcing Governance umfasst dabei u. a. die Identifikation und Analyse von Wertschöpfungspotenzialen innerhalb der Bank, das effektive Management der zentralen Aufgaben in allen Phasen sowie die Verankerung der wichtigsten Outsourcing-Steuerungsinstrumente im Unternehmen. Der Einbezug des Outsourcings in das unternehmensweite Risikomanagement geht somit über die historische Form des operativen Risiko-managements, deren Fokus primär auf die Risikovermeidung und -minderung ausgelegt war, hinaus. Hauptziel ist das effiziente und effektive Management der ausgelagerten Bereiche, welches alle wesentlichen Einzelrisiken und deren Abhängigkeiten umfasst. Das risikoorientierte Management der ausgelagerten Bereiche hat das Ziel, eine ausgewogene Sichtweise von Risiken und Wertschöpfung über die gesamte Laufzeit des Outsourcing-Verhältnisses hinweg zu etablieren. Ein moderner chancen- und risikoorientierter Outsourcing-Management-Ansatz integriert die Organisation, die Aufgaben und die Instrumente in ein ganzheitliches Rahmenwerk. Die Analyse der Risiken ist wesentlich für die erfolgreiche Umsetzung des Outsourcings. Diese Risikobetrachtung besteht in der Analyse der veränderten Risikosituation der Bank nach einer möglichen Auslagerung von Prozessen und Funktionen. Voraussetzung für die Durchführung einer solchen Analyse ist die Existenz eines für die Bank angemessenen, bankweiten Risikomanagementsystems. Die Analyse kann als ein durch das Management sowie die jeweiligen Prozessverantwortlichen beeinflusster, fortlaufender Prozess beschrieben werden, der im Zuge der Strategiefindung definiert und unternehmensweit angewendet werden sollte. Potenzielle Gefahren für das Unternehmen sollen damit identifiziert und unter Berücksichtigung eines bankspezifischen Risikoappetits gesteuert werden, um die festgelegten Bankziele mit angemessener Sicherheit erreichen zu können. Das unternehmensweite Risikomanagement selbst lässt sich konzeptionell in die drei Komponenten Risikoumfeld, Risikomanagement und Risikocontrolling aufteilen. Dabei ist wesentlich, dass der Bereich Risikoumfeld auf Unternehmensebene und Risikomanagement sowie Risikocontrolling auf Prozessebene stattfinden. Die Kommunikation und Informationsverbreitung ist das notwendige Bindeglied zwischen Risikoumfeld, Risikomanagement und Risikocontrolling. Im Zusammenhang mit dem Outsourcing sind bei der Betrachtung von Risiken innerhalb einer Risikoanalyse (und damit innerhalb des unternehmensweiten Risikomanagements) zwei Risikodimensionen relevant: Risiken aufgrund externer Unsicherheiten und inhärente Risiken der Auslagerung. Der laufende Betrieb umfasst die Erbringung der vertraglich vereinbarten Leistung durch den Insourcer und ihre Steuerung und Kontrolle durch das Kreditinstitut. Ein mehrschichtiges Governance-Modell ermöglicht eine Differenzierung unterschiedlicher Ebenen der Zusammenarbeit. Kernaufgabe dieser Aktivität ist die risikominimale Zielerreichung unter Anwendung kosteneffizienter laufender Überwachungsmaßnahmen gemäß einem vollständigen Managementzyklus. Das Ziel der Dienstleistersteuerung sollte sein, durch Kontroll- und Koordinationsmaßnahmen eine regelmäßige Beurteilung der Leistungen des Dienstleisters vorzunehmen, um ggf. geeignete Maßnahmen ergreifen zu können. Die Steuerung erfolgt auf Basis der SLA’s sowie der Berichte des externen Dienstleisters oder aufgrund sonstiger Auffälligkeiten. Hierfür sollten klare Verantwortlichkeiten festgelegt und eine regelmäßige Berichterstattung sichergestellt werden. Zur risikoorientierten Dienstleistersteuerung ist eine einheitliche Methodik festzulegen. Hierbei macht es Sinn, den Steuerungsaufwand einerseits an der Wesentlichkeit des Geschäftsprozesses auszurichten und andererseits weitere Faktoren mit zu berücksichtigen. Abhängig vom Auslagerungsumfang können sich auch bei nicht als „wesentlich“ eingestuften Auslagerungen ggf. datenschutzrechtliche oder GuV-relevante Sachverhalte für die Dienstleistersteuerung ergeben. Meist erreicht der Gesamtaufwand für weitere Auslagerungen und Vergaben (nicht wesentliche, sonstiger Fremdbezug und nicht i. S. d. MaRisk zu klassifizierende Auslagerungen) ebenfalls sehr namhafte Beträge. Da solche vergebenen Leistungen oft nicht zentral gesteuert werden, benötigen die betreuenden Fachbereiche Hilfestellungen zur Steuerung ihrer Dienstleistungspartner. Bei dieser Dezentralisierung ist es wichtig, dass ein einheitliches Verständnis für die Aufgabenstellungen der vielen Prozesse oder Schnittstellenbeteiligten besteht. Eine besondere Herausforderung liegt hierbei vor allem beim rechtzeitigen Erkennen von Auffälligkeiten in der Leistungserbringung, der Ableitung und Umsetzung geeigneter Maßnahmen sowie dem gegenseitigen zeitgerechten Informationsaustausch. Die Funktionalität der Prozesse der Dienstleistersteuerung in Verbindung mit den übrigen Prozessen des Unternehmens, die auf Informationen aus der Dienstleistersteuerung angewiesen sind, z.B. Risikomanagement, Datenschutzbeauftragter oder Notfallmanagement, ist im Wesentlichen von der Qualität dieses Informationsaustausches abhängig. Perspektivisch werden die Anforderungen an die Ausgestaltung und Besetzung der Dienstleistersteuerung steigen. Die damit verbundenen hohen Etats und die Aufgabenvielfältigkeit bedingen auch Anforderungen an die stetige Weiterentwicklung der Dienstleistersteuerungsmethodik sowie Mitarbeiterquantität und -qualität. Der entscheidende Ansatz für eine nach AT 9 Tz. 7 der MaRisk angemessenen Überwachung der Aktivitäten des Dienstleisters beginnt mit der klaren systematischen Funktionstrennung auf Ebene der Internen Kontrollverfahren mit den beiden Teilen des Internen Kontrollsystems und der Internen Revision. Die Überwachung und Steuerung des Dienstleisters ist eine Aufgabe des Risikomanagements, die dem Internen Kontrollsystem zuzuordnen ist, da es sich um eine geschäfts- bzw. prozessbezogene Überwachungstätigkeit handelt. Die unternehmensinterne Methodik zur Dienstleistersteuerung spielt dabei eine wesentliche Rolle, da diese auch für die in den Fachbereichen nicht zentral gesteuerten Dienstleister den Handlungsrahmen vorgibt, um die mit der Auslagerung verbundenen Risiken angemessen zu steuern.

Neben dem Management der Überwachungsgrößen ist deren Kommunikation und Reporting Bestandteil dieser Aktivität. Die Reportinginformationen sollten sich an den Anforderungen orientieren und unterschiedliche Hierarchiestufen integrieren. Zur Verbesserung der Qualität der erbrachten Leistungen und der Zusammenarbeit wird ein periodischer oder dynamischer Optimierungsvorgang durchlaufen. Die Funktion „Dienstleistersteuerung” ist für die grundsätzliche Regelung der Leistungsbeziehung zwischen Institut als Abnehmer und einem dritten Dienstleister als Ersteller der Leistung verantwortlich. Im Fokus steht dabei zunächst – sofern relevant – die Erfüllung sämtlicher aufsichtsrechtlicher Anforderungen gemäß § 25a Abs. 2 KWG in Bezug auf die Auslagerung von Bank- und Finanzdienstleistungen. Eine sinnvolle Methode für eine solche Prüfung ist die regelmäßige Durchführung einer Zertifizierung nach IDW PS 951 Typ 2 durch einen Wirtschaftsprüfer. Die Berichterstattung nach IDW PS 951 ist explizit auf die Erfüllung der Anforderungen aus IDW PS 331 abgestellt. Insbesondere bei Mehrmandantendienstleistern bietet die Berichterstattung nach IDW PS 951 eine effiziente Prüfungsdurchführung, da die Abschlussprüfer der auslagernden Unternehmen i.d.R. keine eigenen Prüfungshandlungen beim Dienstleistungsunternehmen mehr durchführen müssen. Darüber hinaus kümmert sich die Dienstleistersteuerung im Sinne einer ganzheitlichen Steuerung der Leistungsbeziehung auch um die Wahrung der wirtschaftlichen Interessen bzgl. der Leistungsbeziehung.

Im Fall des § 25a Abs. 2 KWG ist sie für die Vorgabe von Bearbeitungsrichtlinien für den Dienstleister verantwortlich. Sie trägt somit die Prozessverantwortung für die Abläufe hinsichtlich des Leistungsbezugs vom Dienstleister. Fachspezifisches Know-how lässt sich die Dienstleistersteuerung aus den jeweiligen Fachbereichen im Haus zuliefern. Die strategische Dienstleistersteuerung ist zum Beispiel für Vertragsverhandlungen und sehr kritische Eskalationen wie schwere Vertragsbrüche zuständig. Auf taktischer Ebene werden beispielsweise größere Changes genehmigt und Eskalationen geklärt. Die operative Dienstleistersteuerung sorgt für den störungsfreien Betrieb und prüft die Erfüllung aller Service Level. Die Auswertung der Ergebnisse zeigt, dass die Dienstleistersteuerung weitgehend definiert, jedoch nicht durchgehend vollzogen ist. Von der strategischen hin zur operativen Ebene nimmt der Anteil standardisierter Prozesse zu. Als unterdurchschnittlich reif werden die Prozesse Service-Kataloge und Service-Portfolio-Management beurteilt. Demnach verfügen etliche Banken noch über keinen standardisierten IT-Service-Katalog und keinen Prozess für das Management ihres Service-Portfolios. Sofern unter Effizienzgesichtspunkten sinnvoll kann die Dienstleistersteuerung den Dienstleister als weiteren Kompetenzträger in die Erarbeitung von Bearbeitungsrichtlinien einbeziehen oder Vorschläge von ihm einholen. Die Dienstleistersteuerung berichtet – hinsichtlich § 25a-KWG-relevanter Dienstleistungen – direkt der Geschäftsführung.

Die BaFin geht grundsätzlich davon aus, dass bankinterne Mechanismen beispielsweise im Risikocontrolling sowie bei Compliance-Aufgaben und Interner Revision auch bei Auslagerungen und Unterauslagerungen greifen. Die von der Bankenaufsicht erwünschte Risikokultur erstreckt sich damit unmittelbar auf die Dienstleistersteuerung. Institute müssen vor diesem Hintergrund die mit wesentlichen Auslagerungen verbundenen Risiken angemessen steuern und die Ausführung der ausgelagerten Aktivitäten ordnungsgemäß überwachen. Die Ergebnisse sind über einen expliziten Auslagerungsbericht in das eigene Berichtswesen aufzunehmen. Dieser muss zudem eine Aussage darüber treffen, ob die erbrachten Dienstleistungen der Auslagerungsunternehmen den vereinbarten Leistungen entsprechen. Die mit der Durchführung ausgelagerter Aktivitäten einhergehende Verantwortung lässt sich, vereinfacht gesagt, also nicht einfach mit auslagern. Das stellt die Aufsicht unmissverständlich klar: Sie bewertet die Frage des Auslagerungstatbestands unabhängig von möglichen zivilrechtlichen Verträgen. Das Reporting der Dienstleister ist die Grundlage für Entscheidungen im Rahmen der Anbietersteuerung. Exit-Klauseln für den Fall der Schlechtleistung, Controlling und Anpassung der Qualitätsanforderungen bauen auf ein aussagekräftiges Reporting auf. Einige IT-Führungskräfte be-klagten weiterhin ungenaue Berichte sowie SLA-Werte, die immer nur knapp über den Schwellenwerten liegen und dadurch Misstrauen hervorrufen. Zusammenfassend vermissen die Unternehmen bezüglich der Umsetzung des Berichtswesens bei ihrem IT-Dienstleister häufig Nachvollziehbarkeit, Zuverlässigkeit und Zweckmäßigkeit. Viele sind mit dem Berichtswesen ihrer IT-Dienstleister nicht zufrieden oder sehen lediglich die Minimalanforderungen als erfüllt an. Zu häufig werden Tätigkeiten, die eindeutig anderen Teilen des Internen Kontrollsystems zugeordnet sind, von der Internen Revision ausgeführt. Hierzu gehört auch die Auswertung von Risikoberichten von Mehrmandantendienstleistern. In diesen Fällen ist es nicht die Aufgabe der Internen Revision diese auszuwerten‚ sondern sie muss im Rahmen von Prüfungstätigkeiten feststellen, ob die Überwachung angemessen ist. Die Überwachungseinheiten der Auslagerung (z.B. die auslagernde Fachabteilung, der IT-Sicherheitsbeauftragte und/oder Risikomanager) müssen die erhaltenen Berichte/Informationen auswerten und vor dem Hintergrund der institutsinternen Risikokennziffer beurteilen. Es muss sich ein eigenes Urteil von der Leistung und den Risiken des Dienstleisters gebildet werden, welches anschließend in die institutsweite Betrachtung einfließt. Es sollte darauf geachtet werden, dass sich die Interne Revision nicht in diese Funktion drängen lässt und damit die nach MaRisk geforderte Funktionstrennung aufgehoben wird.

Die zentrale Norm für einen mindestens vierteljährlichen Risikobericht findet sich in AT 4.3.2 Tz. 3 der MaRisk. An dieser Stelle erwarten die MaRisk eine mindestens vierteljährliche Beschäftigung mit den wesentlichen Risiken und fordern ebenso in AT 4.3.2 Tz. 6 das vierteljährliche Reporting an den Aufsichtsrat über deren Entwicklung. Insbesondere die Risiken aus IT-Auslagerungen werden bei den meisten Banken, sofern sie nicht als eigene Risikoart eingestuft werden, in der Risikoinventur unter den operationellen Risiken aufgeführt. Alle mandantenrelevanten Mängel müssen der Bank offengelegt werden. Hierbei darf keine Filterung durch den Dienstleister erfolgen.

>>> Überleitung zum 2. Artikel: Im zweiten Teil des Artikels werden neue Alternativen betrachtet sowie konkrete Änderungen im IT-Risikomanagement berücksichtigt. Weiterhin werden verschiedene Aspekte von Softwarebezug, der künftig Outsourcing sein kann, beleuchtet.

IV. Software als Auslagerung

Die pauschale Auslagerungsqualifikation von Softwarebezug und diesbezüglichen Unterstützungsleistungen im Zusammenhang mit Risikoüberwachung ist neu, da diese – entgegen der Systematik des AT 9 – nicht an einen Auslagerungstatbestand anknüpft und bisher weder dem Risikogedanken der MaRisk noch den tatsächlichen Prozessen in der Bankpraxis gerecht wird. So würde sich auch eine vom Institut fremdbezogene, aber selbst betriebene Software als Auslagerung qualifizieren, ohne dass allgemeine Auslagerungselemente vorliegen. Dies träfe bei enger Auslegung sogar für den einmaligen Erwerb von in Eigenregie individuell an die Bedürfnisse der Banken angepasster Software ohne jeglichen Dienstleistungsbezug zu. Damit wurden die tatbestandlichen Voraussetzungen von § 25b KWG, AT 9 für (und nur für) das Thema Software de facto übergangen. Software ist für die Durchführung von Bankgeschäften per se von großer Bedeutung, da heutzutage jedes in § 1 KWG aufgeführte Bankgeschäft auf der Grundlage von IT-Systemen (teilweise vollständig automatisiert) durchgeführt wird. Die besondere Bedeutung von IT-Systemen führt dazu, dass klassische Unterstützungsleistungen wie Entwicklungsleistungen, IT-Consulting oder Wartung als Auslagerungstätigkeiten verstanden werden, da auch andere Risiken vertraglich geregelt und inhaltlich gesteuert werden müssen. Der Einkauf spezialisierten, qualitativ hochwertigen IT-Know-hows würde durch die neue Anforderung de facto verteuert und erschwert, was der gewünschten Konzentration auf Kernkompetenzen bei den Banken leider entgegenwirkt und außer Acht lässt, dass aufgrund einer Vielzahl an rechtlichen und marktgetriebenen Vorgaben eine spezialisierte, hoch entwickelte IT-Branche für die kostengünstige, effiziente und schnelle Massendatenverarbeitung zwingend erforderlich ist. Es kann aber nicht das Ziel sein, das Rad zurückzudrehen und die IT-Lösungen wieder inzusourcen. Nicht zuletzt ist zu berücksichtigen, dass die strengen Vorgaben der MaRisk für eine Vielzahl von kleineren Softwareanbietern, die auf bestimmte Randfunktionalitäten spezialisiert sind, aus Personal- und letztlich Kostengründen nicht umsetzbar sind. Dies engt die Banken bei der Auswahl fachlich geeigneter Dienstleister in diesem Bereich zusätzlich ein. Gleichzeitig wird indirekt in bestehende Marktstrukturen eingegriffen und letztlich ein Verdrängungswettbewerb gefördert. In den Banken wird Standardsoftware regelmäßig für einen bestimmten Zeitraum inkl. der Standard-Updates gekauft. Häufig erfolgt zusätzlich ein Customizing nach den Vorgaben der nutzungsberechtigten Bank, wobei die Vorgaben von der Bank selbst kommen, dessen Mitarbeiter regelmäßig projekthaft in die Umsetzungstätigkeiten des Softwareanbieters eingebunden sind, die Tests (mit-)durchgeführt werden und auch die Freigabe zur Produktion erteilt wird. Unter Risikogesichtspunkten sind diese individuellen Leistungen des Softwareanbieters über den gesamten Prozess in der Hand der jeweiligen Auftrag gebenden Banken. Aktivitäten und Prozesse werden also keinesfalls ausgelagert, vielmehr wird ein klar definierter, einmaliger Auftrag an den Softwareanbieter erteilt, der zudem institutsseitig noch eng begleitet wird. Zudem werden bei der Mehrzahl der Banken Programmeinsatzverfahren angewandt, die die mit der Software einhergehenden Risiken einer Beurteilung unterziehen. Eine solch erhebliche Ausweitung der Dienstleistersteuerung steht in keinem Verhältnis zu dem damit verbundenen Risiko. Mir sind bis dato keine besonderen Schadensfälle in dieser Hinsicht bekannt. Spezialisierte IT-Anbieter werden kaum den Source-Code, der Grundlage ihrer Geschäftstätigkeit ist, offenlegen.

V. Robotic Process Automation (RPA)

Bankenvorstände sind heutzutage nicht zu beneiden. Sie müssen immer mehr Prozesseffizienz schaffen, haben es aber mit wachsenden IT-Landschaften zu tun. Um in so einem Umfeld Prozesse zu vereinfachen, sind komplexe IT-Transformationsvorhaben wie die Modernisierung der Kernsysteme oder eine Implementierung von BPM-Systemen nötig. Will man ohne diese Projekte mehr Effizienz rausholen, bleibt oft nur noch das Outsourcing. Und doch sind Transformations- und BPM-Vorhaben oft schwierig: lange Umsetzungszyklen und ein hoher Integrationsaufwand. Oft sind diese Projekte komplex und risikoreich und amortisieren sich erst sehr spät. Outsourcing auf der anderen Seite büßt nach und nach an Effizienzeffekten ein. Dort wo es bereits seit langem im Einsatz ist, hat das Potenzial bereits ein Maximum erreicht. Auch das Lohnkostenargument wird zunehmend obsolet, wenn Löhne steigen. In diese Lücke springt nun die Robotic Process Automation (RPA), also die Automatisierung via Software-Roboter. Die Hersteller versprechen Einsparungen von bis zu 60 Prozent und eine schnelle und risikoarme Implementierung. Die wird vor allem dadurch möglich, dass kein Integrationsaufwand auf Seiten der bestehenden Systemlandschaft anfällt. Warum? Weil Robotics Automation außerhalb der bestehenden Systeme sitzt. Die Schnittstelle ist das User Interface. Die Konfiguration erfolgt durch „vormachen“ am System. Das kann durch den Fachexperten erfolgen und bindet dadurch kaum Ressourcen auf Seiten der IT – „Code free“ sozusagen. Einmal konfiguriert, werden Prozesse hochskalierbar. Hunderte Roboter können gleichzeitig das tun, was sonst einzelne Mitarbeiter seriell abarbeiten müssen. Glücklicherweise sind diese Roboter keine physisch existenten maschinellen Gestalten mit Armen, Beinen oder Rädern so wie wir sie aus der Fertigungsindustrie kennen – wo sollten wir so viele von ihnen auch unterbringen? RPA-Roboter sind reine Software und brauchen keine Schreibtische. Aber sie könnten einen ähnlichen Einfluss auf die Arbeitswelt im Backoffice haben wie ihre physischen Vorgänger auf die Fertigung. Automatisierung von Geschäftsprozessen ist nichts Neues. Unternehmen haben immer nach Möglichkeiten gesucht, um die Effizienz zu steigern und Wachstum zu fördern. Bisher haben Unternehmen dies oft über Investitionen in Enterprise-Systeme (ERP), Business Process Management-Lösungen oder in Shared Services/Outsourcing realisiert. Trotz starker Investitionen in diese Lösungen sind Prozesse immer noch nicht voll automatisiert und sehen häufig eher aus wie ein Flickenteppich. Das liegt oft daran, dass traditionelle Lösungen häufig sehr kostenintensiv sind, viele Ressourcen beanspruchen und zusätzlich nicht schnell auf veränderte Marktsituationen reagieren können.

Beispielfunktionen, welche RPA durchführen kann:

  • Daten extrahieren, verändern und Berichte erstellen
  • Formulare ausfüllen
  • Daten kopieren, einfügen und verschieben
  • In Systeme einloggen und diese bedienen bspw. ERP- und Kundenmanagementsysteme
  • Informationen aus mehreren Systemen lesen und verarbeiten
  • Informationen aus strukturierten Dokumenten lesen
  • Berechnungen durchführen
  • „Wenn/Dann“ Befehle ausführen
  • E-Mails öffnen und Anhänge verarbeiten

Robotic Process Automation kann auch als virtueller Mitarbeiter betrachtet werden. RPA greift dazu auf Ihre bestehenden Applikationen zu und führt so strukturierte Prozesse automatisch aus. Es müssen keine Veränderungen an bestehenden Systemen durchgeführt werden, da RPA darauf genauso zugreift wie Ihre Mitarbeiter. Somit kann RPA eine Vielzahl von Prozessen automatisieren wie beispielsweise Rechnungsbearbeitung, Report-Erstellung oder Mitarbeiter-Onboarding. Durch Robotic Process Automation werden Geschäftsprozesse schnell, fehlerfrei und automatisch erledigt. Bei dieser Art von Prozessautomatisierung setzt ein Software-Roboter Aufgaben in einem System oder einer Anwendung in der gleichen Weise um, wie es ein Mensch tun würde. Der Roboter wird zum virtuellen Angestellten, der manuelle und sich ständig wiederholende Teilprozesse oder Aufgaben ausführt, die ein hohes Maß an Genauigkeit erfordern. Die Vorteile der Prozessautomatisierung via Roboter bestehen darin, dass Mitarbeiter von ermüdenden und immer wiederkehrenden Routinetätigkeiten entlastet werden, die Roboter wesentlich schneller erledigen können. Automatisierung durch Softwareroboter entdecken viele Banken aktuell für sich. Neun von zehn Instituten in Deutschland planen laut einer Studie, bis 2019 so viele Abläufe wie möglich zu standardisieren, sodass diese von Algorithmen übernommen werden können. Der Softwareroboter bildet dabei die Aktivitäten eines Menschen an Bildschirm und Tastatur nach. Möglichkeiten für den Einsatz sind etwa Tätigkeiten nach der Kontoeröffnung oder die Bearbeitung von Fehlerlisten.

VI. IT-Risikomanagement

Das KWG verlangt von der Bank eine ordnungsgemäße Geschäftsorganisation. Die ordnungsgemäße Geschäftsorganisation einer Bank muss insbesondere ein angemessenes und wirksames Risikomanagement umfassen, auf dessen Basis die Bank die Risikotragfähigkeit laufend sicherzustellen hat. Eine Auslagerung darf weder die Ordnungsmäßigkeit dieser Geschäfte und Dienstleistungen noch die Geschäftsorganisation im Sinne des § 25a Abs. 1 KWG beeinträchtigen. Insbesondere muss ein angemessenes und wirksames Risikomanagement durch das Institut gewährleistet bleiben, welches die ausgelagerten Aktivitäten und Prozesse einbezieht. Zuerst stellt sich die Frage, was eigentlich unter dem Begriff Risiko zu verstehen ist. An dieser Stelle soll deshalb der Risikobegriff erläutert werden und ein Überblick über die Risiken des IT-Outsourcings gegeben werden. Das Wort Risiko hat seinen Ursprung im frühitalienischen Wort „risicare“, das übersetzt „etwas wagen“ bedeutet. Obwohl sich zahlreiche Veröffentlichungen mit der Risikoproblematik wirtschaftlichen Handelns beschäftigen, gibt es trotz der Fülle keine einheitlich allgemeingültige Definition des Risikobegriffs. Bevor nun auf die Methoden des Risikomanagements eingegangen wird, soll zunächst geklärt werden, was unter dem Begriff des „Risikomanagements“ zu verstehen ist. Ähnlich wie beim Risikobegriff, gibt es in der Literatur auch zum Begriff des “Risikomanagements” eine Vielzahl an Definitionen. Prinzipiell ist Risikomanagement eine systematische Vorgehensweise im Umgang mit Risiken. Für ein besseres Verständnis helfen allgemeine Definitionen. In einer allgemeineren Definition werden unter Risiko- Management “alle erforderlichen Aufgaben und Maßnahmen zur Risikobekämpfung“ verstanden. Aufgabe des Risikomanagements ist es also, die wesentlichen Risiken, die den Unternehmenserfolg oder -bestand gefährden, frühzeitig zu erkennen und Gegenmaßnahmen zu treffen. Risiken können dabei in sehr zahlreichen Erscheinungsformen auftreten. Das IT-Risikomanagement ist ein Teil des Information Security Management Systems (ISMS) und befasst sich mit der Analyse und Bewertung von Risiken. Dieses Vorgehen generiert einen Mehrwert für das Unternehmen und seine Kunden, indem es die Umsetzung von Schutzmaßnahmen abhängig von der Höhe des Risikos macht. Dadurch wird es leichter, ein angemessenes Sicherheitsniveau zu finden, zu erreichen und zu halten. Dieses Vorgehen ist wirtschaftlich sinnvoller als starre Vorgaben in Form von komplett umzusetzenden Maßnahmenkatalogen. Im Rahmen des IT-Risikomanagements werden nur Risiken betrachtet, die die vier Schutzziele der IT (Verfügbarkeit, Integrität, Vertraulichkeit und Authentizität) bedrohen. Risikomanagement hat zum Ziel, fatale, sprich existenzgefährdende, Schäden für das Unternehmen möglichst zu verhindern. Die Steuerung von IT-Risiken muss in Übereinstimmung mit der Unternehmensstrategie erfolgen. Dazu müssen bestehende Risiken für die Unternehmensführung transparent sein. Mit den MaRisk werden die Anforderungen aus § 25a KWG weiter konkretisiert. Ziele der MaRisk (AT 2) sind u.a. der Schutz der anvertrauten Vermögenswerte, die häufig als Daten in IT-Systemen technisch repräsentiert werden, und die ordnungsgemäße Durchführung der Bankgeschäfte oder Finanzdienstleistungen. Die Risikoidentifikation als Teil des Gesamtrisikoprofils der Bank auf der einen und die Festlegung des bestehenden Risikodeckungspotenzials (AT 4.1) der Bank auf der anderen Seite ist der erste wesentliche Schritt bei allen Risikomanagement-Prozessen der IT-Risiken. Sie ist dabei einer der schwierigsten Teile des Risikomanagement-Prozesses, da alle weiteren Maßnahmen auf ihr beruhen. Schließlich können nur die Risiken bewertet und gesteuert werden, die im Vorfeld erkannt wurden. Es gilt die Regel, dass ein Risiko, das nicht im Vorfeld erkannt werden konnte, beim Eintreten auch nicht mit entsprechenden Maßnahmen in den Griff bekommen werden kann. Als Mindestanforderungskriterien an die Phase der Risikoidentifikation können dementsprechend Vollständigkeit, Aktualität und regelmäßige Überprüfungen genannt werden. Vollständigkeit bedeutet dabei eine vollständige Erfassung von Risiken eines Projekts. Unter Aktualität wird eine zeitnahe Erfassung von Risiken verstanden. Da sich Risiken durch z.B. veränderte Rahmenbedingungen auch ändern können, muss, um die Kriterien der Vollständigkeit und Aktualität erfüllen zu können, das Kriterium der regelmäßigen Überprüfung herangezogen werden. Auf dieser Grundlage wird die Geschäftsstrategie definieret und daraus ableitbare Teilstrategien (AT 4.2), zu denen auch die IT-Strategie gemäß IDW RS FAIT 1 als Funktionalstrategie gehört. Die Auswirkungen der Risiken lassen sich mindern, jedoch nie gänzlich ausschließen. Aus meiner Sicht gibt es konkret folgende wesentliche Risiken:

  1. Die Bank hat keinen Einfluss auf die Wirtschaftlichkeit und eine eventuelle Insolvenz des Dienstleisters.
  2. Die Bank hat keinen Einfluss und keinen direkten Zugriff mehr auf die handelnden Mitarbeiter.
  3. Der Service für die Mitarbeiter wird von ‘Externen’ erbracht.
  4. Business-Know-how geht auf Dauer verloren. Die Abhängigkeit von den allgemeinen Dienstleistern wird mit den Jahren größer.
  5. Der Dienstleister erbringt seine Leistungen nicht nur für die Bank. Mit der Zeit könnte die Bank nicht mehr an erster Priorität stehen.

Die nachfolgenden Maßnahmen könnten die Auswirkung der Risiken mindern:

  1. Außerordentliches Kündigungsrecht der Bank mit der Möglichkeit, im Insolvenzfall Mitarbeiter ohne Zustimmung des Dienstleisters zu übernehmen.
  2. Monatliche Kopie der Personalsysteme und der Daten wird dem IT-Bereich der Bank übergeben. Im Havariefall kann eine eigene Plattform erstellt werden.
  3. Partnerschaftlicher und professioneller Umgang mit dem Dienstleister, ohne sich gegenseitig zu übervorteilen.
  4. Schaffung von Stellen in der Bank zur Überwachung und Steuerung der Dienstleistung.
  5. Optimierung der Prozesse beim Dienstleister, gemeinsame Einrichtung der Schnittstellen und Festlegen der Prozesse.

Unter Risikosteuerung versteht man die aktive Beeinflussung der im Rahmen der Risikoidentifikation und Risikobewertung ermittelten Risiken entsprechend ihrer Risikoposition. Voraussetzung für eine effektive Risikosteuerung ist eine regelmäßige Erfassung der Analyseergebnisse und eine sachgerechte Information der Entscheidungsträger. Die Maßnahmen, die für die Steuerung getroffen werden, haben dabei eine Verringerung der Eintrittswahrscheinlichkeit und/oder eine Begrenzung der Auswirkungen zum Ziel. Die Steuerungs- und
-controllingprozesse müssen gewährleisten, dass die wesentlichen IT-Risiken – auch aus ausgelagerten Aktivitäten und Prozessen (z.B. an die Rechenzentrale) – frühzeitig erkannt, vollständig erfasst und in angemessener Weise dargestellt werden können. Die Steuerungs- und
-controllingprozesse für IT-Risiken sind zeitnah an sich ändernde Bedingungen anzupassen. Es muss gewährleistet sein, dass wesentliche IT-Risiken zumindest jährlich identifiziert und beurteilt werden (BTR 4 Tz. 2). Bedeutende Schadensfälle (z.B. längerer Ausfall von IT-Systemen) sind unverzüglich hinsichtlich ihrer Ursachen zu analysieren (BTR 4 Tz. 3). Die Umsetzung der zu treffenden Maßnahmen ist zu überwachen (BTR 4 Tz. 5). Der Vorstand hat sich in angemessenen Abständen über die IT-Risikosituation berichten zu lassen. Die IT-Risikoberichterstattung ist in nachvollziehbarer, aussagefähiger Art und Weise zu verfassen. Sie hat neben einer Darstellung auch eine Beurteilung der Risikosituation zu enthalten. In die Berichterstattung sind bei Bedarf auch Handlungsvorschläge, z.B. zur Risikoreduzierung, aufzunehmen. Die IT-Risikoberichterstattung an den Vorstand kann – soweit dies aus Sicht des Vorstandes als sinnvoll erachtet wird – durch prägnante Darstellungen ergänzt werden (z.B. ein Management Summary). Soweit sich keine relevanten Änderungen ergeben haben, kann im Rahmen der aktuellen Berichterstattung auf diese Informationen verwiesen werden. Auch eine Diskussion der Handlungsvorschläge mit den jeweils verantwortlichen Bereichen ist grundsätzlich unproblematisch, solange sichergestellt ist, dass der Informationsgehalt der Berichterstattung beziehungsweise der Handlungsvorschläge nicht auf eine unsachgerechte Weise verzerrt wird. In den Risikoberichten sind insbesondere auch die Ergebnisse der Stresstests von IT-Risiken sowie ggf. die Ergebnisse der Notfalltests (AT 7.3 Tz. 1) und deren potenzielle Auswirkungen auf die Risikosituation und das Risikodeckungspotenzial darzustellen. Ebenfalls darzustellen sind die den Stresstests zugrunde liegenden wesentlichen Annahmen. Darüber hinaus ist auch auf Risikokonzentrationen und deren potenzielle Auswirkungen gesondert einzugehen. Der Vorstand ist mindestens jährlich über bedeutende IT-Schadensfälle und wesentliche IT-Risiken als Teil der operationellen Risiken zu unterrichten. Die Berichterstattung hat die Art des Schadens beziehungsweise IT-Risikos, die Ursachen, das Ausmaß des Schadens beziehungsweise IT-Risikos und gegebenenfalls bereits getroffene Gegenmaßnahmen zu umfassen (BTR 4 Tz. 4). Auf Basis der Berichterstattung ist zu entscheiden, ob und welche Maßnahmen zur Beseitigung der Ursachen zu treffen oder welche Risikosteuerungsmaßnahmen (z.B. Versicherungen, Ersatzverfahren, Neuausrichtung von Geschäftsaktivitäten, Katastrophenschutzmaßnahmen) zu ergreifen sind (BTR 4 Tz. 5). Unter Risikogesichtspunkten wesentliche Informationen sind unverzüglich an den Vorstand, die jeweiligen Verantwortlichen und gegebenenfalls die Interne Revision weiterzuleiten, sodass geeignete Maßnahmen beziehungsweise Prüfungshandlungen frühzeitig eingeleitet werden können. Hierfür ist ein geeignetes Verfahren festzulegen. IT-Risiken sollten in angemessener Weise bei der Berichterstattung des Vorstandes an den Aufsichtsrat berücksichtigt werden. Der Ausdruck „Stresstests für IT-Risiken“ wird im Folgenden als Oberbegriff für die unterschiedlichen Methoden gebraucht, mit denen die Bank ihr individuelles Gefährdungspotenzial auch bezüglich außergewöhnlicher, aber plausibel möglicher Ereignisse im Umfeld der IT-Risiken auf den jeweils relevanten Ebenen der Bank überprüfen. Sollte die Bank IT-Risiken als wesentliche Risiken festgelegt haben, sind regelmäßig angemessene Stresstests für die IT-Risiken durchzuführen, die Art, Umfang, Komplexität und den Risikogehalt der Geschäftsaktivitäten widerspiegeln. Ein wichtiger Faktor zur erfolgreichen Umsetzung des Risikomanagements ist deshalb eine gelebte Risikokultur. Sie bildet das Fundament der einzelnen Risikomaßnahmen, die im Rahmen des Risikomanagements getroffen werden. Eine Risikokultur beinhaltet die Bereitschaft zur Wahrnehmung von Risiken, die Sensibilisierung der Mitarbeiter und die Kommunikation der Risiken. Die Geschäftsleitung erfüllt also eine wichtige Vorbildfunktion. Nicht vergessen darf man natürlich die Compliance-Aspekte. Die Bestimmungen zur Jahresabschlussprüfung wurden z.B. in Deutschland durch das Gesetz über Kontrolle und Transparenz im Unternehmensbereich und für an US-Börsen notierte Gesellschaften im SOX verschärft. Darüber hinaus existieren viele weitere Vorschriften mit teilweise nur lokaler oder bankspezifischer Bedeutung (MaRisk) sowie weitere Regulierungen wie Basel II, Solvency II oder die EU-Richtlinie MiFID („Markets in Financial Instruments Directive“). Banken können sich nicht durch Auslagerung ihren Nachweispflichten entziehen. Das auslagernde Unternehmen muss sicherstellen, dass die Vorgehensweisen des Dienstleisters den Ansprüchen des Gesetzgebers und der Regulatoren entsprechen.

Nach der MaRisk AT 9 hat eine regelmäßige Auswertung von Informationen und Berichten im Rahmen des internen Kontrollsystems für ausgelagerte Aktivitäten und Prozesse zu erfolgen. Hierbei sind grundsätzlich folgende Fragestellungen zu beachten:

  1. Wer ist bankintern für die Überwachung und Steuerung der Auslagerungsdienstleitung verantwortlich?
  2. Handelt es sich um einen Bericht über die Durchführung von Tätigkeiten der Internen Revision beim Auslagerungsunternehmen?
  3. Erfolgt die Berichterstattung außerhalb eines regelmäßigen Turnus?
  4. Ergeben sich Lücken bei den geprüften Zeiträumen?
  5. Wurden wesentliche, schwerwiegende oder besonders schwerwiegende Mängel festgestellt?
  6. Handelt es sich um Mängel, die bereits in vorangegangenen Berichten festgestellt wurden?
  7. Sind Maßnahmen beim Insourcer erforderlich?
  8. Müssen von der Bank Maßnahmen ergriffen werden?

In der Praxis ergibt sich in vielen Banken ein kompliziertes Geflecht aus Auslagerungen, die eine zentrale Instanz notwendig machen, um den Überblick über die Steuerung von Auslagerungen zu behalten. Denn häufig haben es die Institute nicht mit einfachen 1:1-Beziehungen zu nur einem Dienstleister zu tun, sondern mit 1:n-Beziehungen, falls beauftragte Dienstleister ihrerseits Auslagerungen vornehmen. Vor allem bei kleineren Instituten ist es beispielsweise verbreitet, den Zahlungsverkehr an einen gemeinsamen Dienstleister auszulagern. Angesichts des beschränkten Geschäftsauftrags lagert dieser dann häufig die Interne Revision zumindest teilweise aus. Das entlastet jedoch die erstauslagernden Institute nicht von der Verantwortung, für einen ordnungsgemäßen Informationsfluss zu sorgen. Dies ist in den Bedingungen für Weiterauslagerungen festzuhalten und durch das erstauslagernde Institut nachzuhalten.

VII. Konsistenz von Sicherheitsmanagement und Notfallplanung

Durch den IT-Outsourcing-Vertrag wird mittels der SLA festgelegt, welche Dienstleistungen vom Service Anbieter in welchem Umfang erbracht werden müssen. Dabei ist die Verantwortlichkeitsverteilung klar geregelt und die Konsequenzen bei Nicht-Erfüllung sind entsprechend definiert. Bei der IT-Sicherheit hingegen sind die Verantwortlichkeiten nicht mittels der SLA geregelt. Damit gewährleistet werden kann, dass mit Anwendungen oder Kundendaten auch beim Service Anbieter sicher umgegangen wird, wird zwischen den Outsourcing-Parteien ein sogenanntes IT-Sicherheitskonzept erstellt. In diesem Sicherheitskonzept sind die verschiedenen Verantwortlichkeiten und die relevanten Themen geregelt. Die zentrale Frage bei der Erstellung eines IT-Sicherheitskonzeptes lautet: Welchen Schutz benötigen welche IT-Systeme? Es ist zu beachten, was genau geschützt werden muss und wogegen die Systeme geschützt werden müssen. Wurde eine entsprechende Risikoanalyse vorgenommen, so muss man sich mit der Frage auseinandersetzen, wie ein wirksamer Schutz erreicht werden kann und ob der Nutzen des Schutzes einen potentiellen Schaden übersteigt. Damit sind die Kernbestandteile eines IT-Sicherheitskonzeptes umriussen. Der Service Anbieter schließt mit jedem einzelnen Kunden ein separates Konzept ab. Ein IT-Sicherheitskonzept ist wesentlicher Bestandteil zwischen Service Anbieter und Outsourcingnehmer, die Themen des Sicherheitskonzeptes sind nicht verhandelbar. Dies gilt auch für Kunden, die z.B. einem „geteilten Service“ angehören. Das sind Kunden, die sich beim Service Anbieter im gleichen Netzwerk oder Rechenzentrum wie andere Kunden befinden. Die Erstellung des IT-Sicherheitskonzeptes ist im Idealfall eine Zusammenarbeit zwischen dem Outsourcingnehmer und dem Service Anbieter. Diese Vorgehensweise wird in der Praxis auch so gehandhabt. Bei nicht wesentlichen Geschäftsprozessen ist eine gemeinsame Erarbeitung des Sicherheitskonzepts nicht zwingend. Die IT-Sicherheits-Verantwortlichen der Bank haben zu beachten, dass die eigenen internen Sicherheitsrichtlinien in das Sicherheitskonzept integriert werden. Die Praxis hat gezeigt, dass die Service Anbieter Vorlagen der Sicherheitskonzepte besitzen, die an die jeweiligen Kunden angepasst werden. Diese Vorlagen sind mit den Richtlinien und Weisungen des Service Anbieters bezüglich der IT-Sicherheit versehen. Die Einbringung der Richtlinien des Outsourcingnehmers gehört zu den Pflichten des IT-Sicherheit-Verantwortlichen des Outsourcingnehmers. Das Informationssicherheitskonzept ist in jedem IT-Projekt sowie in Projekten mit IT-Anteil zu erstellen. Das projektbezogene Informationssicherheitskonzept enthält alle an das zu entwickelnde System verbindlich gestellten Informationssicherheitsanforderungen und die Informationssicherheitsmaßnahmen zum Schutz der Informationen vor Verlust der Integrität, Verbindlichkeit, Vertraulichkeit und Verfügbarkeit sowie die Informationssicherheitsanforderungen und Informationssicherheitsmaßnahmen zum Schutz der technischen Anlagen zur Informationsverarbeitung und Informationsübermittlung. Im Rahmen der Erstellung und Fortschreibung des Informationssicherheitskonzepts sind seine Inhalte auf Korrektheit, Konsistenz und Vollständigkeit zu überprüfen und ggf. anzupassen.

PRAXISTIPPS

  • Identifizieren Sie die Software in ihrer Bank, die zukünftig als Auslagerung gelten könnte
  • Gestaltet Sie die Prozesse durch eine zentrale Dienstleistersteuerung effizient
  • Auswertung der Berichterstattung ist zentraler Baustein der Dienstleistesteuerung
  • Führen Sie Stresstests zu IT-Risiken durch
  • Stimmen Sie Sicherheitsmanagement und Notfallplanung mit ihrem Dienstleister auch unterjährig ab

Beitragsnummer: 39063

„BaFin … wir haben (k)ein Problem!“

Auswirkungen rechtlicher Vorgaben auf die Datenqualität von Kundendaten

Klaus Jakobi, IT-Auditor, Prüfung / Betreuung Banken, Datenanalyse, AWADO – Deutsche Audit GmbH

I. Die Ausgangslage

Im Rahmen des Kundenannahmeprozesses erwartet der Gesetzgeber höchste Anstrengungen und Sorgfalt einer Bank, da diese Maßnahmen in der Regel nur zu Beginn einer Geschäftsbeziehung durchgeführt werden. Alle Willenserklärungen, die nachfolgend zwischen Kunde und Bank ausgetauscht werden, bauen darauf, dass der Know-Your-Customer-Prozess fehlerfrei durchgeführt wurde. Doch ist das wirklich so? Sind die betreffenden Daten fehler- und zweifelsfrei und in sich konsistent?

Die berühmt gewordenen Worte „Houston … wir haben ein Problem“ des Apollo-13-Kommandanten Jim Lovell umschreiben einen spektakulären Störfall in der Raumfahrtgeschichte während einer Mondmission im Jahre 1970, die letztendlich aber doch noch zu einem guten Ende gebracht werden konnte. Alle Crewmitglieder überlebten. Man sprach von einem erfolgreichen Fehlschlag.

Der Titel dieses Artikels wurde in Anlehnung an diese Worte, die auf ein bedrohliches Problem hindeuteten, gewählt, weil bestimmte Inhalte in den von den Banken gespeicherten Kundendaten möglicherweise nicht vollständig den regulatorischen Vorgaben entsprechen und dieser Umstand unangenehme Folgen für eine Bank in Form von erheblichen Sanktionen nach sich ziehen kann. Es besteht aber die Möglichkeit, bei rechtzeitigem Erkennen und Beheben der Schwächen drohendes Ungemach abzuwenden.

Die folgenden Ausführungen stellen häufige Fehler in den Kundendaten da, die im Rahmen von Daten-Qualitäts-Checks festgestellt wurden.

II. Die (neue) Rechtslage

In den letzten Jahren haben sich Terrorgefahr und Gefahren aus organisierter Kriminalität erkennbar für jedermann erhöht. Auch dies hat den Gesetzgeber dazu bewogen, Ende Juni 2017 ein neues Geldwäschegesetz (GwG) zu verabschieden[1] und in Kraft zu setzen. Der Umfang der Vorschriften hat sich dabei „dramatisch“ ausgeweitet. Endete die vorherige Fassung des GwG noch bei § 17, so umfasst die aktuelle Fassung jetzt 59 Paragraphen. Für Finanzinstitute ergaben sich dabei insbesondere folgende Neuerungen:

  • Einrichtung eines zentralen Transparenzregisters
  • Umstrukturierung der Zentralstelle für Finanztransaktionsuntersuchungen (kurz FIU)
  • Verschärfung der Sanktionen bei Verstößen gegen GwG-Vorschriften

Auch sind in Teilbereichen die bankeigenen Prozesse betroffen. Beispielsweise war bisher die Hereinnahme von Ausweiskopien bei Kunden obligatorisch; jetzt ist es für jede Bank verpflichtend, entsprechende Nachweise abzulegen.

Unverändert blieben jedoch die zentralen Anforderungen an das Know-Your-Customizer-Prinzip und der damit verbundene hohe Qualitätsanspruch des Gesetzgebers an entsprechende Daten. Dies gilt neben den Kunden auch für weitere Personen (wirtschaftlich Berechtigte, Bevollmächtigte), die an einer Geschäftsbeziehung beteiligt sind.

Die damit verbundenen Sanktionen wurden spürbar verschärft. Gemäß § 56 Abs. 2 GwG liegt die Obergrenze einer Geldbuße für ein Finanzinstitut bei nunmehr 5 Millionen Euro bzw. 10 % des Gesamtumsatzes (vorher 100.000 Euro).

III. Kundendaten

Die rechtlichen Anforderungen aus GwG, KWG und anderen Gesetzen an die in den Geschäftsprozessen verwendeten Daten formen eine Art „Data-Compliance“, also den formulierten Anspruch an deren Integrität und Konsistenz. Tatsächlich ist es jedoch so, dass durch die bestehenden Rahmenbedingungen hohe Fehlerquoten nicht ungewöhnlich sind und ein wirklich fehlerfreien Datenbestand sehr unwahrscheinlich ist. Zu diesen Rahmenbedingungen gehören

  • Komplexe rechtliche Vorgaben
  • Komplexe IT-Verfahren
  • Vielzahl von Mitarbeitern
  • Nicht voll ausgeprägte Interne Kontrollsysteme

Die GwG-Vorschriften verlangen bei Kunden die fehlerfreie und vollständige Erhebung (= Aufzeichnung) folgender Angaben:

  • Bei natürlichen Personen:
    • Vor- und Nachname, Geburtsort, Geburtsdatum, Staatsangehörigkeit und Wohnanschrift …[2]
    • Art, Nummer und ausstellende Behörde des zur Überprüfung der Identität vorgelegten Dokuments[3]
  • Bei juristischen Personen oder Personengesellschaften:
    • Firma, Name oder Bezeichnung, Rechtsform, Registernummer (falls vorhanden)[4], Anschrift des Sitzes oder der Hauptniederlassung, Name von Vertretungsberechtigten …[5]

Einige dieser Angaben werden nachfolgend im Hinblick auf häufig festgestellte Fehler nähergehend erläutert.

1. Der Kundenname

In den verwendeten Bankverfahren[6] gibt es für die Erfassung von Kundennamen verschiedene Felder mit unterschiedlichen Eigenschaften. Dies können Lang- und Kurznamen sowie Sortiernamen oder Nebenadressnamen sein. Dabei können für Privat- und Unternehmenskunden unterschiedliche Namensfelder existieren. Weiterhin gibt es in auch noch gesonderte Felder für den § 24c-KWG-Namen, deren Inhalte für das Kontoabrufverfahren der Bundesbank vorgesehen sind und in denen der „rechtliche“ Name eines Kunden enthalten sein muss, also der „echte“ Name eines Kunden – frei von Abkürzungen und Zusätzen. Die folgenden Ausführungen beschreiben die Anforderungen an diesen „rechtlichen“ Namen eines Kunden. Häufig werden diese Felder durch Daten aus anderen Namensfeldern zunächst vorbefüllt, wobei eine nachträgliche Anpassung der Inhalte, so denn erforderlich, möglich ist.

Es gilt der Grundsatz, dass der „rechtliche“ Name eines Kunden durch ein zugelassenes Legitimationspapier oder einen Eintrag aus einem öffentlichen Register (= LegiRegi-Daten) nachweisbar sein muss. Dabei ist auf eine exakte, zeichengenaue Übernahme dieser Einträge in die Namensfelder zu achten.

a) Der Name der natürlichen Person

Zunächst mal muss der rechtliche Kundenname einer natürlichen Person alle Vornamen und Nachnamen ohne Abkürzungen enthalten, und zwar so wie der Name auch im Ausweisdokument enthalten ist. Sollte jedoch aufgrund technischer Restriktionen ein langer Name nicht erfassbar sein, kann auf einzelne Namensbestandteile verzichtet werden[7]. In einigen Kulturkreisen besteht der Name nur aus Vornamen. In diesem Sonderfall sind alle Vornamen im Feld für den rechtlichen Nachnamen zu erfassen[8].

Namenszusätze wie „Junior“, „Senior“ oder entsprechende Abkürzungen sind nicht Bestandteil des rechtlichen Namens einer natürlichen Person, da sie nicht im Ausweis eingetragen werden. Hingegen sind Namensbestandteile, die früher als „Adelstitel“ bezeichnet wurden (z. B. „Baron“, „Gräfin“, „von“), immer Bestandteil des Nachnamens und nicht des Vornamens oder eines gesonderten Titelfeldes[9]. Beispiel:

Vorname: Otto

Nachname: Fürst von Bismarck

Als akademischer Titel darf lediglich der „Dr.“ ohne weitere Grade, wie „med.“ oder „phil.“, verwendet werden, wenn der Titel auch im Ausweisdokument so eingetragen ist.

Bestimmte Zeichen sind im Namen einer natürlichen Person unplausibel. Dazu zählen alle (arabischen und römischen) Ziffern sowie alle Sonderzeichen mit Ausnahme des Bindestriches.

PRAXISTIPP 1

Untersuchen Sie in Ihrem Kundenbestand die „rechtlichen“ Namen natürlicher Personen auf vorstehend genannte Inhalte. Sollten Sie keine entsprechenden Treffer haben, haben Sie (hier) erstmal kein Problem.

b) Der Name des Kaufmanns

Bei Kaufleuten muss nach eingetragenen und nicht eingetragenen Kaufleuten unterschieden werden.

Der Name des eingetragenen Kaufmannes lässt sich aus dem entsprechenden Handelsregisterauszug ablesen. Es handelt sich dabei um eine „Firma“ im Sinne des HGB[10].

Für den eingetragenen Kaufmann als Kunden ist immer die Anlage von mindestens zwei Kundenstämmen erforderlich. Der erste Kundenstamm enthält die Firma des eingetragenen Kaufmannes mit den Registerdaten, der zweite Kundenstamm den Namen des Geschäftsinhabers bzw. des wirtschaftlich Berechtigten mit seinen persönlichen Legitimationsdaten.

Aber wie sieht der rechtliche Name eines nicht eingetragenen Kaufmann und Gewerbetreibenden aus? Kann der rechtliche Name unter einer vom Kunden gewählten „Geschäftsbezeichnung“ geführt werden? Beispiele:

  • Hotel zum Löwen, Inh. Egon Müller
  • Rats-Apotheke
  • Kfz-Werkstatt Inh. Hans Meyer
  • Blitz-Elektro-Installation

Die klare Antwort ist: Nein, der rechtliche Name eines nicht eingetragenen Kaufmannes bzw. Gewerbetreibenden ist nicht die gewählte Geschäftsbezeichnung, sondern ausschließlich der Privatname des Geschäftsinhabers bzw. Gewerbetreibenden ohne weitere Zusätze[11]. In diesem Zusammenhang sei auch darauf hingewiesen, dass die gespeicherte Hauptadresse natürlich nicht die Geschäftsanschrift sein darf, sondern der Wohnsitz bzw. die Privatanschrift des Inhabers[12].

Geschäftsbezeichnung und -adresse können jedoch in anderen Namens- und (Neben-) Adressfeldern bei diesen Kunden verwendet werden.

PRAXISTIPP 2

Untersuchen Sie in Ihrem Kundenbestand die rechtlichen Namen von Kunden mit der Rechtsform „Einzelunternehmen“ oder „Gewerbetreibender“ auf das Fehlen eines Zusatzes wie „e. K.“. Dies deutet auf einen nicht eingetragenen Kaufmann hin. Entsprechen in diesen Fällen die Inhalte der Namensfelder dem Namen einer natürlichen Person? Wenn ja, haben Sie kein Problem [13] [14].

c) Der Name der Personenmehrheit

Bei Personenmehrheiten handelt es sich um einen Zusammenschluss von mehreren Personen zwecks Erreichung eines gemeinsamen Zieles, ohne dass für diesen Zusammenschluss eine registerpflichtige Gesellschaftsform gewählt wurde und somit ein Eintrag in ein öffentliches Register erfolgte. Dieser Umstand erschwert natürlich die Suche nach dem „rechtlichen Namen“ dieser Gemeinschaft, da kein öffentliches Register zur Verfügung steht.

In der Literatur wird häufig von „losen“ Personenzusammenschlüssen gesprochen. Es gibt aber auch „fixe“ Personenzusammenschlüsse. Lose und fixe Personenzusammenschlüsse sind bei der Kundenanlage und der Erfassung des rechtlichen Namens unterschiedlich zu behandeln.

Zunächst zu den fixen Personenzusammenschlüssen: Dies sind Personenvereinigungen, die sich eine „selbstverpflichtende Verfassung“ in Form eines schriftlichen Gesellschaftsvertrages, einer Satzung oder eines Gründungsprotokolls gegeben haben. Dazu zählen insbesondere

  • der nicht eingetragene Verein[15],
  • die Gesellschaft bürgerlichen Rechts[16] sowie
  • die Wohnungseigentümergemeinschaft (WEG)[17].

Bei diesen „fixen“ Personenmehrheiten ist es zulässig, die in der „Verfassung“ gewählten Gemeinschaftsbezeichnung als rechtlichen Namen des Kunden zu verwenden[18]. Beispielsweise:

  • Freiwillige Feuerwehr Irgendwo
  • Müller und Schmidt GbR
  • WEG Hauptstraße 10, Berlin

Lose Personenzusammenschlüsse verfügen hingegen nicht über eine „Verfassung“ in schriftlicher Form. Beispiele für solch lose Personenmehrheiten sind

  • Sparclubs, Stammtischrunden, Wohngemeinschaften,
  • Spiel- und Sportgemeinschaften,
  • Klassen- und Belegschaftskassen

Und wie muss nun der rechtliche Namen bei solchen Kunden gestaltet werden? Er darf natürlich nicht auf den selbst gewählten Namen wie „Kegelclub alle Neune“ lauten, sondern ist entweder auf den Namen aller an der Gemeinschaft beteiligten Personen oder eines Treuhänders anzulegen[19]. Aus praktischen Erwägungen wird die Anlage auf den Namen eines Treuhänders empfohlen, insbesondere wenn eine hohe Anzahl von Personen an der Gemeinschaft beteiligt ist.

PRAXISTIPP 3

Untersuchen Sie in Ihrem Kundenbestand die rechtlichen Namen von Kunden auf Inhalte wie beispielsweise „Sparclub“ oder „Klassenkasse“[20]. Haben Sie keine Treffer, haben Sie hier kein Problem!

d) Der Name von eingetragenen Unternehmen

Anders als bei Privatpersonen können bei Unternehmensnamen auch Abkürzungen, Sonderzeichen oder Ziffern verwendet werden. Allerdings gibt es hinsichtlich der Verwendung von Sonderzeichen Beschränkungen[21]. Es sollen nur Sonderzeichen in der Firma eingetragen werden, wenn sie als Wort ersetzendes Zeichen verwendet werden können, z. B. das Zeichen @ für „at“ oder das Zeichen & für „und“. Andere Bildzeichen, wie beispielsweise das Paragrafen-, Rauten- oder Klammerzeichen, erfüllen keine Namensfunktion.

e) (Adress-)Zusätze im Namen

Häufig finden sich in Namensfeldern auch ergänzende (Adress-)Zusätze wie „c/o“, „zu Hdn.“ oder „wegen“ und ähnliches. Solche Zusätze sind nie Bestandteil eines rechtlichen Namens und dürfen daher auch nicht in den entsprechenden Feldern vorkommen.

e) Sonstige Namens(un)plausibilitäten

Weitere Auswertungsansätze können ebenfalls Schwächen in den Daten offenbaren. Dies sind beispielsweise

  • Anreden (Herr, Frau, Eheleute, Firma) im Namensfeld
  • Vorname ist gleich Nachname
  • Kurze Namen oder Namen ohne Vokale
  • Phonetische Gleichheit von Nachnamen mehrerer Kunden mit gleicher Adresse bei unterschiedlicher Schreibweise (z. B. „Kowalski“ und „Kovalsky“)

2. Die Staatsangehörigkeit

Neben dem Namen einer natürlichen Person ist deren Staatsangehörigkeit ein weiteres Merkmal, welches zwingend nach den Geldwäsche-Vorschriften aufzuzeichnen ist. Vielfach arbeiten die genutzten Systeme auch hier mit vorbelegten Ländercodes (z. B. Bundesbank-Ländercode 000 für Deutschland). Im Abgleich mit weiteren erfassten Daten eines Kunden zeigen sich jedoch vielfach Unplausibilitäten, die bereinigt werden müssen.

Bei doppelten Staatsbürgerschaften sollte jene Staatsangehörigkeit als „Leit-Staatsange-hörigkeit“ erfasst werden, zu der der Kunde die entsprechenden Legitimationspapiere vorgelegt hat. Staatsangehörigkeit und Legitimationsdaten korrespondieren in diesem Fall miteinander.

a) Veraltete Ländercodes

In der Vergangenheit ist es insbesondere in der Zeit des Zusammenbruchs der ehemaligen Ostblockstaaten Ende der 80er-Jahre zu neuen Staatsgebilden gekommen, die teilweise nur von kurzer Dauer waren. Beispielsweise existieren folgende Staaten nicht mehr (in Klammern der entsprechende Bundesbank-Ländercode)[22]:

  • Sowjetunion (056)
  • Jugoslawien (048 bzw. 090)
  • Serbien-Montenegro (094)

Gleichwohl zeigt die Analyse von Massendaten, dass bei einigen Kunden Staatsangehörigkeiten immer noch gespeichert sind, obwohl der entsprechende Staat seit fast 30 Jahren nicht mehr existiert. Finanzdienstleister sind jedoch gesetzlich verpflichtet, entsprechende Daten zu korrigieren. In § 11 Abs. 3 Satz 2 GwG heißt es:

„Muss der Verpflichtete aufgrund der äußeren Umstände Zweifel hegen, ob die bei der früheren Identifizierung erhobenen Angaben weiterhin zutreffend sind, hat er eine erneute Identifizierung durchzuführen.“

Dies dürfte bei veralteten Staatsangehörigkeiten unstrittig sein.

PRAXISTIPP 4

Checken Sie anhand der aktuellen Bundesbank-Länderliste die Staatsangehörigkeiten Ihrer Kunden. Staatsangehörigkeiten, die nicht mehr gelistet sind, müssen durch eine erneute Identifizierung des Kunden bereinigt werden. Sonst haben Sie ein Problem!

b) Falscher Inländer

Wie bereits erläutert, kann das Feld Staatsangehörigkeit durch einen Standardwert vorbelegt sein. Die genutzten Verfahren verfügen nicht immer über fehlerverhindernde Systeme, die bei Unplausibilitäten einen entsprechenden Fehlerhinweis geben. Wird also jemand mit der Staatsangehörigkeit „000“ (= Inländer / Deutscher) angelegt und im Feld „Ausstellende Behörde“ befindet sich beispielsweise eine der folgenden Begrifflichkeiten, erscheint die gespeicherte Staatsangehörigkeit unplausibel:

  • Ausländerbehörde
  • Embassy
  • Government
  • State

Gleiches gilt, wenn die Ausweisart bei einem inländischen Kunden

  • ein Aufenthaltstitel,
  • ein Ankunftsnachweis oder
  • ein Reiseausweis für Ausländer, Flüchtlinge oder Staatenlose (= Passersatz)

sein sollte.

Und zu guter Letzt:

Handelt es sich bei der ausstellenden Behörde des Legitimationspapieres um eine Botschaft oder ein Konsulat in einer deutschen Stadt, muss der betreffende Kunde ebenfalls Ausländer sein. Deutschland unterhält keine Auslandsvertretungen im Inland.

PRAXISTIPP 5

Suchen Sie bei inländischen Kunden nach diesen Bezeichnungen in den Feldern „ausstellende Behörde“ oder „Ausweisart“! Haben Sie keine Treffer, haben Sie (vermutlich[23]) keine Probleme!

b) Falscher Ausländer

Umgekehrt besteht natürlich auch die Möglichkeit, dass ein Kunde fälschlicherweise eine ausländische Staatsangehörigkeit haben soll, obwohl er Inländer ist. Dies kann beispielsweise vorkommen, wenn sich im Laufe der Geschäftsbeziehung eine Einbürgerung erfolgt ist. Insofern ist eine ausländische Staatsangehörigkeit unplausibel, wenn eine deutsche Behörde einen Personalausweis oder einen Reisepass für den Kunden ausgestellt hat. Auch hier sollte der Finanzdienstleister Zweifel anhand der äußeren Umstände hegen, wenn diese Daten Inkonsistenzen aufweisen und eine erneute Identifizierung für diesen Kunden vornehmen.

3. Die Rechtsform

Personenhandelsgesellschaften und juristische Personen des privaten Rechts sind in einem öffentlichen Register eingetragen. In verschiedenen Gesetzen werden Anforderungen an die Firma gestellt. In aller Regel muss ein Namensbestandteil vorhanden sein, der die gewählte Rechtsform entsprechend präsentiert[24]. Mithilfe eines Rechtsformschlüssels kann dann abgeglichen werden, ob solche Mindestinhalte im Namen auch zutreffend vorkommen und ob der Name des Unternehmens somit plausibel ist. Kommt also beispielsweise bei der Verwendung des Rechtsformschlüssels „GmbH“ diese Abkürzung oder eine vergleichbare auch tatsächlich im Unternehmensnamen (= Firma) des Kunden vor?

Fehler treten auch häufig bei Kunden auf, die eine juristische Person des öffentlichen Rechts sind. Insbesondere die Zuordnung zu einer Körperschaft oder einer Anstalt des öffentlichen Rechts oder gegebenenfalls weitere Untergliederungen (Gebiets-, Personal-, Verbands- oder Realkörperschaft) bereiten Schwierigkeiten. Dies liegt auch daran, dass es in diesen Fällen an einer Möglichkeit zur Einsichtnahme in ein öffentliches Register mangelt.

PRAXISTIPP 6

Gleichen Sie bei eingetragenen Unternehmenskunden die Inhalte der Firma mit dem Rechtsformschlüssel ab! Haben Sie nur Übereinstimmungen, haben Sie kein Problem!

Aufgrund der überschaubaren Anzahl von Kunden in der Rechtsform der juristischen Person des öffentlichen Rechts empfiehlt sich ein vollständiger Abgleich der vorgenommenen Zuordnungen.

PRAXISTIPPS

  • Untersuchen Sie zwecks Bereinigung in Ihrem Kundenbestand die rechtlichen Namen natürlicher Personen auf nicht zulässige Angaben wie Ziffern, Abkürzungen, Sonderzeichen oder Namenszusätze wie „Junior“ oder „Senior“.
  • Untersuchen Sie in Ihrem Kundenbestand die rechtlichen Namen von Kunden mit der Rechtsform „Einzelunternehmen“ oder „Gewerbetreibender“ auf das Fehlen eines Zusatzes wie „e. K.“. Dies deutet auf einen nicht eingetragenen Kaufmann hin. Dessen rechtlicher Name ist ausschließlich der Privatname des Geschäftsinhabers bzw. Gewerbetreibenden ohne weitere Zusätze.
  • Untersuchen Sie in Ihrem Kundenbestand die rechtlichen Namen von Kunden auf Inhalte wie beispielsweise „Club“, „Klasse“, „Kasse“, die auf lose Personenzusammenschlüsse ohne eigenen rechtlichen Namen hindeuten.
  • Checken Sie anhand der aktuellen Bundesbank-Länderliste die Staatsangehörigkeiten Ihrer Kunden. Staatsangehörigkeiten, die nicht mehr gelistet sind, müssen durch eine erneute Identifizierung des Kunden bereinigt werden.
  • Suchen Sie bei inländischen Kunden in den Feldern „ausstellende Behörde“ oder „Ausweisart“ nach Angaben, die auf eine (in diesem Fall unplausible) Auslandsberührung hinweisen wie „Ausländerbehörde“, „Embassy“, „Aufenthaltstitel“ oder „Passersatz“.
  • Gleichen Sie zwecks Plausibilisierung bei eingetragenen Unternehmenskunden die Inhalte der Firma mit dem Rechtsformschlüssel ab.
  1. Das Gesetz zur Umsetzung der 4. EU-Geldwäscherichtlinie, zur Ausführung der EU-Geldtransferverordnung und zur Neuorganisation der Zentralstelle für Finanztransaktionsuntersuchungen wurde am 23.06.2017 verabschiedet und ist am 26.06.2017 in Kraft getreten.
  2. § 11 Abs. 4 Nr. 1 GwG, gilt teilweise auch für wirtschaftlich Berechtigte, sieh § 11 Abs. 5 GwG
  3. § 8 Abs. 2 i.V.m. § 12 Abs. 1 S. 1 Nr. 1 GwG
  4. Anmerkung des Verfassers: Eine Registernummer allein ist nicht eindeutig. Ergänzend müssen dazu auch das Registergericht und die Registerart (Handelsregister, Vereinsregister, etc.) für einen eindeutigen Nachweis benannt werden.
  5. § 11 Abs. 4 Nr. 2 GwG
  6. Hier speziell agree21 und bank21. In anderen Verfahren wird von ähnlichen Strukturen ausgegangen.
  7. Laut Schnittstellenspezifikation 3.2.2 der BaFin zum Kontoabrufverfahren im Abschnitt 5.1 (4c) bei Namen mit mehr als 50 Zeichen. Mittlerweile wurde in den Verfahren die Speicherkapazität je Namensfeld deutlich erhöht (bis 200 Zeichen).
  8. ebenda
  9. Siehe auch bei Wikipedia zum Stichwort „Adelstitel“
  10. Siehe § 17 HGB – Unter der Firma werden die Geschäfte betrieben, Unterschriften geleistet, kann geklagt oder verklagt werden.
  11. siehe vorstehende Ausführungen zum Namen des Privatkunden
  12. Siehe § 11 Abs. 4 Nr. 1 e) GwG – „Wohnanschrift“
  13. In agree21 sind entsprechende Konten für nicht eingetragene Firmen ausdrücklich auf den Namen der natürlichen Person anzulegen (siehe S. 65 in Anwenderdokumentation Personendaten V 16.2)
  14. In bank21 gibt es die Rechtsformen 10 – Einzelunternehmen und 11 – eingetragener Kaufmann
  15. § 54 BGB
  16. § 705 ff. BGB
  17. Die WEG hat gemäß § 10 Abs. 6 Wohnungseigentumsgesetz eine „Quasi-Firma“, unter der sie Rechte erwerben und Pflichten eingehen, klagen und verklagt werden kann.
  18. Siehe auch „ Die Legitimationsprüfung / Identifizierung bei der Kontoeröffnung“ aus der BVR-Bankenreihe unter D. Einzelfragen 2.3 bis 2.5
  19. Siehe auch „ Die Legitimationsprüfung / Identifizierung bei der Kontoeröffnung“ aus der BVR-Bankenreihe unter D. Einzelfragen 2.1 Konto eines losen Personenzusammenschlusses
  20. Weniger kann mehr sein: Effektiver ist die Suche mit Kurzbegriffen wie „Club“, „Klasse“, „Kasse“ etc. jeweils mit Groß- und Kleinschreibung. Dadurch wird das Trefferspektrum vergrößert.
  21. siehe Beschluss des LG München vom 15.Dezember 2008 (AZ: 17 HKT 920/09)
  22. Ob der Ländercode mit oder ohne führende Nullen geführt wird, ist systemabhängig und muss entsprechend berücksichtigt werden.
  23. Bei den genannten Begrifflichkeiten handelt es sich um keine abschließende Aufzählung. Auch andere Begriffe können in Frage kommen.
  24. Beispielsweise e.K., OHG, KG = § 19 HGB; GmbH = § 4 GmbHG; e.V. = § 65 BGB; Partnerschaft = § 2 PartGG etc.

Beitragsnummer: 39047

„BaFin … wir haben immer noch (k)ein Problem!“

 

Auswirkungen rechtlicher Vorgaben auf die Datenqualität von Kundendaten – 2. Teil

Klaus Jakobi, IT-Auditor, Prüfung / Betreuung Banken, Datenanalyse, AWADO – Deutsche Audit GmbH Wirtschaftsprüfungsgesellschaft Steuerberatungsgesellschaft

I. Vorwort

Der 1. Teil eines Artikels zu Detailfragen in der Datenqualität von Kundendaten wurde in der BankPraktiker-Ausgabe BP 12-01/2018 veröffentlich. Die nachfolgenden Ausführungen knüpfen nahtlos daran an.

Im ersten Teil lag der Schwerpunkt der Ausführungen bei den „allgemeinen“ Stammdaten von Kunden, wie beispielsweise Namen, Staatsangehörigkeit und Rechtsform. In diesem Teil wird nunmehr beschrieben, worauf bei der Erfassung von Legitimations- bzw. Registerdaten (kurz auch LegiRegi-Daten) zu achten ist und wie man diese Daten verplausibilisieren kann, da es auch hier einige Fallstricke gibt, die bei entsprechender Qualitätssicherung vermieden werden können. Schwerpunkt bei den nachfolgenden Betrachtungen sind insbesondere inländische Identitätsnachweise, da bei ausländischen Dokumenten eine Vielzahl von Konstellationen möglich sind, die hier nicht abschließend dargestellt werden können. In solchen Fällen empfiehlt sich ein Blick in das „öffentliche Online-Register echter Identitäts- und Reisedokumente“ des Rates der Europäischen Union.[1]

Für die Analyse dieser Daten können bereits vorhandene Datenkontrollsysteme oder aber auch Standard- (Excel, Access) oder Spezialprogramme (IDEA) genutzt werden.

II. Die Rechtslage

Die GwG-Vorschriften verlangen bei Kunden neben der Erfassung verschiedener Stammdaten auch die fehlerfreie und vollständige Erhebung (= Aufzeichnung) folgender Angaben zur Legitimation des Kunden:

  • Bei natürlichen Personen:
    • Art, Nummer und ausstellende Behörde des zur Überprüfung der Identität vorgelegten Dokuments[2]
  • Bei juristischen Personen oder Personengesellschaften:
    • Registernummer (falls vorhanden)[3]

III. Legitimationsdaten von natürlichen Personen

Die vorstehend genannten Legitimationsdaten werden grundsätzlich edv-technisch erfasst und gespeichert. Folgende Felder stehen in den genutzten Bankverfahren[4] zur Verfügung:

  • Art des Ausweises
  • Freitextfeld zur erweiterten Beschreibung der Ausweisart
  • Ausweisnummer
  • Ausstellende Behörde
  • Ausstellungsdatum des Legitimationspapieres[5]
  • Ablaufdatum des Legitimationspapieres

Dabei verfügen die Systeme teilweise über unterstützende Systemkontrollen (z. B. Mussfelder oder Vorauswahllisten), die den Erfassungsprozess proaktiv unterstützen sollen. Dennoch sind diese Kontrollen nicht allumfassend und Fehler schleichen sich in die Daten ein. Nachstehend werden häufig vorgefundene Datenfehler beschrieben.

1. Die Ausweisart

Die häufigsten Ausweisarten sind der Personalausweis (international auch ID-Card genannt) sowie der (Reise-)Pass. Weiterhin finden auch Geburtsurkunden (bei Minderjährigen bis zum 16. Lebensjahr) oder als Ausweisersatz ausgestellte Aufenthaltstitel Verwendung. Für ausländische Kunden kommen auch Passersatzpapiere wie Reise-Ausweise für Ausländer, Flüchtlinge oder Staatenlose oder Papiere, die im Rahmen eines laufenden oder abgeschlossenen Asylverfahrens ausgestellt werden (Ankunftsnachweis, Aufenthaltsgestattung, Duldung als Ausweisersatz) als Identitätsnachweis in Betracht.

Folgende Fallstricke bestehen:

  • Personalausweise bzw. ID-Cards dürfen nur bei Inländern sowie Unionsbürgern als Identitätsnachweis verwendet werden.[6] Für andere Staatsangehörigkeiten ist standardmäßig nur der (Reise-)Pass als Identitätspapier zulässig.
  • Einige EU-Länder geben keine Personalausweise aus. Dazu gehören Großbritannien, Irland und Dänemark. Folglich kann bei diesen Kunden mit entsprechender Staatsangehörigkeit die Ausweisart auch nicht „Personalausweis“ sein.
  • Kunden, bei denen die Ausweisart ein Pass- oder Ausweisersatzdokument bzw. ein Dokument aus einem Asylverfahren ist, können nicht die Staatsangehörigkeit „Inländer / Deutsch“ haben.
  • Werden Ausweisarten mit unbestimmten Begriffen wie „Sonstiges“ oder „Ausländisches Dokument“ verwendet, ist zwingend im Freitextfeld eine weitergehende Erläuterung des Identitätspapieres erforderlich.
  • Sollten die Verfahren auch die Erfassung nicht gesetzlich zulässiger Ausweisdokumente (z. B. „Lebensbescheinigung“) ermöglichen, muss durch eine laufende Datenkontrolle die Verwendung dieser Ausweisart überwacht und ggf. unterbunden werden.

2. Die Ausweisnummer

Die Ausweisnummer – insbesondere von inländischen Personalausweisen und Reisepässen – bietet vielfältige Möglichkeiten für Plausibilisierungskontrollen, die durchaus auch geeignet sind, „gefakte“ Daten zu erkennen. Dies können erfundene Ausweisnummern oder aber auch Ausweisnummern sein, die aus gefälschten Identitätsdokumenten übernommen wurden. Dafür sind folgende Grundlagenkenntnisse zu Ausweisnummern erforderlich, um entsprechende Fehler in den Ausweisnummern aufzuspüren:

  • Inländische Ausweisnummern können in unterschiedlicher Ausprägung erfasst sein, 9-, 10- oder 11-stellig. Alle Ausprägungen sind erlaubt. Die 10. Stelle ist eine Prüfziffer, die 11. Stelle das „D“ für Deutschland.
  • Bei inländischen vorläufigen Pässen und Personalausweisen setzt sich die Ausweisnummer aus einem Buchstaben und 7 Ziffern zusammen.[7]
  • Die Prüfziffer an der 10. Stelle ist in Identitätsdokumenten immer nummerisch. Sie kann aus den anderen Zeichen der Ausweisnummer errechnet werden.[8] Diese Regel gilt auch für viele Ausweisnummern in ausländischen Identitätsdokumenten.
  • Eine Ausweisnummer ist in Kombination mit der Staatsangehörigkeit eines Kunden immer eindeutig und darf daher in den Kundendaten auch nur bei einem Kunden vorkommen.
  • Bei inländischen Identitätsdokumenten wurden seit November 2007 bei (Reise-)Pässen und bei Personalausweisen ab November 2010 alphanummerische Ausweisnummern verwendet. Vorher waren diese Ausweisnummern rein nummerisch. Ausweisnummern beginnen seit diesem Zeitpunkt bei Reisepässen mit einem „C“ und bei Personalausweisen mit einem „L“.
  • Die ersten 4 Zeichen in der Ausweisnummer enthalten eine Behördenkennziffer, die einen festen Bezug zur ausstellenden Behörde hat.
  • Einige Buchstaben dürfen nicht in inländischen Ausweisnummern enthalten sein. Dies sind alle Vokale sowie Buchstaben, die leicht mit Ziffern verwechselt werden können (z. B. „B“, „S“ oder „Q“).[9]
  • Leer- oder Sonderzeichen sind ebenfalls in deutschen Ausweisnummern nicht erlaubt.

Leider gibt es zu Behördenkennziffern keine offiziellen Aufstellungen oder Listen, die man zu einem Abgleich der Behördenkennziffer mit der ausstellenden Behörde heranziehen kann. Die im Internet frei zugänglichen Aufstellungen sind fehlerhaft und unvollständig. Will man entsprechende Datenkontrollen durchführen, muss man eine entsprechende Referenzliste aus dem eigenen Datenbestand erstellen.

3. Die ausstellende Behörde

Auf den ausgegebenen Identitätsdokumenten wird auch immer eine „ausstellende Behörde“ (engl. „Authority“) angegeben, die als ausgebende Behörde für die Ausstellung des Identitätsdokuments verantwortlich war. Diese Angabe muss zwingend aus dem vorgelegten Identitätspapier übernommen und ebenfalls aufgezeichnet werden. Für deutsche Staatsbürger sind die inländischen Einwohnerbehörden in Städten und Gemeinden sowie Botschaften und Konsulate im Ausland die ausgebenden Stellen.

Auch hier werden bei der Dateneingabe mitunter Fehler gemacht. Zum einen werden vielfach Abkürzungen verwendet, die zwar regional gebräuchlich sind (z. B. Stadt HH), aber nicht immer auch allgemeingültig verstanden werden. Weiterhin sind die Angaben auch in einigen Fällen unvollständig (z. B nur Angabe „Ordnungsamt“ ohne Ortsangabe oder „Botschaft Berlin“). Mit entsprechenden unvollständigen Angaben lässt sich natürlich nicht zweifelsfrei die ausstellende Behörde ermitteln, die für die Ausgabe des betreffenden Dokuments verantwortlich war.

4. Das Ausstellungs- und das Ablaufdatum

Diese Informationen sind zwar nicht gesetzlich zur Aufzeichnung vorgeschrieben, werden jedoch in den genutzten Verfahren abgefragt. Auch diese Informationen können genutzt werden, um die Daten der erfassten Kunden auf Richtigkeit zu überprüfen.

Aus beiden Daten kann eine Gültigkeitsdauer des Identitätsdokuments errechnet werden, die dann mit den gesetzlichen Rahmenbedingungen abgeglichen werden kann. Bei inländischen Identitätsdokumenten gelten folgende Laufzeiten:

  • Bei Personalausweisen und (Reise-)Pässen beträgt die Regellaufzeit 10 Jahre.[10] Dies ist auch international die Standard-Laufzeit von Identitätsdokumenten.
  • Kurze Laufzeiten von 6 Jahren kommen bei inländischen Personen vor, die noch nicht 24 Jahre alt sind.[11]
  • Vorläufige Personalausweise haben eine Gültigkeit von höchstens 3 Monaten und vorläufige (Reise-)Pässe von höchstens einem Jahr.[12]

Beispiel der Gültigkeitsdauer eines inländischen Identitätsdokuments (Personalausweis oder Pass) mit 10jähriger Gültigkeit:

  • Ausstellungsdatum ist der 29.03.2017
  • Ablaufdatum (gültig bis) ist der 28.03.2027

Bei einigen, ausländischen Dokumenten wäre im vorstehenden Beispiel auch der 29.03.2027 (= 10 Jahre + 1 Tag) ein gültiges Ablaufdatum.

IV. Registerdaten von juristischen Personen

Für juristische Personen stehen in den genutzten Bankverfahren folgende Felder zur Verfügung:

  • Registergericht
  • Registerart
  • Registernummer

Auch wenn die beiden erst genannten Informationen nicht ausdrücklich gesetzlich zur Aufzeichnung vorgeschrieben sind, sind sie dennoch für eine eindeutige Identifizierung der juristischen Person erforderlich. Seit einiger Zeit stehen für inländische Kunden die erforderlichen Registerinformationen online zur Verfügung.[13] Auch im Ausland gibt es mittlerweile einige Internetportale, über die Registerinformationen abgerufen werden können.

Ähnlich wie bei der Ausweisnummer muss auch die Registernummer in Kombination mit Registergericht und Registerart eindeutig sein und darf im Datenbestand nur einmal vorkommen.

Weiterhin ist auch die korrekte Zuordnung zu einer Registerart anhand der Rechtsform der juristischen Person prüfbar. Folgende Zuordnungen gelten[14]:

Handelsregister Abteilung A (HRA):

Eingetragener Kaufmann/-frau (e.K.), Offene Handelsgesellschaft (OHG), Kommanditgesellschaft (KG), Europäische wirtschaftliche Interessenvereinigung (EWIV)

Handelsregister Abteilung B (HRB):

Aktiengesellschaft (AG), Kommanditgesellschaft auf Aktien (KGaA), Gesellschaft mit beschränkter Haftung (GmbH, auch UG und Ltd.), Versicherungsverein auf Gegenseitigkeit (VVaG)

Für die Rechtsformen eingetragene Genossenschaft, eingetragener Verein sowie Partnerschaften gibt es jeweils eine eigene Registerart.

V. Fazit

Durch eine Verprobung und Verplausibilisierung von Kundendaten anhand der in Teil 1 und 2 dieses Artikels dargestellten Möglichkeiten lässt sich ein Zugewinn an Sicherheit in den genutzten Daten realisieren. Dies führt zu positiven Effekten wie

  • Einhaltung des IT-Sicherheitszieles „Integrität“
  • Einhaltung geldwäscherechtlicher Anforderungen
  • Weniger Angriffsfläche bei entsprechenden, bankaufsichtlichen Prüfungen

PRAXISTIPPS

  • Untersuchen Sie in Ihrem Kundenbestand Ausweisart in Kombination mit der Staatsangehörigkeit eines Kunden auf:
  • Vorkommen von Personalausweisen und ID-Cards von Nicht-EU-Bürgern
  • Vorkommen von Personalausweisen und ID-Cards von Kunden aus EU-Staaten, die keine entsprechenden Dokumente ausgeben
  • Vorkommen von Pass- und Ausweis-Ersatzdokumenten (z. B. Aufenthaltstitel) oder Dokumenten aus einem Asylverfahren bei inländischen Kunden
  • Werden unbestimmbare Ausweisarten weitergehend erläutert?
  • Rechnen Sie die Prüfziffer der erfassten Ausweisnummer nach (teilweise wird dies bereits vom eingesetzt Bankverfahren automatisch bei der Datenerfassung vorgenommen).
  • Untersuchen Sie, ob eine Ausweisnummer in Kombination mit der Staatsangehörigkeit eines Kunden im Datenbestand einmalig ist, also nur einmal vorkommt.
  • Prüfen Sie inländische Ausweisnummern auf unzulässige Zeichen (z. B. Vokale oder Sonderzeichen).
  • Prüfen Sie die Länge bzw. die Anzahl der Zeichen in einer Ausweisnummer.
  • Suchen Sie in den Ausweisnummern nach Füllzeichenfolgen wie beispielsweise „123456“ oder „888888“.
  • Untersuchen Sie die Feldinhalte in der „ausstellenden Behörde“ nach Abkürzungen.
  • Suchen Sie nach fehlenden Ortsbezeichnungen in der „ausstellenden Behörde“.[15]
  • Gleichen Sie bei inländischen Kunden die Behördenkennziffer in der Ausweisnummer mit der ausstellenden Behörde ab.
  • Errechnen Sie anhand von Ausstellungs- und Ablaufdatum eine Gültigkeitsdauer und gleichen sie diese mit den gesetzlichen Vorgaben (siehe vorstehend) ab.
  • Prüfen Sie in Ihrem Kundendatenbestand, ob es registerpflichtige Unternehmen gibt, bei denen Registerdaten fehlen oder registerfreie Rechtsformen vorhanden sind, die Einträge in den Registerfeldern aufweisen.
  • Prüfen Sie anhand der Registerdaten, ob die Registernummer in Verbindung mit dem Registergericht sowie der Registerart einmalig ist.
  • Prüfen Sie anhand der Rechtsform einer juristischen Person, ob die Registerart zutreffend ist.
  1. Siehe http://www.consilium.europa.eu/prado/de/prado-start-page.html
  2. § 8 Abs. 2 i.V.m. § 12 Abs. 1 S. 1 Nr. 1 GwG
  3. Anmerkung des Verfassers: Eine Registernummer allein ist nicht eindeutig. Ergänzend müssen dazu auch das Registergericht und die Registerart (Handelsregister, Vereinsregister, etc.) für einen eindeutigen Nachweis benannt werden.
  4. Hier speziell agree21 und bank21. In anderen Verfahren wird von ähnlichen Strukturen ausgegangen.
  5. Die Erfassung eines Ausstellungsdatums und eines Ablaufdatums sind nicht gesetzlich vorgeschrieben.
  6. § 2 Abs. 5 Freizügigkeitsgesetz
  7. Siehe § 2 Abs. 8 Personalausweisgesetz bzw. § 4 Abs. 2 Nr. 5 Paßgesetz
  8. Der Algorithmus ist im Internet veröffentlicht, z. B. bei Wikipedia.
  9. Weitergehende Informationen findet man auf der Homepage des Bundesinnenministers über die Suche nach „alphanummerische Seriennummer in deutschen Pässen und Ausweisen“.
  10. Siehe § 6 Abs. 1 PAuswG bzw. § 5 Abs. 1 PaßG
  11. Siehe § 6 Abs. 3 PAuswG bzw. § 5 Abs. 1 PaßG
  12. Siehe § 6 Abs. 4 PAuswG bzw. § 5 Abs. 3 PaßG
  13. Siehe www.handelsregister.de
  14. Siehe § 3 Handelsregisterverordnung
  15. Einige ausländische Authorities verwenden keine geografischen Angaben.

Beitragsnummer: 39037