RBAC is het moment waarop de gateway zichzelf begint terug te verdienen. In een multi-tenant bankplatform kan de toegang niet onbeperkt zijn, alleen maar omdat de medewerker “intern” is. Elke tenant heeft zijn eigen machtigingsmatrix nodig. Een handelaar die alleen gebruikmaakt van betalingsinitiatie, zou geen KYC-tools moeten krijgen. Een supportmedewerker in de ene regio zou geen kaartcontroles voor een andere regio moeten kunnen zien. Een workflow die alleen een saldo-uitleg nodig heeft, zou geen voorbereiding voor overschrijvingen moeten krijgen.
Schema-validatie is het volgende filter. De gateway moet elk verzoek toetsen aan goedgekeurde OpenAPI-specificaties of gelijkwaardige contracten. Zo worden ongeldige payloads opgespoord: een verkeerde valuta-indeling, een ontbrekend begunstigde-ID, een niet-ondersteund betalingskanaal, een onmogelijke datumrange of een onjuist opgesteld KYC-statusverzoek. Het model kan weliswaar correct zijn opgesteld, maar toch een payload opleveren die het systeem moet afwijzen.
Goedkeuringsprocessen zijn de punten waarop het model zonder beheer concreet vorm krijgt. De agent kan een actie voorbereiden, maar voor risicovolle transacties is een wachtrij nodig, bijvoorbeeld vanwege drempelwaarden voor bedragen, nieuwe begunstigden, verdachte rekeningstatus, onvolledige KYC, verhoogde fraudesignalen of huurderspecifieke beleidsregels. De gateway moet het goedkeuringsitem aanmaken, de goedkeurder op de hoogte stellen, time-outregels bijhouden en een duidelijke status terugkoppelen aan de gebruiker of operator.
Auditlogboekregistratie moet in het traject worden ingebouwd. Voor elk verzoek moet de gateway een record schrijven dat alleen kan worden aangevuld. Dit record moet de volgende gegevens bevatten: tenant, gebruiker, kanaal, workflowstatus, tool, parameters na redigering, validatieresultaat, goedkeuringsstatus, downstream-reactie en correlatie-ID. Compliance-teams hebben geen behoefte aan een fraai transcript. Ze hebben behoefte aan een duidelijk spoor dat uitlegt waarom het systeem de actie heeft toegestaan of geblokkeerd.
Een onderscheid dat het de moeite waard is om vanaf het begin te maken: het logboek bewijst wat er is uitgevoerd, niet wie bevoegd was om dit te laten gebeuren. Een trace kan perfect aantonen dat een overdracht onder een bepaald token van A naar B is gegaan. Het kan op zichzelf niet aantonen dat de handeling is geautoriseerd door een opdrachtgever die beide partijen erkennen, of dat de autorisatie niet al was ingetrokken. In een single-tenant-omgeving is die kloof onzichtbaar, omdat het logboek en de autorisatiegegevens op dezelfde plek staan. Zodra er een geschil ontstaat tussen een tenant of een tegenpartij, vormt die kloof het hele probleem. Het record moet dus de bevoegdheid vastleggen: welk mandaat gaf toestemming voor de aanroep, binnen welke reikwijdte, en of het op dat moment nog geldig was. Ik ga hier dieper op in in mijn artikel Een mandaat is geen bestuur.
Stroomonderbrekers Dit is een probleem omdat bankdienstverleners op saaie manieren falen, zoals time-outs, gedeeltelijke storingen, trage reacties, verouderde statussen en tariefbeperkingen. De gateway moet dat patroon herkennen, het opnieuw proberen met een backoff-tijd wanneer dat veilig is, herhaalde verzoeken stoppen wanneer dat niet het geval is, en de gebruiker een bruikbaar alternatief bieden. “AML-provider niet beschikbaar, probeer het later nog eens” is beter dan de agent in een lus te laten zitten, een status te verzinnen of een slecht presterende dienst te blijven bestoken.
Toepassingsgebied van tokens beperkt de omvang van de schade. Een aanroep van een tool moet slechts de minimale toegang krijgen die nodig is voor dat specifieke verzoek, die specifieke tenant, die specifieke gebruiker en die specifieke workflowstatus. Tijdelijke tokens met een beperkt bereik zijn veel veiliger dan lang geldige inloggegevens voor services die rondzwerven in de agentlaag. Als er iets misgaat, moet het mislukte verzoek een beperkte impact hebben.
Inhuren
Over ons