Både skärmskrapning och åtkomst baserad på programmeringsgränssnitt för applikationer (API:er) hjälper ett företag att få de finansiella data det behöver från en kunds bankkonto, men de använder fundamentalt olika mekanismer för att göra det. Skärmskrapning loggar in på ditt bankkonto med dina inloggningsuppgifter och läser data från samma sidor som du skulle se själv. API-åtkomst dirigerar dig genom din egen banks inloggning och utfärdar sedan en avgränsad, återkallelig token utan att någonsin röra ditt lösenord. I vissa fall har API-baserade anslutningar ökat framgångsfrekvensen till hela 99,9 %. Utöver tillförlitlighet har den här metoden höga säkerhetsnivåer, kan förbättra användarupplevelsen och kan hjälpa företag att hålla sig i linje med regelverk.

Nedan utforskar vi hur skärmskrapning och API-åtkomst fungerar, varför lagring av inloggningsuppgifter skapar en annan riskprofil än tokenbaserad åtkomst och hur banker och tillsynsmyndigheter påskyndar övergången till API:er.

Viktiga lärdomar

• Traditionell skärmskrapning kräver att man sparar en kunds inloggningsuppgifter för banken, medan API-åtkomst förlitar sig på avgränsade, återkalleliga token som utfärdas efter att kunden autentiserar sig direkt hos sin bank.

• Skärmskrapning kan gå sönder när en bank ändrar sin webbplats, medan API:er returnerar strukturerade data genom ett kontrakt som generellt sett bara ändras när banken medvetet uppdaterar det.

• Regelverket från Consumer Financial Protection Bureau (CFPB) sektion 1033 och befintliga ramverk för open banking i Storbritannien och EU driver banker mot standardiserad åtkomst, vilket ofta innebär API:er, och bort från uppgiftsbaserad skrapning.

Vad är skärmskrapning inom finansiella tjänster?

Skärmskrapning innebär att en tredjepartstjänst loggar in på ditt bankkonto med ditt användarnamn och lösenord och sedan läser av data direkt från de sidor som din bank visar när du loggar in själv. Det finns ingen dedikerad datakanal. Tjänsten använder samma session som en kund skulle göra och hämtar kontosaldon, transaktionshistorik och kontonummer direkt från den renderade sidan.

Hur fungerar API:er för finansiella data?

API-baserad åtkomst ersätter delning av inloggningsuppgifter med en behörighetsstyrd överlämning och körs vanligtvis på Open Authorization (OAuth) 2.0, de facto-standarden för online-auktorisering.

Processen bryts ner i några distinkta steg:

• Omdirigering och autentisering: Du skickas direkt till din banks inloggningssida där du anger inloggningsuppgifter som bara din bank ser.

• Samtycke och omfattning: Din bank ber dig att godkänna begränsade behörigheter, som kontosaldon eller transaktionshistorik som det begärande företaget tillåts se, istället för att ge fullständig åtkomst till allt på ditt konto.

• Utfärdande av token: När du har godkänt utfärdar din bank en åtkomst-token till det begärande företaget. Den token representerar ett begränsat, återkalleligt medgivande.

• Strukturerad dataleverans: Företaget anropar bankens API med den token och får rena, strukturerade data som JavaScript Object Notation (JSON) i retur.

Varför minskar API:er säkerhetsrisken jämfört med skärmskrapning?

Skärmskrapning och API-åtkomst skiljer sig mest markant åt i vad som sparas och vem som kontrollerar åtkomsten. Den skillnaden formar nästan varje säkerhetskonsekvens som följer, från exponering vid intrång till hur snabbt en komprometterad anslutning kan stängas ned.

Att spara inloggningsuppgifter jämfört med att utfärda token

Traditionell skärmskrapning kräver vanligtvis att en aggregator sparar ditt faktiska användarnamn och lösenord för banken någonstans i sina system, ofta så länge du fortsätter att använda tjänsten. Varje sparad uppsättning inloggningsuppgifter är ett mål om den aggregatorns databas utsätts för intrång.

Med API:er är den åtkomsttoken som skickas till ett företag efter OAuth-autentisering en avgränsad, återkallelig inloggningsuppgift som vanligtvis löper ut och bara ger åtkomst till det du godkände, som skrivskyddad insyn i transaktionshistorik. Om ett företags system komprometteras kan den token stängas av på banknivå utan att det krävs en lösenordsåterställning från din sida.

Fullständig åtkomst jämfört med definierad åtkomst

Ett sparat lösenord ger den som innehar det samma breda åtkomst som du skulle ha om du loggade in själv. En token kan begränsas till exakt en funktion, så ett företag som bekräftar ditt kontosaldo för en låneansökan inte går därifrån med fem års transaktionshistorik som det aldrig behövde. Klyftan mellan fullständig åtkomst och definierad åtkomst är en anledning till att banker, tillsynsmyndigheter och API-leverantörer behandlar lagring av inloggningsuppgifter som den mer riskfyllda modellen.

Hur skiljer sig tillförlitlighet och skalbarhet mellan skärmskrapning och API:er?

Skärmskrapning är skört i sin design eftersom det beror på bankens egen webbplats. När en bank uppdaterar sitt inloggningsflöde, designar om sin Dashboard eller lägger till ett nytt autentiseringssteg kan skrapor som byggts på den gamla layouten sluta fungera tills en tekniker bygger om dem manuellt. Den skörheten, plus det skalbarhetsproblem som den skapar, resulterar i några distinkta problem:

• Webbplatsberoende: Skrapor förlitar sig på att en banks HTML förblir konstant, vilket innebär att en rutinmässig omdesign i tysthet kan bryta en anslutning utan varning till aggregatorn.

• Manuellt underhåll: Trasiga skrapor behöver ofta en tekniker för att bygga om dem för den nya layouten – ett arbete som upprepas över tusentals banker enligt deras egna lanseringsscheman.

• Högre felfrekvenser: Skrapningsbaserade anslutningar tenderar att misslyckas i betydligt högre grad än API-baserade, särskilt direkt efter att en bank publicerar en webbplatsuppdatering.

API:er anses generellt vara mer tillförlitliga av några anledningar:

• Definierade datakontrakt: En banks API returnerar kontodata i fasta strukturer, till exempel ett fält för saldo formaterat som ett heltal i cent, och den strukturen ändras vanligtvis inte såvida inte banken medvetet uppdaterar API:et och meddelar detta.

• Tydlig felhantering: Ett API returnerar en uttrycklig felkod när något går sönder, så att ett företags system vet att de ska försöka igen eller flagga problemet istället för att arbeta med korrupta eller felaktigt utformade data.

• Linjär jämfört med nätverksbaserad skalbarhet: Open banking-infrastruktur underlättar direkta relationer med tusentals banker och kreditföreningar, vilket innebär att ett företag som integrerar en gång kan nå hela det nätverket. En skrapningsbaserad metod behöver dock ett anpassat script som byggs och underhålls för varje bank på listan.

Hur påverkar skärmskrapning användarupplevelse och kundförtroende?

Att lämna över ditt användarnamn och lösenord för banken till en tredjepartsapp kräver en nivå av tillit som många inte är bekväma med. Många bankers egna säkerhetsmeddelanden tränar användare att aldrig dela inloggningsuppgifter utanför bankens egen webbplats, så en skrapningsbaserad app som ber användare att göra exakt det i sitt eget gränssnitt kan betraktas med misstänksamhet. Den obalansen kan skapa tveksamhet vid tidpunkten för kontoanslutningen, vilket avskräcker användare från att slutföra länkningsflödet eller får dem att avbryta det halvvägs när begäran om inloggningsuppgifter känns fel.

OAuth-baserade flöden kringgår det problemet eftersom du bara skriver in ditt lösenord på din banks egen inloggningssida. Det är ett välbekant gränssnitt på en känd domän, och behörighetsskärmen talar om för dig exakt vad du samtycker till att dela. Den specificiteten ändrar psykologin kring samtycke eftersom du får en konkret lista med objekt, som ett kontosaldo och transaktionshistorik för de senaste 90 dagarna, och ombeds att godkänna eller neka den direkt. Följaktligen kan samtyckesflöden byggda på direkt bankautentisering resultera i högre slutförandefrekvenser än uppgiftsbaserad aggregering.

När förtroendet väl har skakats av en dålig upplevelse eller en rubrik om ett intrång hos en skrapningsbaserad aggregator är det svårt att vinna tillbaka tilliten. Företag som bygger finansiella produkter behandlar i allt högre grad själva autentiseringsmetoden som en indikator på trovärdighet snarare än en enkel implementeringsdetalj.

Hur driver tillsynsmyndigheter övergången från skärmskrapning till API:er?

CFPB:s regel för sektion 1033, som för närvarande är pausad efter att en federal domstol utfärdade ett preliminärt föreläggande, syftar till att implementera en del av Dodd-Frank-lagen som kräver att dataleverantörer, som banker, gör kunders finansiella data tillgängliga för tredje part på kundens uppmaning. Regelns avsikt är att ge kunder en lagstadgad rätt till sina egna data i ett användbart, portabelt format. Regeln förespråkar uttryckligen standardiserade, säkra elektroniska överföringsmetoder, vilket i praktiken ofta innebär API:er framför uppgiftsbaserad skrapning.

Många stora finansiella institutioner har redan tillbringat åratal med att bygga dedikerad API-infrastruktur, delvis så att de kan sluta stödja skrapartrafik som drabbar deras kundvända webbplatser. Detta kan belasta serverkapaciteten och skapa komplikationer vid säkerhetsgranskningar. Ramverk för open banking i Storbritannien och EU skapade ett tidigare prejudikat för detta skifte.

Eftersom många mindre institutioner och kreditföreningar fortfarande saknar den API-infrastruktur som större banker redan har byggt, fortsätter vissa aggregatorer med skrapning som ett reservalternativ för konton som ännu inte har något API-alternativ. I takt med att implementeringen av sektion 1033 går framåt och fler banker har kompatibla API-slutpunkter, har dock de företag som bygger finansiella produkter de största anledningarna att agera tidigt – innan skrapningsbaserade anslutningar blir föråldrade.

Så kan Stripe Financial Connections hjälpa dig

Stripe Financial Connections är en uppsättning API:er som gör att du på ett säkert sätt kan ansluta till dina kunders bankkonton och hämta deras finansiella data, vilket gör att du kan bygga innovativa finansiella produkter och tjänster.

Financial Connections kan hjälpa dig att:

• Förenkla onboardingen: Erbjud en smidig, omedelbar verifieringsprocess av bankkonto som inte kräver manuell identitets- och kontoverifiering.

• Få åtkomst till rika finansiella data: Hämta omfattande information om dina kunders bankkonton, inklusive saldon, transaktioner och kontouppgifter.

• Automatisera återkommande betalningar: Gör det möjligt för dina kunder att på ett säkert sätt länka sina bankkonton för återkommande betalningar, vilket förbättrar andelen genomförda betalningar.

• Förbättra riskhanteringen: Analysera kundernas finansiella data för att fatta mer välgrundade beslut om krediter, utlåning och andra finansiella produkter.

• Följ bestämmelserna: Financial Connections hjälper dig att uppfylla kraven på kundkännedom (KYC) och bekämpning av penningtvätt (AML).

• Innovera med tillförsikt: Bygg nya finansiella produkter och tjänster ovanpå den säkra och tillförlitliga Financial Connections-infrastrukturen.

Läs mer om Financial Connections eller börja idag.