Primary tabs

Uitdagingen bij het ontwikkelen van nieuwe APIs

De afgelopen tijd zijn financiële instellingen druk geweest met de implementatie van de PSD2 APIs. De stap die veel banken nu gaan maken is het aanbieden van commerciële APIs. Bij een grote bank heb ik geconstateerd dat, naast de uitdagingen bij het ontwikkelen en opleveren van de nieuwe APIs zelf, er nog veel meer speelt voordat een API voor een breed publiek in productie genomen kan worden. Als dit niet goed geregeld wordt, dan worden er nieuwe APIs gebouwd die nog niet aangeboden kunnen worden. Na gesprekken die ik gevoerd heb met diverse financiële instellingen, blijkt dat deze uitdaging bijna overal speelt.

Wat bespreken?

Deze blog zal een aantal aspecten bespreken waarmee rekening gehouden moet worden bij het naar productie brengen van een API bij bijvoorbeeld een bank. Deze zaken zullen (grotendeels) aanwezig moeten zijn voordat de API aan een groot publiek aangeboden kan worden.

Waar moeten we rekening mee houden?

Vinden van de API

De prospect of bestaande klant van de bank moet in staat zijn om de API te kunnen vinden. Voor deze taak wordt vaak een (API) Developers Portal ingezet. De vraag is wel hoe de customer journey begint. Dit kan zijn vanuit de vertrouwde omgeving (gesloten domein) van de klant, maar ook via het open domein. Binnen het gesloten domein kan de bank ook rekening houden met de huidige product portfolio van de klant. De Developers Portal kan door de bank zelf ontwikkeld worden maar wordt vaak aangeschaft. Als onderdeel van de Full Lifecycle API Management oplossingen maakt een bank vaak gebruik van bijvoorbeeld Google Apigee, Axway, IBM, Software AG, Mulesoft of het CGI Open Finance platform.

Nieuwe klanten

Een traditionele klant van een bank zal een standaard set van producten afnemen, meestal gecombineerd met een (spaar)rekening. Een API-klant zoals een Fintech zal zijn bankzaken niet altijd afnemen bij de bank waar de API afgenomen wordt. De kans is natuurlijk groot dat de API-klant bij meerdere banken soortgelijke APIs zal afnemen. Zijn de huidige processen toereikend voor dit type nieuwe klanten? De 'Know Your Customer' (KYC) validaties zullen wellicht anders zijn. Soms zijn de validaties zwaarder (indien de nieuwe klant veel data van klanten van de bank zal ophalen) en soms minder zwaar (bijvoorbeeld het aanroepen van APIs ten behoeve van publieke informatie zoals openingstijden van de filialen). Kan de API-klant uiteindelijk ook toegevoegd worden aan de huidige klantenadministratie? Vaak moeten de huidige systemen aangepast worden voor dit soort nieuwe klanten.

Billing

Als de nieuwe API-klant geen betaalrekening heeft bij de bank, dan kan het geld niet altijd zoals gebruikelijk automatisch afgeschreven worden van een rekening bij deze bank. De kans is groot dat er daarom wijzigingen aan de huidige billing systemen moeten plaatsvinden. Ook moet de bank nadenken over de afrekeningsvormen. Naast eventuele aansluitkosten of abonnementsgelden is het gebruikelijk om te betalen voor het aantal API aanroepen. Deze informatie moet aan het billing systeem geleverd worden. Soms heeft het afrekenmodel zelfs te maken met de inhoud van de API responses (hoeveelheid data bijvoorbeeld).

Self service

De nieuwe API klant zal de instellingen van zijn APIs willen aanpassen of een additionele API willen afnemen. Maar hoe kan deze nieuwe API klant eigenlijk inloggen in de vertrouwde portal als hij geen traditionele klant met een rekening bij deze bank is? De authenticatie moet dus ook op een andere manier plaatsvinden dan op de gebruikelijke manieren bij een internetbankieren omgeving. Een oplossing kan zijn om APIs te gebruiken om instellingen te wijzigen. Interessant is hoe het aanvragen van een additionele API in dit geval zou moeten gaan. Het handigste lijkt toch om een aparte omgeving aan te bieden, zoals veel partijen al doen die APIs aanbieden.

Pakketintegratie

De developers portal is al eerder genoemd. Dit is vaak een onderdeel van een veelomvattende Full Lifecycle API Management oplossing, inclusief een authenticatie oplossing, billing, support etc. De vraag is echter of dit niet geïntegreerd moet worden met de huidige werkwijze van de bank. Of is het prima om het voor dit speciaal soort klanten anders te doen? Het ligt voor de hand om eerst te kijken naar de bestaande oplossingen binnen de bank, vaak zijn er veel meer processen bij betrokken. In het geval van billing zijn dat processen voor bijvoorbeeld foutieve of achterstallige betalingen.

Support

Bovenstaande uitdagingen hebben natuurlijk impact op de supportorganisatie en de wijze waarop zij benaderbaar zijn. We hebben te maken met nieuwe klanten die een nieuw soort product afnemen, waar andere kennis voor nodig is bij supportmedewerkers. Een bank kan ook nu technisch georiënteerde vragen verwachten.

Conclusie

Naast het beschikbaar stellen van een API zullen er veel andere zaken veranderen. Business processen en tooling om commerciële APIs beschikbaar te stellen moeten beschikbaar zijn. In de praktijk blijkt dat dit vaak te complex wordt om opgepakt te kunnen worden binnen het team dat de eerste commerciële API maakt. Als eerste stap kan daarom gekozen worden voor een friends & family release. Hierbij is het vaak nog niet nodig om alles, waaronder billing, geïmplementeerd te hebben. De wijzigingen zullen binnen verschillende afdelingen van de bank plaats vinden. Het verdient daarom de voorkeur om eerst een analyse te maken hoe de vereiste capabilities ingevuld gaan worden en welke IT dit gaat ondersteunen. CGI wil hier graag met u over van gedachten wisselen!

Over de auteur

Marc Blok

Marc Blok

Thought Leader Open Banking

Marc Blok werkt sinds 1998 bij CGI, maar zijn belangstelling voor ICT bestaat al veel langer . Na eerst als ontwikkelaar, ontwerper en projectleider te hebben gewerkt, is hij sinds 10 jaar als architect werkzaam binnen de bancaire wereld. Hij ...

Voeg commentaar toe

Comment editor

  • No HTML tags allowed.
  • Lines and paragraphs break automatically.
Blog richtlijnen en gebruiksvoorwaarden