Service Description
Version 1.1, 7 October 2026. The previous version is available at service-description-2026-07-08. This document forms part of the Agreement and describes the Services in general terms. The current list of supported banks, countries, payment types and channels is available in the product and in the Documentation at bankconnector.com/docs.
1Outbound payments
- Canonical input: you submit payment instructions in one bank-neutral JSON format (the canonical format, specified in the Documentation), via the API or the web portal. Amounts are given as exact decimal values, and totals are calculated without rounding errors.
- Three-level validation: every instruction is validated against (1) generic rules that apply to any payment, (2) the chosen bank's specific rules, and (3) rules for the declared payment type. Validation reports all issues in a single response, each with a stable machine-readable code, the field path, and a plain-language message.
- Conversion: valid instructions are converted to the target bank's ISO 20022 payment-file format (pain.001), following that bank's implementation guidelines; generated files are validated against the official ISO 20022 schemas.
- Approval: release requires approval under your configured approval policy (single, dual, or customised: amount limits, separation of duties, ordered tiers). Approval policies are versioned; changes are subject to the controls described in the Documentation.
- Delivery: approved files are delivered by us directly to the bank over your active bank connection. Signed payment files are not returned to you or any third party, unless the Documentation describes otherwise.
- Duplicate protection: idempotency keys guard against double submission (retention: 24 hours).
2Bank connectivity channels
Connections are established per company, per bank, under your own bank agreement, in test or production environment (a bank may have both). Supported channel families:
| Family | Description |
|---|---|
| SFTP (+ PGP) | Host-to-host file exchange; files signed and encrypted by default; host-key pinning required in production |
| Web Services | Bank web-service protocols (e.g. Nordea Corporate Access, Danske EDI, OP Financial), with signed requests and verified responses |
| Bank Connect | The Danish Bank Connect gateway |
| EBICS (H005) | The German/Austrian/French market standard, including subscriber initialisation (INI/HIA/HPB) |
Setup is guided in the portal, including key/certificate generation and bank-side enrolment steps. Bank onboarding timelines depend on the bank.
3Inbound reporting
- Statements: camt.053 and legacy MT940 statements are retrieved over your bank connections (or uploaded manually) and normalised into one structured format across all banks.
- Payment status: bank acknowledgements (pain.002) are ingested and matched to your payments, which updates each payment's status (imported, converted, sent, validated, executed, or rejected, partially accepted or cancelled).
- Reconciliation events are exposed in the portal, via the API, and via webhooks.
4Platform features
- Web portal: dashboard with go-live readiness, manual conversion, test payments, bank setup wizards, journals of payments sent and statements imported, approvals, users and roles, activity log, settings.
- API: JSON over HTTPS with a stable error contract (machine-readable codes), cursor pagination, and OpenAPI documentation.
- Webhooks: HMAC-signed event delivery with retries and stable event ids.
- Journal and audit: retained normalised documents; a per-company, hash-chained, verifiable activity log.
- Account structure: platform, company and user levels, with roles (admin, approver, viewer) and a workspace administrator level; white-label branding on platform arrangements.
- Email invitations for user onboarding.
5Environments and Limited Releases
- Production: live bank endpoints and payments with real funds, protected by the measures in the Security Policy.
- Sandbox: a separate environment with test bank endpoints and demonstration scenarios, in which no real payments are made. Sandbox is available for the full term but is a Limited Release (no SLA/support commitments).
- Limited Releases: sandbox, betas, pilot bank integrations, and features marked preview/beta/early access, provided as-is, per the Agreement.
6Data retention schedule
| Data | Retention |
|---|---|
| Journal documents (payments, statements; encrypted payloads) | 90 days in the live service, then in an encrypted archive; deleted no later than 180 days after creation |
| Raw bank statement files | 30 days in the live service; any archive copy is deleted no later than 180 days after creation |
| Audit/activity records | 5 years, then deleted, including any archive copy |
| Failed sign-in records | 1 year |
| Usage events (adoption metrics; no payment content) | 365 days |
| Browser error reports (web portal fault diagnostics; encrypted payloads) | 30 days, then purged |
| Idempotency records | 24 hours |
| Sessions, invitations, and similar operational records | Operational lifetime only |
Company-level and per-user GDPR erasure functions are built in and also reach the archive. A legal hold pauses deletion until it is lifted. Backups expire on their normal cycle. Export of journal and documents is available self-service throughout the term.
7Service boundaries
- We do not hold, receive or transmit funds; payment execution is performed by your bank under your own bank agreement and mandates.
- We do not guarantee that a bank will accept or process any file; validation reduces but cannot eliminate rejections.
- The Services may flag payment parties resembling entries on public sanctions lists. Such flags are advisory only, may be incomplete or wrong, and are not a compliance service. We do not perform KYC/AML on counterparties or monitor transactions for financial-crime purposes.
- Bank onboarding, bank fees and bank-side configuration are matters between you and your bank.
BankConnector ApS, bankconnector.com/legalBC-POL-SVC-1.1