Every serious API publishes an uptime number. Almost none publishes a time-to-first-successful-call number, and in our integration work, the second predicts what gets built far better than the first.
Reliability and easiness are different properties. Reliability is contractual: SLAs, status pages, five nines, monitored to the decimal. Easiness has no unit, so it has no dashboard, so it has no owner. It shows up only indirectly: in how many integrations exist against an interface, and how many were quietly abandoned halfway.
Banking makes the contrast unusually visible, because banks sit at one extreme: reliability is exceptional, and easiness is treated as a risk to be minimized.
What "hard" looks like in practice
The pattern repeats across Swiss projects:
- the API exists, technically; reaching it means a partner agreement or an EBICS contract no five-person firm is going to negotiate
- the data arrives as ISO 20022 camt files (a solid standard that still assumes a banking engineer on the receiving end)
- the documentation reads like it was written for a review board, not for someone trying to ship
- sandbox access takes weeks, when it exists at all
None of this makes the interface unreliable: once connected, these systems run for years without incident. But "reliable once connected" hides the real filter: who gets to connect at all, and what it costs them to try.
The cost of hard access rarely shows up as a failed project. It shows up as projects never started. A funded team with a quarter of runway gets through EBICS onboarding; the bookkeeper who wanted to stop retyping Friday's transactions into Bexio does not. Multiply that second case across an economy of small firms and the invisible loss is probably larger than anything an outage ever caused.
The counterexample
PostFinance is worth naming because it leans the other way: published APIs, documentation readable by someone who has never worked inside a bank, ISO 20022 handled cleanly, account information reachable for business customers without an enterprise-only agreement. The interface is treated as a product with users.
The immediate effect is mundane: integrations get built faster. The second-order effect is the interesting one: when access is easy, a different population starts building. Not just licensed fintechs with integration teams, but fiduciaires, property managers, small software shops solving one local problem. The interface didn't get more reliable; it got more reachable, and the ecosystem around it changed shape.
Uptime metrics never show that part. Reliability decides whether existing integrations keep working. Easiness decides how many integrations come to exist.
Easiness is an engineering property, not a vibe
It's tempting to file "easy" under developer experience and move on. In practice it decomposes into concrete, testable requirements:
- auth a small team can complete: self-service OAuth2, not a contract negotiation
- a sandbox reachable the same day (the gap between "read the docs" and "see real data" is where most integration attempts die)
- errors that explain themselves: a 400 with a reason is documentation; a 400 without one is a support ticket
- formats with an escape hatch: full ISO 20022 for those who need it, a sane JSON view for those who don't
Each of these can be specified, built, and reviewed like any other requirement. Banks that gate easiness are assuming the only safe integrator is a large one; the track record of large integrators suggests otherwise.
The layer that turns access into use
An open, easy API still leaves a gap. Most firms that would benefit from bank data will never write an OAuth flow or a camt parser, and shouldn't have to. What they need is the layer between the API and their actual process: fetch movements since Friday, classify, post to the accounting system, flag the rest for a human. Platforms in the Process Execution Layer category (flow8 among them) exist to be that layer, which is also why they benefit disproportionately from banks that choose easy access: every reachable interface becomes a step a non-engineer can put into a process.
The order matters: reliable data, easy access, then an execution layer. Remove the first and nothing can be trusted. Remove the third and only engineers benefit. Remove the middle one and the whole thing exists only on paper.
A simple tell
One habit we picked up: open a provider's status page and its quickstart side by side, and see which one was maintained with care. In banking it's almost always the status page (polished, historical, proud of its nines), while the quickstart was last touched two reorganizations ago. That ratio usually says more about what will get built on top than any SLA does.
Curious how others read a data provider before committing to an integration: what's your version of this check?