Financiële diensten
Transactiebeoordeling, AML-screening en escalatieketens delen allemaal dezelfde vereiste: niet alleen dat een beslissing juist was, maar dat deze achteraf onafhankelijk kan worden gereconstrueerd, zonder te vertrouwen op de eigen logboeken van de instelling. Op deze pagina wordt uiteengezet hoe een dergelijke workflow zou worden gepland en uitgevoerd in TheEU Assist, geen verslag van een voltooide implementatie.
Hoe de workflow zou worden gestructureerd
Een voorgestelde actie die uit meerdere stappen bestaat, een transactiebeoordeling, een gemarkeerd patroon, een escalatie, zou worden gepland als een reeks fasen. De volledige reeks wordt gehasht voordat deze wordt uitgevoerd, zodat het plan dat een goedkeurder beoordeelt, precies het plan is dat wordt uitgevoerd. Er is geen kloof tussen wat aan een mens werd getoond en wat het systeem feitelijk deed.
Fasen die als risicodragend zijn gemarkeerd (een escalatie, een klantgerichte output, een definitieve beslissing) zouden een onafhankelijke, tweede goedkeuring met zich meebrengen, los van de initiële aftekening op planniveau. Een algemene goedkeuring voor de workflow vervangt niet een specifieke goedkeuring op het punt dat er werkelijk toe doet.
Waar menselijke goedkeuring zit
Voor elke fase die van invloed kan zijn op een klant, een transactie of een registratie bij de toezichthouders is een expliciete ondertekende goedkeuring vereist voordat verder kan worden gegaan. Compliance- en kwantitatieve teams blijven de autoriteit op het gebied van wat een risicosignaal inhoudt. De rol van het platform is ervoor te zorgen dat zodra zij een besluit nemen, het besluit en de basis ervan aantoonbaar zijn en niet alleen maar worden vastgelegd.
Waar dit vandaag de dag op gebaseerd is, en waar niet
De goedkeuringsstructuur op twee niveaus, de hashing op planniveau en het ondertekende, offline verifieerbare audittraject achter elke uitvoeringsstap zijn werkende onderdelen van het platform. Wat hier geen deel van uitmaakt: een vooraf gebouwd AML- of fraudedetectiemodel. De eigen compliance- en kwantitatieve teams van de instelling zouden de logica leveren die een risicosignaal definieert; het platform levert de beheerde uitvoerings- en auditlaag daaronder.
Een deel van de architectuur die ten grondslag ligt aan deze capaciteitenset is gedocumenteerd in documenten die nog in behandeling zijn. Deze pagina beschrijft waarvoor het platform is ontworpen, op een niveau dat geschikt is voor het plannen van een pilot, en niet voor een implementatiespecificatie.
-platform kunnen voortdurend worden verbeterd. Beschrijvingen in deze handleiding geven mogelijk niet de exacte lay-out of formulering van de laatst uitgebrachte versie weer.