Fintech Integration: What Banks Won't Tell You
Building software that integrates with banks sounds straightforward until you try it. The technical challenges are real, but the bigger obstacles are political, regulatory, and institutional. Here's what you're actually signing up for.
The Integration Landscape
Bank integrations fall into three categories, each with different tradeoffs:
| Method | Speed | Reliability | Bank Cooperation |
|---|---|---|---|
| Screen scraping | Fast | Fragile | Not required (often hostile) |
| Aggregator APIs (Plaid, etc.) | Medium | Good | Indirect |
| Direct bank APIs | Slow | Best | Required |
Screen Scraping Is Dying
Screen scraping—logging in as the user and parsing HTML—was how fintech started. It's fast to implement and requires no bank cooperation. It's also increasingly problematic.
Banks actively break scrapers through UI changes. Two-factor authentication creates friction. Security teams view credential sharing as a liability. Regulatory pressure is mounting against the practice. If you're building on screen scraping today, you're building on sand.
Aggregator APIs: The Middle Ground
Companies like Plaid, Yodlee, and MX have built the infrastructure to connect with thousands of financial institutions. For most fintechs, this is the right starting point.
Aggregators are also middlemen. You're dependent on their roadmap, their pricing decisions, and their relationships with banks. If a major bank decides to restrict aggregator access, you're affected even though you have no direct relationship.
Direct Integration: The Long Game
Large fintechs eventually build direct bank relationships. This provides better reliability, richer data, and independence from aggregator pricing. It's also enormously expensive and time-consuming.
Each bank integration requires separate negotiation, legal review, technical implementation, and ongoing maintenance. The largest banks might have API programs; smaller ones might require custom solutions or partnerships through their core banking providers.
Most companies use a hybrid approach: aggregators for broad coverage, direct integrations for high-volume relationships where the investment is justified.
What Banks Actually Care About
When you approach banks about integration, they're evaluating:
Risk: What happens if your security is compromised? Will it reflect badly on them? Their legal and compliance teams will scrutinize your security practices, data handling, and liability exposure.
Customer experience: Will your product create support calls to the bank? Will customers blame the bank for issues that are actually your fault?
Competitive threat: Are you building something that could disintermediate them? Banks are increasingly wary of fintechs that might capture customer relationships.
Revenue: For larger integrations, banks expect to be paid. Either directly through partnership fees or indirectly through customer acquisition or retention benefits.
Regulatory Reality
Open banking regulations (PSD2 in Europe, evolving frameworks elsewhere) are slowly forcing banks to provide API access. This is good for fintechs long-term but messy in implementation. Banks are complying with the letter of regulations while making access as difficult as possible within the rules.
Don't assume regulatory mandate means easy access. Each jurisdiction has different requirements, and bank compliance varies from genuine partnership to hostile minimum compliance.
Practical Advice
Start with aggregators. Accept their limitations. Build your product assuming bank data will sometimes be delayed, incomplete, or unavailable. Design graceful degradation.
As you scale, identify which bank relationships justify direct investment. Usually these are banks where you have significant customer concentration and where aggregator limitations are causing real problems.
Bank integration is infrastructure, not product. It's necessary but not differentiating. Spend the minimum resources required for your current needs, knowing you'll need to revisit as you grow.