FinTech Security Architect

En FinTech security architect tegner sikkerheden ind i finansielle it-systemer, før de bliver bygget. Rollen sidder mellem udviklere, forretning og tilsyn. Arkitekten beslutter, hvordan en betaling, en kundeoprettelse eller et lån beskyttes hele vejen igennem. Fejl her koster ikke kun data. De koster penge, kundernes tillid og i værste fald tilladelsen til at drive virksomhed.

Typiske opgaver

• Trusselsmodellering af betalingsflows, kortdata og open banking-API'er.
• Design af stærk kundeautentifikation, ofte med MitID, biometri eller push-godkendelse i app.
• Nøglehåndtering og kryptografi, typisk med HSM'er og tokenisering af kortnumre.
• Segmentering, så kortdatamiljøet holdes adskilt fra resten af netværket.
• Sikkerhedskrav til cloud i AWS, Azure eller Google Cloud, gerne skrevet som kode.
• Adgangsstyring for udviklere, driftsfolk og eksterne partnere (IAM og PAM).
• Vurdering af tredjeparter: kernebanksystem, KYC-leverandør, kortindløser, sms-gateway.
• Sparring med SOC og fraud-teamet om logning, alarmer og hændelsesrespons.
• Dokumentation, der kan holde til en revision eller et tilsynsbesøg.

En almindelig dag
Dagen starter sjældent med at tegne. Den starter i et review. Et udviklerteam vil lancere en funktion, hvor kunden kan sende penge til en kontakt. Arkitekten stiller de kedelige spørgsmål: Hvor ligger data? Hvem kan se dem? Hvad sker der, hvis telefonen er stjålet? Bagefter går tiden med et designdokument, et møde om en ny cloudleverandør og en risikovurdering til compliance-afdelingen. En stor del af arbejdet er skrivning og overtalelse. Arkitekten har sjældent selv adgang til at ændre noget i produktion.

Rollen findes i banker, realkredit, forsikring og pension. Den findes også hos betalingsudbydere, kortindløsere og i sektorens fælles it-huse som BEC, Bankdata og JN Data. Mindre fintechvirksomheder køber ofte rollen som konsulent, indtil de vokser.

Hvilken lovgivning dækker denne rolle?
Faget kræver ingen autorisation, men det findes på grund af regulering. EU's DORA-forordning stiller krav til digital modstandsdygtighed, leverandørstyring og indberetning af it-hændelser i finanssektoren. PSD2 er i Danmark gennemført i betalingsloven og kræver stærk kundeautentifikation og sikre API'er. Finanstilsynet fører tilsyn, og Nationalbanken står bag TIBER-DK, hvor bankers forsvar testes med rigtige angrebsscenarier. Hertil kommer GDPR under Datatilsynet, hvidvaskloven, EU's NIS2-direktiv og kortselskabernes standard PCI DSS.

Der findes ingen fast uddannelse til jobbet. Næsten alle kommer ind sidelæns efter år i et andet it-fag.

Den typiske vej

• Bachelor og kandidat i datalogi, softwareteknologi eller cybersikkerhed. Fem år i alt.
• Uddannelserne udbydes blandt andet på DTU, Aalborg Universitet, Syddansk Universitet, IT-Universitetet og Aarhus Universitet.
• Adgangskravet er typisk en gymnasial eksamen med matematik A og engelsk B.
• Derefter fem til ti år som udvikler, cloud- eller netværksspecialist, penetrationstester eller SOC-analytiker.
• Først bagefter kommer arkitekttitlen. Arbejdsgivere leder efter en, der selv har bygget systemer.

Kortere veje ind

• Datamatiker på to et halvt år, efterfulgt af en professionsbachelor i softwareudvikling eller it-sikkerhed. Udbydes på erhvervsakademier som KEA, Zealand, Erhvervsakademi Aarhus og UCL.
• Skift internt i banken. Mange arkitekter kommer fra drift eller udvikling i huset og kender betalingsforretningen i forvejen.
• Skift fra compliance, intern revision eller risikostyring. Så skal den tekniske dybde hentes bagefter, og det tager år.
• Skift fra konsulenthus. Et par år med DORA-gapanalyser og sikkerhedsreviews i flere banker giver hurtigt bredde.

Certificeringer, der tæller
CISSP fra ISC2 er den mest efterspurgte i danske jobopslag og kræver fem års dokumenteret erfaring. Overbygningen CISSP-ISSAP er målrettet arkitekter. CCSP dækker cloud, CISM fra ISACA dækker ledelsesvinklen, og SABSA eller TOGAF dækker selve arkitekturhåndværket. Sikkerhedscertificeringerne fra AWS og Microsoft vejer tungt i praksis, fordi arbejdet ofte ligger i deres platforme.

Hvad der reelt afgør ansættelsen
Regning på papir er ikke nok. Du skal kunne forklare et betalingsflow på en tavle og pege på, hvor det knækker. Du skal kunne læse en kontrakt med en leverandør og se, hvad der mangler. Og du skal kunne sige nej til et udviklerteam uden at blive holdt uden for næste projekt.

Efteruddannelse
Der findes masteruddannelser i it-sikkerhed på deltid, blandt andet gennem IT-vest-samarbejdet. Sektorens egne kurser dækker regler og produkter, ikke teknik. Meget læring sker i praksis: hændelser, revisionsbemærkninger og rapporter fra eksterne pentestere.

En FinTech security architect koder sjældent til produktion. Men værktøjerne skal kendes godt nok til at stille præcise krav.

• Diagrammer og modeller: draw.io, Archi og Visio til arkitekturtegninger. Trusselsmodellering i OWASP Threat Dragon eller IriusRisk.
• Rammeværk: OWASP ASVS og SAMM, MITRE ATT&CK, NIST Cybersecurity Framework, ISO 27001 og kravene i PCI DSS.
• Cloud og infrastruktur: AWS, Azure og Google Cloud. Kubernetes, Terraform og politikker skrevet som kode.
• Kryptografi og nøgler: HSM'er fra fx Thales eller Utimaco, HashiCorp Vault, cloududbydernes nøgletjenester og tokenisering af kortnumre.
• Identitet og adgang: OAuth 2.0, OpenID Connect, FAPI-profilen til open banking, mTLS, Entra ID, Okta eller Keycloak.
• Test og kode: Burp Suite, SAST- og SCA-værktøjer som Snyk, SonarQube eller Checkmarx, plus rapporter fra eksterne pentestere.
• Overvågning: Splunk, Microsoft Sentinel eller Elastic, ofte koblet til fraud-systemer, der scorer transaktioner i realtid.
• Skriveredskaber: Confluence, Jira og et regneark. Risikoregistre og designdokumenter fylder mere end nogen tror.

Dertil kommer den danske virkelighed: MitID til autentifikation, Dankort- og kortskemaer fra indløseren, og integrationer til fælles infrastruktur i sektoren.