Trust center
Security at BankConnector
We send payment instructions to banks for the companies we serve. We never hold or move money ourselves. This page sets out how we protect those instructions and the bank data that comes back.
Controls
How we protect your payments
Product security
Payment approvals
- Approval rules can depend on the amount, need several approvers, or require them in a fixed order. A company can bar anyone from approving a payment they created.
- Weakening an approval rule needs a second admin to co-sign it, and lifting the ban on self-approval alerts every other admin.
- Approvers approve exactly what is sent: a payment cannot be edited once submitted, and a payment file submitted twice is flagged as a possible double payment.
- Signed payment files go straight to the bank. We never hand a signed file back to the caller.
Your team's controls
- Admins can require two-factor authentication for everyone in the company, and approvers who use it enter a fresh code to approve.
- Three roles: admin, approver and a strictly read-only viewer.
- Sign-in checks against common and breached passwords, throttles repeated attempts, and ends sessions after 30 minutes idle or 8 hours in total. Users see and end their own sessions, and are emailed when their password or two-factor setting changes or after suspicious sign-in attempts.
- Your activity log can be pulled into your own monitoring through the API.
Encryption
- All traffic is encrypted with TLS 1.2 or later, including the connection between the application and its database.
- Disks, the database and backups are encrypted at rest. Payment content, bank credentials, signing keys and approver identity data are also encrypted field by field with AES-256-GCM before they reach the database.
Keeping customers apart
- Every request is tied to the company of the person or system making it, never to an identifier in the request itself.
- The database enforces the same separation with row-level security, so a query without a company scope returns nothing.
Audit trail
- Every change is written to a log that the database refuses to edit or delete. Each entry is chained to the one before it, so a changed, removed or reordered entry shows up when the chain is checked.
- Customers can run that check themselves from the activity log.
Bank connections
- Each bank connection uses the signing and encryption that bank requires: EBICS, web services or SFTP.
- Bank certificates and server keys are pinned. If what the bank presents does not match, the connection stops. Bank signing keys cannot be exported from the platform.
Infrastructure and operations
Hosting
- Production runs on Amazon Web Services in Stockholm, Sweden, and customer data is stored there.
- Physical security is provided by AWS, whose SOC 2 Type II report we have reviewed.
- The cloud environment is defined as code, so it can be rebuilt automatically from that code.
Network and administrative access
- Only web traffic reaches the server from the internet. The database cannot be reached from the internet and accepts connections from the application server alone.
- Staff reach the cloud account only through single sign-on with multi-factor authentication and sessions of four hours or less.
- Every administrative action in the cloud account is recorded in a tamper-evident log.
Access management
- Least privilege and one identity per person. Shared accounts are not allowed.
- Multi-factor sign-in is enforced on our cloud account, our code host, our password manager and the consoles of the vendors that run our service.
- Every machine credential is registered with its owner and the date it is next due for rotation.
Monitoring
- Automated threat detection on the cloud account, with findings of medium severity and above sent to a person.
- Alerts on server health, database load, failed backups and bursts of application errors.
- Availability is checked every minute from outside our own servers and published on our status page.
Backups and recovery
- The database can be restored to any point in the last 14 days. Encrypted copies with an integrity check are also taken every hour and kept for 90 days.
- Our targets are at most 15 minutes of lost data and service back within 2 hours. In our last full restore test, data was back in about 10 minutes.
- Restoring the hourly backups is drilled every month.
- Our continuity plan covers losing the database, the server, the AWS region, a key vendor or a key person.
Not tied to one cloud
- The platform runs on standard containers, PostgreSQL and S3-compatible storage, with no AWS-only service in its core.
- Our sandbox already runs the same application on a second provider.
Engineering
Change management
- No change reaches production without passing our release gate: type checks, linting, database-migration checks, more than 30,000 automated tests, secret scanning, bank regression tests and a boot test of the built application.
- Infrastructure changes are applied by a person from a reviewed plan. Releases are immutable, tagged versions, and production is deployed only from a tag.
Vulnerability management
- Dependencies are audited on every change, and a high-severity finding fails the build. Dependency updates are raised automatically, and every push is scanned for leaked secrets.
- Our cloud setup, public endpoints and code are scanned with open-source security scanners: Prowler, nuclei and Opengrep.
- We keep a threat model and a control-by-control assessment against OWASP ASVS Levels 2 and 3, checked automatically.
- Fix deadlines by severity: critical within 7 days, high within 30, medium within 90.
Governance, risk and incidents
Governance
- Our COO is accountable for the security programme. Our CTO runs the technical controls and leads incident response.
- Management reviews security every quarter: controls, open findings, risks, incidents and vendor changes.
- Access to every system is reviewed every quarter.
- Everyone with access completes security training and signs our security acknowledgement at onboarding and every year.
- A weekly compliance check flags every review, credential rotation and test as it falls due.
Risk and vendors
- A full risk assessment every year and after any significant change. It covers fraud as well as security: an altered payment, an added beneficiary, a bypassed approval or a misused bank credential.
- Every vendor is recorded with the data it sees and how critical it is, and is reviewed every year, including its security reports.
- Our security policies are reviewed every year and after any significant change or incident.
Incident response
- Incidents are graded by severity. For a critical incident we respond within 2 business hours and update you every 4 business hours, as our SLA sets out.
- If a personal-data breach affects your data, we tell you within 48 hours of becoming aware of it. Where a bank credential is involved, the bank is told at once.
- Every serious incident gets a written review within five business days, and we rehearse our response every year.
Privacy and retention
- We act as your data processor under a GDPR Data Processing Agreement, and we notify you at least 14 days before adding a sub-processor.
- Payment and statement records leave the live database after 90 days, and raw statement files after 30. Archive copies are deleted within six months of creation. The audit trail is kept for 5 years. At the end of a contract, customer data is erased under the agreement.
- Approver national ID numbers are encrypted, masked on screen and never written to logs.
Live availability is on our status page.
Reliability
When something is down
We measure our uptime once a minute from outside our own servers and publish it on our status page. Here is what happens to your payments when BankConnector or a bank is down.
If BankConnector is down
- Your payments stay in the payment journal in your ERP. Nothing is lost.
- A payment that got no answer is marked as such on its line. Send it again when we are back: BankConnector recognises the payment and answers with the first result, so it is never paid twice.
- A payment that never reached us can simply be sent again.
- If a payment cannot wait, you can always pay it in your bank's online banking instead, and then remove the line from the journal. If you had already sent it from the journal, contact our support first, because it may still be paid when we are back.
If a bank is down
- BankConnector tries again by itself several times over the next few minutes, as long as it is certain that the payment did not reach the bank.
- If the bank is still down after that, the payment is marked as not delivered and nothing is paid. Your journal says so, and you can send the payment again from your ERP.
- If the connection breaks after the payment may have reached the bank, it is never sent again automatically. It is held, and we are alerted to check it.
- BankConnector fetches statements from the bank throughout the day. If the bank does not answer, it keeps trying, and if the last bank day's statement is missing at 10:00 when one is expected (the bank has sent an empty one before, or money moved), an alert shows in BankConnector and goes to your webhooks; by email, if you switch that on.
- Downtime at the bank itself is outside our control, so our SLA does not cover it.
Support
- Support is given in Danish and English.
- By email to support@bankconnector.com, on business days from 09:00 to 17:00 Danish time, except Danish public holidays.
- A critical incident, with production down, can also be reported outside those hours to urgent@bankconnector.com. We answer it as fast as we can.
- The first answer comes within 2 business hours for a critical incident and within 4 for a severe one, as our SLA sets out.
For security reviewers
Technical detail
The specifics behind the controls above.
Authentication
Passwords are hashed with scrypt, compared in constant time and checked against a list of common and breached passwords. Two-factor authentication is TOTP; a used code cannot be replayed inside its window, and the ten backup codes are single use and hashed at rest. API keys carry 256 bits of entropy and are stored only as a hash. Login throttling applies per identity and per source address, and the counters are shared across instances.
Sessions
Sessions are opaque server-side tokens, hashed at rest, sent in an HttpOnly, Secure, SameSite=Strict cookie. A session ends after 30 minutes of inactivity or 8 hours in total, whichever comes first. Users can see and revoke their sessions, administrators can end a user's sessions, and turning two-factor on or off ends all other sessions. Sensitive changes ask for a fresh two-factor code.
Tenant isolation
The tenant scope comes from the authenticated caller and is checked against the request. PostgreSQL row-level security runs in FORCE mode on every tenant table, so it binds the table owner too. Inside a company, roles are an allow-list: a new route that changes data is closed to read-only users until it is explicitly opened.
Encryption at rest
Field encryption is AES-256-GCM in the application. Each ciphertext is bound to its table, column, tenant and row, so a copied value cannot be decrypted somewhere else. Ciphertexts carry a key identifier so data keeps decrypting through a key rotation, and an unknown identifier is an error. The audit-signing key is separate from the field-encryption key.
Encryption in transit
The server will not start if the database connection is unencrypted or does not verify the certificate. Outbound calls to banks and webhook endpoints are HTTPS only, verify the certificate, connect to the address that was checked, follow no redirects and cap the response size.
Bank channel cryptography
Web-service channels sign and encrypt with RSA-SHA256, and inbound signatures are checked against a pinned certificate. EBICS uses XML signatures with checks against signature wrapping. SFTP encrypts files to the bank's pinned key and verifies the server's host key. Where a bank publishes its EBICS key fingerprints, we check them and refuse a mismatch; otherwise we record the bank's key on first contact and pin it from then on. Pinned certificates warn before they expire.
Outbound requests
Every outbound address is checked against an allow-list and refused if it resolves to a loopback, private, link-local or cloud-metadata address, including disguised IP formats. The connection is pinned to the checked address to defeat DNS rebinding. Webhook destinations are checked again at delivery.
Files and XML
Uploads have type and size limits, compressed files are checked for decompression bombs, and file names are checked for path traversal. Every XML parser refuses a DOCTYPE, which blocks external-entity and entity-expansion attacks before parsing starts. Database access is parameterised and request bodies are validated against strict schemas.
Web hardening
Responses carry a Content-Security-Policy, frame-ancestors none, nosniff, a referrer policy, cross-origin isolation headers and HSTS with preload. Cookies are Secure, HttpOnly and SameSite=Strict, and CSRF tokens are bound to the session. Duplicate request parameters are rejected.
Audit log
The journal is append-only, enforced by a database trigger that also binds the table owner. Entries are HMAC-chained per company with a key held outside the database, so write access to the database is not enough to rewrite the chain.
Production configuration
Production refuses to start with development keys, without authentication, without verified database TLS or with a database role that could bypass row-level security. Production connections cannot point at bank test endpoints. Debug output is off and monitoring endpoints need a token. Logs are scrubbed of secrets and account numbers by field name and by pattern.
Software supply chain
A CycloneDX software bill of materials is produced by our scheduled and release CI runs. Dependencies are audited against the committed lockfile on every pull request and push, and a high-severity finding blocks the build. Third-party CI actions are pinned to commit hashes. Each push is scanned for committed secrets. Releases are immutable tags and the tag is what gets deployed.
Documents
Read or request the documents
Public
- Read →Security PolicyVersion 1.2, 9 October 2026. Part of our customer agreement
- Read →Data Processing AgreementVersion 1.1, 7 October 2026. Sub-processors in Annex III
- Read →SLA and Support PolicyVersion 1.2, 20 October 2026
- Read →Privacy PolicyVersion 1.5, 20 October 2026
On request, under confidentiality
- Request by email →Information security policiesAccess, change, incident response, continuity, vendor and risk management
- Request by email →Security assessment summaryOur self-assessment against OWASP ASVS v5 Levels 2 and 3
All our contracts and policies are on the legal page. AWS's own SOC 2 and ISO reports are available to its customers through AWS Artifact.
Responsible disclosure
Found a vulnerability?
Email security@bankconnector.com with what you found and how to reproduce it. We confirm receipt within two business days and keep you informed until it is fixed.
Please test only against our public sandbox, do not access or change other people's data, and give us reasonable time to fix the issue before you publish it. We will not take legal action against research done in good faith under these terms.