Plaid vs. MX vs. Finicity: welke bankdata-aggregator zit er achter je boekhoudfeed?

Je koppelt je zakelijke betaalrekening aan je boekhoudapp en de transacties beginnen automatisch binnen te stromen. Wat je zelden ziet, is het bedrijf ertussenin — de data-aggregator die namens jou inlogt bij je bank, je transacties ophaalt, opschoont en aan je app doorgeeft. Wanneer je feed uitvalt, de helft van je aankopen verkeerd categoriseert of stilletjes een week aan activiteit mist, zit het probleem meestal in die tussenlaag, niet in je app.

Drie bedrijven verwerken het grootste deel van die data in de Verenigde Staten: Plaid, MX en Finicity (sinds 2020 eigendom van Mastercard). Als je een kleine onderneming runt, heb je een van hen gekozen op het moment dat je je boekhoudsoftware koos — en als je bankfeed blijft haperen, vertelt begrijpen waar elke aggregator goed en slecht in is je of het wisselen van app helpt of hetzelfde probleem alleen naar een nieuw scherm verplaatst.

Wat een bankdata-aggregator eigenlijk doet​

Wanneer je in een boekhoudapp op "koppel je bank" klikt, begint een keten van gebeurtenissen:

1. Authenticatie. Je voert je bankgegevens in (of keurt een OAuth-redirect bij je bank goed). De aggregator legt een verbinding aan die aan je rekeningen is gekoppeld.
2. Ophalen. De aggregator haalt saldi en transacties op — idealiter via een directe bank-API, soms door in te loggen op internetbankieren zoals een browser dat zou doen.
3. Verrijking. Ruwe bankomschrijvingen zoals SQ *COFFEE SHOP 000123 worden opgeschoond tot een handelsnaam, een categorie en soms een locatie.
4. Levering. Je boekhoudapp ontvangt genormaliseerde data via de API van de aggregator.

Stappen 2 en 3 zijn waar de drie aanbieders het meest verschillen. Het ophalen bepaalt welke banken verbinden en hoe vaak de feed uitvalt. De verrijking bepaalt of je boekhouding begint met schone categorieën of met een berg "Niet-gecategoriseerd"-transacties die je met de hand moet oplossen.

Waarom dit meer uitmaakt dan vroeger​

Jarenlang verkregen aggregators je data vooral via screen scraping: inloggen op je internetbankieren met je opgeslagen inloggegevens en de pagina's uitlezen. Het werkte, maar het was fragiel — elke herziening van een bankwebsite verbrak verbindingen — en het betekende dat je wachtwoord op andermans servers stond.

De sector migreert al een decennium naar directe, token-gebaseerde API-verbindingen, en regelgeving dwingt de kwestie nu af. De open-banking-regel van het Consumer Financial Protection Bureau onder Section 1033 van de Dodd-Frank Act zou consumenten een formeel recht geven om hun bank opdracht te geven data te delen met geautoriseerde derde partijen via beveiligde interfaces, waarmee screen scraping effectief wordt uitgefaseerd. De oorspronkelijke regel uit 2024 werd door de rechter geblokkeerd en een herzien voorstel ging in augustus 2026 naar herziening door het Witte Huis, dus de definitieve vorm ligt nog niet vast — maar de richting is eenrichtingsverkeer. Directe overeenkomsten tussen banken en aggregators en de Financial Data Exchange (FDX)-standaard zijn al de manier waarop de meeste verbindingen met grote banken werken.

Voor jou als ondernemer heeft deze migratie twee praktische gevolgen. Ten eerste zijn verbindingen met grote banken over het algemeen betrouwbaarder dan vijf jaar geleden, omdat op OAuth gebaseerde API-koppelingen minder vaak breken dan scraping. Ten tweede zijn verbindingen met kleine banken en kredietunies — die het minst waarschijnlijk over moderne API's beschikken — waar feeds nog steeds falen, en precies daar komen de verschillen in dekking tussen aggregators naar voren.

De drie aggregators naast elkaar​

Plaid: de standaard met de breedste ontwikkelaarsvoetafdruk​

Plaid is de naam die je waarschijnlijk hebt gezien — het verbindingsscherm verschijnt in duizenden apps, van budgetteringstools tot betaaldiensten. Het documenteert verbindingen met meer dan 12.000 financiële instellingen en staat bekend om zijn ontwikkelaarservaring: duidelijke documentatie, snelle integratie en de kortste weg van "we hebben bankdata nodig" naar een werkend product.

Die breedte maakt Plaid de veiligste standaardkeuze wanneer je prioriteit simpelweg is zoveel mogelijk verschillende banken te verbinden. Als je zaak bij een ongebruikelijke bank bankiert — een regionale bank, een niche-onlinebank — is Plaid vaak de aggregator die deze al het meest waarschijnlijk ondersteunt.

De afwegingen komen bij schaal naar voren. Analyses van derden schatten de prijs van Plaid op ongeveer $0,50 tot $2,00 per geslaagde verbinding, met volumekortingen bij hogere niveaus — een model dat vriendelijk is voor kleine apps en een echte kostenpost wordt voor grote. En hoewel de verrijking van Plaid degelijk is, wordt die over het algemeen als goed beschouwd in plaats van toonaangevend: handelsnamen en categorieën kloppen meestal, maar bedrijven met rommelige, hoogvolume-transactiestromen vinden dat de categorisering meer handmatige correctie vergt dan die van MX.

MX: de categoriseringsspecialist met wortels in gemeenschapsbanken​

MX is opgegroeid met het direct bedienen van gemeenschapsbanken en kredietunies, en dat erfgoed bepaalt het nog steeds. Het publiceert verbindingscijfers in de orde van 15.000 tot 16.000, met bijzondere sterkte bij kleinere instellingen — precies de lange staart waar Plaid-verbindingen dun kunnen zijn en waar de zakelijke focus van Finicity minder zichtbaar is.

Het opvallendste kenmerk van MX is dataverrijking. De categoriseringsengine wordt algemeen beschouwd als de sterkste van de drie: schonere handelsidentificatie, consistentere categorieën en betere omgang met dubbelzinnige transacties. Als je ooit je boekhoudapp hebt geopend en tientallen transacties in "Overig" of "Niet-gecategoriseerd" hebt zien belanden, heb je de prijs van zwakke verrijking gevoeld — elk daarvan is een minuut van je tijd aan het einde van de maand. De belofte van MX is dat minder van je transacties daar ooit terechtkomen.

De keerzijde is toegang. MX verkoopt voornamelijk via zakelijke contracten gericht op banken en grotere fintechs, dus als eigenaar van een klein bedrijf kies je MX zelden direct — je krijgt het omdat je boekhoud- of bankapp het heeft gekozen. De prijs wordt onderhandeld in plaats van gepubliceerd, wat rechtstreekse kostenvergelijkingen moeilijk maakt. En buiten de Verenigde Staten is de dekking dun.

Finicity: de verificatiekrachtpatser van Mastercard​

Finicity, in 2020 overgenomen door Mastercard, dekt een vergelijkbaar aantal van meer dan 15.000 instellingen en heeft de sterkste positie in leen- en verificatieworkflows. De gestructureerde output voor inkomens- en vermogensverificatie sluit direct aan op hypotheek- en acceptatieprocessen, waar acceptatie door Fannie Mae en Freddie Mac echt gewicht in de schaal legt. Als je onlangs een zakelijke lening of hypotheek hebt aangevraagd en werd gevraagd je rekeningen "digitaal te verifiëren" in plaats van afschriften te uploaden, is de kans groot dat Finicity die data heeft verwerkt.

Met de steun van Mastercard heeft Finicity ook de diepste bank aan directe datauitwisselingsovereenkomsten met grote banken, wat de verbindingen met grote banken doorgaans stabiel maakt. Net als MX verkoopt het via onderhandelde zakelijke deals, en net als MX is het in de eerste plaats een Amerikaans verhaal.

Waar Finicity minder onderscheidend is, is algemene transactieverrijking voor het dagelijkse boekhouden. Het is bekwaam, maar het is niet de reden waarom iemand Finicity kiest — je kiest Finicity voor verificatie-intensieve workflows, en de boekhoudfeed komt er als vanzelf bij.

De eerlijke vergelijkingstabel​

Behandel elk instellingenaantal met scepsis: elke aanbieder telt "verbindingen" en "databronnen" anders, en geen enkel totaal zegt iets over de vraag of jouw bank betrouwbaar verbindt. De enige dekkingsvraag die ertoe doet is de jouwe — zoek de naam van je bank plus de naam van je app voordat je je vastlegt, en controleer recente meldingen, want verbindingen veranderen.

Betrouwbaarheid: waarom je feed uitvalt (en wiens schuld dat is)​

Storingen in bankfeeds vallen in drie categorieën, en slechts één daarvan is de schuld van je app:

1. Verbinding verbroken. Je bank wijzigt zijn inlogflow, voegt meerstaps-verificatie toe of roteert zijn API, en de koppeling van de aggregator breekt. Je krijgt de melding "koppel je bank opnieuw". Op OAuth gebaseerde API-verbindingen breken veel minder vaak dan verbindingen op basis van inloggegevens, wat de reden is dat feeds bij grote banken stilletjes beter zijn geworden.
2. Ontbrekende of gedupliceerde transacties. De verbinding werkt, maar de data is fout: openstaande kosten die nooit worden afgewikkeld als geboekte transacties, een weekend aan activiteit dat nooit aankomt, of dezelfde uitbetaling twee keer geïmporteerd. Dit is een ophaalprobleem van de aggregator, en het is het moeilijkst te signaleren — er treedt geen fout op, je boeken zijn gewoon fout.
3. Slechte categorisering. De transacties komen aan, maar belanden op de verkeerde rekeningen. Dit is een verrijkingsprobleem, en hier is de voorsprong van MX het meest zichtbaar in dagelijks gebruik.

Wanneer gebruikers klagen dat een app "de verbinding met mijn bank niet kan vasthouden", ligt de onderliggende oorzaak meestal in categorie 1 op het niveau van de aggregator — wat de reden is dat sommige apps je nu in hun instellingen voor dezelfde bank van aggregator laten wisselen. Als je app Plaid, MX en Finicity als uitwisselbare aanbieders voor één verbinding aanbiedt, probeer dan een andere voordat je de app de schuld geeft. Een andere aggregator kan echt een betere verbinding met jouw instelling hebben.

Prijs: wat je betaalt zonder een factuur te zien​

Bijna geen enkel klein bedrijf betaalt rechtstreeks aan een aggregator. De kosten komen verpakt in het abonnement van je boekhoudsoftware — wat de reden is dat "welke aggregator is het goedkoopst" voor jou de verkeerde vraag is. De juiste vraag is welk gedrag het prijsmodel je leverancier aanmoedigt.

Prijs per verbinding (het publieke model van Plaid) rekent je app-leverancier telkens wanneer een verbinding tot stand wordt gebracht of vernieuwd, dus leveranciers met dit model hebben een stille prikkel om feeds minder vaak te verversen of te beperken hoeveel rekeningen je op goedkope plannen kunt koppelen. Zakelijke contracten (de wereld van MX en Finicity) bundelen platformkosten met gebruik, wat leveranciers doorgaans eerder naar hogere abonnementsniveaus duwt dan naar limieten per rekening.

Hoe dan ook, je betaalt. Wat verschilt, is waar de kosten opduiken: verbindingslimieten en verversingsfrequentie aan de ene kant, hogere basisprijzen aan de andere. Bij het vergelijken van boekhoudplannen is "hoeveel bankrekeningen kan ik koppelen, en hoe vaak wordt de feed ververst" een nuttigere vraag dan "welke aggregator gebruiken jullie" — maar nu weet je waarom de antwoorden verschillen.

Wat dit betekent voor je boeken​

Hier is de ongemakkelijke waarheid over geautomatiseerde feeds: het is een importpijplijn, geen boekhouder. Elke transactie vereist nog steeds een tweede blik voordat die deel wordt van je financiële administratie, omdat de hierboven beschreven faalmodi stil zijn. Een feed die je privéopnames categoriseert als zakelijke maaltijden geeft geen foutmelding — die overschat gewoon stilletjes je aftrekposten tot iemand het merkt.

De praktische routine is een wekelijkse controle, geen maandelijkse haastklus:

• Scan eerst niet-gecategoriseerde en onzekere items. De meeste apps markeren waar de aggregator onzeker over was. Werk deze wekelijks bij terwijl de aankopen nog vers in je geheugen zitten.
• Reconcilieer tegen het banksaldo, niet tegen de feed. Je maandelijkse controle is "komt mijn grootboek overeen met het afschrift", nooit "heeft de feed alles geïmporteerd". Het afschrift is de autoriteit; de feed is een gemak.
• Let op duplicaten rond herverbindingen. Controleer telkens wanneer je een bank opnieuw koppelt het overlapvenster. Opnieuw verbonden feeds zijn de nummer één bron van dubbel getelde transacties.

Als je je boeken in platte tekst bijhoudt, geldt dezelfde discipline — de feedoutput wordt conceptboekingen die je beoordeelt, geen waarheid die je aanvaardt. Een gesynchroniseerde uitbetaling met kosten moet bijvoorbeeld in je grootboek belanden als zijn componenten, niet als de netto storting:

2026-10-15 * "Shopify payout #4821" "Oct 12-14 sales, fees split out"
  Assets:Checking:Business                            1,842.36 USD
  Expenses:Fees:Payment-Processing                      58.14 USD
  Income:Sales                                          -1,900.50 USD

De bruto verkoop en de kosten apart vastleggen — in plaats van de netto storting als omzet te boeken — is wat je omzetcijfers eerlijk houdt en je kostenpost zichtbaar maakt bij de belastingaangifte. Wat je software ook is, sta erop dat de feed je genoeg detail geeft om bruto van kosten te scheiden; een feed die alleen netto stortingen importeert, verbergt informatie die je belastingaangifte nodig heeft. De Beancount-documentatie behandelt de structuur van boekingen in detail, en met Fava kun je geïmporteerde boekingen eenvoudig beoordelen voordat ze in je boeken belanden.

Hoe te kiezen (of te beoordelen wat je al hebt)​

Je zult waarschijnlijk niet rechtstreeks een aggregator kiezen — je kiest boekhoudsoftware, en de aggregator komt mee. Vertaal de vergelijking dus naar aankoopvragen:

• Waar bankier je? Bij een top-20-bank verbinden alle drie goed; kies op verrijking en app-functies. Bij een kleine bank of kredietunie, vraag de leverancier welke aggregator jouw instelling bedient en hoe de verbinding authenticeert (OAuth verslaat opgeslagen inloggegevens).
• Hoe rommelig zijn je transacties? Hoog volume, veel vergelijkbare leveranciers, veel contante uitgaven — kwaliteit van verrijking weegt zwaarder, wat apps op basis van MX bevoordeelt.
• Leen je? Als je workflow leningaanvragen en inkomensverificatie omvat, kan een Finicity-gebaseerd traject die stap soepeler maken.
• Kun je binnen de app van aanbieder wisselen? Ondersteuning voor meerdere aggregators met een schakelaar per verbinding is de beste betrouwbaarheidsfunctie die een app kan bieden. Vraag er expliciet naar.

En houd één oog op de open-banking-regelgeving. Welke definitieve vorm Section 1033 ook aanneemt, gestandaardiseerde bank-API's zullen fragiele verbindingen op basis van inloggegevens blijven vervangen — wat betekent dat de dekkingskloof tussen grote en kleine instellingen het punt is om in de gaten te houden. Je feed wordt eerst bij grote banken betrouwbaarder. Bankier je klein, dan is de aggregator met de diepste wortels in gemeenschapsbanken nog steeds degene die je verbinding het meest waarschijnlijk in leven houdt.