Screen scraping in vergelijking met API's: Hoe elk model omgaat met je inloggegevens voor de bank

Financial Connections

Met Stripe Financial Connections kunnen je gebruikers hun financiële gegevens veilig met je delen.

Meer informatie 
  1. Inleiding
  2. Kernpunten
  3. Wat is screen scraping in financiële diensten?
  4. Hoe werken API’s voor financiële data?
  5. Waarom verminderen API’s het beveiligingsrisico in vergelijking met screen scraping?
    1. Inloggegevens opslaan versus tokens uitgeven
    2. Volledige toegang versus gedefinieerde toegang
  6. Hoe verschillen betrouwbaarheid en schaalbaarheid tussen screen scraping en API’s?
  7. Welke invloed heeft screen scraping op de gebruikerservaring en het vertrouwen van de klant?
  8. Hoe stimuleren regelgevers de verschuiving van screen scraping naar API’s?
  9. Hoe Stripe Financial Connections kan helpen

Zowel screen scraping als toegang op basis van Application Programming Interfaces (API's) helpen een onderneming om de benodigde financiële data van de bankrekening van een klant te krijgen, maar ze gebruiken fundamenteel verschillende mechanismen om dit te doen. Screen scraping logt in op je bankrekening met je inloggegevens en leest data rechtstreeks van dezelfde pagina's die je zelf zou zien. API-toegang leidt je door de eigen inlog van je bank en geeft vervolgens een beperkt, herroepbaar token uit zonder je wachtwoord ooit aan te raken. In sommige gevallen hebben API-gebaseerde koppelingen het succespercentage verhoogd tot maar liefst 99,9%. Naast betrouwbaarheid beschikt deze methode over een hoog beveiligingsniveau, kan het de gebruikerservaring verbeteren en kan het ondernemingen helpen afgestemd te blijven op regelgeving.

Hieronder verkennen we hoe screen scraping en API-toegang werken, waarom de opslag van inloggegevens een ander risicoprofiel creëert dan op tokens gebaseerde toegang, en hoe banken en regelgevers de verschuiving naar API's versnellen.

Kernpunten

  • Traditionele screen scraping vereist de opslag van de inloggegevens voor de bank van een klant, terwijl API-toegang afhankelijk is van beperkte, herroepbare tokens die worden uitgegeven nadat de klant rechtstreeks bij de eigen bank is geauthenticeerd.

  • Screen scraping kan kapotgaan wanneer een bank de website wijzigt, terwijl API's gestructureerde data retourneren via een contract dat over het algemeen alleen verandert wanneer de bank het opzettelijk bijwerkt.

  • De regel van sectie 1033 van het Consumer Financial Protection Bureau (CFPB) en de bestaande frameworks voor open banking in het Verenigd Koninkrijk en de EU pushen banken richting gestandaardiseerde toegang, wat in de praktijk vaak API's betekent, en weg van op inloggegevens gebaseerde scraping.

Wat is screen scraping in financiële diensten?

Screen scraping houdt in dat een externe dienst inlogt op je bankrekening met je gebruikersnaam en wachtwoord, en vervolgens rechtstreeks de data afleest van de pagina's die je bank toont als je zelf inlogt. Er is geen specifiek datakanaal. De dienst gebruikt dezelfde sessie als een klant en haalt accountsaldo's, transactiegeschiedenissen en accountnummers rechtstreeks op van de gerenderde pagina.

Hoe werken API's voor financiële data?

Op API's gebaseerde toegang vervangt het delen van inloggegevens door een overdracht met toestemming en draait over het algemeen op Open Authorization (OAuth) 2.0, de de facto standaard voor online autorisatie.

Het proces valt uiteen in een paar afzonderlijke stappen:

  • Omleiding en authenticatie: Je wordt direct naar de inlogpagina van je bank gestuurd, waar je inloggegevens invoert die alleen je bank ziet.

  • Toestemming en reikwijdte: Je bank vraagt je om beperkte machtigingen goed te keuren, zoals accountsaldo's of de transactiegeschiedenis die de aanvragende onderneming mag bekijken, in plaats van algemene toegang te verlenen tot alles op je account.

  • Uitgifte van tokens: Zodra je dit goedkeurt, geeft de bank een toegangstoken uit aan de aanvragende onderneming. Dat token vertegenwoordigt een beperkte, herroepbare machtiging.

  • Georganiseerde levering van data: De onderneming roept de API van de bank aan met dat token en ontvangt in ruil daarvoor schone, gestructureerde data, zoals JavaScript Object Notation (JSON).

Waarom verminderen API's het beveiligingsrisico in vergelijking met screen scraping?

Screen scraping en API-toegang verschillen het sterkst in wat er wordt opgeslagen en wie de toegang beheert. Dat verschil bepaalt bijna elk beveiligingsgevolg dat daaruit voortvloeit, van blootstelling aan datalekken tot hoe snel een gecompromitteerde koppeling kan worden afgesloten.

Inloggegevens opslaan versus tokens uitgeven

Bij traditionele screen scraping moet een aggregator over het algemeen de daadwerkelijke gebruikersnaam en het wachtwoord voor de bank ergens in de eigen systemen opslaan, vaak zolang je de service blijft gebruiken. Elke opgeslagen set inloggegevens is een doelwit als de database van die aggregator wordt gecompromitteerd.

Met API's is het toegangstoken dat na OAuth-authenticatie aan een onderneming wordt doorgegeven een beperkt, herroepbaar token dat over het algemeen vervalt en alleen toegang verleent tot wat je hebt goedgekeurd, zoals alleen-lezen zichtbaarheid in de transactiegeschiedenis. Als de systemen van een onderneming worden gecompromitteerd, kan het token op bankniveau worden uitgeschakeld zonder dat je aan jouw kant het wachtwoord opnieuw hoeft in te stellen.

Volledige toegang versus gedefinieerde toegang

Een opgeslagen wachtwoord verleent degene die het in bezit heeft dezelfde brede toegang die je zou hebben als je zelf inlogt. Een token kan worden beperkt tot exact één functie, zodat een onderneming die je accountsaldo bevestigt voor een aanvraag voor een lening niet wegloopt met een transactiegeschiedenis van vijf jaar die ze nooit nodig hadden. De kloof tussen volledige toegang en gedefinieerde toegang is een van de redenen waarom banken, toezichthouders en API-providers de opslag van inloggegevens behandelen als het meer risicovolle model.

Hoe verschillen betrouwbaarheid en schaalbaarheid tussen screen scraping en API's?

Screen scraping is van nature kwetsbaar, omdat het afhankelijk is van de eigen website van de bank. Wanneer een bank de inlogflow bijwerkt, het dashboard opnieuw ontwerpt of een nieuwe authenticatiestap toevoegt, stoppen scrapers die zijn gebouwd op de oude lay-out mogelijk met werken totdat een engineer ze handmatig opnieuw opbouwt. Die kwetsbaarheid en het schaalprobleem dat het creëert, resulteren in een paar afzonderlijke problemen:

  • Site-afhankelijkheid: Scrapers zijn ervan afhankelijk dat de HTML van een bank constant blijft, wat betekent dat een routinematig nieuw ontwerp een koppeling ongemerkt kan verbreken zonder enige waarschuwing aan de aggregator.

  • Handmatig onderhoud: Kapotte scrapers vereisen vaak een engineer om ze opnieuw op te bouwen voor de nieuwe lay-out, werk dat zich herhaalt in duizenden banken volgens de eigen releaseschema's.

  • Hogere storingspercentages: Op scraping gebaseerde koppelingen mislukken over het algemeen veel vaker dan op API's gebaseerde koppelingen, met name direct nadat een bank een site-update heeft doorgevoerd.

API's worden over het algemeen om een aantal redenen als betrouwbaarder beschouwd:

  • Gedefinieerde datacontracten: De API van een bank retourneert accountgegevens in vaste structuren, zoals een saldoveld dat is opgemaakt als een geheel getal in centen, en die structuur verandert over het algemeen niet, tenzij de bank de API opzettelijk bijwerkt en hiervan kennisgeving doet.

  • Duidelijke foutafhandeling: Een API retourneert een expliciete foutcode wanneer er iets misgaat, zodat de systemen van een onderneming weten dat ze het opnieuw moeten proberen of het probleem moeten markeren, in plaats van te werken met beschadigde of onjuist opgemaakte data.

  • Lineaire in vergelijking met genetwerkte schaalbaarheid: De infrastructuur voor open banking vergemakkelijkt directe relaties met duizenden banken en kredietverenigingen, wat betekent dat een onderneming die één keer integreert, dat hele netwerk kan bereiken. Voor een op scraping gebaseerde aanpak moet echter voor elke bank op de lijst een aangepast script worden gebouwd en onderhouden.

Welke invloed heeft screen scraping op de gebruikerservaring en het vertrouwen van de klant?

Het overhandigen van de gebruikersnaam en het wachtwoord voor de bank aan een externe app vereist een mate van vertrouwen die veel mensen niet willen geven. De eigen beveiligingsberichten van veel banken instrueren gebruikers om inloggegevens nooit buiten de eigen website van de bank te delen, dus een op scraping gebaseerde app die gebruikers vraagt om precies dat binnen de eigen interface te doen, kan met argwaan worden bekeken. Deze mismatch kan zorgen voor aarzeling op het moment van het koppelen van het account, wat gebruikers ervan weerhoudt om het proces voor de koppeling te voltooien of ertoe leidt dat ze het halverwege afbreken wanneer het verzoek om inloggegevens niet goed aanvoelt.

Op OAuth gebaseerde flows omzeilen dat probleem, omdat je het wachtwoord alleen invoert op de eigen inlogpagina van de bank. Het is een vertrouwde interface op een bekend domein en het machtigingenscherm vertelt je specifiek wat je ermee instemt om te delen. Deze specificiteit verandert de psychologie van toestemming, omdat je een concrete lijst met items krijgt, zoals een accountsaldo en de transactiegeschiedenis van de afgelopen 90 dagen, en wordt gevraagd deze direct goed te keuren of af te wijzen. Bijgevolg kunnen flows voor toestemming die zijn gebouwd op directe authenticatie via de bank resulteren in hogere voltooiingspercentages dan op inloggegevens gebaseerde aggregatie.

Zodra het vertrouwen is geschaad door een slechte ervaring of een krantenkop over een datalek bij een op scraping gebaseerde aggregator, is het moeilijk om dat vertrouwen terug te winnen. Ondernemingen die financiële producten bouwen, behandelen de methode voor authenticatie zelf in toenemende mate als een indicator van geloofwaardigheid in plaats van als een eenvoudig detail van de implementatie.

Hoe stimuleren regelgevers de verschuiving van screen scraping naar API's?

De regel van sectie 1033 van het CFPB, die momenteel is gepauzeerd nadat een federale rechtbank een voorlopig verbod had uitgevaardigd, is bedoeld om een gedeelte van de Dodd-Frank Act te implementeren dat data-aanbieders, zoals banken, verplicht om de financiële data van klanten op aanwijzing van de klant beschikbaar te stellen aan derden. Het doel van de regel is om klanten een wettelijk recht op hun eigen data te geven in een bruikbaar, overdraagbaar formaat. De regel is expliciet voorstander van gestandaardiseerde, veilige elektronische overdrachtsmethoden, wat in de praktijk vaak betekent dat de voorkeur wordt gegeven aan API's boven op inloggegevens gebaseerde scraping.

Veel grote financiële instellingen hebben al jarenlang gewerkt aan het bouwen van een speciale API-infrastructuur, deels zodat ze kunnen stoppen met het ondersteunen van het scraping-verkeer dat hun klantgerichte websites bezoekt. Dit kan de capaciteit van de server belasten en complicaties opleveren voor beveiligingsbeoordelingen. Frameworks voor open banking in het Verenigd Koninkrijk en de EU zijn een eerder precedent voor deze verschuiving.

Omdat veel kleinere instellingen en kredietverenigingen nog steeds niet over de API-infrastructuur beschikken die grote banken al hebben gebouwd, behouden sommige aggregators scraping als een terugvaloptie voor accounts zonder API-alternatief. Naarmate de implementatie van sectie 1033 echter vordert en meer banken over conforme API-eindpunten beschikken, hebben de ondernemingen die financiële producten bouwen de meeste redenen om in een vroeg stadium te handelen, voordat op scraping gebaseerde koppelingen verouderd raken.

Hoe Stripe Financial Connections kan helpen

Stripe Financial Connections is een set API's waarmee je veilig een koppeling kunt maken met de bankrekeningen van je klanten en hun financiële data kunt ophalen, zodat je innovatieve financiële producten en services kunt bouwen.

Financial Connections kan je helpen:

  • Onboarding te vereenvoudigen: bied een naadloos, direct verificatieproces voor bankrekeningen aan, zonder dat handmatige identiteits- en accountverificatie nodig is.

  • Toegang tot rijke financiële data: Haal uitgebreide informatie op over de bankrekeningen van je klanten, inclusief saldo's, transacties en accountgegevens.

  • Terugkerende betalingen te automatiseren: laat je klanten hun bankrekeningen veilig koppelen voor terugkerende betalingen, waardoor het succespercentage van betalingen omhoog gaat.

  • Je risicobeheer te verbeteren: analyseer de financiële gegevens van klanten om beter geïnformeerde beslissingen te nemen over krediet, leningen en andere financiële producten.

  • Aan de regelgeving te voldoen: Financial Connections helpt je te voldoen aan de vereisten op het gebied van ken-je-klant (KYC) en witwasbestrijding (AML).

  • Met vertrouwen te innoveren: ontwikkel nieuwe financiële producten en diensten op basis van de veilige, betrouwbare infrastructuur van Financial Connections.

Lees meer over Financial Connections, of ga vandaag nog aan de slag.

De inhoud van dit artikel is uitsluitend bedoeld voor algemene informatieve en educatieve doeleinden en mag niet worden opgevat als juridisch of fiscaal advies. Stripe verklaart of garandeert niet dat de informatie in dit artikel nauwkeurig, volledig, adequaat of actueel is. Voor aanbevelingen voor jouw specifieke situatie moet je het advies inwinnen van een bekwame, in je rechtsgebied bevoegde advocaat of accountant.

Meer artikelen

  • Er is iets misgegaan. Probeer het opnieuw of neem contact op met support.

Klaar om aan de slag te gaan?

Maak een account en begin direct met het ontvangen van betalingen. Contracten of bankgegevens zijn niet vereist. Je kunt ook contact met ons opnemen om een pakket op maat voor je onderneming samen te stellen.

Financial Connections

Met Stripe Financial Connections kunnen je gebruikers hun financiële gegevens veilig met je delen.

Documentatie voor Financial Connections

Ontdek hoe je toegang krijgt tot gegevens van de financiële rekeningen van je gebruikers, waarvoor toestemming is gegeven.