Bank accounts CSV import API
bank_accounts_v1
Import this template via API. Import bank account records from any CSV with IBAN mod-97 and BIC validation built in. Multilingual headers handled at zero cost.
30-second curl
curl -X POST https://api.adaptivmapr.com/v1/uploads \ -H "Authorization: Bearer $ADAPTIVMAPR_API_KEY" \ -F "template=bank_accounts_v1" \ -F "file=@your_data.csv"
At a glance
- Pack
- Finance & Payments
- FHIR resource
- —
- Risk level
- high
- Fields
- 6 (2 required, 2 validated)
Why it exists
Why this template?
The Bank accounts template is the canonical schema for payee and beneficiary banking detail — the file a treasury export, a supplier-payment list, or a payout-account directory reduces to. Each row carries an account_holder (required), an IBAN (required, validated), an optional BIC/SWIFT, an account_number and routing_number for non-IBAN regions, and a currency. Finance and treasury teams reach for it when onboarding a new payments rail, when migrating a payee master between ERPs, and when consolidating banking detail after an acquisition. The IBAN is the load-bearing field: it runs mod-97 validation with a country restriction (CH, LI, DE, FR, IT, ES by default) so a transposed digit is caught before a failed transfer costs a return fee. Because banking detail is regulated data, schema-only mode is the default ingress — raw account rows never leave the customer; only headers and clamped sample cells are processed to make the mapping decision.
Two validators do the heavy lifting: IBAN runs mod-97 in chunks (no BigInt needed, so it works inside a Cloudflare Worker) and rejects out-of-country-list IBANs at import; BIC is checked against the SWIFT format (8 or 11 alphanumerics). account_holder and iban are required; bic, account_number, routing_number, and currency are optional so both IBAN-region and ABA-region files ingest cleanly. Hints cover DE / FR / IT / ES / EN naming so a multilingual treasury export does not fall through to the LLM.
Migration scenarios & common foreign headers
Migration scenarios for the Bank accounts template: standing up a new payments or payroll rail that needs a clean payee master on day one, migrating a beneficiary list between ERPs (SAP → NetSuite, Sage → Xero), consolidating banking detail after a group acquisition, and quarterly refreshes of supplier payout accounts. Foreign headers we see in the wild: "Kontoinhaber / Titulaire / Titolare / Titular / IBAN / Compte / Konto / BIC / SWIFT / Kontonummer / Numéro de compte / Numero di conto / Número de cuenta / Bankleitzahl / BLZ / Code guichet / ABA / Routing / Währung / Devise / Valuta / Moneda". The cascade absorbs the cross-language variation through the registered hints and never escalates to the paid layer — the mod-97 IBAN check then catches the typos before they reach the bank.
Canonical columns
Schema
The canonical column set, with the type each row carries, whether it is required, the field-level validators that fire on commit, and the multilingual header hints the cascade resolves against.
| Column | Type | Required | Validators | Hints |
|---|---|---|---|---|
| account_holder | string | yes | — | kontoinhaber · titulaire · titolare · account holder · titular |
| iban | string | yes | iban (CH, LI, DE, FR, IT, ES) | iban · compte · konto · bank account |
| bic | string | — | bic | bic · swift · swift code |
| account_number | string | — | — | kontonummer · numéro de compte · numero di conto · account number · número de cuenta |
| routing_number | string | — | — | bankleitzahl · blz · code guichet · aba · routing |
| currency | string | — | — | währung · devise · valuta · moneda |
The cascade
How AdaptivMapr maps your headers to this template
Five layers run in order, cheapest first. Layer 1 (Statistics) auto-accepts headers that have been mapped the same way across past uploads. Layer 2 (Heuristic) compares your header to the column name, the optional label, and every registered hint (DE / FR / IT / EN / ES) after a Unicode-and-punctuation-normalising pass. Layer 3 (Fuzzy) catches typos and reordered words. Layer 4 (Semantic) uses cached embeddings to catch the long tail of paraphrases. Layer 5 (LLM) only fires on genuinely ambiguous columns, constrained to the template’s allowed column set so it cannot invent a field. When a layer auto-accepts, the lower-cost layers below it never run — that is the cost lever.
REST · POST /v1/uploads
Pass the template_id; the cascade picks up the rest.
curl -X POST https://api.adaptivmapr.com/v1/uploads \ -H "Authorization: Bearer $ADAPTIVMAPR_API_KEY" \ -F "template=bank_accounts_v1" \ -F "file=@your_data.csv"
The canonical template definition is read-only at GET /v1/templates/bank_accounts_v1.
MCP · Cursor / Claude Desktop
Drop AdaptivMapr into your IDE. Schema-only calls are free and unlimited.
// In Cursor or Claude Desktop with the AdaptivMapr MCP server installed:
adaptivmapr.match_headers({
template: "bank_accounts_v1",
headers: ["account_holder", "iban", "bic", "account_number"]
})MCP install instructions →Questions
FAQ — Bank accounts CSV import
What if my account list crosses the IBAN country restriction?
Fork the template and broaden the `countries` array on the IBAN validator. The default allow-list is CH / LI / DE / FR / IT / ES; the validator otherwise treats an out-of-list IBAN as a hard reject at import.
Can I import US accounts that have no IBAN?
The canonical template marks IBAN as required because most regulated EU/CH payment flows depend on it. For ABA-region files, fork the template to make iban optional and rely on account_number + routing_number instead.
Does AdaptivMapr verify the account against the bank?
No — only the IBAN mod-97 checksum and BIC format are verified locally. Live account verification (e.g. confirmation-of-payee) is a separate, paid banking service; the cascade stays offline-safe.
How is banking data protected during mapping?
Schema-only mode is the default: only headers and three clamped sample rows (≤80 chars each) are processed. Full account rows never leave your environment unless you opt into full-data mode under an active subscription.