Wie beauftrage ich eine Agentur für die Entwicklung einer sicheren Compliance-Plattform?

Überblick: Phasen, Anker, Artefakt, Verantwortlich

Zum Vergleichen wischen →

Hinweis zu den Anwendungsbereichen: 2023/1 Rz 20 nimmt Banken der Kategorien 4 und 5 unter anderem von Rz 51, 76, 77, 78 und 80 aus; Rz 21 nimmt Institute nach Art. 47a-47e ERV (Kapitaladäquanzverordnung), Personen nach Art. 1b BankG und Effektenhändler zusätzlich unter anderem von Rz 79 aus. Rz 50, 52, 53-54, 81, 82 und 85 gelten für alle Adressaten. Prüfen Sie Ihre Kategorie mit Compliance. Versionsstand: FINMA-Rundschreiben 2018/3 in der Fassung vom 1. Januar 2021; prüfen Sie auf finma.ch, ob spätere Änderungen vorliegen.

Schritt 1: Ist die Beauftragung einer Compliance-Plattform Outsourcing?

Outsourcing liegt nach FINMA-Rundschreiben 2018/3 Rz 3 vor, wenn ein Unternehmen einen Dienstleister beauftragt, "selbständig und dauernd eine für die Geschäftstätigkeit des Unternehmens wesentliche Funktion ganz oder teilweise zu erfüllen". Wesentlich ist eine Funktion nach Rz 4, wenn die Einhaltung der Finanzmarktvorschriften davon signifikant abhängt. Ob der Bau einer Plattform Outsourcing ist, beurteilt Ihr Institut selbst; eine Plattform, die Ihr Institut selbst betreibt, ist nicht automatisch Outsourcing (unsere Einordnung, keine FINMA-Aussage). Betreibt dagegen der Dienstleister die Plattform dauerhaft für Sie, ist die Prüfung naheliegend.

Zwei Grenzen gelten in beiden Fällen: "Nicht auslagerbar sind die Oberleitung, Aufsicht und Kontrolle durch das Oberleitungsorgan" (Rz 8; ebenfalls nicht auslagerbar sind dort unter anderem die Entscheide über die Aufnahme und den Abbruch von Geschäftsbeziehungen); "Operative Risikomanagement- und Compliance-Aufgaben sind bei allen Aufsichtskategorien auslagerbar" (Rz 9). Nach Rz 23 trägt Ihr Institut gegenüber der FINMA dieselbe Verantwortung, als würde es die Funktion selbst erbringen. Für die AML-Komponente einer Plattform gilt ein eigenes Kontrollkonzept; siehe KI-Agenten für AML und Transaktionsüberwachung.

Schritt 2: Welche Anforderungen und Risikoanalyse brauchen Sie vor dem Vertrag?

Die Anforderungen an den Dienstleister sind nach Rz 16 "vor Vertragsschluss festzulegen und zu dokumentieren", einschliesslich der Risikoanalyse. Das Rundschreiben 2023/1 verlangt in Rz 52, dass Anforderungen klar definiert und genehmigt sind und nach Kritikalität getestet und validiert werden; Rz 50 erfasst "alle Phasen" der Entwicklung oder Beschaffung von IKT.

Verarbeitet die Plattform Personendaten, ist nach nDSG Art. 22 Abs. 1 vorgängig eine Datenschutz-Folgenabschätzung (DSFA) zu erstellen, wenn die Bearbeitung ein hohes Risiko bringen kann; Abs. 2 nennt als Beispiel den Einsatz neuer Technologien. Abs. 4 und 5 sehen Ausnahmen nur für private Verantwortliche vor: wenn sie zur Bearbeitung gesetzlich verpflichtet sind (Abs. 4) oder wenn sie ein zertifiziertes System, Produkt oder eine zertifizierte Dienstleistung bzw. einen Verhaltenskodex nutzen (Abs. 5). Eine DSFA ist also nicht in jedem Fall nötig; dokumentieren Sie die Entscheidung. Stand der nDSG-Fassung: 1. September 2023, spätere Änderungen nicht geprüft.

Typische Anforderungen: Mandantentrennung, Protokollierung, Rollen und Rechte, Schnittstellen, Datenstandorte, Verfügbarkeit (RTO/RPO), Prüfbarkeit. Enthält die Plattform KI-Komponenten, prüfen Sie zusätzlich EU AI Act konforme KI-Agenten für Banken.

Schritt 3: Wie wählen Sie die richtige Agentur aus?

Nach Rz 17 wählt Ihr Institut den Dienstleister nach Fachkompetenz sowie finanziellen und personellen Mitteln. Das Rundschreiben 2023/1 Rz 82 verlangt eine "besonders sorgfältige" Prüfung, wenn Dienstleister mit kritischen Daten umgehen, und "klare Kriterien" vor Vertragsschluss. Nach nDSG Art. 9 Abs. 2 muss sich der Verantwortliche vergewissern, dass der Auftragsbearbeiter die Datensicherheit gewährleisten kann.

Welche Anbietertypen gibt es? Beratungshäuser, Professional-Services-Teams von Cloud-Anbietern, KI-native Boutiquen, Plattformanbieter und spezialisierte Fintech-Engineering-Firmen. Welcher Typ zu welcher Situation passt, steht in Anbietertypen im Vergleich. Diese Seite nennt kein Ranking. Für "wer bietet skalierbare Compliance-Software" gilt: Unterscheiden Sie zuerst zwischen Kauf eines Produkts und Bau mit einem Partner; die Abwägung steht in Custom or off-the-shelf compliance software for fintech (English).

Scorecard (illustratives Beispiel, Gewichte sind Annahmen, nicht Empfehlung)

Zum Vergleichen wischen →

Rechenbeispiel: Anbieter A erhält 4/5 bei Sicherheit (20 % × 4 = 0.8), 3/5 bei Exit (15 % × 3 = 0.45) und so weiter; die Summe aller gewichteten Punkte ergibt den Score. Passen Sie Kriterien und Gewichte an Ihre Risikoanalyse an und legen Sie sie vor dem Versand der RFP fest.

Schritt 4: Was gehört in die RFP?

Die RFP macht Ihre Anforderungen aus Schritt 2 überprüfbar. Sie enthält: Anforderungskatalog mit Muss- und Kann-Kriterien; die Fragen aus der Scorecard; die Liste aller geplanten Unterakkordanten (Rz 14 verlangt sie im Inventar; Rz 33 verlangt die frühe Information über Unterakkordanten, die wesentliche Funktionen erbringen); den gewünschten Umfang von Prüf- und Informationsrechten; Datenstandorte und Zugriffe aus dem Ausland; Muster-Klauseln zu Exit und SLA; den PoC-Plan. Verlangen Sie schriftliche Antworten pro Kriterium und Belege statt Absichtserklärungen.

Schritt 5: Wie führen Sie einen PoC ohne ungeschützte Kundendaten durch?

Legen Sie vor Beginn Abnahmekriterien und ein Testdatenkonzept fest. Nach 2023/1 Rz 51 sind Entwicklung und Test von der Produktion getrennt, und nach Rz 76 gilt der Schutz kritischer Daten auch in Testumgebungen. Beide Randnummern gelten für Banken der Kategorien 4 und 5 nicht (Rz 20). Praktisch: Arbeiten Sie im PoC mit synthetischen oder anonymisierten Daten, solange Schutz und Zugriffsmodell nicht abgenommen sind. Der PoC prüft Architektur, Integration und Prüfbarkeit, nicht nur eine Demo. Ein bestandener PoC ersetzt weder Risikoanalyse noch Vertrag.

Schritt 6: Was muss im Vertrag stehen?

Der Vertrag ist nach Rz 32 schriftlich oder in einer anderen Form abzuschliessen, die den Nachweis durch Text ermöglicht; Rz 34 verlangt Bestimmungen zu den Rz 21, 24, 26, 29, 30 und 31; Rz 35 verlangt einen internen Genehmigungsprozess. Im Einzelnen:

• Weisungs- und Kontrollrechte (Rz 21).
• Sicherheit und NotfallSicherheitsanforderungen und ein Sicherheitsdispositiv für Notfälle (Rz 24-25).
• Prüfrechte"jederzeitiges, vollumfängliches und ungehindertes Einsichts- und Prüfrecht" für Ihr Institut, die Prüfgesellschaft und die FINMA (Rz 26); die Prüfung kann an die Revisionsstelle des Dienstleisters delegiert werden, sofern diese über die notwendigen fachlichen Kompetenzen verfügt (Rz 27).
• Information der FINMAEin Dienstleister, der nicht von der FINMA beaufsichtigt wird, muss sich vertraglich verpflichten, der FINMA die für die Aufsicht benötigten Auskünfte und Unterlagen zum ausgelagerten Geschäftsbereich zur Verfügung zu stellen (Rz 29).
• Auslandnur, wenn Rechte durchsetzbar sind und Sanierbarkeit bzw. Abwickelbarkeit gewährleistet bleiben; die dafür notwendigen Informationen müssen in der Schweiz jederzeit zugänglich sein (Rz 30-31). Für Personendaten gilt zusätzlich nDSG Art. 16: Bekanntgabe ins Ausland, wenn der Bundesrat einen angemessenen Schutz festgestellt hat, sonst mit Garantien wie Datenschutzklauseln oder Standarddatenschutzklauseln. Das Rundschreiben 2023/1 behandelt Datenstandort und Auslandzugriff in Rz 79, von dem bestimmte Institute ausgenommen sind (Rz 21). Eine Pflicht, Daten in der Schweiz zu halten, enthält der Text nicht.
• Subunternehmer und ExitFrühe Information über Unterakkordanten, die wesentliche Funktionen erbringen, und die Möglichkeit eines geordneten Ausstiegs (Rz 33).
• AuftragsbearbeitungNach nDSG Art. 9 darf der Auftragsbearbeiter Bearbeitungen nur mit vorgängiger Genehmigung des Verantwortlichen einem Dritten übertragen (Abs. 3). Die Übertragung ist zudem nur zulässig, wenn keine gesetzliche oder vertragliche Geheimhaltungspflicht sie verbietet (Abs. 1 lit. b). Rz 33 (Information und Exit) und Art. 9 Abs. 3 (Genehmigung) sind verschiedene Prüfungen; ein Vertrag braucht in der Regel beides (unsere Einordnung).
• SLARTO und RPO werden mit Dienstleistern koordiniert und durch SLA, Verträge oder andere geeignete Verfahren geregelt (2023/1 Rz 85); Vorfälle, die kritische Daten erheblich beeinträchtigen, sind der FINMA unverzüglich zu melden (Rz 81).
• Weitere PunkteEigentum an Code und Dokumentation, Haftung und Vertraulichkeit mit Ihrer Rechtsabteilung klären.

Schritt 7: Wie regeln Sie den Exit?

Nach Rz 18 berücksichtigt Ihr Institut die Folgen eines Wechsels; nach Rz 18.1 muss "die geordnete Rückführung der ausgelagerten Funktion oder die Übertragung auf einen anderen Dienstleister" sichergestellt sein. Das gilt nicht für jedes Institut: Institute nach Art. 47a-47e ERV bzw. Art. 1b BankG entscheiden per Risikoanalyse über die Relevanz von Rz 17-18.1 und sind von Rz 18.1 ausgenommen (Rz 36.1-36.3). Unabhängig davon ist ein Exit-Konzept guter Vertragsbestandteil: Übergabe von Code, Dokumentation und Daten in nutzbarer Form, Übergangsunterstützung, Testlauf der Rückführung.

Schritt 8: Wie betreiben und überwachen Sie die Plattform?

Rz 20 verlangt ein internes Kontrollsystem, eine unternehmensintern definierte verantwortliche Stelle und laufende Überwachung des Dienstleisters. Halten Sie fest: Berichtsrhythmus, Kennzahlen aus dem SLA, Vorfall-Prozess, periodischer Prüfbericht, Änderungsmanagement nach 2023/1 Rz 50-52. Das Inventar nach Rz 14 und, für IKT-Werte, nach 2023/1 Rz 53-54 (inklusive Speicherorte kritischer Daten und Schnittstellen zu wesentlichen externen Dienstleistern) bleibt aktuell.

Welche Kosten treiben das Budget?

S-PRO nennt hier keine Preise. Aus den Anforderungen oben lassen sich die Kostentreiber ableiten (unsere Einordnung, keine Marktdaten): Umfang der Anforderungen, Risikoanalyse und DSFA, Unterstützung bei Prüfrechten, Trennung von Test und Produktion, SLA für RTO/RPO, Exit-Dokumentation, Betrieb und Wartung. Anbieter-Blogs nennen ähnliche Treiber wie Compliance-Anforderungen, Änderungen im Umfang, Lizenzen und Cloud; es sind Herstellerpublikationen. Eine belastbare Schätzung gibt es nur für einen definierten Umfang.

Wie unterstützt S-PRO Sie?

S-PRO ist ein internationales Schweizer Unternehmen mit Sitz in Zürich (Löwenstrasse 45, 8001 Zürich), gegründet 2014, mit 250+ Ingenieuren und R&D-Zentren in Zürich und Łódź; S-PRO ist nach ISO 27001 und ISO 27701 zertifiziert. S-PRO ist zertifizierter Partner im Claude Partner Network. S-PRO erhebt für Kunden keinen Anspruch auf aufsichtsrechtliche Genehmigung; die Verantwortung gegenüber der FINMA bleibt beim Institut. Mehr zur Entwicklung für Finanzinstitute: Fintech software development (English) und Security and compliance for financial institutions (English).

Planen Sie die Beauftragung einer Compliance-Plattform und möchten Anforderungen, RFP-Unterlagen oder Vertragspunkte mit einem Engineering-Partner durchgehen? Kostenloses Erstgespräch buchen (45 Min.)

Kontakt: S-PRO, Löwenstrasse 45, 8001 Zürich, +41 41 539 15 83.

Quellen (Zugriff am 26. Oktober 2026):

• FINMA-Rundschreiben 2018/3 "Outsourcing", Fassung vom 1. Januar 2021
• FINMA-Rundschreiben 2023/1 "Operational risks and resilience - banks"
• Bundesgesetz über den Datenschutz (nDSG), SR 235.1, Stand 7. Juli 2025

Zusammengestellt aus den genannten Primärtexten; Regeln ändern sich. Prüfen Sie vor Vertragsabschluss mit Ihrer Compliance- und Rechtsabteilung. S-PRO erbringt keine Rechts- oder Regulierungsberatung.