Why Open Banking isn't built for ERP payment automation.

PSD2, the regulation that created Open Banking, was a consumer protection measure. Its goal was to break the banks' grip on consumer financial data so that third-party apps could offer budgeting tools, payment initiation for checkout, and account aggregation for individuals.

That origin story is still baked into the spec. The authentication model, the scope of available payment types, and the API rate limits all assume a person is behind the request. For a B2C fintech, that is the right assumption. For an ERP payment batch, it is the wrong one.

Under PSD2, Strong Customer Authentication (SCA) requires a human re-authentication at least every 90 days. There is no exception for corporate use, and no "permanent consent" model. Every quarter, someone has to physically approve the connection again, usually via a bank app on a phone.

For an unattended nightly payment run, that is a guaranteed point of failure. If the re-auth lapses on a Friday evening and the next payment run is Sunday night, you find out on Monday morning when suppliers haven't been paid. There is no way to engineer around this; it is a regulatory requirement.

Corporate payment policy almost always requires dual authorisation above a threshold. PSD2 has no native mechanism for this. The standard assumes a single authenticated user submitting a payment.

Any four-eyes workflow on top of Open Banking has to be implemented outside the bank, in middleware or in the ERP, with no visibility from the bank that a second approval actually happened. From a fraud and audit perspective, that is materially weaker than what corporate treasury teams have had through Host-to-Host for decades, where the bank itself enforces dual control.

Open Banking APIs typically support single SEPA Credit Transfers. Bulk payment files, the bread and butter of corporate operations, are not part of the spec. That means a 500-line supplier payment run becomes 500 API calls, each subject to rate limits, retries, and partial failure handling.

International payments, direct debit mandates, and instant payments are either inconsistently supported across banks or absent entirely. The format mapping that ISO 20022 solves at the file level has to be re-invented per bank API, with no standard to lean on.

Every bank implements PSD2 differently. Rate limits, endpoint shapes, error semantics, and the set of supported payment types vary bank by bank. A working integration with one bank tells you almost nothing about how it will look with the next.

For consumer apps that integrate with one or two banks, this is manageable. For a company running ten bank relationships across five countries, the per-bank engineering work compounds quickly, and the bank's API SLA becomes a load-bearing assumption for your payment operations.

Open Banking matches its design in consumer-facing flows: balance checks, account information in a budgeting app, and single payments a person starts and confirms on every action.

Some treasury teams split the two: Open Banking to read accounts at a few banks, H2H for the banks that carry the payments. That leaves a consent to renew every 90 days at each of those banks, and two kinds of connection to keep running. One H2H connection per bank keeps payments, statements and approvals in one place, with nothing to renew.

The shortlist is short: permanent authentication that doesn't break unattended runs, native four-eyes approval enforced at the bank, support for bulk ISO 20022 files, consistent behaviour across every bank the company uses, and statements and confirmations that come back into the ERP without anyone downloading a file.

Host-to-Host delivers all of those. Open Banking, by design, does not.

BankConnector is a Host-to-Host connectivity layer built for ERP systems. It manages the H2H connection to your bank, handles ISO 20022 payment file generation, and returns status confirmations and statements directly into your ERP. There is no 90-day re-auth, no bank portal and no four-eyes logic rebuilt in middleware.