Solution · Finance & payments

Ledgers, invoices, KYC — PCI-aware.

Finance teams ingest invoices, payments, bank-account and KYC files from countless sources. AdaptivMapr maps them with checksum-strict IBAN and BIC validators, and keeps raw PANs in-house.

Get an API key Read the docs

The problem

Why this is hard

Finance teams ingest invoices, payments, bank-account and KYC files from countless sources — banks, PSPs, ERPs, spreadsheets — and no two layouts match. A single IBAN or BIC typo, or a column mapped to the wrong field, is costly and hard to catch after the fact. The AdaptivMapr finance pack ships four templates — invoices, payments, bank_accounts and kyc_profiles — with mod-97 IBAN and BIC validators that reject malformed identifiers at map time. High-risk templates auto-flag for human review, and schema-only mode keeps raw PANs and account numbers inside your perimeter.

How it works

The pipeline, end to end

1
Upload the finance file
Send an invoice, payments, bank-account or KYC export. In schema-only mode only headers and a few short sample rows leave your system — raw PANs, IBANs and account numbers stay in-house.
Schema-onlyPANs stay in-house
2
The cascade maps to the finance template
Deterministic layers resolve most columns against the finance pack (invoices, payments, bank_accounts, kyc_profiles) using multilingual hints; only genuinely ambiguous headers reach the metered LLM layer.
invoicespaymentsbank_accountskyc_profiles
3
Validate IBAN (mod-97) and BIC
Bank-account identifiers are checked with the mod-97 checksum for IBAN and a format check for BIC — a transposed digit or a bad country code is caught before the row is accepted.
IBAN mod-97BIC
4
Human review on high-risk, then commit
payments, bank_accounts and kyc_profiles are high-risk; invoices is medium. The mappings response flags requires_hitl so your workflow gates the commit, then delivers to your ledger or webhook.
requires_hitlCommit / deliver

Why AdaptivMapr

What makes it fit

Checksum-strict banking validators

IBAN is verified with the mod-97 checksum and BIC with a format check — the same arithmetic a bank runs — so a mistyped account identifier fails at map time instead of on a payment run.

HITL risk gating

payments, bank_accounts and kyc_profiles are high-risk and invoices is medium; the mappings response flags requires_hitl / pending_review automatically so a human confirms before commit.

Schema-only keeps data in-house

Schema-only mapping sends only headers and a few clamped sample rows — raw PANs and account numbers never leave your perimeter, which keeps the common case out of PCI scope.

Full-data in-region

When you opt into full-data mapping, the layer-5 call routes to a PHI-eligible provider with X-Region pinning, so sensitive rows stay in the jurisdiction you choose.

In code

A representative call

Map a payments export to the finance template — the high-risk template auto-flags for review, and mod-97 catches a bad IBAN before commit.

curl

# 1. upload (schema-only)
curl https://api.adaptivmapr.com/v1/uploads \
  -H "Authorization: Bearer $MAPR_KEY" \
  -F file=@payments.csv

# 2. map to the finance "payments" template
curl https://api.adaptivmapr.com/v1/uploads/$ID/mappings \
  -H "Authorization: Bearer $MAPR_KEY" \
  -X PATCH -d '{"template":"payments"}'

# 3. commit once a reviewer confirms (high-risk = HITL)
curl https://api.adaptivmapr.com/v1/uploads/$ID/commit \
  -H "Authorization: Bearer $MAPR_KEY" -X POST

response

{
  "template": "payments",
  "risk": "high",
  "requires_hitl": true,
  "hitl_status": "pending_review",
  "fields": {
    "iban": { "source": "AccountIBAN", "validator": "iban", "ok": true },
    "bic":  { "source": "SWIFT",       "validator": "bic",  "ok": true },
    "amount": { "source": "Amount", "ok": true }
  }
}

FAQ

Common questions

Not in schema-only mode. Only column headers and up to 3 short sample rows leave your system, so raw PANs and full account numbers stay inside your perimeter — which keeps the everyday mapping case out of PCI scope. Full-data mapping is a separate, opt-in mode.

With the mod-97 checksum defined in ISO 13616 — the same check a bank performs — plus a country-code and length check. A transposed digit or a wrong country prefix fails validation at map time. BIC is validated for format.

payments, bank_accounts and kyc_profiles are high-risk and invoices is medium-risk, so all four flag requires_hitl: true in the mappings response. The flag is derived from the template risk level; your workflow decides how to gate the commit.

Yes — connectors let you register a scheduled ingest source with encrypted secrets, and one-click layout reuse remembers the confirmed mapping for a recurring file so repeat imports skip the mapping step.

Field validators Schema-only vs full-data

Ready when you are

Map finance & payments data without shipping raw records.

Test on schema-only for a few tokens per map. Full-data routing under a BAA when you go live.

Get an API key See pricing →

$10 minimum to start · pay only for what you map · PHI under BAA coverage