Research date: 2026-09-04
Scope: IBAN-Naam Check services for NL, API access model, GDPR/AVG implications for an audit tool, and integration fit with DA-098 (PR #188).
Context: DA-098 V1 (PR #188) flags unknown beneficiary IBANs extracted from payment descriptions against a director registry. It has no mechanism to verify whether a detected IBAN actually belongs to the name stated in the transaction description. This document explores enriching that check with live IBAN-name verification.
Companion docs: docs/erp-integration-exact-afas-research.md (counterparty structured data from ERP), docs/liquide-middelen-audit-research.md
SurePay is the de facto Dutch IBAN-Naam Check standard. It began as a Rabobank corporate startup in 2016 and became an independent legal entity in February 2020. It is the provider behind the IBAN-Naam Check that all major Dutch banks expose to their retail and business customers.
Banks powered by SurePay (exhaustive for NL): | Bank | Status | |---|---| | Rabobank | Live | | ING Bank | Live | | ABN AMRO | Live | | SNS Bank | Live | | Regiobank | Live | | ASN Bank | Live | | Knab | Live |
Coverage: Over 99.9% of all Dutch bank accounts are covered. More than 3 million checks are performed daily with an average response time of ~100 ms.
Regulatory context: Since October 2025, Verification of Payee (VOP) is mandatory for all euro-area banks under the EU SEPA Instant Payments Regulation. SurePay provides the VOP service for Dutch banks. The same service that banks use internally for payment initiation checks is also available to non-bank organizations via a separate B2B API product.
Each major bank exposes its own developer portal entry for the IBAN-Naam Check, but all route to SurePay data underneath:
developer.abnamro.com/api-products/iban-name-check): Requires an ABN AMRO Business Current Account registered in NL plus a contract for Internet Banking Business or Access Online. Technically wraps SurePay's API.Implication for Athena: Using a bank-specific wrapper ties Athena to that bank's business relationship requirement. The SurePay ORG API (section 2) is the bank-agnostic access path and is the correct integration target.
No alternative NL IBAN-naam check service with comparable coverage exists. SurePay's data-sharing agreements with all major Dutch banks create a network effect that third-party competitors cannot replicate without the same bank partnerships. For NL-specific account checks, SurePay is the only viable option.
SurePay offers two distinct B2B API products relevant to Athena:
| Product | Endpoint | Target customer | Coverage |
|---|---|---|---|
| INC for Banks | POST /v2/account/check/banks | Banks and PSPs (requires QWAC PSD2 certificate) | EU + UK |
| INC for Organisations (ORG API) | POST /account/check/organisations | Non-bank companies, insurers, municipalities, corporates | EU + UK |
Athena would use the ORG API (INC for Organisations). The bank API requires a PSD2 QWAC certificate that non-banks cannot obtain.
Developer portal: developer.surepay.nl
Bearer token (OAuth 2.0). Full details at developer.surepay.nl/inc-for-organisations/auth-specification. A sandbox/test environment is available for integration testing prior to production access.
POST /account/check/organisations
Authorization: Bearer <token>
Content-Type: application/json
X-Correlation-Id: <uuid, max 70 chars>
{
"accountId": {
"value": "NL91ABNA0417164300",
"type": "IBAN"
},
"name": "Jansen Installatietechniek BV",
"accountType": "ORG",
"companyIds": [
{ "companyIdType": "NL_KVK", "companyIdValue": "12345678" }
]
}
name: the payee name Athena extracted from the transaction description (or from ERP counterparty data — see section 4).accountType: "NP" (natural person) or "ORG" (organisation). If omitted, SurePay infers from bank data. Specifying it enables an additional account-type-mismatch check.companyIds: optional; enables KvK number cross-check for business accounts.{
"nameMatchResult": "MATCH",
"dataUsedForMatching": "VERIFIED",
"nameSuggestion": null,
"account": {
"accountNumberValidation": "VALID",
"paymentPreValidation": "PASS",
"status": "ACTIVE",
"accountType": "ORG",
"accountTypeMatchResult": "MATCH",
"jointAccount": false,
"numberOfAccountHolders": 1,
"countryCode": "NL"
},
"companyIds": [
{ "type": "NL_KVK", "matchResult": "MATCH" }
],
"scheme": "SurePay"
}
nameMatchResult codes| Code | Meaning | Athena action |
|---|---|---|
| MATCH | Submitted name matches bank's registered account-holder name | Clears suspicion — flag risk weight reduced |
| MISTYPE | Submitted name closely resembles account-holder name (e.g. spelling variant, initials) | Present to auditor with nameSuggestion for review |
| NOT_MATCHING | Submitted name does not match; or accountType mismatch | Elevates flag risk weight — strong fraud signal |
| COULD_NOT_MATCH | Verification inconclusive (no name supplied, insufficient data, check routing failure) | Flag remains in review state; not conclusive |
| NAME_TOO_SHORT | Submitted name too short for matching | Retry with longer name or mark as inconclusive |
| NAME_TOO_LONG | Submitted name exceeds 70-character limit | Truncate and retry |
nameSuggestion fieldFor MISTYPE results, SurePay may return a partial or truncated version of the actual registered name. Privacy restriction: For NL personal (NP) accounts, the full name is never disclosed to the requestor — only a truncated hint. For NL organizational (ORG) accounts, the name can be shared fully. This is by design (see section 3).
account.status: ACTIVE / INACTIVE / NOT_FOUND — an inactive or not-found IBAN is itself a fraud signal independent of name matching.account.accountType: bank-registered type (NP vs ORG) — mismatch with what the description implies (e.g., a salary payment to an account registered as a company) is suspicious.account.numberOfAccountHolders: > 1 indicates a joint account — names may not match exactly if the payee name matches only one of the holders.| Tier | Volume | Price | Notes | |---|---|---|---| | Insight Starter (portal only) | 900 checks/year | €2,700/year ex. VAT | No API; portal UI only | | Insight Pro (portal + file upload) | 4,000 checks/year | €5,700/year ex. VAT | Batch file upload, dashboarding | | Connect (API) | Min. 16,000 checks/year | Custom quote | REST API access; contact sales | | Free | 100 checks | €0 | Trial via portal signup |
Per-check cost (indicative): €0.16–€3.00/check depending on volume tier (derived from Starter/Pro rates). API tier pricing is volume-negotiated and not published.
Contract requirement: The ORG API requires a separate contract from SurePay's portal products. Contact: info@surepay.nl or book via surepay.nl/en/iban-name-check-api-org/.
No specific rate-limit number is publicly documented. The API returns HTTP 429 when limits are exceeded with a backoff message ("reduce frequency and retry"). SurePay's minimum API tier (16,000 checks/year ≈ 44 checks/day averaged) suggests the limits are tied to contracted volume rather than per-second throughput constraints. For an audit tool processing flagged transactions rather than all transactions, volume will be well within normal limits.
SurePay is:
Single checks are never stored by SurePay. Batch file results are retained for maximum 30 days.
When Athena calls SurePay to verify an IBAN against a name from a client's transaction data, Athena is processing personal data about third parties (the client's suppliers, employees, or other counterparties). These individuals have not consented to the check.
Available legal bases under GDPR Article 6:
| Basis | Applicability for Athena | |---|---| | Art. 6(1)(c) — Legal obligation | Statutory auditors in NL perform mandatory audits under Wta/BW 2:393. Fraud detection is an explicit duty (ISA 240, NBA Standards). Strongest basis for statutory audit engagements. | | Art. 6(1)(f) — Legitimate interest | Athena and the audit client have a legitimate interest in detecting fraud. Must be balanced against data subjects' interests. Appropriate for non-statutory (agreed-upon procedures, internal audit) engagements. | | Art. 6(1)(a) — Consent | Not practical for third-party counterparty data; counterparties are not parties to the audit engagement. |
Recommendation: Athena's terms of service and privacy policy must explicitly state that IBAN-naam checks are performed on counterparty data as part of the fraud-detection analysis, and must establish the correct legal basis per engagement type.
SurePay's core privacy principle: no information is disclosed to the requestor that was not already known to the requestor. This manifests as:
nameSuggestion. Athena submits the name it already has (from the transaction description) and gets a verdict — it does not learn the private individual's bank-registered name if it doesn't already know it.Implication: The privacy risk to data subjects from Athena calling SurePay is low — Athena learns only whether the name it already has is correct or not, not the actual name (for NP accounts). This is consistent with a privacy-by-design audit tool.
A Verwerkersovereenkomst (VWO) / Data Processing Agreement with SurePay is required before using the API in production. SurePay operates as a data processor on behalf of Athena (data controller) for the purpose of name verification. The DPA covers:
DA-098 V1 (FraudDetectionService.java) operates as follows for pattern 1 (unknown beneficiary):
Gap addressed by IBAN-Naam Check: DA-098 does not verify whether the name stated in the payment description actually corresponds to the IBAN registered at the bank. A fictitious-bank-account fraud scheme specifically manipulates this relationship — the fraudster substitutes a legitimate payee's name with their own IBAN in the payment instruction.
IBAN-Naam Check complements the existing approach. It does not replace it.
| Layer | Existing DA-098 | IBAN-Naam Check addition |
|---|---|---|
| Detection trigger | IBAN extracted from description ≠ director's known IBAN | Flag already raised by DA-098 |
| Current result | "Unknown IBAN" — auditor must investigate manually | Automated verdict: does the name in the description match the IBAN owner at the bank? |
| Output enhancement | BeneficiaryIbanFlagDto.riskWeight = 1 (unknown) or 2 (new) | Third risk level: 3 = name mismatch confirmed (NOT_MATCHING), or name cleared (MATCH reduces priority) |
| False-positive reduction | High (any unknown IBAN is flagged regardless of whether the name is plausible) | MATCH result can downgrade a flag; only NOT_MATCHING and MISTYPE remain elevated |
The following describes the intended future integration — implementation is not in scope for this research task.
FraudDetectionService (existing)
→ BeneficiaryIbanFlagDto list (unknown IBANs)
→ [V2] IbanNaamCheckService.enrich(flaggedIbans, transactionNames)
→ POST /account/check/organisations (SurePay ORG API)
→ enriches BeneficiaryIbanFlagDto with:
nameMatchResult (MATCH|NOT_MATCHING|MISTYPE|COULD_NOT_MATCH)
nameSuggestion (optional, NP accounts truncated)
accountStatus (ACTIVE|INACTIVE|NOT_FOUND)
accountType (NP|ORG)
→ FraudDetectionResultDto (enriched)
Selective invocation: Calls should be made only for IBANs in BeneficiaryIbanFlagDto (already-flagged unknown beneficiaries), not for all transactions. For a typical audit population (hundreds of payments), the number of unknown IBAN flags will be significantly smaller than the total transaction count.
Derived name for the check: The name parameter submitted to SurePay must be the payee name Athena can extract. Currently TransactionDto.description is a free-text field. The extraction quality depends on accounting package conventions:
counterpartyName is a separate field — submit directly.Fallback: If name cannot be reliably extracted, the check can still be invoked without a name to obtain account status (ACTIVE/INACTIVE/NOT_FOUND) and account type — these are actionable even without name matching. An inactive or not-found IBAN is a fraud signal independent of name.
Proposed extension to DA-098's risk weight scale:
| Scenario | Risk weight | Label |
|---|---|---|
| Unknown IBAN, not new (existing) | 1 | Onbekende begunstigde |
| Unknown IBAN, new in fiscal year (existing) | 2 | Nieuwe begunstigde |
| [V2] Unknown IBAN + NOT_MATCHING name | 3 | Naam-IBAN mismatch bevestigd |
| [V2] Unknown IBAN + MISTYPE name | 2 | Naam-IBAN afwijking (mogelijk tikfout) |
| [V2] Unknown IBAN + MATCH name | 1 → 0 | Naam bevestigd — lagere prioriteit |
| [V2] IBAN INACTIVE or NOT_FOUND | 3 | Inactief/onbekend rekeningnummer |
The IBAN-Naam Check's quality is constrained by the quality of the name field Athena can supply. The current XAF ingestion path provides a free-text description, not a structured payee name. Two paths to improve this:
docs/erp-integration-exact-afas-research.md): provides a structured counterpartyName field per transaction, eliminating the need for name extraction from description. This is the high-quality path.<customerSupplier> section: XAF 3.2 includes <custSupName> and <iban> in the counterparty master section. Athena currently does not parse this section (noted as a gap in ERP research doc). Parsing it would give a structured name/IBAN mapping for the counterparty master list that DA-098 V1 explicitly lacks.Path 2 is lower effort than full ERP integration and would unlock structured counterparty data for the IBAN-Naam Check without requiring OAuth setup.
Minimum viable name quality from XAF descriptions: Can Athena extract a reliable payee name from the free-text description field well enough for the IBAN-Naam Check to return anything other than COULD_NOT_MATCH? This needs empirical testing with a sample of real XAF files from Dutch accounting packages (Exact, AFAS, SnelStart, Twinfield).
XAF <customerSupplier> parsing: Parsing the counterparty master section of the XAF file would provide a structured IBAN → name mapping. This should be evaluated as a prerequisite or parallel task for IBAN-Naam Check integration (lower effort than ERP API, higher quality than description parsing).
Cost model fit: At the Connect tier's minimum of 16,000 checks/year, Athena must expect that audit-tool users collectively trigger this volume. For a SaaS product billed per dossier, this cost should be modelled into the per-dossier price. At indicative rates (~€0.16–€0.30/check at volume), 16K checks/year = €2,500–€4,800/year — meaningful but not prohibitive at scale.
User consent flow for non-statutory audits: For agreed-upon-procedures engagements (not mandatory statutory audits), Athena should prompt the auditor to confirm the legal basis before triggering IBAN-naam checks on employee/personal account data. A toggle in the DA-098 UI ("IBAN-naam check uitvoeren — vereist verwerkingsgrondslag") would allow auditors to make this decision per engagement.
SurePay sandbox access: Confirm whether a sandbox environment is available without a full commercial contract, to allow early-stage integration testing. The developer portal at developer.surepay.nl references a Quick Setup guide that should clarify this.
Account-type check value: For salary-fraud detection (DA-098 pattern 2), a salary payment to an account registered as ORG rather than NP is a significant red flag independent of name matching. The accountType field in the SurePay response should be surfaced even when name matching is inconclusive.
| Dimension | Finding |
|---|---|
| Primary provider | SurePay — the only viable NL IBAN-naam check service; powers all major Dutch banks |
| Access path | SurePay ORG API (developer.surepay.nl), separate contract required |
| Pricing model | Connect API tier: custom quote, min. 16,000 checks/year; contact info@surepay.nl |
| API protocol | REST, Bearer token auth, POST /account/check/organisations |
| Response | MATCH / NOT_MATCHING / MISTYPE / COULD_NOT_MATCH + account status + account type |
| GDPR/AVG legal basis | Art. 6(1)(c) for statutory audits; Art. 6(1)(f) for non-statutory engagements |
| DPA required | Yes — a Verwerkersovereenkomst with SurePay is required before production use |
| Privacy risk | Low — SurePay's privacy-by-design only confirms/denies what the requestor already knows |
| DA-098 integration | Complements (does not replace) existing unknown-beneficiary flagging |
| Key prerequisite | Reliable payee name extraction (from XAF counterparty section or ERP API) |
| Recommended next step | (1) Parse XAF <customerSupplier> section for structured name/IBAN data; (2) contact SurePay sales for ORG API contract and sandbox access |
| Resource | URL | Notes |
|---|---|---|
| SurePay ORG API developer portal | developer.surepay.nl/inc-for-organisations/introduction | API specification, auth, quick setup |
| SurePay pricing | surepay.nl/en/pricing/ | Portal tiers; API pricing by quote |
| SurePay ORG API product page | surepay.nl/en/iban-name-check-api-org/ | Commercial overview; book meeting |
| ABN AMRO IBAN-Name Check API | developer.abnamro.com/api-products/iban-name-check | Bank-specific wrapper of SurePay — requires ABN AMRO business account |
| SurePay GDPR article | surepay.nl/en/solving-gdpr-challenges-in-iban-name-verification/ | Privacy-by-design principles |
| SurePay security | surepay.nl/en/surepay-security/ | ISO 27001, ISAE 3000, GDPR compliance |
| VOP EU mandate (SurePay) | surepay.eu/mandatory-payee-verification/ | Regulatory context for VOP October 2025 mandate |
| EPC Verification of Payee | europeanpaymentscouncil.eu/what-we-do/other-schemes/verification-payee | EPC VOP rulebook |
| docs/erp-integration-exact-afas-research.md | (this repo) | Structured counterparty data via Exact Online / AFAS — prerequisite for high-quality IBAN-Naam Check |
Reacties