Bankfeed uses PSD2/Open Banking APIs and does not require users to share online-banking credentials.
The connection is protected by several technical controls:
1. Strong Customer Authentication (SCA) – the user authenticates directly with the bank using PSD2-compliant multi-factor authentication. Bankfeed does not receive passwords, PINs or authentication codes.
2. Explicit AIS consent – access is granted only for Account Information Services (AIS) and only for the accounts and data covered by the user’s consent. This is read-oriented account-data access, not unrestricted online-banking access or payment authority.
3. Token-based authorization – Open Banking APIs commonly use OAuth 2.0 Authorization Code Grant or equivalent delegated-authorisation mechanisms. After successful authentication and consent, API access is performed using short-lived access tokens and, where supported, refresh tokens, instead of reusable banking credentials.
4. Scoped and revocable access – token permissions are constrained by the bank-side consent, requested scopes and validity period. Consent can expire or be revoked without changing the customer’s banking credentials.
Encrypted and authenticated API communication – PSD2 requires encrypted communication and identification of regulated parties using eIDAS certificates. Implementations commonly use TLS/mTLS, including QWAC/QSealC-based identification.
5. Business Central security boundary – Bankfeed runs inside the customer’s own Microsoft Dynamics 365 Business Central environment. Business Central provides tenant isolation, encryption at rest using TDE, encrypted network traffic, Microsoft Entra ID authentication and granular permission controls.
Bankfeed therefore does not receive the customer’s bank login. The security model is:
SCA → explicit consent → scoped token → encrypted Open Banking API → customer’s Business Central environment.
This limits both the scope and lifetime of access and allows the customer to revoke the connection at any time.