Open Banking vs Host-to-Host: which bank connectivity method does your business need?

Open Banking is a regulatory framework introduced by the EU's Payment Services Directive 2 (PSD2) that requires banks to open their APIs to licensed third-party providers. It was designed to increase competition in financial services and give consumers more control over their financial data.

In practice, Open Banking lets applications connect to a bank account using OAuth2-based authentication and make payments or retrieve account data through a standardised API. For consumer apps, budget trackers, payment initiation for e-commerce, accounting tools for freelancers, it works well.

The limitations become apparent quickly when you try to use it for corporate payment operations.

Host-to-Host is a direct, bank-approved connection between your company's systems and your bank's infrastructure. Instead of going through a consumer API layer, your ERP or treasury system communicates directly with the bank using encrypted file transfers authenticated by permanent cryptographic keys.

H2H has been the standard for corporate banking connectivity for decades. It underpins how large companies run daily payment batches, payroll, supplier payments, and direct debits at scale, without human intervention, without re-authentication windows, and without the constraints that come with consumer-grade APIs.

It is also the connectivity layer that ISO 20022 payment files are built for.

The single biggest practical problem with Open Banking for corporate use is the Strong Customer Authentication (SCA) requirement under PSD2. Every 90 days, a human being must re-authenticate the connection, typically through a bank app or SMS code.

For a consumer checking their balance, that is a minor inconvenience. For an automated ERP payment run that executes at 11pm every night, it is a potential point of failure that breaks the entire workflow without warning.

There is no workaround for this within PSD2. It is a regulatory requirement, not a bank policy. If your payment automation needs to run unattended, and it does, Open Banking is the wrong foundation.

Most corporate payment policies require dual authorisation. No single person can approve a payment above a certain threshold without a second signatory. This is both a compliance requirement and basic fraud prevention.

Host-to-Host supports this natively through VEU (Verteilte Elektronische Unterschrift) and equivalent dual-control mechanisms built directly into the protocol. The bank verifies both authorisations before processing.

Open Banking has no equivalent. The PSD2 spec does not include a native four-eyes mechanism. Any dual-approval workflow has to be bolted on externally, and even then the bank has no visibility into it.

Choose Open Banking if you are building a consumer-facing app, need to retrieve account transaction data for reconciliation purposes, or are initiating low-volume single payments on behalf of individual users.

Choose Host-to-Host if your business runs automated payment batches, processes payroll or supplier payments through an ERP, requires dual authorisation on payment instructions, or simply cannot afford a connectivity disruption to your payment operations.

For most mid-market companies running Dynamics 365, SAP, or Business Central, the answer is H2H. The setup requires a one-time bank agreement and key exchange, but once established, the connection is permanent, uninterrupted, and built to handle whatever volume your business requires.

BankConnector is a bank connectivity layer built specifically for ERP systems. It manages the H2H connection to your bank, handles ISO 20022 payment file generation, and returns status confirmations and account statements directly to your ERP, without your finance team touching a file or logging into a bank portal.

Supported banks span Denmark, Germany, the Netherlands, Sweden, Norway, and the UK. Setup is handled as part of onboarding.