RBAC Det är här som gatewayen börjar betala sig. I en bankplattform med flera kunder kan åtkomsten inte vara omfattande bara för att handläggaren är “intern”. Varje kund behöver sin egen behörighetsmatris. En handlare som endast använder betalningsinitiering bör inte få tillgång till KYC-verktyg. En supportmedarbetare i en region bör inte kunna se kortkontroller för en annan region. Ett arbetsflöde som endast kräver en saldobeskrift bör inte få tillgång till överföringsförberedelser.
Schema-validering är nästa filter. Gatewayen bör kontrollera att varje förfrågan överensstämmer med godkända OpenAPI-specifikationer eller motsvarande avtal. På så sätt upptäcks felaktiga datapaket: felaktigt valutaformat, saknat mottagar-ID, betalningssätt som inte stöds, omöjligt datumintervall, felaktigt utformad KYC-statusförfrågan. Modellen kan vara välformulerad och ändå generera ett datapaket som systemet bör avvisa.
Godkännandeprocesser är där modellen utan förvaring konkretiseras. Agenten kan förbereda en åtgärd, men högriskoperationer kräver en kö, till exempel beloppsgränser, nya mottagare, misstänkt kontostatus, ofullständig KYC, förhöjda bedrägerisignaler eller hyresgästspecifika riktlinjer. Gatewayen bör skapa godkännandeposten, meddela den som ska godkänna, övervaka tidsgränsregler och återkoppla en tydlig status till användaren eller operatören.
Revisionsloggning måste byggas in i flödet. För varje begäran bör gatewayen skriva en post som endast kan kompletteras. Denna post bör innehålla hyresgäst, användare, kanal, arbetsflödesstatus, verktyg, parametrar efter redigering, valideringsresultat, godkännandestatus, nedströms svar och korrelations-ID. Efterlevnadsteamen behöver inte en vacker utskrift. De behöver en tydlig spårbarhet som förklarar varför systemet tillät eller blockerade åtgärden.
En distinktion som är värd att klargöra redan från början: loggen visar vad som utfördes, inte vem som hade behörighet att genomföra det. En logg kan tydligt visa att en överföring skedde från A till B under ett visst token. Den kan inte i sig visa att åtgärden godkändes av en huvudman som båda parter erkänner, eller att godkännandet inte redan hade återkallats. I ett flöde med en enda klient är denna lucka osynlig, eftersom loggen och behörighetsuppgifterna finns på samma ställe. I det ögonblick en tvist berör en klient eller en motpart blir just denna lucka hela problemet. Därför bör uppgifterna redovisa behörigheten: vilket mandat som godkände transaktionen, inom vilken räckvidd och om det fortfarande var giltigt vid det tillfället. Jag utvecklar denna punkt i min artikel Ett mandat är inte detsamma som styrning.
Strömavbrytare Det är ett problem eftersom bankleverantörer drabbas av tråkiga problem som tidsgränser, partiella avbrott, långsamma svar, inaktuell status och begränsningar av antalet förfrågningar. Gatewayen bör upptäcka detta mönster, göra ett nytt försök med backoff när det är säkert att försöka igen, avbryta upprepade anrop när det inte är det och erbjuda användaren ett användbart alternativ. “AML-leverantören är inte tillgänglig, försök igen senare” är bättre än att låta agenten gå i en loop, hitta på en status eller fortsätta att överbelasta en tjänst med försämrad prestanda.
Tokenets tillämpningsområde begränsar påverkningsområdet. Ett verktygsanrop bör beviljas den minsta behörighet som krävs för just den specifika begäran, den specifika kunden, den specifika användaren och det specifika arbetsflödesstatusen. Kortvariga, begränsade token är betydligt säkrare än långvariga tjänsteautentiseringsuppgifter som cirkulerar i agentlagret. Om något går fel bör den misslyckade begäran ha en begränsad påverkan.
Anlita oss
Om oss