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 payroll runs Sunday night, you find out on Monday morning when employees 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 payroll 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 mid-market 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 earns its keep where the use case matches its design: account information for reconciliation, balance checks, low-volume single payments initiated by a person, or consumer-facing flows where the user is in the loop on every action.

Some treasury teams use Open Banking for read-only account aggregation across smaller bank relationships while keeping H2H for the banks that handle the actual payment volume. That split makes sense. What doesn't make sense is using Open Banking as the primary rail for unattended ERP payment runs.

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. No 90-day re-auth. No bank portals. No reinventing four-eyes in middleware.