Service Description
v1.0Last updated 8 July 2026. This document forms part of the Agreement and describes the services. The live, always-current list of supported banks, countries, payment types, and channels is available in the product and in the Documentation at bankconnector.com/docs; this document describes the service's shape and commitments, which do not shrink when the coverage list grows.
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 exact decimal strings; sums are computed exactly (no floating-point drift).
- 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 returns all issues at once, 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 and immutable; changes require dual co-signature.
- Delivery (direct only): approved files are delivered by us directly to the bank over your active bank connection. Signed payment files are never returned to you or any third party.
- 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, driving the payment lifecycle: *imported → converted → sent → validated → executed* (or rejected/partially accepted/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, payments sent / statements imported journals, 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.
- Multi-tenancy: platform → company → user, 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: real bank endpoints, real-money sends, full security posture.
- Sandbox: a deployed, secure environment with test bank endpoints and demo scenarios; no real-money sends. 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, then purged |
| Audit/activity records | 5 years |
| Usage events (adoption metrics; no payment content) | 365 days |
| Idempotency records | 24 hours |
| Sessions, invitations, and similar operational records | Operational lifetime only |
Company-level and per-user GDPR erasure functions are built in, subject to documented legal holds. Export of journal and documents is available self-service throughout the term.
7Service boundaries
- We never 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.
- We do not screen payments against sanctions or embargo lists, perform KYC/AML on counterparties, or monitor transactions for financial-crime purposes, except for screening features expressly described in the Documentation that you have configured.
- Bank onboarding, bank fees, and bank-side configuration are between you and your bank.
BankConnector ApS · bankconnector.com/legalBC-POL-SVC-1.0