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 business banking connectivity for decades. It is how the most demanding finance teams run daily payment batches, supplier payments and direct debits, 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 full explanation, with the abbreviation and how the files move: What is Host-to-Host (H2H) in banking?

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.

Open Banking was made for consumer-facing apps and for low-volume single payments started on behalf of individual users.

Host-to-Host is the choice for every business that runs automated payment batches, pays suppliers from an ERP, requires dual authorisation on payment instructions, or simply cannot afford a connectivity disruption to its payment operations.

For companies running Dynamics 365, SAP or Business Central, the answer is H2H. The setup takes a one-time bank agreement and key exchange, and from then on the connection is permanent and handles 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.