Software-Tests für Vermögensverwaltung: Der vollständige Leitfaden

Ein einziger übersehener Fehler in einer Formel zur Portfoliobewertung kann zu einer echten finanziellen Falschdarstellung werden, die in einem Kundenauszug, einem Prüfbericht oder einer Anfrage der Aufsichtsbehörde auftaucht. Ein Datenleck auf einer Plattform für Vermögensverwaltung kann noch mehr anrichten: Es kann den Ruf eines Unternehmens innerhalb eines einzigen Nachrichtenzyklus ruinieren. Software-Tests für Vermögensverwaltung sind kein Bereich, in dem „ausreichendes“ QA akzeptabel ist, und wer sie wie ein normales Web- oder Mobile-Testprojekt behandelt, sorgt genau dafür, dass solche Fehler überhaupt erst in die Produktion gelangen.

Software-Tests für Vermögensverwaltung prüfen drei Dinge gleichzeitig: dass Portfolio-, Performance- und Gebührenberechnungen centgenau stimmen, dass die Plattform Finanzvorschriften wie DORA, MiCA und die AML/KYC-Anforderungen erfüllt und dass die Finanzdaten der Kunden einem echten Angriff standhalten. Fehlt einer der drei Bereiche, ist die Plattform angreifbar, ganz gleich, wie solide die anderen beiden sind.

Dieser Leitfaden zeigt, was Software-Tests für Vermögensverwaltung vom Standard-QA unterscheidet: finanzielle Genauigkeit, regulatorische Compliance und die Sicherheit der Kundendaten, dazu die praktischen Herausforderungen bei Integration und Teamkoordination, die selten in einem Anforderungsdokument stehen.

Wenn Sie die Qualität einer Plattform für Vermögensverwaltung verantworten, lautet die eigentliche Frage nicht, ob Sie diese drei Bereiche testen, sondern ob Ihr aktueller Prozess alle drei wirklich in der Tiefe abdeckt, die jeder einzelne braucht, oder ob er sich vor allem auf den Bereich stützt, den Ihr Team ohnehin am besten kennt (meist funktionales QA), während Compliance und Sicherheit nur oberflächlich geprüft werden. Genau in diesem Ungleichgewicht stecken die teuren Fehler.

Tests der finanziellen Genauigkeit

Portfoliobewertung, Performanceberechnung und Gebührenberechnung sind die drei Stellen, an denen Präzision am meisten zählt, und Präzision ist ein anderer Maßstab als funktionale Korrektheit. Eine Funktion kann „funktionieren“ (die Seite lädt, die Zahl wird angezeigt) und trotzdem in der dritten Nachkommastelle falsch sein, und in der Vermögensverwaltung ist ein Fehler in der dritten Nachkommastelle ein Fehler, den der Kunde sieht.

Tests der Portfoliobewertung prüfen, ob der Nettoinventarwert (NAV) aktuelle Marktpreise, Kapitalmaßnahmen (Aktiensplits, Wiederanlage von Dividenden, Fusionen) und Währungsumrechnungen korrekt abbildet, auch genau an dem Tag, an dem eine Maßnahme wirksam wird. Tests der Performanceberechnung prüfen zeitgewichtete und geldgewichtete Renditen gegen einen von Hand berechneten Referenzwert, nicht nur gegen frühere Ergebnisse der Plattform selbst. Tests der Gebührenberechnung decken gestaffelte Gebührenmodelle, anteilige Gebühren bei Kontoänderungen mitten im Abrechnungszeitraum und das Zusammenspiel mehrerer Gebührenarten auf demselben Konto ab.

Die Testmethode, die solche Probleme tatsächlich findet, sind Regressionstests mit Referenzwerten (Golden Values): Man legt eine kleine Menge von Konten mit manuell verifizierten, korrekten Sollwerten an und lässt jede Änderung an einer Berechnung vor dem Release gegen diese Menge laufen. Das Wiedereinspielen historischer Daten, also das erneute Durchlaufen echter (anonymisierter) historischer Marktdaten durch die Berechnungs-Engine, findet Grenzfälle wie Schaltjahre, Konten mit Nullsaldo und negative Barbestände, die ein synthetischer Testdatensatz meist übersieht.

Währungsumrechnung und Rundung verdienen eigene Testfälle statt einer einzigen Prüfung nach dem Motto „die Rechnung stimmt“. Ein Mehrwährungskonto, das am falschen Tag zum falschen Kurs umrechnet oder bei jeder einzelnen Transaktion eine Gebühr ab- statt aufrundet, erzeugt einen Fehler, der bei einer Stichprobe zu klein ist, um aufzufallen, und über einen vollständigen Abrechnungszyklus groß genug, um ins Gewicht zu fallen. Die Lösung ist eine Testsuite, die gezielt kleine, systematische Fehler aufdeckt, und nicht mehr manuelle Kontrolle.

Tests der regulatorischen Compliance

Tests der regulatorischen Compliance umfassen zwei Kategorien: Funktionen, die eigens zur Erfüllung einer Vorschrift existieren, und den Prüfpfad, der belegt, dass die Plattform ihre eigenen Regeln eingehalten hat.

AML/KYC-Prüffunktionen (Abläufe zur Identitätsprüfung, Abgleich mit Sanktionslisten und Schwellenwerte der Transaktionsüberwachung) brauchen eigene Testszenarien, die auf echten regulatorischen Auslösern aufbauen, statt nur einen Durchlauf allgemeiner Funktionstests. Eine Überwachungsregel, die im Test nie auslöst, weil keine Testtransaktion dafür gebaut wurde, ist eine Regel, die niemand wirklich überprüft hat.

Die Anforderungen an den Prüfpfad lassen sich ebenso testen. Jede Berechnung, jeder Zugriff auf Kundendaten und jede Anlageempfehlung muss protokolliert, mit Zeitstempel versehen und so unveränderlich sein, dass sie einer echten Prüfung standhält. Das bedeutet zu testen, was passiert, wenn jemand versucht, einen Protokolleintrag zu ändern oder zu löschen, und nicht nur zu bestätigen, dass unter normalen Bedingungen Protokolle geschrieben werden.

An dieser Stelle lohnt es sich, direkt auf die Compliance-Inhalte zu verweisen, die QAwerk bereits veröffentlicht hat, statt ein allgemeines „wir testen sorgfältig“ zu behaupten: Unser Leitfaden zu den Compliance-Anforderungen der DORA behandelt die Pflichten zum IKT-Risikomanagement und zur Meldung von Vorfällen, die zunehmend für Plattformen der Vermögensverwaltung in der EU gelten, unsere DORA-Compliance-Checkliste macht aus diesen Pflichten eine prüfungsfertige Checkliste, und für Plattformen, die auch mit digitalen Vermögenswerten arbeiten, deckt unsere MiCA-Compliance-Checkliste den parallelen Rahmen für Kryptowerte ab. Die meisten Beiträge über Tests in der Vermögensverwaltung erwähnen „regulatorische Compliance“, ohne diese Art von veröffentlichter Tiefe dahinter.

Hier kommt Compliance-Arbeit beim Testen von FinTech-Software unter Termindruck auch am häufigsten zu kurz: Compliance-Szenarien brauchen länger als funktionale Testfälle, weil sie jemanden erfordern, der neben der Funktion auch die Vorschrift wirklich versteht. Ein Testszenario für eine Regel zum Sanktionslistenabgleich muss wissen, wie ein echter Beinahe-Treffer aussieht, nicht nur, ob der Abgleich ein Ergebnis liefert. Wer Compliance-Tests als abzuhakende Liste behandelt statt als regulatorische Pflichten, die tatsächlich zu verifizieren sind, besteht zwar das interne QA, fällt aber bei einer externen Prüfung durch.

Datensicherheit und Penetrationstests

Die Finanzdaten der Kunden (Kontonummern, Salden, Transaktionshistorie, Ausweisdokumente) sind ein besonders wertvolles Ziel, gerade weil sie sich direkt zu Geld machen lassen. Das macht Plattformen für Vermögensverwaltung zu einem attraktiveren Ziel als ein durchschnittliches SaaS-Produkt mit dem gleichen Traffic.

Wirksames Testen geht hier über einen allgemeinen Schwachstellenscan hinaus. Es bedeutet Penetrationstests, die gezielt auf die tatsächliche Angriffsfläche der Plattform zugeschnitten sind: die Authentifizierung im Kundenportal (einschließlich Sitzungsverwaltung und Versuchen, die Multi-Faktor-Authentifizierung zu umgehen), die API-Endpunkte, die die Kunden-App versorgen, und die Integrationen von Drittanbietern (Feeds von Verwahrstellen, Marktdatenanbieter, CRM-Anbindungen), an deren Test die meisten Teams nicht denken, weil sie sie nicht selbst gebaut haben. Die Validierung der Verschlüsselung, also die Bestätigung, dass Daten im Ruhezustand und bei der Übertragung tatsächlich verschlüsselt sind und nicht nur ein Richtliniendokument dies vorsieht, rundet den Kern eines echten Sicherheitstests ab.

Die Sitzungsverwaltung verdient auf einer Plattform für Vermögensverwaltung eine besondere Aufmerksamkeit, die sie in einer App mit geringerem Risiko nicht bräuchte: Eine Sitzung, die nach einer Passwortänderung zu lange gültig bleibt, oder ein Multi-Faktor-Schritt, der sich durch das erneute Senden einer alten Anfrage überspringen lässt, ist ein kleiner Fehler mit übergroßen Folgen, wenn hinter dem Konto echtes Vermögen steht. Testen Sie diese Pfade so, wie ein Angreifer es tun würde, und nicht nur entlang des idealen Nutzerflusses.

Wann internes QA ausreicht und wann nicht

Nicht jede Phase der Software-Tests für Vermögensverwaltung braucht einen externen Partner. Ein Team mit tiefem Produktwissen und einer stabilen Berechnungs-Engine kann die Tests der finanziellen Genauigkeit oft gut selbst übernehmen. In diesem Fall zählt die Vertrautheit mit dem Produkt mehr als spezialisierte Werkzeuge.

Bei Tests der regulatorischen Compliance und bei Penetrationstests zahlt sich externe Expertise meist aus. Die Pflichten aus DORA und MiCA ändern sich schneller, als die meisten internen Teams neben einer vollen Produkt-Roadmap verfolgen können, und wirksame Penetrationstests profitieren von Testern, die die blinden Flecken des Systems noch nicht kennen, denn gerade die Vertrautheit sorgt dafür, dass eine echte Schwachstelle unbemerkt bleibt. Die ehrliche Antwort für die meisten Plattformen für Vermögensverwaltung im Mittelstand ist eine Mischung: Die Genauigkeitstests bleiben nah am Produktteam, spezialisierte Compliance- und Sicherheitstests kommen in einem regelmäßigen Rhythmus hinzu statt als einmalige Prüfung vor dem Launch.

Praktische Herausforderungen: Multi-Stack-Integration und globale Teams

Zwei der häufigsten Herausforderungen beim Testen von Finanzsoftware in diesem Bereich stehen selten in einem Anforderungsdokument, weil sie damit zu tun haben, wie die Plattform gebaut und personell besetzt ist, und nicht damit, was sie leisten soll.

Die erste ist die Multi-Stack-Integration. Plattformen für Vermögensverwaltung sind selten sauber aufgebaut: Die meisten kombinieren eine moderne Kunden-App mit einem älteren Kern für die Portfoliobuchhaltung sowie mehreren Datenfeeds von Drittanbietern für Salden der Verwahrstellen, Marktpreise und CRM-Daten. Jede Integrationsstelle braucht einen eigenen Contract-Test, denn eine Änderung an beliebiger Stelle dieser Kette (eine API einer Verwahrstelle, die ihr Antwortformat ändert, ein Marktdatenfeed, der einen Feldnamen umbenennt) kann eine nachgelagerte Berechnung ohne erkennbare Ursache zum Scheitern bringen. Wer die Plattform als Ganzes testet und die Tests auf Ebene der Integrationsstellen auslässt, lässt genau diese Brüche in die Produktion durch.

Die zweite ist die Koordination über Zeitzonen hinweg. Ein Entwicklungsteam in einer Zeitzone, ein Testteam in einer anderen und Compliance-Prüfer in einer dritten ist bei solchen Projekten eine übliche Konstellation, und ohne bewusste Überschneidung der Arbeitszeiten und einen zentralen Ansprechpartner entstehen echte Lücken bei der Übergabe: Ein Fehler, der am Ende des Arbeitstags eines Teams gefunden wird, bleibt stundenlang liegen, bevor das nächste Team ihn überhaupt sieht, und eine Compliance-Frage aus der Prüfung kann einen ganzen Tag auf eine Antwort warten. Das ist ein echtes Argument für einen Testpartner, der mit dem Kunden als ein Team arbeitet, mit überlappenden Arbeitszeiten und einem zentralen Ansprechpartner, statt als isolierter Dienstleister, der Ergebnisse über eine Zeitzonengrenze hinweg übergibt.

Beide Herausforderungen verstärken sich gegenseitig. Eine Plattform mit fünf Integrationsstellen und einem Testteam, das über drei Zeitzonen verteilt ist, hat ein Problem, das schwerer zu diagnostizieren ist als jede Herausforderung für sich, denn ein Fehler, der wie ein Integrationsfehler aussieht, kann in Wahrheit ein Koordinationsfehler sein: Die Korrektur gibt es bereits, sie hat nur die richtige Person noch nicht erreicht.

Finanzielle Genauigkeit, regulatorische Compliance und Datensicherheit im Überblick

Infografik mit drei Säulen: Tests der finanziellen Genauigkeit, der regulatorischen Compliance und der Datensicherheit als parallele Bestehensbedingungen, jeweils mit den realen Folgen, wenn sie ausgelassen werden.

Häufige Fragen

Software-Tests für Vermögensverwaltung gelingen, wenn finanzielle Genauigkeit, regulatorische Compliance und Datensicherheit als gleich wichtig behandelt werden und nicht als nachträgliche Schritte, die kurz vor dem Launch angehängt werden. Eine Plattform, die die Portfolioberechnungen perfekt beherrscht, aber eine DORA-Prüfung nicht besteht, ist nicht bereit. Eine Plattform, die die Compliance besteht, aber über einen schwachen API-Endpunkt Kundendaten preisgibt, ebenso wenig.

QAwerk bringt echte, veröffentlichte Tiefe in regulatorischer Compliance (DORA, MiCA) zusammen mit spezialisierten Penetrationstests mit, also die Art von Branchenkompetenz, die intern schwerer aufzubauen ist, als es scheint. Wir haben noch nicht mit einem Kunden aus der Vermögensverwaltung gearbeitet, den wir öffentlich nennen können, und sagen das lieber offen, als etwas anderes anzudeuten. Worauf wir verweisen können: mehr als 11 Jahre Erfahrung im Testen von Finanz- und regulierter Software, eine Bibliothek an Compliance-Inhalten, die die meisten Wettbewerber in diesem Bereich nicht haben, und ein Team, das Termintreue als Liefergegenstand behandelt.

Wenn Sie eine Plattform für Vermögensverwaltung durch ein Testprojekt bringen, sprechen Sie mit uns darüber, wie unsere DORA-Compliance-Beratung in Ihren QA-Plan passt.

Sehen Sie, wie wir die Onboarding-Abläufe für eine Krypto-Asset-Management-Plattform optimiert und die Nutzerabwanderung um 15 % reduziert haben

Bitte geben Sie Ihre Geschäfts-E-Mail ein ist keine Geschäfts-E-Mail

Holen Sie sich die Fallstudie