Open Banking Specialist

En open banking specialist arbejder med adgang til bankkonti gennem API'er. Altså: at en app må hente kontooplysninger eller starte en betaling for kunden. Det kræver kundens aktive samtykke hver gang.

Specialisten sidder enten i banken, der stiller API'et til rådighed, eller hos tredjepartsudbyderen, der bruger det. De to sider af bordet ligner hinanden fagligt, men opgaverne vender modsat.

Typiske opgaver:

• Integrere mod bankernes PSD2-API'er — både kontooplysninger (AIS) og betalingsinitiering (PIS)
• Håndtere samtykke: indhente det, forny det og lukke adgangen igen, når det udløber
• Bygge og teste flows til stærk kundeautentifikation, hvor kunden godkender med MitID i bankens app
• Holde styr på eIDAS-certifikater (QWAC og QSEAL), som en tredjepart skal bruge for at kalde et bank-API
• Fejlsøge, når en bank ændrer format, fejlkoder eller timeout uden varsel
• Rense og kategorisere posteringer, så en rå betalingstekst bliver til husleje eller dagligvarer
• Måle og rapportere API'ets oppetid og svartider, som banker skal offentliggøre kvartalsvist efter EBA's tekniske standarder

En almindelig dag starter tit med overvågningen. Hvor mange kald fejlede i nat, og hos hvilken bank? Derefter kommer supportsager: en kunde kan ikke forbinde sin konto, og fejlen ligger et sted mellem app, redirect og bankens login. Om eftermiddagen er det typisk møder med produkt, jurister eller en banks API-team. Meget af arbejdet er detektivarbejde i logfiler.

En stor del af jobbet er ikke kode. Det er dokumentation, aftaler med banker, dialog med Finanstilsynet og forklaringer til folk, der ikke kender forskel på AIS og PIS.

Branchen dækker banker og realkredit, de fælles datacentraler BEC, Bankdata og SDC, betalingsvirksomheder som Nets, samt fintechs. Typiske brugsområder er budget- og overblikapps, abonnementsopsigelse, kreditvurdering ved låneansøgning, automatisk bogføring i regnskabsprogrammer og konto-til-konto-betaling i webshops. Aggregatorer som Tink og Aiia sælger adgangen videre som ét samlet API.

For en arbejdsgiver: rollen findes sjældent alene. Den hænger sammen med backend-udvikling, compliance og betalingsdrift. En stærk profil kan læse en teknisk standard og oversætte den til noget, forretningen kan handle på.

Hvilken lovgivning dækker denne rolle?
Faget findes, fordi EU's andet betalingstjenestedirektiv (PSD2) tvinger bankerne til at åbne kontoadgang for tredjeparter — i Danmark gennemført i lov om betalinger. De tekniske krav til stærk kundeautentifikation og sikker kommunikation står i en delegeret forordning, som Den Europæiske Banktilsynsmyndighed (EBA) har udarbejdet. Finanstilsynet giver tilladelse som kontooplysningstjeneste eller betalingsinitieringstjeneste og fører tilsyn med virksomheden. Samtidig gælder databeskyttelsesforordningen (GDPR) for kundedata, og EU's DORA-forordning for driftssikkerhed og leverandørstyring. PSD2 er fortsat gældende ret, men afløseren PSD3 og betalingsforordningen PSR er politisk færdigforhandlet, mens forordningen om finansiel dataadgang (FIDA) stadig forhandles.

Der findes ingen uddannelse, der hedder open banking specialist. Folk kommer ind ad to hovedveje: den tekniske og den forretningsmæssige.

Den tekniske vej starter typisk som datamatiker (2 år) eller diplomingeniør i softwareteknologi. Adgangskravet til datamatiker er en gymnasial eksamen med matematik på C-niveau eller en relevant erhvervsuddannelse. Oven på datamatiker kan man tage professionsbachelor i softwareudvikling på halvandet år. Universitetsvejen er datalogi, software engineering eller cand.it og tager fem år.

Den forretningsmæssige vej går ofte via finansøkonom (2 år) eller professionsbachelor i finans. Mange kommer også med HD i finansiering ved siden af et job i banken. Den profil ender typisk i produktejer- eller compliance-delen af open banking.

Alternative veje ind er de mest almindelige i praksis:

• Fra bankens egen IT-afdeling, hvor man i forvejen kender kernesystemet
• Fra betalingsdrift eller kortområdet
• Fra hvidvask- og compliance-arbejde, hvor man kender Finanstilsynets sprog
• Fra support eller onboarding i en fintech, hvor man ser fejlene på tættest hold

Du kan træne faget uden en arbejdsgiver. Flere banker og aggregatorer har åbne sandkassemiljøer, hvor man kan teste kald mod testkonti uden tilladelse. Berlin Groups NextGenPSD2-specifikation er offentlig og er den standard, de fleste europæiske banker bygger deres API på. Et lille projekt, der henter testtransaktioner og kategoriserer dem, er et stærkere bevis end et kursusbevis.

Der er ingen personlig autorisation. Tilladelsen ligger hos virksomheden, ikke hos medarbejderen, og den gives af Finanstilsynet. Relevante certificeringer er derfor frivillige — typisk inden for sikkerhed (CISSP, CISM) eller cloud (Azure, AWS). Finanssektorens Uddannelsescenter udbyder kortere kurser i betalingsområdet.

Engelsk er et reelt krav. Al API-dokumentation, alle standarder og de fleste møder med udenlandske banker foregår på engelsk.

Realistisk tidshorisont: to til fire år i finanssektoren eller en fintech, før man kan kalde sig specialist. Selve API-teknikken kan læres på måneder. Det, der tager tid, er at kende bankernes særheder og reglernes gråzoner.

Kernen er almindelig web-teknologi brugt under stramme regler. REST-API'er med JSON, dokumenteret i OpenAPI og testet i Postman eller Insomnia.

Sikkerhedsdelen fylder mest:

• OAuth 2.0 og OpenID Connect til samtykke og redirect til bankens login
• mTLS og eIDAS-certifikater (QWAC og QSEAL) udstedt af en betroet tillidstjenesteudbyder
• FAPI-profilen, som mange banker bruger til at stramme OAuth-opsætningen
• MitID i det danske godkendelsesflow

Standarder man skal kunne finde rundt i: Berlin Groups NextGenPSD2 for selve API-formatet og ISO 20022 for betalingsbeskeder. Britiske og polske banker bruger andre standarder, hvilket er en klassisk kilde til bøvl i europæiske projekter.

Kode skrives typisk i Java, Kotlin, C# eller TypeScript på bankside. Python bruges meget til dataanalyse og kategorisering af transaktioner. Drift ligger oftest i Azure eller AWS med Kafka til hændelser og Datadog, Splunk eller Grafana til overvågning.

Mange arbejder aldrig direkte mod bankerne, men gennem en aggregator som Tink, Aiia, Enable Banking eller GoCardless Bank Account Data. Det sparer hundredvis af integrationer, men flytter fejlsøgningen et lag væk.

Dertil kommer det uglamourøse: Jira, Confluence, registret over betalingstjenesteudbydere hos Finanstilsynet og EBA, og et regneark med hver banks kendte afvigelser.