Så väljer du en AML-plattform utan att skaffa ytterligare en silos

Många AML-silos skapas inte av mjukvaran i sig. De uppstår tidigare, när ett företag behandlar en AML-plattform som compliance-avdelningens verktyg snarare än som en del av hur hela kundrelationen fungerar.

Mönstret är välbekant. Compliance identifierar ett krav — onboarding, screening, riskklassificering, löpande övervakning — utvärderar leverantörer och köper en lösning som kanske gör exakt det den ombeds göra. Ingen frågar nödvändigtvis hur den passar ihop med sälj, onboarding-operationer, kundservice eller information som redan finns på annat håll. Kravet uppfylls. Driftsmodellen förbättras inte nödvändigtvis.

Frågan de flesta företag ställer vid upphandling är: vilket AML-system behöver vi för att uppfylla detta krav? Den mer användbara frågan är: hur uppfyller vi våra regulatoriska skyldigheter och samtidigt förbättrar det övergripande kundflödet? De två frågorna leder till mycket olika inköp.

Mjukvaran följer organisationsstrukturen. Det gör inte kunderna.

En silo är inte bara ett system utan ett API. Det djupare problemet är organisatoriskt och föregår varje enskilt mjukvarusystem. Företag delar naturligt in sig i avdelningar — sälj, compliance, verksamhet, ekonomi, kundservice — var och en med sitt eget ledarskap, sina egna KPI:er och, så småningom, sina egna system. När ett företag växer hårdnar dessa uppdelningar, och upphandlingen börjar spegla organisationsstrukturen: compliance köper compliance-mjukvara, sälj köper ett CRM, verksamheten köper arbetsflödesverktyg. Varje inköp, bedömt för sig, är vanligtvis rationellt. Det sammanlagda resultatet är det ofta inte.

Företag köper mjukvara utifrån sin organisationsstruktur. Kunder upplever inte företaget utifrån dess organisationsstruktur. Kunden upplever ett enda företag; relationen bakom det kan vara uppdelad mellan fem avdelningar och fem system som knappt kommunicerar med varandra.

Ett system blir en silo när informationen eller arbetsflödet inuti det inte kan delta i den bredare relationen: synligt för compliance men inte för det kommersiella teamet, samma kund representerad på olika sätt på olika ställen, en förändring som fångas upp i en plattform men som inte utlöser något någon annanstans, information som matas in manuellt för att inget är sammankopplat. En silo håller inte bara information ute. Den hindrar värdefull information från att ta sig ut.

Informationen som fastnar i compliance kan vara viktig på annat håll

Löpande övervakning kan fånga upp att en kunds ägarstruktur har förändrats, att en styrelseledamot har bytts ut eller att kunden har omklassificerat sin registrerade verksamhet. Det har uppenbar compliance-relevans. Det kan också vara viktigt för relationsansvarig, som annars går in i nästa möte ovetande — i stället för att inleda med "Jag noterade att er ägarstruktur nyligen förändrades, vad innebär det för verksamheten?" Poängen är inte att compliance finns till för att generera säljleads; det är att information som samlats in för ett legitimt syfte kan ha ett bredare värde på andra håll, där delning är lämplig. Samma händelse kan vara en compliance-trigger och användbar kundinformation. En silo tvingar organisationen att behandla den som enbart det ena — en fråga om genomtänkt informationsarkitektur, inte ett argument för att sprida varje compliance-datapunkt till varje kommersiell användare.

Företag exponerar samma silos för kunderna: information som efterfrågas två gånger, en relationsansvarig som inte känner till något offentligt om sin egen kund, separata portaler för delar av det som borde vara en och samma process. Bra teknik förvandlar inte en dålig relationsansvarig till en utmärkt, men bättre information kan hjälpa en någorlunda duktig att komma väl förberedd. En välintegrerad plattform bör få organisationen att framstå som mer samordnad för kunden, inte avslöja ytterligare en intern avdelning. Kunder ska inte behöva hantera era interna silos åt er.

En plattform eller flera? Det beror på företaget

Det är frestande att rama in detta som allt-i-ett kontra best-of-breed. Den debatten är i stor utsträckning bredvid poängen: rätt arkitektur beror på företagets storlek, komplexitet och tillväxtfas, inte på en generell preferens för den ena modellen.

För ett mindre reglerat företag kan en plattform som hanterar stora delar av klientlivscykeln vara fullt rationell — och köparen är ofta av ett annat slag, inte bara en fråga om storlek. Inköparen kan vara grundaren, en ansvarig partner, VD:n eller en senior operativ ledare som ser på tekniken som en del av att driva verksamheten som helhet snarare än som ett avdelningsspecifikt compliance-beslut, ofta för att det inte finns någon separat compliance-avdelning som kan fatta det i stället. Den personen är också personligen medveten om att tid som läggs på onboarding, dokumentinsamling, KYC och granskningar är tid som inte läggs på att generera intäkter eller betjäna kunder — vilket kan göra ett mindre företag mer kapabelt att fatta ett enda, sammanhållet teknikbeslut än ett större. Att köpa sex leverantörer för sex snäva funktioner ger liten mening i den skalan; konsolidering är en fördel. Beroende på marknad och konfiguration kan IQON täcka en betydande del av den livscykeln direkt — onboarding, KYC/KYB, screening, riskklassificering och löpande övervakning, bland andra funktioner. Den exakta konfigurationen beror på marknad och kundens krav.

När företag växer tenderar upphandlingen att bli mer avdelningsbaserad — compliance köper för compliance, sälj köper för sälj, verksamheten köper för verksamheten — vilket är en av anledningarna till att silos uppstår från första början. För en större organisation är flera specialiserade system ofta oundvikliga och önskvärda. Den viktiga frågan är inte hur många system ett företag kör, utan om dessa system sammantaget bildar en driftsmodell eller en uppsättning isolerade avdelningsarbetsflöden. Faran är inte att köpa flera system. Faran är att köpa system som låser fast företaget i separata arbetsflöden — och det är här tillväxt behöver designas för i förväg. En kund kan börja använda IQON för större delen av klientlivscykeln och senare ta in ett specialiserat CRM, en dedikerad dokumentplattform eller egna analysverktyg i takt med att verksamheten växer. Det bör inte tvinga kunden att byta ut IQON bara för att man vuxit ur en enskild modul: en kund ska kunna växa ur enskilda funktioner utan att behöva växa ur plattformen som helhet. IQON är byggt modulärt med API-baserad integration, så information kan flöda in och ut när den omgivande tekniken utvecklas — utan att låtsas att varje integration är problemfri; vad en specifik integration kräver är en rimlig fråga att ställa till alla leverantörer.

Den bästa AML-demon börjar innan skärmdelningen

Det är ingenting fel med att en leverantör visar sin produkt tidigt och med självförtroende. Varningssignalen ser annorlunda ut: en leverantör som aldrig lämnar det standardiserade demoscriptet — som inte på allvar frågar hur köparen arbetar idag, var de verkliga smärtpunkterna finns, eller hur en idealisk framtida process skulle se ut, utan helt enkelt utgår från att dess fördefinierade arbetsflöde bör bli kundens.

Ett bättre samtal börjar någon annanstans: hur ser er vardag faktiskt ut — den verkliga processen, inte den idealiserade; var gör det ont — det manuella arbetet, kalkylbladen som överbryggar system som borde kommunicera med varandra, arbete som utförs av personer med högre kompetens än uppgiften kräver; och hur skulle ni helst vilja att det här fungerade i en idealvärld. Först då visar en bra leverantör vad plattformen kan göra — och demonstrerar kundens framtida process, inte sin egen föredragna. En bra AML-demo bör utgå från köparens arbetsflöde, inte leverantörens funktionslista.

Det här spelar roll eftersom köpare rutinmässigt förväxlar en tillfällig lösning med ett faktiskt krav. En potentiell kund beskrev en mycket anpassad riskklassificeringsmetodik som vid första anblick lät som ett krävande tekniskt krav. Ytterligare frågor visade att det i praktiken sköttes i ett kalkylblad, eftersom revisorerna som hanterade det kände sig hemma i Excel och den befintliga plattformen inte hade möjlighet att hantera det. Det verkliga kravet var aldrig "vi måste använda Excel." Det var "vi behöver ett ramverk för riskklassificering som är tillräckligt flexibelt för att återspegla vår metodik." En bra leverantör hjälper till att skilja på vad ett företag verkligen måste göra och vad det bara gör för att det nuvarande systemet inte erbjuder något annat alternativ — utan att göra anspråk på att förstå företagets egen verksamhet bättre än företaget självt. Målet är inte heller att digitalisera dagens process precis som den ser ut: företag samlar på sig onödiga steg av en mängd olika skäl, och att återskapa dem troget är inte framgång. En bra leverantör är ingen managementkonsult, men bör förstå problemet tillräckligt väl för att kunna visa var steg kan förenklas snarare än föras vidare oförändrade.

Ett fåtal frågor gör mer nytta i upphandlingsprocessen än en lång checklista: hur skulle vår befintliga process fungera i er plattform, och var skulle vi fortfarande behöva Excel eller e-post för att täppa till luckor? Utlöser en relevant händelse rätt arbetsflöde, eller måste någon uppmärksamma den manuellt? Den mest avslöjande frågan av alla: vilka delar av den här processen kommer vi fortfarande att behöva hantera någon annanstans efter att vi köpt er plattform?

Visa mig år fem

De flesta AML- och KYC-demonstrationer börjar med onboarding, av det uppenbara skälet att det är där en ny kund först möter produkten. Men onboarding utgör kanske några timmar i en relation som löper i fem eller tio år, och ett beslut som huvudsakligen grundas på hur tilltalande den första resan ser ut besvarar fel del av frågan. Köp inte en AML-plattform enbart utifrån hur väl den hanterar dag ett — be den visa hur år fem ser ut.

Fråga vad som händer när ett dokument löper ut, när ägarförhållanden eller en styrelseledamot förändras, när en granskning förfaller eller när relationen avslutas. Ta den enklaste varianten: en kund identifieras med ett pass som löper ut om arton månader. Vad är det som faktiskt meddelar organisationen, arton månader senare, att något behöver göras — och det ärliga svaret bör inte vara någons minne, en kalenderpåminnelse eller förhoppningen att den ursprungliga medarbetaren fortfarande är kvar. Samma logik gäller för varje livscykelhändelse, utan att göra anspråk på att varje utgångsdatum för med sig identiska regulatoriska konsekvenser. Och när något från tre år tillbaka behöver förklaras spelar plattformens förmåga att visa vad som var känt och beslutat vid den tidpunkten en stor roll — något som den här serien har behandlat på annat håll.

Kundtillväxt bör inte kräva linjär tillväxt av manuellt compliancearbete

Regulatoriska skyldigheter tar mänsklig tid i anspråk, och en del av den är välbetänkt — omdöme och ansvarsskyldighet är inte saker man automatiserar bort. Men en stor del av tiden kring det omdömet är administration: att samla in information, spåra utgångsdatum, bevaka förändringar, utlösa granskningar och sammanställa det underlag som en beslutsfattare behöver. Det är den delen tekniken bör minska, och bra AML-teknik bör bryta det linjära sambandet mellan hur många kunder ett företag betjänar och hur mycket manuellt compliancearbete det kräver.

Det rätta utfallet för en köpare är inte "vårt system kan hantera fler kunder." Det är snarare: vi ökade antalet kunder vi betjänar väsentligt utan att compliance-bemanningen växte i närheten av samma takt — en form av hävstång med verkliga föregångare på annat håll inom finansiella tjänster, där skalbara driftplattformar har låtit företag öka volymen utan en motsvarande ökning av personalstyrkan. Det bästa måttet på automatisering är inte hur många uppgifter en leverantör kallar "automatiserade." Det är hur mycket mer verksamhet organisationen kan hantera utan att behöva lägga till motsvarande manuellt arbete.

Det innebär inte att ta bort människor från de beslut som är viktiga. Bra automatisering bör eliminera repetitiv administration, samla in och strukturera data, bevaka förändringar, styra arbete till rätt person, lyfta fram det de behöver se och automatiskt underhålla historiken — så att människan proportionellt sett ägnar mer tid åt omdöme och komplexa fall, och mindre åt administration. Målet är inte att automatisera compliance-omdömet. Det är att sluta slösa bort compliance-omdömet på administration.

Vad händer när företaget korsar en gräns

Världen styrs inte av ett enda AML-regelverk. Olika jurisdiktioner har olika krav, riskfaktorer och dokumentationsförväntningar, och allt detta förändras över tid. En plattform byggd kring en enda jurisdiktions antaganden tenderar att göra varje ny marknad till en egen compliance-silo, driven av den som råkar förstå den marknadens regler bäst.

IQON är utformat för en värld där regulatoriska krav skiljer sig åt mellan jurisdiktioner och förändras över tid. Dess riskklassificeringsarkitektur är utformad för att stödja jurisdiktionskänsliga regulatoriska parametrar parallellt med ett företags egen metodik och riskaptit. Det garanterar inte compliance i varje jurisdiktion, känner inte automatiskt till och tillämpar inte varje juridisk regel världen över, och ersätter inte ett företags egen juridiska tolkning av vad som gäller för det — vad det är utformat för att göra är att ge ett företag en enda driftsmodell som kan anpassas till jurisdiktionella skillnader, snarare än att tvinga fram en ombyggnad varje gång det går in på en ny marknad. Den verkliga frågan för ett internationellt verksamt företag: kan en enda driftsmodell anpassas över jurisdiktioner, eller kommer expansion helt enkelt att skapa en ny silo per land?

Börja med problemet, inte funktionslistan

Det här är inget argument för en checklista. Den starkaste versionen av det är vad en bra köpare instinktivt vill säga till en leverantör: vi har ett problem, kan ni lösa det — snarare än att anlända med tjugosju obligatoriska funktioner och fråga vem som bockar av flest rutor. Funktioner spelar roll, men en process som börjar med en funktionsjämförelse har redan låtit leverantörernas befintliga produktstrukturer definiera lösningen, innan företaget har beskrivit sitt eget problem ordentligt.

Den bättre processen börjar med företagets egen beskrivning av sig självt: hur det fungerar idag, var tid slösas bort, var kunder upplever friktion, var information fastnar mellan avdelningar och vad som inte kan skalas upp som det ser ut nu. Först därefter är det meningsfullt att be en leverantör bevisa att dess plattform stödjer den driftsmodellen — detta år och i år fem. Börja inte med att fråga vilken leverantör som har den längsta funktionslistan. Börja med: det här är problemet vi har, kan ni lösa det. Använd IQON för så mycket av kundlivscykeln som verkligen är meningsfullt, och integrera det med vad annat som rimligen bör finnas kvar. Den bästa AML-plattformen är inte nödvändigtvis den som gör mest. Det är den som låter ett företag fungera som en organisation, snarare än att skapa ytterligare en plats där compliance lever i isolering.