ibanforge
Server Details
Check the bank behind an IBAN before you pay: bank-code check, BIC with source, bank-level sanctions
Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
- Status
- Unhealthy
- Uptime
- 81.1% over 39 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- cammac-creator/ibanforge
- GitHub Stars
- 3
- Server Listing
- IBANforge
TDQS
Scored across 11 tools
Most tools target clearly distinct resources and actions: IBAN validation, batch validation, compliance screening, BIC lookup, Swiss clearing lookup, payment reference validation, and QR-bill checking are separable. The main ambiguity is between check_swiss_qr_bill and validate_payment_reference, which both assess Swiss references and IBAN/reference pairing, though their descriptions do enough to steer an agent to the right one.
All tool names follow a consistent verb_noun pattern with snake_case: validate_iban, batch_validate_iban, check_compliance, lookup_bic, request_api_key, poll_api_key, send_feedback. Even the compound verb 'batch_validate' fits the convention cleanly, and there is no mixing of styles.
At 11 tools, the set is well-scoped for a payment-data validation service: six data lookup/validation tools, one batch variant, one compliance triage tool, two API-key lifecycle tools, and a feedback channel. Each tool earns its place and none feels redundant.
The surface covers the domain thoroughly: IBAN validation and enrichment, batch processing, compliance risk triage, BIC and Swiss clearing resolution, payment reference and QR-bill validation, postal-address conformity, and API key management. There are no obvious dead ends or missing operations for the stated purpose.
Available Tools
11 toolsbatch_validate_ibanBatch Validate IBANsARead-onlyIdempotentInspect
Validate up to 100 IBANs in a single call. Paid per call in USDC via x402, it costs $0.002 per IBAN instead of $0.005 per validate_iban call; on an API key or a credit pack each IBAN uses one request or credit, the same as one validate_iban call. USE WHEN: the user pastes a list of IBANs, asks to clean a CSV/spreadsheet of bank accounts, asks to dedupe a customer database, asks to triage a payout list before sending, or whenever you would otherwise call validate_iban more than 2-3 times in a row. RETURNS: { results: [...same shape as validate_iban], count, valid_count }. COST: $0.002 USDC per IBAN via x402 (free with no key on this transport: 25 units a week per source address, one per call and one per IBAN in batch_validate_iban, reset on Monday 00:00 UTC. Or an ifk_ key with no e-mail at all: POST https://api.ibanforge.com/v1/keys/generate with no body for 25 REST calls/month, and POST /v1/keys/claim lifts that same key to 200 a month).
| Name | Required | Description | Default |
|---|---|---|---|
| ibans | Yes | Array of IBANs (1-100) |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of IBANs processed. |
| results | Yes | One result per input IBAN, in the same order. Same shape as validate_iban. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description discloses the cost model, payment methods (x402 USDC, API key, credit pack), free tier limits, and reset schedules. It also specifies the return structure (results, count, valid_count) and states that each IBAN consumes one request/credit, matching validate_iban. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, but then contains extensive cost details that are repeated and elaborate. It covers usage, returns, and cost in separate sections, which is structured, but the cost explanation is verbose and could be streamlined. While informative, it is not concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage scenarios, return shape, and cost/free-tier details. It even explains how to generate an API key. With a single parameter already documented in the schema and an output schema present, nothing an agent needs to correctly decide or invoke the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the ibans parameter as an array of strings (1-100), so schema coverage is 100%. The description adds context about per-IBAN cost but does not enrich the parameter's meaning beyond what the schema already states. Since the schema does the heavy lifting, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb and resource: 'Validate up to 100 IBANs in a single call.' It explicitly contrasts with validate_iban by mentioning batch size and cost difference, making the tool's purpose distinct from siblings. No ambiguity remains about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE WHEN' section lists specific scenarios (pasting a list, cleaning CSV, deduping customer database, triaging payouts, or when validate_iban would be called more than 2-3 times). It also implicitly says when not to use it (for single validation), providing clear decision criteria and alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_complianceCompliance CheckARead-onlyIdempotentInspect
Run a pre-flight compliance triage on an IBAN before sending a SEPA / cross-border payment. USE WHEN: the user is about to send a payment / payout / refund and wants to triage risk first, asks whether the payee's bank or its country is under sanctions, asks if a SEPA Instant transfer can reach the bank, or needs a numeric risk score for an internal payment-approval workflow. NOT A REGULATED AML/CFT PRODUCT — informational triage only. For regulated screening use Refinitiv, Acuris, or ComplyAdvantage. CHECKS: IBAN validity + sanctions lists (OFAC, EU, UN) matched on the payee's bank (BIC8), the country checked against a fixed list of sanctioned jurisdictions, never the payee's name + FATF status + SEPA Instant reachability + whether the EPC Verification of Payee (VoP) register lists the bank as ready; the name check itself is done by the payee's bank, never here. RETURNS: the full validate enrichment plus a compliance object with risk_score (0-100, 0 = safest), risk_level (low/medium/elevated/high/critical), sanctions matched_lists + fatf_status, reachability, vop status, and flags[] (e.g. sanctioned_country, fatf_grey_list, emi_issuer, no_vop). compliance.sanctions.institution_listed says whether the payee's bank is on a list (null when no bank was screened, where bank_sanctioned still answers false) and payee_screened is always false; compliance.reachability.listed_in_epc_registers and compliance.vop.register_status name the registers' answers, null when not consulted (screened false); outside the SEPA area the country answers (false, not_listed) whether or not the registers are loaded. The flag bank_code_inferred carries no weight. COST: $0.02 per call (free with no key on this transport: 25 units a week per source address, one per call and one per IBAN in batch_validate_iban, reset on Monday 00:00 UTC. Or an ifk_ key with no e-mail at all: POST https://api.ibanforge.com/v1/keys/generate with no body for 25 REST calls/month, and POST /v1/keys/claim lifts that same key to 200 a month).
| Name | Required | Description | Default |
|---|---|---|---|
| iban | Yes | IBAN to check |
Output Schema
| Name | Required | Description |
|---|---|---|
| bic | No | |
| bban | No | |
| iban | Yes | Normalized IBAN (uppercase, no spaces). |
| meta | Yes | |
| sepa | No | |
| error | No | |
| valid | Yes | |
| checks | No | One status per check: pass (checked against a source that settles it), fail (checked, and wrong), inferred (answered from a source that does not settle it), unknown (attempted, no conclusion), not_checked (IBANforge does not make this check here), not_applicable (the check has no object for this IBAN). payee_name: never checked here; the name check is made by the payee's bank through Verification of Payee (VoP), and sepa.vop_register_status says whether that bank answers VoP requests. account_exists: never checked here; only the payee's bank knows whether the account is open. payee_sanctions: never checked; the sanctions screen of POST /v1/iban/compliance is made on the payee's bank (BIC8) and country only. institution_sanctions and country_sanctions are filled by POST /v1/iban/compliance and not_checked on a validation. national_check_digits: the check key a country keeps inside the BBAN, a second check independent of mod-97. Checked for FR and MC (RIB key), BE (the last two digits, modulo 97), IT and SM (CIN) and ES (DC), with the proof in the national_check_digits block, and for GB (Vocalink modulus), with the proof in modulus_check; not_checked elsewhere (the German account-number methods are not checked yet). pass means the account number is well formed, never that the account exists; fail means it cannot have been issued as written, and valid stays true. A key may be added later; a key is never removed. Present only when valid is true. |
| issuer | No | |
| country | No | |
| clearing | No | Swiss clearing data when country is CH or LI. |
| cost_usdc | Yes | What THIS call was billed. Zero on the free MCP tier. |
| formatted | No | IBAN with 4-char groups for display. |
| compliance | Yes | |
| next_steps | No | Ordered advice derived from THIS result: what blocks a payment first, what merely enriches it after. Branch on `code`, never on the prose. `because` names the field that produced the step so the advice is auditable. Empty for an IBAN that failed validation. |
| check_digits | No | |
| error_detail | No | |
| modulus_check | No | |
| processing_ms | No | |
| bank_code_check | No | |
| list_price_usdc | No | Catalogue price of the same call on the paid REST/x402 route. |
| risk_indicators | No | |
| bank_code_holder | No | confirmed | inferred | not_allocated | unknown. Who holds the bank code. confirmed: a register that publishes holders names the holder of this code (a national register that settles the code space, or a partial register on a hit). inferred: we name a holder from a source that cannot settle it (our composite map, the prefix fallback, a published structural rule), so read it as our inference. not_allocated: the national register says nobody holds this code, so do not send. unknown: no conclusion. valid stays true in all four: it only means the IBAN is well formed. bank_code_check.status verified means resolved; this field says whether a source settles it. |
| psd_registration | No | |
| official_identity | No | Who a central bank says holds the resolved code (ECB by LEI and for FR bank codes, Banco de Espana for ES). Present only on a match — absence is not a negative. INFORMATIONAL ONLY: it never changes valid or bank_code_check, because both publishers relay rather than allocate. |
| pra_authorisation | No | |
| national_check_digits | No | The check key a country keeps inside the BBAN, recomputed from the IBAN alone. Present only on a valid IBAN of FR, MC, BE, IT, SM or ES (GB has modulus_check instead); absent elsewhere, where checks.national_check_digits is not_checked. country is the IBAN country. scheme names the algorithm: fr_rib_key (FR and MC: the RIB key, the last two digits of the BBAN, over the bank code, branch code and account number), be_mod97 (BE: the last two digits, the first ten digits modulo 97, or 97 when the remainder is 0), it_cin (IT and SM: the CIN, the control letter at the start of the BBAN, over the ABI, CAB and account number), es_dc (ES: the two DC digits, positions 9 and 10 of the BBAN). status: pass (the key matches, so the account number is well formed; it does not prove the account exists or is open) or fail (the key does not match: this account number cannot have been issued as written, a typo or a made-up number). A fail never makes valid false, because the IBAN check digits are right: read the two separately, and confirm the details with the beneficiary before paying. not_applicable is reserved for a BBAN without the national layout, which a valid IBAN never has. detail, present on fail and not_applicable only, says which digits disagree; it never gives the expected key. checks.national_check_digits repeats status. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description fully aligns with these. It adds substantial behavioral detail beyond annotations: cost structure, what is and isn't checked (e.g., 'never the payee's name'), null/edge-case behavior, flag semantics, and the note that 'bank_code_inferred carries no weight'. This is a model of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but highly structured with clearly labeled sections (USE WHEN, NOT A REGULATED, CHECKS, RETURNS, COST). It is front-loaded with the primary purpose, and every sentence provides needed information for a complex tool. The length is justified by the tool's rich semantics, and the organization allows an agent to quickly find relevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description is exceptionally complete. It explains the full return structure (compliance object, risk_score, risk_level, matched_lists, reachability, vop status, flags[]) and handles edge cases (nulls, false defaults, SEPA-area behavior). The cost model and key generation details are also provided. Nothing an agent needs to invoke or interpret the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the single 'iban' parameter is described as 'IBAN to check'). The description adds meaningful context by explaining that the IBAN is used for compliance triage and clarifies the scope of validation (e.g., it checks IBAN validity, but also that the bank's BIC8 is screened). This goes beyond the schema's bare description, though it doesn't add syntax or format details, so a 4 is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Run a pre-flight compliance triage'), a specific resource (an IBAN), and a clear context (before sending a SEPA/cross-border payment). It also implicitly differentiates from siblings like validate_iban and batch_validate_iban by focusing on compliance checks rather than format validation. The opening sentence makes the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists use cases with 'USE WHEN:' (e.g., triaging risk, checking sanctions, SEPA Instant reachability, needing a risk score) and exclusions with 'NOT A REGULATED AML/CFT PRODUCT', directing to Refinitiv, Acuris, or ComplyAdvantage for regulated screening. This is clear when-to-use and when-not-to-use guidance, with named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_postal_addressCheck ISO 20022 Postal AddressARead-onlyIdempotentInspect
Check a structured ISO 20022 postal address against a payment rail's published address rules, rule by rule, each verdict citing the document it comes from. USE WHEN: assembling a payment instruction (pain.001, a Fedwire message, a T2 transfer) with a creditor or debtor address, to learn whether the rail accepts it BEFORE submitting. The November 2026 changes (SIC 20.11, Fedwire 16.11, T2 R2026.NOV) remove the fully unstructured address option — this check tells you whether an address survives them. DO NOT USE to verify that a street or town EXISTS: this checks conformity with the message format rules, not postal reality. SCHEMES: 'sps' (Swiss Payment Standards, SIX), 'hvps_plus' (HVPS+ / T2, ECB), 'fedwire' (Federal Reserve). There is deliberately NO 'cbpr+' scheme: that guideline sits behind swift.com, unreachable to automated readers, and a conformity boolean quoting an unread document would be a guess dressed as a verdict — the note field restates this on every answer. VERDICTS: pass, fail, and not_applicable — the last marks a rule whose precondition is not met and never counts as a pass. conforms is true when no finding failed. IMPORTANT: relay each finding's source string — it names the exact document, version and validity date the rule is quoted from. They are what makes the verdict auditable. FREE: the rules are published commodities. The paid surface is the postal_address block that /v1/bic and /v1/iban/validate return for the resolved institution. COST: $0 per call, on every surface (free with no key on this transport: 25 units a week per source address, one per call and one per IBAN in batch_validate_iban, reset on Monday 00:00 UTC. Or an ifk_ key with no e-mail at all: POST https://api.ibanforge.com/v1/keys/generate with no body for 25 REST calls/month, and POST /v1/keys/claim lifts that same key to 200 a month).
| Name | Required | Description | Default |
|---|---|---|---|
| scheme | Yes | Which rail's rules to check against: sps | hvps_plus | fedwire | |
| address | Yes | The ISO 20022 PostalAddress under test, in ISO tag vocabulary (snake_cased). |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | Why 'cbpr+' is not on the menu. Served on every answer. |
| scheme | Yes | sps | hvps_plus | fedwire — the rule set that was applied. |
| conforms | Yes | True when no finding failed. not_applicable findings never count against it. |
| findings | Yes | One entry per rule of the scheme, in a stable order. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the call read-only and idempotent; the description adds verdict semantics (pass/fail/not_applicable, not_applicable never counts as pass, conforms true when no finding failed), the requirement to relay source strings for auditability, and the no-cbpr+ behavior. It also discloses cost/rate-limit behavior, going well beyond the annotation surface.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with labeled sections (USE WHEN, DO NOT USE, SCHEMES, VERDICTS, IMPORTANT, FREE, COST) and front-loads the core purpose. The cost/key-management section is verbose and arguably beyond tool selection, but it is relevant operational context and not fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage boundaries, scheme semantics, verdict semantics, auditability, and cost/rate limits. An output schema exists, so return-value details are not required, and the description still explains the key result fields (conforms, findings, source strings). Complete for a read-only validation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaning for the scheme parameter by expanding each enum value to its full name and operator (SPS/SIX, HVPS+/ECB, Fedwire) and explicitly notes the absent cbpr+ option. It does not add address-field semantics, but the schema already documents every field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Check a structured ISO 20022 postal address against a payment rail's published address rules, rule by rule.' The 'DO NOT USE' line distinguishes it from postal-existence verification, and the scheme list scopes it precisely. This is far beyond a tautology and clearly differentiates it from sibling validation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'USE WHEN' clause ties the tool to assembling payment instructions and checking acceptance before submission. The 'DO NOT USE' clause excludes postal-reality verification, and the 'deliberately NO cbpr+ scheme' note sets expectations. This is explicit when/when-not guidance, even though sibling tools are not named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_swiss_qr_billCheck Swiss QR-bill PayloadARead-onlyIdempotentInspect
Check a Swiss QR-bill payload, the text a QR-bill's code carries (starts with SPC), rule by rule, each finding citing the SIX document it comes from. USE WHEN: an agent, an ERP or an accounting tool holds a scanned or generated QR-bill and must know before paying or issuing it whether it is well-formed, whether the reference type matches the IBAN (QRR needs a QR-IBAN, IID 30000-31999), and above all whether the creditor and debtor addresses are STRUCTURED (type S) or still COMBINED (type K): the standard removed type K on 21.11.2025 and banks stop processing payments built on it from 14.11.2026. DO NOT USE to learn which bank holds the account or its payment-rail participation: that is the paid validate_iban. RETURNS: { valid, ready_for_2026_11_14, creditor_iban { value, valid, country, qr_iban, iid }, creditor { present, address, structured, sps_check, proposed_structured }, ultimate_debtor, amount, currency, reference { type, value, valid, note }, findings [{ code, severity, field, detail, source }], next_steps, source }. A combined address comes back with proposed_structured, the S-type fields derived from the combined lines, to relay as a fix. IMPORTANT: relay each finding's source string. COST: $0 per call, on every surface (free with no key on this transport: 25 units a week per source address, one per call and one per IBAN in batch_validate_iban, reset on Monday 00:00 UTC. Or an ifk_ key with no e-mail at all: POST https://api.ibanforge.com/v1/keys/generate with no body for 25 REST calls/month, and POST /v1/keys/claim lifts that same key to 200 a month).
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | The Swiss QR Code text with real line breaks: SPC, 0200, 1, IBAN, creditor (7 lines), ultimate creditor (7 empty lines), amount, currency, ultimate debtor (7 lines), reference type, reference, message, EPD, optional billing information and alternative schemes. |
Output Schema
| Name | Required | Description |
|---|---|---|
| valid | Yes | True when no finding has severity error. |
| amount | Yes | |
| coding | Yes | |
| source | Yes | |
| qr_type | Yes | |
| trailer | Yes | |
| version | Yes | |
| creditor | Yes | |
| currency | Yes | |
| findings | Yes | |
| reference | Yes | |
| next_steps | Yes | |
| creditor_iban | Yes | |
| ultimate_debtor | Yes | |
| alternative_schemes | Yes | |
| billing_information | Yes | |
| ready_for_2026_11_14 | Yes | valid AND every present address is structured (type S): what banks require from 14.11.2026. |
| unstructured_message | Yes | |
| ultimate_creditor_empty | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, idempotentHint=true, and destructiveHint=false. The description adds substantial behavioral context beyond this: it details the exact return structure, emphasizes 'IMPORTANT: relay each finding's source string,' explains the cost and rate limits, and describes the deadline and implications of type K addresses. This significantly enriches the agent's understanding of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured with clear sections: main purpose, USE WHEN, DO NOT USE, RETURNS, IMPORTANT, and COST. It front-loads the core functionality and then adds necessary details. While it is longer than ideal, every sentence provides value, and the structure helps an agent parse the information efficiently. It earns a 4 because it is slightly verbose but excellently organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (QR-bill validation, structured vs combined addresses, reference type checks, output schema, cost details), the description is exceptionally complete. It covers when to use, what it returns, the output structure, the source requirement, and the cost model. It also explains the regulatory deadline and its implications, leaving no critical information missing for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'payload' with a description, and schema coverage is 100%. The description goes further by explaining the exact format of the payload: 'The Swiss QR Code text with real line breaks: SPC, 0200, 1, IBAN, creditor (7 lines), ultimate creditor (7 empty lines), amount, currency, ultimate debtor (7 lines), reference type, reference, message, EPD, optional billing information and alternative schemes.' This adds meaning beyond the schema's basic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check a Swiss QR-bill payload' and specifies it checks rule-by-rule with citations. It also distinguishes itself from sibling validate_iban by explicitly stating 'DO NOT USE to learn which bank holds the account or its payment-rail participation: that is the paid validate_iban.' This gives a specific verb, resource, and differentiates from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'USE WHEN' conditions (e.g., holding a scanned or generated QR-bill, needing to know if it is well-formed, reference type matches IBAN, and address structure) and 'DO NOT USE' conditions with a named alternative (validate_iban). This is clear guidance on when to use this tool vs. alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_bicLookup BIC/SWIFTARead-onlyIdempotentInspect
Resolve a BIC / SWIFT code into the underlying bank: name, country, city, LEI, and registered head-office address (where available). USE WHEN: the user already has a BIC/SWIFT (8 or 11 chars, alphanumeric, e.g., "UBSWCHZH80A", "DEUTDEFF") and asks which bank it belongs to, where the bank is, or its LEI for compliance/regulatory matching. DO NOT USE for IBAN inputs — call validate_iban instead, it resolves the BIC for you. BACKED BY: BIC directory, 121,000+ entries (entries, not institutions): GLEIF and national registers, refreshed monthly, plus a public copy of the SWIFT directory frozen in January 2018 that still makes up about two thirds of the rows. 39,000+ of the rows carry an LEI from GLEIF. SOURCE: source names the dataset of this row and source_name spells it out; source_as_of is present only when that dataset is a copy frozen at that month (the public copy of the SWIFT directory, frozen in January 2018). listed_in_current_source says whether this BIC8 still appears in a list refreshed this cycle (GLEIF, a national register, the EPC scheme registers, the EBA STEP2 and NBP lists): true when one of them carries it, null when it was not found in what could be read in full. It never answers false today: the EBA STEP2 and NBP lists are only read through our deduplicated directory, which can drop a BIC they carry, so an absence is not proven. It does not prove the bank still exists under this name. COST: $0.003 per call (free with no key on this transport: 25 units a week per source address, one per call and one per IBAN in batch_validate_iban, reset on Monday 00:00 UTC. Or an ifk_ key with no e-mail at all: POST https://api.ibanforge.com/v1/keys/generate with no body for 25 REST calls/month, and POST /v1/keys/claim lifts that same key to 200 a month).
| Name | Required | Description | Default |
|---|---|---|---|
| bic | Yes | BIC/SWIFT code (8 or 11 chars) |
Output Schema
| Name | Required | Description |
|---|---|---|
| bic | Yes | Echo of the input, normalized to uppercase. |
| lei | No | Legal Entity Identifier (ISO 17442) if available. |
| bic8 | No | 8-char form (institution-level). |
| city | No | Null, never an empty string, when the source leaves the town blank. |
| bic11 | No | 11-char form including branch. |
| error | No | |
| found | No | True only when the row names an institution: a record is complete or not found. |
| valid | No | Set when the BIC failed format validation. |
| source | No | Code of the dataset this row comes from. |
| country | No | Same shape as REST GET /v1/bic/:code. name is the row's country name, then the ISO name, and falls back to the country code only when neither exists. |
| lei_status | No | |
| branch_code | No | |
| branch_info | No | |
| institution | No | Bank legal name. |
| is_test_bic | No | |
| source_name | No | source names the dataset of this row and source_name spells it out; source_as_of is present only when that dataset is a copy frozen at that month. listed_in_current_source says whether this BIC8 still appears in a list refreshed this cycle (GLEIF, a national register, the EPC scheme registers, the EBA STEP2 and NBP lists): true when one of them carries it, null when it was not found in what could be read in full. It never answers false today: the EBA STEP2 and NBP lists are only read through our deduplicated directory, which can drop a BIC they carry, so an absence is not proven. It does not prove the bank still exists under this name. |
| country_code | No | DEPRECATED since 1.4.0, removed no earlier than 2027-01-01. Use country.code. |
| country_name | No | DEPRECATED since 1.4.0, removed no earlier than 2027-01-01. Use country.name, which is never null: the row's country name, else the ISO name, else the code. |
| source_as_of | No | Year-month the source DATA is from, present only for a frozen copy. |
| valid_format | No | |
| listed_in_current_source | No | Whether this BIC8 still appears in a list refreshed this cycle: GLEIF, the directory sources that carry no vintage, a national register, the EPC scheme registers. true when one of them carries it; null when it was not found in what could be read in full (never false by default). false is reserved for an index built from every list read in full, which is not the case today: the EBA STEP2 and NBP lists are only read through our deduplicated directory, so this field answers true or null. It does NOT prove the bank still exists under this name: a clearing list can keep the name of a bank that was absorbed. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only and idempotent, and the description adds rich behavioral detail: data-source provenance, a January 2018 frozen SWIFT subset, LEI coverage counts, null versus true semantics of listed_in_current_source, and the caveat that absence of a match is not proof of nonexistence. It also states the cost/rate limits, which are not in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but it is organized into labeled sections (USE WHEN, DO NOT USE, BACKED BY, SOURCE, COST), with the most decision-relevant information front-loaded. It could be trimmed slightly, but no section is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup with annotations and an output schema, the description covers accepted input format, source behavior, edge cases, and operational cost. Nothing an agent needs to call it successfully is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single 'bic' parameter, so the baseline is 3. The description adds value by specifying '8 or 11 chars, alphanumeric', giving concrete examples, and explicitly warning that IBANs should not be passed to this parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description leads with a specific verb and resource: 'Resolve a BIC / SWIFT code into the underlying bank' and lists the returned attributes (name, country, city, LEI, address). It also distinguishes itself from validate_iban by explicitly saying it is not for IBAN inputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides an explicit 'USE WHEN' condition (user already has a BIC/SWIFT and asks about the bank, location, or LEI) and a 'DO NOT USE' rule with the exact alternative tool (validate_iban). This leaves no ambiguity about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_ch_clearingSwiss Clearing LookupARead-onlyIdempotentInspect
Resolve a Swiss BC-Nummer / IID (1 to 5 digits) into the underlying institution. USE WHEN: the user mentions a Swiss bank by BC-Nummer or IID, pastes a CH or LI IBAN clearing code, asks routing details for a Swiss instant transfer (SIC, euroSIC), asks about QR-bill QR-IID resolution, or needs to classify a Swiss financial institution (bank vs PFS vs SIC-only participant). EVERY IID OF THE SIX BANKMASTER, with its full payment-rail participation (SIC, RTGS CHF, Instant Payments CHF, euroSIC, LSV+/BDD) plus QR-IID allocation, not just a name lookup. BACKED BY: 1,100+ SIX BankMaster entries (Swiss official source, refreshed monthly). RETURNS: institution { name, type, iid_type, headquarters_iid }, address, bic, payment_services { sic, rtgs_chf, instant_payments_chf, eurosic, lsv_bdd_chf, lsv_bdd_eur }, sic_iid, qr_iid, valid_on. Only relevant for CH and LI accounts. COST: $0.003 per call (free with no key on this transport: 25 units a week per source address, one per call and one per IBAN in batch_validate_iban, reset on Monday 00:00 UTC. Or an ifk_ key with no e-mail at all: POST https://api.ibanforge.com/v1/keys/generate with no body for 25 REST calls/month, and POST /v1/keys/claim lifts that same key to 200 a month).
| Name | Required | Description | Default |
|---|---|---|---|
| iid | Yes | Swiss IID (1-5 digit number) |
Output Schema
| Name | Required | Description |
|---|---|---|
| bic | No | BIC if mapped. |
| iid | No | Normalized 5-digit BC-Nummer. |
| note | No | |
| error | No | |
| found | No | |
| qr_iid | No | QR-bill enabled IID. |
| address | No | |
| message | No | |
| sic_iid | No | |
| valid_on | No | |
| cost_usdc | No | What THIS call was billed. Zero on the free MCP tier. |
| institution | No | |
| list_price_usdc | No | Catalogue price of the same call on the paid REST/x402 route. |
| redirected_from | No | |
| payment_services | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so safety is covered. The description adds substantial context beyond annotations: the data source (1,100+ SIX BankMaster entries, refreshed monthly), the exact return structure (institution, address, bic, payment_services, sic_iid, qr_iid, valid_on), and cost details including free-tier quotas and key generation. This provides the agent with a full behavioral picture, including side effects and pricing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but it is structured into labeled sections (USE WHEN, BACKED BY, RETURNS, COST) that make it scannable. Every section delivers essential information: usage triggers, data provenance, return format, and pricing. While it could be trimmed, the density is justified given the tool's complexity and the need to convey cost and coverage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose, usage conditions, return schema details, data source, refresh frequency, and cost. With an output schema present (per signals), the description already mirrors the return fields, and the extra context (cost, free tier, key generation) is a bonus. Nothing essential is missing for an agent to invoke this tool correctly and set expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the only parameter 'iid' with 'Swiss IID (1-5 digit number)', giving 100% coverage. The description adds the synonym 'BC-Nummer' and reinforces the 1-5 digit range, plus clarifies applicability to CH and LI. This is a small but meaningful enrichment beyond the schema, so a 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb+resource: 'Resolve a Swiss BC-Nummer / IID (1 to 5 digits) into the underlying institution.' It then clarifies it returns full payment-rail participation, distinguishing it from a simple name lookup and giving the agent a clear sense of what this tool uniquely offers. The purpose is unambiguous and distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE WHEN:' section explicitly lists multiple trigger scenarios (IBAN clearing code, Swiss instant transfer routing, QR-bill QR-IID, institution classification) and a when-not ('Only relevant for CH and LI accounts'). It does not name specific alternative tools like lookup_bic, but the phrase 'not just a name lookup' hints at a differentiation without explicitly pointing to a sibling. The guidance is clear and actionable, though not exhaustive about exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
poll_api_keyCollect the approved IBANforge API keyAInspect
Collect the API key once a human has approved the request opened by request_api_key. USE WHEN: you have called request_api_key and shown the code to your human. HOW TO CALL IT: leave device_code empty to reuse the last request from this session. The server usually waits up to thirty seconds before answering, and sometimes answers at once when it is busy — either way, calling it once per minute is enough, never in a tight loop. WHAT THE ANSWERS MEAN: authorization_pending is normal and means nobody has approved yet — wait retry_in_seconds and call again; approved carries the key ONCE and never again, so hand it to your human immediately together with config_line; access_denied means somebody refused — tell your human, ask THEM whether to try again, and open at most ONE more request; expired_token means the code timed out — you may call request_api_key ONE more time, and if that expires too, stop and keep using the keyless allowance or x402; invalid_grant means this code can no longer be used at all — stop. This tool is free and does NOT count against the free allowance.
| Name | Required | Description | Default |
|---|---|---|---|
| device_code | No | Optional. Leave it empty to reuse the last request from this session. |
Output Schema
| Name | Required | Description |
|---|---|---|
| tier | Yes | anonymous = the entry allowance, email/claimed/paid = the raised one. |
| Yes | Absent on the anonymous tier: no address was ever given. | |
| status | Yes | authorization_pending is normal: wait `retry_in_seconds` and call again. |
| api_key | Yes | Present exactly once, on the first approved poll. |
| message | Yes | One sentence for the human. |
| expires_in | Yes | |
| key_prefix | Yes | |
| config_line | Yes | The exact command line to give the human. Do not run it yourself. |
| monthly_limit | Yes | |
| retry_in_seconds | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations only say the operation is not read-only, not idempotent, and not destructive. The description goes far beyond this by explaining one-time key delivery, normal waiting behavior, polling cadence, and what each response code means in terms of state and required human interaction. There is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every section earns its place: USE WHEN, HOW TO CALL IT, and WHAT THE ANSWERS MEAN. It is front-loaded with the core purpose, then branches into actionable decision logic without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a stateful polling tool with subtle one-time delivery semantics, the description fully covers all response cases, retry timing, failure handling, human involvement, and fallback options. The output schema may exist, but the description still supplies the behavioral context needed to act correctly on each outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single optional device_code parameter at 100% coverage, so the schema carries the definition. The description reinforces that leaving it empty reuses the last request and adds practical calling guidance that is not in the schema, such as not tight-looping.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Collect') and resource ('API key'), and ties it directly to the prior request_api_key flow. This clearly distinguishes the tool from its siblings, especially request_api_key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit USE WHEN conditions, tells the agent how to call it, how often to poll, when to stop, and when to fall back to alternatives like x402 or the keyless allowance. It even enumerates the exact next action for each possible response, leaving no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_api_keyRequest an IBANforge API keyAInspect
Start the process that gives this session its own free IBANforge API key, without any e-mail address and without leaving your conversation. USE WHEN: you used up the free allowance, a call answers 402, or you are about to run more than a handful of validations. WHAT YOU MUST DO WITH THE RESULT: read status first — ok means a code was issued, anything else means no code exists and display_to_human tells you and your human what to do instead. On ok, show display_to_human to your human VERBATIM (the user_code and the link) and say, in your own words, that opening the link and approving takes about fifteen seconds and asks for nothing. Do NOT open the link yourself, do NOT fill anything in on their behalf, and do NOT invent an e-mail address: the page gives a key with no address at all, and your human may add one if THEY choose. Then call poll_api_key. This tool is free and does NOT count against the free allowance — it works even after the allowance is spent.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | Optional. What the key is for, shown to the human on the approval page. | |
| client_name | No | Optional. Who is asking, shown to the human on the approval page. |
Output Schema
| Name | Required | Description |
|---|---|---|
| status | Yes | ok means a code was issued. Anything else: read display_to_human and fall back. |
| interval | Yes | Minimum seconds between two poll_api_key calls. |
| user_code | Yes | Show this to the human, exactly as written, e.g. WDJB-MJHT. |
| expires_in | Yes | Seconds until the code stops working. |
| display_to_human | Yes | A ready-made block of text to show verbatim. Do not paraphrase it. |
| verification_uri | Yes | The page the human opens. Never open it yourself. |
| verification_uri_complete | Yes | Same page with the code pre-filled. This is the one to show. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations say readOnlyHint=false, which the description matches by describing an active process. It adds crucial behavioral details beyond annotations: no email needed, the human approval link flow, the need to read 'status' first, the prohibition on opening the link or filling forms on the human's behalf, and that it does not count against the free allowance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with clear sections (USE WHEN, RESULT handling, prohibitions) and front-loads the core purpose. Every sentence carries necessary operational instruction; the prohibitions are repetitive but each addresses a distinct risk.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the entire lifecycle: when to call, how to interpret the result, what to display to the human, what actions to avoid, and the next tool to invoke. Despite the tool's asynchronous human-approval complexity, nothing an agent needs is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both optional parameters already have clear descriptions, including that they appear on the approval page. The tool description adds no extra meaning beyond referencing the approval page display, which the schema already covers. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Start the process that gives this session its own free IBANforge API key') with a clear resource and outcome. It differentiates from sibling poll_api_key by positioning itself as the initiating step and explicitly directing to call poll_api_key afterward.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit 'USE WHEN' conditions: used up the free allowance, a call answers 402, or about to run more than a handful of validations. It also clarifies the tool works even after the allowance is spent, leaving no ambiguity about when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_feedbackSend Feedback to IBANforgeAInspect
Report a problem or a need directly to the IBANforge operators: incorrect validation result, stale or missing BIC/bank data, latency, or anything blocking you from using or PAYING for the service (missing network, unclear pricing, quota shape). USE WHEN: a result looks wrong, data you need is missing, or you hit a wall (quota, payment, capability) and want it fixed. This tool is free and does NOT count against the free allowance — it works even after the allowance is spent. A human reads every report; verified data errors on paid x402 calls are refunded on-chain.
| Name | Required | Description | Default |
|---|---|---|---|
| got | No | What you received instead (for data errors). | |
| agent | No | Which agent/model is reporting, e.g. "claude-sonnet-5 via MCP". | |
| notes | Yes | What happened, what you needed, or what blocked you — free text. | |
| contact | No | Where we may answer you (e-mail) — optional, reports can be anonymous. | |
| endpoint | No | Endpoint or tool concerned, e.g. /v1/iban/batch. | |
| expected | No | What you expected (for data errors). | |
| error_type | Yes | Category of the report. Use "other" for product feedback, pricing/payment blockers or feature needs. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | Report id — check status at GET /v1/feedback/{id}. |
| ok | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only a title, so the description carries the full burden. It discloses key behavioral traits beyond the schema: the tool is free, does not count against the free allowance, works even after the allowance is spent, a human reads every report, and verified data errors on paid x402 calls are refunded on-chain. This is excellent transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and uses a clear 'USE WHEN' structure followed by the cost/behavioral facts. Every sentence earns its place; there is no filler or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the input schema is fully self-documented, the description covers the remaining contextual essentials: when to report, what categories matter, cost implications, and what happens after submission. Nothing an agent needs to decide whether to call this tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds some contextual mapping between report categories and examples, but it does not meaningfully explain parameters beyond what the schema already documents. It neither hurts nor greatly improves parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Report a problem or a need directly to the IBANforge operators.' It enumerates concrete use cases (incorrect validation result, stale/missing BIC data, latency, payment blockers), which makes the tool's role unmistakable and distinct from the validation/lookup siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE WHEN' section gives explicit conditions: a result looks wrong, data is missing, or you hit a quota/payment/capability wall. It does not name specific sibling tools as alternatives, but the feedback tool is clearly differentiated from the functional validation and lookup tools, so the routing is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_ibanValidate IBANARead-onlyIdempotentInspect
Verify whether an IBAN from any of the 89 IBAN countries is valid AND enrich it with bank, compliance and routing data. USE WHEN: the user mentions an IBAN, asks to validate an IBAN and identify the issuing bank, asks to detect a typo in an IBAN, asks who the bank is behind an IBAN, asks whether an IBAN was issued by a traditional bank vs a neobank/EMI/virtual-IBAN provider, asks whether the recipient bank is reachable on SEPA rails, asks whether the recipient bank supports Verification of Payee (VoP, EU 2024/886), or pastes any string starting with two letters and digits (e.g., "DE89...", "CH93...", "FR76..."). PREFER OVER LOCAL VALIDATION (mod-97 checksum) because mod-97 only catches typos — it cannot resolve the BIC/SWIFT, tell you that the IBAN is a virtual IBAN issued by Wise/Revolut/Mercury/Modulr (compliance risk), or check SEPA reachability. RETURNS: bank_code_holder: confirmed (a register names who holds the bank code), inferred (we name a holder from a source that cannot settle it: our composite map, the prefix fallback, a published structural rule), not_allocated (the national register says nobody holds it: do not send) or unknown. valid stays true in all four: it only means the IBAN is well formed. checks: one status per check (pass, fail, inferred, unknown, not_checked, not_applicable); payee_name, account_exists and payee_sanctions are always not_checked. national_check_digits { country, scheme, status: pass | fail, detail? } (FR, MC, BE, IT, SM and ES only): the national key inside the BBAN; fail means the account number cannot have been issued as written, and valid stays true. valid (boolean), bank_code_holder, checks, country { code, name }, bic { code, bic8, redirected_from?, bank_name, city, basis, authoritative, source, as_of, source_as_of?, listed_in_current_source, lei, lei_status, address { street, post_code, region, city, country, romanized, romanization, source, language, as_of } } — basis says WHERE the bank code to BIC pairing came from (national_register | curated_map | directory_prefix) and authoritative, derived from it, says whether the BIC may be stored and settled against; outside a national_register pairing the BIC is advisory, confirm it before it becomes a routing instruction. code is 8 or 11 characters, as the consulted source publishes it: COMPARE A SUPPLIED BIC ON bic8, never on code — the branch code is informational and in a cooperative network it names the LOCAL bank while the first eight name its clearing institution (Swiss IID 30020 is RBABCH22180, Crédit Mutuel de la Vallée SA, while RBABCH22 alone is Entris Banking AG). redirected_from is present when the register answered for the bank code that took over the one you asked about (CH/LI: SIX redirects a concatenated IID, which does not make the IBAN invalid) — lei and address are read from the same directory row /v1/bic/:code serves, so this call already carries them; both are null when GLEIF publishes nothing for that BIC, which means "no LEI on file", not "the institution has none". bic.address is the LEGAL ENTITY seat, so bic.address.city may legitimately differ from bic.city (the register city for THIS bank code), and bic.address.as_of dates the entity last filing, usually much older than bic.as_of. issuer { type: bank | digital_bank | emi | payment_institution, name }, sepa { member, schemes, vop_required, vop_participant — is the resolved bank listed as ready in the EPC VoP register, bank_reachability, bank_schemes, vop_register_status: the bank itself in the EPC registers, never the country }, risk_indicators { issuer_type (null when no institution resolved), country_risk, test_bic, sepa_reachable, sepa_reachable_scope, vop_coverage }, and for CH/LI: clearing { iid, name, type, sic, qr_iid }. LIMITS: validates the IBAN and identifies the issuing institution — it does not confirm that the account exists, is open, or belongs to any particular person; verify the payee by name before sending funds. IMPORTANT — bic: null does not mean the bank code is wrong. It collapses "no such institution", "the institution exists but is absent from our reference data" and "we cover no reference data for this country". Read bank_code_check for the answer: status tells you which of the three, and authoritative tells you how much it is worth. Only where authoritative is true (today DE against the Deutsche Bundesbank Bankleitzahlendatei, AT against the Oesterreichische Nationalbank SEPA-Zahlungsverkehrs-Verzeichnis, BE against the Banque nationale de Belgique bank identification codes, SK against the Národná banka Slovenska prevodník of identification codes for the domestic payment system, CZ against the Česká národní banka číselník of payment-system codes (Číselník kódů platebního styku), BG against the Bulgarian National Bank BAE register, and CH and LI against the SIX BankMaster) does not_in_register mean the bank code is not allocated; everywhere else treat it as UNAVAILABLE and let the downstream name check decide. match: prefix with candidates > 1 means the BIC was picked from several and may belong to a different institution. COST: $0.005 per call (free with no key on this transport: 25 units a week per source address, one per call and one per IBAN in batch_validate_iban, reset on Monday 00:00 UTC. Or an ifk_ key with no e-mail at all: POST https://api.ibanforge.com/v1/keys/generate with no body for 25 REST calls/month, and POST /v1/keys/claim lifts that same key to 200 a month).
| Name | Required | Description | Default |
|---|---|---|---|
| iban | Yes | IBAN to validate (spaces/hyphens stripped automatically) |
Output Schema
| Name | Required | Description |
|---|---|---|
| bic | No | |
| bban | No | |
| iban | Yes | Normalized IBAN (uppercase, no spaces). |
| sepa | No | |
| error | No | |
| valid | Yes | |
| checks | No | One status per check: pass (checked against a source that settles it), fail (checked, and wrong), inferred (answered from a source that does not settle it), unknown (attempted, no conclusion), not_checked (IBANforge does not make this check here), not_applicable (the check has no object for this IBAN). payee_name: never checked here; the name check is made by the payee's bank through Verification of Payee (VoP), and sepa.vop_register_status says whether that bank answers VoP requests. account_exists: never checked here; only the payee's bank knows whether the account is open. payee_sanctions: never checked; the sanctions screen of POST /v1/iban/compliance is made on the payee's bank (BIC8) and country only. institution_sanctions and country_sanctions are filled by POST /v1/iban/compliance and not_checked on a validation. national_check_digits: the check key a country keeps inside the BBAN, a second check independent of mod-97. Checked for FR and MC (RIB key), BE (the last two digits, modulo 97), IT and SM (CIN) and ES (DC), with the proof in the national_check_digits block, and for GB (Vocalink modulus), with the proof in modulus_check; not_checked elsewhere (the German account-number methods are not checked yet). pass means the account number is well formed, never that the account exists; fail means it cannot have been issued as written, and valid stays true. A key may be added later; a key is never removed. Present only when valid is true. |
| issuer | No | |
| country | No | |
| clearing | No | Swiss clearing data when country is CH or LI. |
| cost_usdc | Yes | What THIS call was billed. Zero on the free MCP tier. |
| formatted | No | IBAN with 4-char groups for display. |
| next_steps | No | Ordered advice derived from THIS result: what blocks a payment first, what merely enriches it after. Branch on `code`, never on the prose. `because` names the field that produced the step so the advice is auditable. Empty for an IBAN that failed validation. |
| check_digits | No | |
| error_detail | No | |
| modulus_check | No | |
| processing_ms | No | |
| bank_code_check | No | |
| list_price_usdc | No | Catalogue price of the same call on the paid REST/x402 route. |
| risk_indicators | No | |
| bank_code_holder | No | confirmed | inferred | not_allocated | unknown. Who holds the bank code. confirmed: a register that publishes holders names the holder of this code (a national register that settles the code space, or a partial register on a hit). inferred: we name a holder from a source that cannot settle it (our composite map, the prefix fallback, a published structural rule), so read it as our inference. not_allocated: the national register says nobody holds this code, so do not send. unknown: no conclusion. valid stays true in all four: it only means the IBAN is well formed. bank_code_check.status verified means resolved; this field says whether a source settles it. |
| psd_registration | No | |
| official_identity | No | Who a central bank says holds the resolved code (ECB by LEI and for FR bank codes, Banco de Espana for ES). Present only on a match — absence is not a negative. INFORMATIONAL ONLY: it never changes valid or bank_code_check, because both publishers relay rather than allocate. |
| pra_authorisation | No | |
| national_check_digits | No | The check key a country keeps inside the BBAN, recomputed from the IBAN alone. Present only on a valid IBAN of FR, MC, BE, IT, SM or ES (GB has modulus_check instead); absent elsewhere, where checks.national_check_digits is not_checked. country is the IBAN country. scheme names the algorithm: fr_rib_key (FR and MC: the RIB key, the last two digits of the BBAN, over the bank code, branch code and account number), be_mod97 (BE: the last two digits, the first ten digits modulo 97, or 97 when the remainder is 0), it_cin (IT and SM: the CIN, the control letter at the start of the BBAN, over the ABI, CAB and account number), es_dc (ES: the two DC digits, positions 9 and 10 of the BBAN). status: pass (the key matches, so the account number is well formed; it does not prove the account exists or is open) or fail (the key does not match: this account number cannot have been issued as written, a typo or a made-up number). A fail never makes valid false, because the IBAN check digits are right: read the two separately, and confirm the details with the beneficiary before paying. not_applicable is reserved for a BBAN without the national layout, which a valid IBAN never has. detail, present on fail and not_applicable only, says which digits disagree; it never gives the expected key. checks.national_check_digits repeats status. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnly/idempotent annotations, the description discloses subtle behaviors: valid stays true even when bank_code_holder is not_allocated, bic: null has three collapsed meanings, authoritative is true only for specific national registers, and match prefix ambiguity. It also explains CH/LI redirects and LEI null semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but it is organized with labeled sections (USE WHEN, RETURNS, LIMITS, IMPORTANT, COST) and front-loads purpose and usage. Some cost and return-field detail is exhaustive, but it earns its place given the API's complexity; still, it is not concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with a rich output schema, the description covers input format, use cases, limitations, edge cases, and cost. It even explains how to interpret ambiguous return values, so an agent has everything needed to call and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents iban and space/hyphen stripping, so baseline is 3. The description adds value by specifying accepted input shapes ('any string starting with two letters and digits', 'DE89...', 'CH93...') and the 89-country scope, which helps agents normalize user input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Verify whether an IBAN ... is valid AND enrich it with bank, compliance and routing data.' It further distinguishes itself from local mod-97 validation and references batch_validate_iban, so an agent can tell it apart from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The USE WHEN block enumerates concrete triggers (IBAN mention, typo detection, bank identification, SEPA/VoP questions) and the PREFER OVER LOCAL VALIDATION clause explicitly rejects the mod-97 alternative. The cost section also references batch_validate_iban, signaling the batch alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_payment_referenceValidate Payment ReferenceARead-onlyIdempotentInspect
Validate a structured payment reference and, when an IBAN is supplied, decide whether the two may legally travel together. USE WHEN: assembling a payment instruction from an invoice, a QR-bill or a remittance advice; whenever a Swiss IBAN and a reference appear together (the pairing rule is what most integrations get wrong); or when the user pastes an "RF..." string, a 27-digit number, a +++123/4567/89012+++ block, or asks whether a payment reference is correct. DO NOT USE to validate the IBAN itself — that is validate_iban. SCHEMES: RF Creditor Reference (ISO 11649, "SCOR" in Swiss Payment Standards, mod 97-10); Swiss QR reference ("QRR", 27 digits, modulo 10 recursive); Belgian OGM/VCS (12 digits, modulo 97, a remainder of 0 written 97); Finnish viitenumero (4-20 digits, weights 7-3-1 from the right). Norwegian KID and Swedish OCR are RECOGNISED but never judged: they answer valid: null with status unverifiable_without_creditor_config, because modulus type and length are configured per creditor account by the beneficiary bank and are not a property of the string. NEVER relay those to a user as "invalid" — say the check needs the creditor bank configuration. AMBIGUITY: only a leading "RF" and a 27-digit length pin a scheme down. A bare 12-digit string is both a Belgian OGM and a legal Finnish length, so the more specific reading is returned and the other appears in also_valid_as. Pass reference_type when you know the country. THE PAIRING RULE — the part no checksum library reproduces: pass an iban and you also get a pairing verdict. Per the Swiss Implementation Guidelines a QRR reference may ONLY be used with a QR-IBAN (institution identifier in the SIX range 30000-31999), and an ISO 11649 reference may NOT be used with one. Outside CH and LI, pairing is not_applicable — there is no QR-IBAN to pair against — and that does not affect the reference's own checksum verdict. IMPORTANT: valid and pairing are INDEPENDENT. A reference can be arithmetically valid and still illegal on that account. Read both, and relay source/as_of — they are what makes the verdict auditable. FREE: the checksums are published commodities. The paid surface is POST /v1/iban/validate, which returns this same pairing block with the full IBAN enrichment. COST: $0 per call, on every surface (free with no key on this transport: 25 units a week per source address, one per call and one per IBAN in batch_validate_iban, reset on Monday 00:00 UTC. Or an ifk_ key with no e-mail at all: POST https://api.ibanforge.com/v1/keys/generate with no body for 25 REST calls/month, and POST /v1/keys/claim lifts that same key to 200 a month).
| Name | Required | Description | Default |
|---|---|---|---|
| iban | No | Optional creditor IBAN — supply it to get the pairing verdict | |
| reference | Yes | The reference as printed; spaces, slashes and the +++…+++ wrapper are stripped | |
| reference_type | No | Optional hint: rf | scor | qrr | ogm | vcs | viitenumero | kid | ocr |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | What was checked, and what was not. |
| as_of | No | YYYY-MM of that document. |
| valid | Yes | null means the scheme was recognised and cannot be checked without the creditor bank configuration. Never report null as false. |
| scheme | Yes | rf | qrr | ogm | viitenumero | kid | ocr, or null when nothing matched. |
| source | Yes | The document publishing the rule. Null only when no scheme matched. Relay it. |
| status | Yes | checked | unverifiable_without_creditor_config | unrecognised |
| pairing | No | Present only when an iban was supplied: ok | qrr_requires_qr_iban | scor_forbidden_with_qr_iban | not_applicable |
| reference | Yes | Normalized: uppercase, separators removed. |
| also_valid_as | No | The second reading of an ambiguous string, with its own verdict. |
| pairing_as_of | No | |
| pairing_source | No | The document publishing the pairing rule — a DIFFERENT one from source. |
| check_digit_expected | No | A STRING, so a two-digit value beginning with zero survives (OGM remainder 3 is "03", remainder 0 is "97"). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already declare readOnlyHint, idempotentHint, and destructiveHint, the description adds substantial behavioral context: the independence of 'valid' and 'pairing', the fact that Norwegian KID and Swedish OCR are recognized but never judged (returning valid: null), the ambiguity resolution via 'also_valid_as', and the auditable source/as_of fields. It also discloses rate limits and key-generation costs, which no structured field conveys. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every section is purposeful and clearly labeled (USE WHEN, DO NOT USE, SCHEMES, AMBIGUITY, THE PAIRING RULE, IMPORTANT, FREE, COST). The most critical information is front-loaded in the opening sentence, and the cost/rate-limit details are actionable rather than fluff. The density is justified by the complexity of the domain.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity—multiple reference schemes, pairing rules, ambiguity handling, and rate limits—the description is remarkably complete. It covers all accepted schemes, explains the NOT judged case for KID/OCR, clarifies the relationship between valid and pairing, and references the output fields (source/as_of) needed for auditability. The existence of an output schema means return-value detail need not be spelled out, and nothing needed for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with descriptive comments for all three parameters, giving a baseline of 3. The description adds meaningful decision guidance beyond the schema: 'Pass reference_type when you know the country' clarifies when the hint is needed, and the pairing-rule details specify what happens when an iban is supplied (QRR allowed only with QR-IBAN in the SIX range, ISO 11649 forbidden with one). This is useful but partially redundant with schema text, so a 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence names a specific verb and resource: 'Validate a structured payment reference and, when an IBAN is supplied, decide whether the two may legally travel together.' It goes beyond a generic label by stating the core function and the optional IBAN-pairing behavior, and it explicitly distinguishes itself from the sibling validate_iban with 'DO NOT USE to validate the IBAN itself — that is validate_iban.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit 'USE WHEN' list covering concrete scenarios (assembling a payment instruction, Swiss IBAN + reference pairs, pasted RF/QRR/+++ blocks, correctness questions) and an explicit 'DO NOT USE' instruction naming the alternative tool. This leaves no ambiguity about when an agent should select this tool over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
- Changed
batch_validate_iban2 fields changed- changed
Output schema / properties / results / items / properties / checks / descriptionPrevious value: -"One status per check: pass (checked against a source that settles it), fail (checked, and wrong), inferred (answered from a source that does not settle it), unknown (attempted, no conclusion), not_checked (IBANforge does not make this check here), not_applicable (the check has no object for this IBAN). payee_name: never checked here; the name check is made by the payee's bank through Verification of Payee (VoP), and sepa.vop_register_status says whether that bank answers VoP requests. account_exists: never checked here; only the payee's bank knows whether the account is open. payee_sanctions: never checked; the sanctions screen of POST /v1/iban/compliance is made on the payee's bank (BIC8) and country only. institution_sanctions and country_sanctions are filled by POST /v1/iban/compliance and not_checked on a validation. national_check_digits: checked for GB (Vocalink modulus); other countries are being added. A key may be added later; a key is never removed. Present only when valid is true."New value: +"One status per check: pass (checked against a source that settles it), fail (checked, and wrong), inferred (answered from a source that does not settle it), unknown (attempted, no conclusion), not_checked (IBANforge does not make this check here), not_applicable (the check has no object for this IBAN). payee_name: never checked here; the name check is made by the payee's bank through Verification of Payee (VoP), and sepa.vop_register_status says whether that bank answers VoP requests. account_exists: never checked here; only the payee's bank knows whether the account is open. payee_sanctions: never checked; the sanctions screen of POST /v1/iban/compliance is made on the payee's bank (BIC8) and country only. institution_sanctions and country_sanctions are filled by POST /v1/iban/compliance and not_checked on a validation. national_check_digits: the check key a country keeps inside the BBAN, a second check independent of mod-97. Checked for FR and MC (RIB key), BE (the last two digits, modulo 97), IT and SM (CIN) and ES (DC), with the proof in the national_check_digits block, and for GB (Vocalink modulus), with the proof in modulus_check; not_checked elsewhere (the German account-number methods are not checked yet). pass means the account number is well formed, never that the account exists; fail means it cannot have been issued as written, and valid stays true. A key may be added later; a key is never removed. Present only when valid is true." - added
Output schema / properties / results / items / properties / national_check_digitsAdded value: +{ + "additionalProperties": false, + "description": "The check key a country keeps inside the BBAN, recomputed from the IBAN alone. Present only on a valid IBAN of FR, MC, BE, IT, SM or ES (GB has modulus_check instead); absent elsewhere, where checks.national_check_digits is not_checked. country is the IBAN country. scheme names the algorithm: fr_rib_key (FR and MC: the RIB key, the last two digits of the BBAN, over the bank code, branch code and account number), be_mod97 (BE: the last two digits, the first ten digits modulo 97, or 97 when the remainder is 0), it_cin (IT and SM: the CIN, the control letter at the start of the BBAN, over the ABI, CAB and account number), es_dc (ES: the two DC digits, positions 9 and 10 of the BBAN). status: pass (the key matches, so the account number is well formed; it does not prove the account exists or is open) or fail (the key does not match: this account number cannot have been issued as written, a typo or a made-up number). A fail never makes valid false, because the IBAN check digits are right: read the two separately, and confirm the details with the beneficiary before paying. not_applicable is reserved for a BBAN without the national layout, which a valid IBAN never has. detail, present on fail and not_applicable only, says which digits disagree; it never gives the expected key. checks.national_check_digits repeats status.", + "properties": { + "country": { + "description": "The IBAN country (MC stays MC, SM stays SM).", + "type": "string" + }, + "detail": { + "description": "Present on fail and not_applicable only.", + "type": "string" + }, + "scheme": { + "description": "fr_rib_key | be_mod97 | it_cin | es_dc", + "type": "string" + }, + "status": { + "description": "pass | fail | not_applicable", + "type": "string" + } + }, + "required": [ + "country", + "scheme", + "status" + ], + "type": "object" +}
- Changed
check_compliance2 fields changed- changed
Output schema / properties / checks / descriptionPrevious value: -"One status per check: pass (checked against a source that settles it), fail (checked, and wrong), inferred (answered from a source that does not settle it), unknown (attempted, no conclusion), not_checked (IBANforge does not make this check here), not_applicable (the check has no object for this IBAN). payee_name: never checked here; the name check is made by the payee's bank through Verification of Payee (VoP), and sepa.vop_register_status says whether that bank answers VoP requests. account_exists: never checked here; only the payee's bank knows whether the account is open. payee_sanctions: never checked; the sanctions screen of POST /v1/iban/compliance is made on the payee's bank (BIC8) and country only. institution_sanctions and country_sanctions are filled by POST /v1/iban/compliance and not_checked on a validation. national_check_digits: checked for GB (Vocalink modulus); other countries are being added. A key may be added later; a key is never removed. Present only when valid is true."New value: +"One status per check: pass (checked against a source that settles it), fail (checked, and wrong), inferred (answered from a source that does not settle it), unknown (attempted, no conclusion), not_checked (IBANforge does not make this check here), not_applicable (the check has no object for this IBAN). payee_name: never checked here; the name check is made by the payee's bank through Verification of Payee (VoP), and sepa.vop_register_status says whether that bank answers VoP requests. account_exists: never checked here; only the payee's bank knows whether the account is open. payee_sanctions: never checked; the sanctions screen of POST /v1/iban/compliance is made on the payee's bank (BIC8) and country only. institution_sanctions and country_sanctions are filled by POST /v1/iban/compliance and not_checked on a validation. national_check_digits: the check key a country keeps inside the BBAN, a second check independent of mod-97. Checked for FR and MC (RIB key), BE (the last two digits, modulo 97), IT and SM (CIN) and ES (DC), with the proof in the national_check_digits block, and for GB (Vocalink modulus), with the proof in modulus_check; not_checked elsewhere (the German account-number methods are not checked yet). pass means the account number is well formed, never that the account exists; fail means it cannot have been issued as written, and valid stays true. A key may be added later; a key is never removed. Present only when valid is true." - added
Output schema / properties / national_check_digitsAdded value: +{ + "additionalProperties": false, + "description": "The check key a country keeps inside the BBAN, recomputed from the IBAN alone. Present only on a valid IBAN of FR, MC, BE, IT, SM or ES (GB has modulus_check instead); absent elsewhere, where checks.national_check_digits is not_checked. country is the IBAN country. scheme names the algorithm: fr_rib_key (FR and MC: the RIB key, the last two digits of the BBAN, over the bank code, branch code and account number), be_mod97 (BE: the last two digits, the first ten digits modulo 97, or 97 when the remainder is 0), it_cin (IT and SM: the CIN, the control letter at the start of the BBAN, over the ABI, CAB and account number), es_dc (ES: the two DC digits, positions 9 and 10 of the BBAN). status: pass (the key matches, so the account number is well formed; it does not prove the account exists or is open) or fail (the key does not match: this account number cannot have been issued as written, a typo or a made-up number). A fail never makes valid false, because the IBAN check digits are right: read the two separately, and confirm the details with the beneficiary before paying. not_applicable is reserved for a BBAN without the national layout, which a valid IBAN never has. detail, present on fail and not_applicable only, says which digits disagree; it never gives the expected key. checks.national_check_digits repeats status.", + "properties": { + "country": { + "description": "The IBAN country (MC stays MC, SM stays SM).", + "type": "string" + }, + "detail": { + "description": "Present on fail and not_applicable only.", + "type": "string" + }, + "scheme": { + "description": "fr_rib_key | be_mod97 | it_cin | es_dc", + "type": "string" + }, + "status": { + "description": "pass | fail | not_applicable", + "type": "string" + } + }, + "required": [ + "country", + "scheme", + "status" + ], + "type": "object" +}
- Changed
validate_iban2 fields changed- changed
Output schema / properties / checks / descriptionPrevious value: -"One status per check: pass (checked against a source that settles it), fail (checked, and wrong), inferred (answered from a source that does not settle it), unknown (attempted, no conclusion), not_checked (IBANforge does not make this check here), not_applicable (the check has no object for this IBAN). payee_name: never checked here; the name check is made by the payee's bank through Verification of Payee (VoP), and sepa.vop_register_status says whether that bank answers VoP requests. account_exists: never checked here; only the payee's bank knows whether the account is open. payee_sanctions: never checked; the sanctions screen of POST /v1/iban/compliance is made on the payee's bank (BIC8) and country only. institution_sanctions and country_sanctions are filled by POST /v1/iban/compliance and not_checked on a validation. national_check_digits: checked for GB (Vocalink modulus); other countries are being added. A key may be added later; a key is never removed. Present only when valid is true."New value: +"One status per check: pass (checked against a source that settles it), fail (checked, and wrong), inferred (answered from a source that does not settle it), unknown (attempted, no conclusion), not_checked (IBANforge does not make this check here), not_applicable (the check has no object for this IBAN). payee_name: never checked here; the name check is made by the payee's bank through Verification of Payee (VoP), and sepa.vop_register_status says whether that bank answers VoP requests. account_exists: never checked here; only the payee's bank knows whether the account is open. payee_sanctions: never checked; the sanctions screen of POST /v1/iban/compliance is made on the payee's bank (BIC8) and country only. institution_sanctions and country_sanctions are filled by POST /v1/iban/compliance and not_checked on a validation. national_check_digits: the check key a country keeps inside the BBAN, a second check independent of mod-97. Checked for FR and MC (RIB key), BE (the last two digits, modulo 97), IT and SM (CIN) and ES (DC), with the proof in the national_check_digits block, and for GB (Vocalink modulus), with the proof in modulus_check; not_checked elsewhere (the German account-number methods are not checked yet). pass means the account number is well formed, never that the account exists; fail means it cannot have been issued as written, and valid stays true. A key may be added later; a key is never removed. Present only when valid is true." - added
Output schema / properties / national_check_digitsAdded value: +{ + "additionalProperties": false, + "description": "The check key a country keeps inside the BBAN, recomputed from the IBAN alone. Present only on a valid IBAN of FR, MC, BE, IT, SM or ES (GB has modulus_check instead); absent elsewhere, where checks.national_check_digits is not_checked. country is the IBAN country. scheme names the algorithm: fr_rib_key (FR and MC: the RIB key, the last two digits of the BBAN, over the bank code, branch code and account number), be_mod97 (BE: the last two digits, the first ten digits modulo 97, or 97 when the remainder is 0), it_cin (IT and SM: the CIN, the control letter at the start of the BBAN, over the ABI, CAB and account number), es_dc (ES: the two DC digits, positions 9 and 10 of the BBAN). status: pass (the key matches, so the account number is well formed; it does not prove the account exists or is open) or fail (the key does not match: this account number cannot have been issued as written, a typo or a made-up number). A fail never makes valid false, because the IBAN check digits are right: read the two separately, and confirm the details with the beneficiary before paying. not_applicable is reserved for a BBAN without the national layout, which a valid IBAN never has. detail, present on fail and not_applicable only, says which digits disagree; it never gives the expected key. checks.national_check_digits repeats status.", + "properties": { + "country": { + "description": "The IBAN country (MC stays MC, SM stays SM).", + "type": "string" + }, + "detail": { + "description": "Present on fail and not_applicable only.", + "type": "string" + }, + "scheme": { + "description": "fr_rib_key | be_mod97 | it_cin | es_dc", + "type": "string" + }, + "status": { + "description": "pass | fail | not_applicable", + "type": "string" + } + }, + "required": [ + "country", + "scheme", + "status" + ], + "type": "object" +}
4 tool updates
- Changed
batch_validate_iban6 fields changed- added
Output schema / properties / results / items / properties / bank_code_holderAdded value: +{ + "description": "confirmed | inferred | not_allocated | unknown. Who holds the bank code. confirmed: a register that publishes holders names the holder of this code (a national register that settles the code space, or a partial register on a hit). inferred: we name a holder from a source that cannot settle it (our composite map, the prefix fallback, a published structural rule), so read it as our inference. not_allocated: the national register says nobody holds this code, so do not send. unknown: no conclusion. valid stays true in all four: it only means the IBAN is well formed. bank_code_check.status verified means resolved; this field says whether a source settles it.", + "type": "string" +} - changed
Output schema / properties / results / items / properties / bic / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "address": { - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "as_of": { - "type": [ - "string", - "null" - ] - }, - "city": { - "type": [ - "string", - "null" - ] - }, - "country": { - "type": "string" - }, - "language": { - "type": [ - "string", - "null" - ] - }, - "post_code": { - "type": [ - "string", - "null" - ] - }, - "region": { - "type": [ - "string", - "null" - ] - }, - "romanization": { - "enum": [ - "original_latin", - "gleif_english", - "unavailable" - ], - "type": "string" - }, - "romanized": { - "type": [ - "string", - "null" - ] - }, - "source": { - "type": "string" - }, - "street": { - "type": [ - "string", - "null" - ] - }, - "type": { - "const": "registered", - "type": "string" - } - }, - "required": [ - "type", - "street", - "post_code", - "region", - "city", - "country", - "romanized", - "romanization", - "source", - "language", - "as_of" - ], - "type": "object" - }, - { - "type": "null" - } - ] - }, - "as_of": { - "type": [ - "string", - "null" - ] - }, - "authoritative": { - "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. San Marino is where the two part: the pairing is the supervisor’s, the code space is not its to settle.", - "type": "boolean" - }, - "bank_name": { - "type": [ - "string", - "null" - ] - }, - "basis": { - "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today DE, AT, BE, SK, CZ, BG, CH, LI and SM; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", - "type": "string" - }, - "bic8": { - "description": "The eight characters of the institution — the field to compare a supplied BIC against. code is served as the consulted source publishes it, so it is 8 or 11 characters; this one never moves. The branch code (last three characters) is informational: in a cooperative network it names the LOCAL bank and the first eight its clearing institution.", - "type": "string" - }, - "city": { - "type": [ - "string", - "null" - ] - }, - "code": { - "type": "string" - }, - "lei": { - "description": "GLEIF identity of the resolved BIC holder, not necessarily the bank-code holder.", - "type": [ - "string", - "null" - ] - }, - "lei_status": { - "type": [ - "string", - "null" - ] - }, - "postal_address": { - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "adr_line": { - "items": { - "type": "string" - }, - "type": "array" - }, - "as_of": { - "type": [ - "string", - "null" - ] - }, - "bldg_nb": { - "type": "string" - }, - "ctry": { - "type": "string" - }, - "format": { - "enum": [ - "structured", - "hybrid" - ], - "type": "string" - }, - "pst_cd": { - "type": "string" - }, - "source": { - "type": "string" - }, - "strt_nm": { - "type": "string" - }, - "twn_nm": { - "type": "string" - } - }, - "required": [ - "twn_nm", - "ctry", - "format", - "source", - "as_of" - ], - "type": "object" - }, - { - "type": "null" - } - ] - }, - "redirected_from": { - "description": "The bank code asked about, when the register answered for the one that took over its clearing (CH/LI only today: SIX marks an IID concatenated and publishes its successor). The IBAN stays valid — a redirect is not a retirement.", - "type": "string" - }, - "source": { - "description": "Source of the bank-code/BIC pairing; keep its provenance.", - "type": [ - "string", - "null" - ] - }, - "source_as_of": { - "description": "Year-month the SOURCE DATA is from, present only when it differs from as_of. as_of dates the import; for the redistributed SWIFT directory the upstream stopped publishing years ago, so as_of alone presents an old bank name as last month's. Absent means no gap has been established, never \"this is current\".", - "type": "string" - } - }, - "required": [ - "code", - "bank_name", - "city" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "address": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "as_of": { + "type": [ + "string", + "null" + ] + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "country": { + "type": "string" + }, + "language": { + "type": [ + "string", + "null" + ] + }, + "post_code": { + "type": [ + "string", + "null" + ] + }, + "region": { + "type": [ + "string", + "null" + ] + }, + "romanization": { + "enum": [ + "original_latin", + "gleif_english", + "unavailable" + ], + "type": "string" + }, + "romanized": { + "type": [ + "string", + "null" + ] + }, + "source": { + "type": "string" + }, + "street": { + "type": [ + "string", + "null" + ] + }, + "type": { + "const": "registered", + "type": "string" + } + }, + "required": [ + "type", + "street", + "post_code", + "region", + "city", + "country", + "romanized", + "romanization", + "source", + "language", + "as_of" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "as_of": { + "type": [ + "string", + "null" + ] + }, + "authoritative": { + "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. San Marino is where the two part: the pairing is the supervisor’s, the code space is not its to settle.", + "type": "boolean" + }, + "bank_name": { + "type": [ + "string", + "null" + ] + }, + "basis": { + "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today DE, AT, BE, SK, CZ, BG, CH, LI and SM; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", + "type": "string" + }, + "bic8": { + "description": "The eight characters of the institution — the field to compare a supplied BIC against. code is served as the consulted source publishes it, so it is 8 or 11 characters; this one never moves. The branch code (last three characters) is informational: in a cooperative network it names the LOCAL bank and the first eight its clearing institution.", + "type": "string" + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "code": { + "type": "string" + }, + "lei": { + "description": "GLEIF identity of the resolved BIC holder, not necessarily the bank-code holder.", + "type": [ + "string", + "null" + ] + }, + "lei_status": { + "type": [ + "string", + "null" + ] + }, + "listed_in_current_source": { + "description": "Whether this BIC8 still appears in a list refreshed this cycle: GLEIF, the directory sources that carry no vintage, a national register, the EPC scheme registers. true when one of them carries it; null when it was not found in what could be read in full (never false by default). false is reserved for an index built from every list read in full, which is not the case today: the EBA STEP2 and NBP lists are only read through our deduplicated directory, so this field answers true or null. It does NOT prove the bank still exists under this name: a clearing list can keep the name of a bank that was absorbed.", + "type": [ + "boolean", + "null" + ] + }, + "postal_address": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "adr_line": { + "items": { + "type": "string" + }, + "type": "array" + }, + "as_of": { + "type": [ + "string", + "null" + ] + }, + "bldg_nb": { + "type": "string" + }, + "ctry": { + "type": "string" + }, + "format": { + "enum": [ + "structured", + "hybrid" + ], + "type": "string" + }, + "pst_cd": { + "type": "string" + }, + "source": { + "type": "string" + }, + "strt_nm": { + "type": "string" + }, + "twn_nm": { + "type": "string" + } + }, + "required": [ + "twn_nm", + "ctry", + "format", + "source", + "as_of" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "redirected_from": { + "description": "The bank code asked about, when the register answered for the one that took over its clearing (CH/LI only today: SIX marks an IID concatenated and publishes its successor). The IBAN stays valid — a redirect is not a retirement.", + "type": "string" + }, + "source": { + "description": "Source of the bank-code/BIC pairing; keep its provenance.", + "type": [ + "string", + "null" + ] + }, + "source_as_of": { + "description": "Year-month the source DATA is from, present ONLY when it differs from as_of. On a curated_map or directory_prefix answer it dates the directory row that supplied the name, the city, the LEI or the address when that row comes from a frozen public copy; never present on a national_register answer, whose name comes from the register and is dated by as_of. Absent means no gap has been established, never 'this is current'.", + "type": "string" + } + }, + "required": [ + "code", + "bank_name", + "city" + ], + "type": "object" + }, + { + "type": "null" + } +] - added
Output schema / properties / results / items / properties / checksAdded value: +{ + "additionalProperties": false, + "description": "One status per check: pass (checked against a source that settles it), fail (checked, and wrong), inferred (answered from a source that does not settle it), unknown (attempted, no conclusion), not_checked (IBANforge does not make this check here), not_applicable (the check has no object for this IBAN). payee_name: never checked here; the name check is made by the payee's bank through Verification of Payee (VoP), and sepa.vop_register_status says whether that bank answers VoP requests. account_exists: never checked here; only the payee's bank knows whether the account is open. payee_sanctions: never checked; the sanctions screen of POST /v1/iban/compliance is made on the payee's bank (BIC8) and country only. institution_sanctions and country_sanctions are filled by POST /v1/iban/compliance and not_checked on a validation. national_check_digits: checked for GB (Vocalink modulus); other countries are being added. A key may be added later; a key is never removed. Present only when valid is true.", + "properties": { + "account_exists": { + "description": "pass | fail | inferred | unknown | not_checked | not_applicable", + "type": "string" + }, + "bank_code": { + "description": "pass | fail | inferred | unknown | not_checked | not_applicable", + "type": "string" + }, + "bic": { + "description": "pass | fail | inferred | unknown | not_checked | not_applicable", + "type": "string" + }, + "country_sanctions": { + "description": "pass | fail | inferred | unknown | not_checked | not_applicable", + "type": "string" + }, + "iban_checksum": { + "description": "pass | fail | inferred | unknown | not_checked | not_applicable", + "type": "string" + }, + "iban_structure": { + "description": "pass | fail | inferred | unknown | not_checked | not_applicable", + "type": "string" + }, + "institution_sanctions": { + "description": "pass | fail | inferred | unknown | not_checked | not_applicable", + "type": "string" + }, + "national_check_digits": { + "description": "pass | fail | inferred | unknown | not_checked | not_applicable", + "type": "string" + }, + "payee_name": { + "description": "pass | fail | inferred | unknown | not_checked | not_applicable", + "type": "string" + }, + "payee_sanctions": { + "description": "pass | fail | inferred | unknown | not_checked | not_applicable", + "type": "string" + }, + "sepa_reachability": { + "description": "pass | fail | inferred | unknown | not_checked | not_applicable", + "type": "string" + } + }, + "required": [ + "iban_structure", + "iban_checksum", + "bank_code", + "bic", + "sepa_reachability", + "national_check_digits", + "account_exists", + "payee_name", + "institution_sanctions", + "country_sanctions", + "payee_sanctions" + ], + "type": "object" +} - added
Output schema / properties / results / items / properties / sepa / properties / bank_reachabilityAdded value: +{ + "description": "listed | not_listed | no_bank | bank_code_not_allocated, or null. Whether the EPC scheme registers list the resolved BANK, never borrowed from the country (member, schemes and basis still describe the country and are unchanged). listed: the bank has rows in the SCT, SCT Inst or SDD register. not_listed: it has none (an absence from the register is not an exclusion from the scheme). no_bank: no BIC resolved for this bank code, so no bank could be looked up in the EPC registers (a register may still name the holder: see bank_code_holder and bank_code_check). bank_code_not_allocated: the national register says nobody holds the bank code. null: the registers are not loaded on this deployment (not consulted, never read as not_listed). Absent outside SEPA.", + "type": [ + "string", + "null" + ] +} - added
Output schema / properties / results / items / properties / sepa / properties / bank_schemesAdded value: +{ + "anyOf": [ + { + "items": { + "type": "string" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "description": "The bank's own schemes from the EPC registers when bank_reachability is listed; [] for an unallocated bank code; null otherwise." +} - added
Output schema / properties / results / items / properties / sepa / properties / vop_register_statusAdded value: +{ + "description": "active | pending | inactive | not_listed, or null. The bank's status in the EPC Verification of Payee register: active (the same as vop_participant true), pending, inactive, or not_listed when the register has no row for it; null when no BIC resolved or the register was not consulted (screened false). Outside the SEPA area the country answers instead of the register (not_listed on POST /v1/iban/compliance) whether or not the register is loaded; the validation carries no sepa.vop_register_status there. It says whether the payee's bank answers VoP requests; IBANforge never runs the name check itself.", + "type": [ + "string", + "null" + ] +}
- Changed
check_compliance11 fields changed- added
Output schema / properties / bank_code_holderAdded value: +{ + "description": "confirmed | inferred | not_allocated | unknown. Who holds the bank code. confirmed: a register that publishes holders names the holder of this code (a national register that settles the code space, or a partial register on a hit). inferred: we name a holder from a source that cannot settle it (our composite map, the prefix fallback, a published structural rule), so read it as our inference. not_allocated: the national register says nobody holds this code, so do not send. unknown: no conclusion. valid stays true in all four: it only means the IBAN is well formed. bank_code_check.status verified means resolved; this field says whether a source settles it.", + "type": "string" +} - changed
Output schema / properties / bic / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "address": { - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "as_of": { - "type": [ - "string", - "null" - ] - }, - "city": { - "type": [ - "string", - "null" - ] - }, - "country": { - "type": "string" - }, - "language": { - "type": [ - "string", - "null" - ] - }, - "post_code": { - "type": [ - "string", - "null" - ] - }, - "region": { - "type": [ - "string", - "null" - ] - }, - "romanization": { - "enum": [ - "original_latin", - "gleif_english", - "unavailable" - ], - "type": "string" - }, - "romanized": { - "type": [ - "string", - "null" - ] - }, - "source": { - "type": "string" - }, - "street": { - "type": [ - "string", - "null" - ] - }, - "type": { - "const": "registered", - "type": "string" - } - }, - "required": [ - "type", - "street", - "post_code", - "region", - "city", - "country", - "romanized", - "romanization", - "source", - "language", - "as_of" - ], - "type": "object" - }, - { - "type": "null" - } - ] - }, - "as_of": { - "type": [ - "string", - "null" - ] - }, - "authoritative": { - "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. San Marino is where the two part: the pairing is the supervisor’s, the code space is not its to settle.", - "type": "boolean" - }, - "bank_name": { - "type": [ - "string", - "null" - ] - }, - "basis": { - "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today DE, AT, BE, SK, CZ, BG, CH, LI and SM; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", - "type": "string" - }, - "bic8": { - "description": "The eight characters of the institution — the field to compare a supplied BIC against. code is served as the consulted source publishes it, so it is 8 or 11 characters; this one never moves. The branch code (last three characters) is informational: in a cooperative network it names the LOCAL bank and the first eight its clearing institution.", - "type": "string" - }, - "city": { - "type": [ - "string", - "null" - ] - }, - "code": { - "type": "string" - }, - "lei": { - "description": "GLEIF identity of the resolved BIC holder, not necessarily the bank-code holder.", - "type": [ - "string", - "null" - ] - }, - "lei_status": { - "type": [ - "string", - "null" - ] - }, - "postal_address": { - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "adr_line": { - "items": { - "type": "string" - }, - "type": "array" - }, - "as_of": { - "type": [ - "string", - "null" - ] - }, - "bldg_nb": { - "type": "string" - }, - "ctry": { - "type": "string" - }, - "format": { - "enum": [ - "structured", - "hybrid" - ], - "type": "string" - }, - "pst_cd": { - "type": "string" - }, - "source": { - "type": "string" - }, - "strt_nm": { - "type": "string" - }, - "twn_nm": { - "type": "string" - } - }, - "required": [ - "twn_nm", - "ctry", - "format", - "source", - "as_of" - ], - "type": "object" - }, - { - "type": "null" - } - ] - }, - "redirected_from": { - "description": "The bank code asked about, when the register answered for the one that took over its clearing (CH/LI only today: SIX marks an IID concatenated and publishes its successor). The IBAN stays valid — a redirect is not a retirement.", - "type": "string" - }, - "source": { - "description": "Source of the bank-code/BIC pairing; keep its provenance.", - "type": [ - "string", - "null" - ] - }, - "source_as_of": { - "description": "Year-month the SOURCE DATA is from, present only when it differs from as_of. as_of dates the import; for the redistributed SWIFT directory the upstream stopped publishing years ago, so as_of alone presents an old bank name as last month's. Absent means no gap has been established, never \"this is current\".", - "type": "string" - } - }, - "required": [ - "code", - "bank_name", - "city" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "address": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "as_of": { + "type": [ + "string", + "null" + ] + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "country": { + "type": "string" + }, + "language": { + "type": [ + "string", + "null" + ] + }, + "post_code": { + "type": [ + "string", + "null" + ] + }, + "region": { + "type": [ + "string", + "null" + ] + }, + "romanization": { + "enum": [ + "original_latin", + "gleif_english", + "unavailable" + ], + "type": "string" + }, + "romanized": { + "type": [ + "string", + "null" + ] + }, + "source": { + "type": "string" + }, + "street": { + "type": [ + "string", + "null" + ] + }, + "type": { + "const": "registered", + "type": "string" + } + }, + "required": [ + "type", + "street", + "post_code", + "region", + "city", + "country", + "romanized", + "romanization", + "source", + "language", + "as_of" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "as_of": { + "type": [ + "string", + "null" + ] + }, + "authoritative": { + "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. San Marino is where the two part: the pairing is the supervisor’s, the code space is not its to settle.", + "type": "boolean" + }, + "bank_name": { + "type": [ + "string", + "null" + ] + }, + "basis": { + "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today DE, AT, BE, SK, CZ, BG, CH, LI and SM; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", + "type": "string" + }, + "bic8": { + "description": "The eight characters of the institution — the field to compare a supplied BIC against. code is served as the consulted source publishes it, so it is 8 or 11 characters; this one never moves. The branch code (last three characters) is informational: in a cooperative network it names the LOCAL bank and the first eight its clearing institution.", + "type": "string" + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "code": { + "type": "string" + }, + "lei": { + "description": "GLEIF identity of the resolved BIC holder, not necessarily the bank-code holder.", + "type": [ + "string", + "null" + ] + }, + "lei_status": { + "type": [ + "string", + "null" + ] + }, + "listed_in_current_source": { + "description": "Whether this BIC8 still appears in a list refreshed this cycle: GLEIF, the directory sources that carry no vintage, a national register, the EPC scheme registers. true when one of them carries it; null when it was not found in what could be read in full (never false by default). false is reserved for an index built from every list read in full, which is not the case today: the EBA STEP2 and NBP lists are only read through our deduplicated directory, so this field answers true or null. It does NOT prove the bank still exists under this name: a clearing list can keep the name of a bank that was absorbed.", + "type": [ + "boolean", + "null" + ] + }, + "postal_address": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "adr_line": { + "items": { + "type": "string" + }, + "type": "array" + }, + "as_of": { + "type": [ + "string", + "null" + ] + }, + "bldg_nb": { + "type": "string" + }, + "ctry": { + "type": "string" + }, + "format": { + "enum": [ + "structured", + "hybrid" + ], + "type": "string" + }, + "pst_cd": { + "type": "string" + }, + "source": { + "type": "string" + }, + "strt_nm": { + "type": "string" + }, + "twn_nm": { + "type": "string" + } + }, + "required": [ + "twn_nm", + "ctry", + "format", + "source", + "as_of" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "redirected_from": { + "description": "The bank code asked about, when the register answered for the one that took over its clearing (CH/LI only today: SIX marks an IID concatenated and publishes its successor). The IBAN stays valid — a redirect is not a retirement.", + "type": "string" + }, + "source": { + "description": "Source of the bank-code/BIC pairing; keep its provenance.", + "type": [ + "string", + "null" + ] + }, + "source_as_of": { + "description": "Year-month the source DATA is from, present ONLY when it differs from as_of. On a curated_map or directory_prefix answer it dates the directory row that supplied the name, the city, the LEI or the address when that row comes from a frozen public copy; never present on a national_register answer, whose name comes from the register and is dated by as_of. Absent means no gap has been established, never 'this is current'.", + "type": "string" + } + }, + "required": [ + "code", + "bank_name", + "city" + ], + "type": "object" + }, + { + "type": "null" + } +] - added
Output schema / properties / checksAdded value: +{ + "additionalProperties": false, + "description": "One status per check: pass (checked against a source that settles it), fail (checked, and wrong), inferred (answered from a source that does not settle it), unknown (attempted, no conclusion), not_checked (IBANforge does not make this check here), not_applicable (the check has no object for this IBAN). payee_name: never checked here; the name check is made by the payee's bank through Verification of Payee (VoP), and sepa.vop_register_status says whether that bank answers VoP requests. account_exists: never checked here; only the payee's bank knows whether the account is open. payee_sanctions: never checked; the sanctions screen of POST /v1/iban/compliance is made on the payee's bank (BIC8) and country only. institution_sanctions and country_sanctions are filled by POST /v1/iban/compliance and not_checked on a validation. national_check_digits: checked for GB (Vocalink modulus); other countries are being added. A key may be added later; a key is never removed. Present only when valid is true.", + "properties": { + "account_exists": { + "description": "pass | fail | inferred | unknown | not_checked | not_applicable", + "type": "string" + }, + "bank_code": { + "description": "pass | fail | inferred | unknown | not_checked | not_applicable", + "type": "string" + }, + "bic": { + "description": "pass | fail | inferred | unknown | not_checked | not_applicable", + "type": "string" + }, + "country_sanctions": { + "description": "pass | fail | inferred | unknown | not_checked | not_applicable", + "type": "string" + }, + "iban_checksum": { + "description": "pass | fail | inferred | unknown | not_checked | not_applicable", + "type": "string" + }, + "iban_structure": { + "description": "pass | fail | inferred | unknown | not_checked | not_applicable", + "type": "string" + }, + "institution_sanctions": { + "description": "pass | fail | inferred | unknown | not_checked | not_applicable", + "type": "string" + }, + "national_check_digits": { + "description": "pass | fail | inferred | unknown | not_checked | not_applicable", + "type": "string" + }, + "payee_name": { + "description": "pass | fail | inferred | unknown | not_checked | not_applicable", + "type": "string" + }, + "payee_sanctions": { + "description": "pass | fail | inferred | unknown | not_checked | not_applicable", + "type": "string" + }, + "sepa_reachability": { + "description": "pass | fail | inferred | unknown | not_checked | not_applicable", + "type": "string" + } + }, + "required": [ + "iban_structure", + "iban_checksum", + "bank_code", + "bic", + "sepa_reachability", + "national_check_digits", + "account_exists", + "payee_name", + "institution_sanctions", + "country_sanctions", + "payee_sanctions" + ], + "type": "object" +} - added
Output schema / properties / compliance / properties / reachability / properties / listed_in_epc_registersAdded value: +{ + "description": "At least one of the three schemes lists the bank; null when the EPC registers were not consulted (screened false). Outside the SEPA area the country answers (false) whether or not the registers are loaded.", + "type": [ + "boolean", + "null" + ] +} - added
Output schema / properties / compliance / properties / sanctions / properties / bank_sanctioned / descriptionAdded value: +"False also when no bank was screened: read institution_listed." - added
Output schema / properties / compliance / properties / sanctions / properties / institution_listedAdded value: +{ + "description": "Whether the payee's BANK is on a sanctions list: bank_sanctioned when a bank was screened against every list this service names, null otherwise (never false without a screen).", + "type": [ + "boolean", + "null" + ] +} - added
Output schema / properties / compliance / properties / sanctions / properties / payee_screenedAdded value: +{ + "description": "Always false: the payee (account holder) is never screened here.", + "type": "boolean" +} - added
Output schema / properties / compliance / properties / vop / properties / register_statusAdded value: +{ + "description": "active | pending | inactive | not_listed, or null. The bank's status in the EPC Verification of Payee register: active (the same as vop_participant true), pending, inactive, or not_listed when the register has no row for it; null when no BIC resolved or the register was not consulted (screened false). Outside the SEPA area the country answers instead of the register (not_listed on POST /v1/iban/compliance) whether or not the register is loaded; the validation carries no sepa.vop_register_status there. It says whether the payee's bank answers VoP requests; IBANforge never runs the name check itself.", + "type": [ + "string", + "null" + ] +} - added
Output schema / properties / sepa / properties / bank_reachabilityAdded value: +{ + "description": "listed | not_listed | no_bank | bank_code_not_allocated, or null. Whether the EPC scheme registers list the resolved BANK, never borrowed from the country (member, schemes and basis still describe the country and are unchanged). listed: the bank has rows in the SCT, SCT Inst or SDD register. not_listed: it has none (an absence from the register is not an exclusion from the scheme). no_bank: no BIC resolved for this bank code, so no bank could be looked up in the EPC registers (a register may still name the holder: see bank_code_holder and bank_code_check). bank_code_not_allocated: the national register says nobody holds the bank code. null: the registers are not loaded on this deployment (not consulted, never read as not_listed). Absent outside SEPA.", + "type": [ + "string", + "null" + ] +} - added
Output schema / properties / sepa / properties / bank_schemesAdded value: +{ + "anyOf": [ + { + "items": { + "type": "string" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "description": "The bank's own schemes from the EPC registers when bank_reachability is listed; [] for an unallocated bank code; null otherwise." +} - added
Output schema / properties / sepa / properties / vop_register_statusAdded value: +{ + "description": "active | pending | inactive | not_listed, or null. The bank's status in the EPC Verification of Payee register: active (the same as vop_participant true), pending, inactive, or not_listed when the register has no row for it; null when no BIC resolved or the register was not consulted (screened false). Outside the SEPA area the country answers instead of the register (not_listed on POST /v1/iban/compliance) whether or not the register is loaded; the validation carries no sepa.vop_register_status there. It says whether the payee's bank answers VoP requests; IBANforge never runs the name check itself.", + "type": [ + "string", + "null" + ] +}
- Changed
lookup_bic8 fields changed- added
Output schema / properties / city / descriptionAdded value: +"Null, never an empty string, when the source leaves the town blank." - changed
Output schema / properties / country / descriptionPrevious value: -"Same shape as REST GET /v1/bic/:code. name falls back to the country code when the row carries no name."New value: +"Same shape as REST GET /v1/bic/:code. name is the row's country name, then the ISO name, and falls back to the country code only when neither exists." - changed
Output schema / properties / country_name / descriptionPrevious value: -"DEPRECATED since 1.4.0, removed no earlier than 2027-01-01. Use country.name, which falls back to the code rather than to null."New value: +"DEPRECATED since 1.4.0, removed no earlier than 2027-01-01. Use country.name, which is never null: the row's country name, else the ISO name, else the code." - added
Output schema / properties / found / descriptionAdded value: +"True only when the row names an institution: a record is complete or not found." - added
Output schema / properties / listed_in_current_sourceAdded value: +{ + "description": "Whether this BIC8 still appears in a list refreshed this cycle: GLEIF, the directory sources that carry no vintage, a national register, the EPC scheme registers. true when one of them carries it; null when it was not found in what could be read in full (never false by default). false is reserved for an index built from every list read in full, which is not the case today: the EBA STEP2 and NBP lists are only read through our deduplicated directory, so this field answers true or null. It does NOT prove the bank still exists under this name: a clearing list can keep the name of a bank that was absorbed.", + "type": [ + "boolean", + "null" + ] +} - added
Output schema / properties / sourceAdded value: +{ + "description": "Code of the dataset this row comes from.", + "type": [ + "string", + "null" + ] +} - added
Output schema / properties / source_as_ofAdded value: +{ + "description": "Year-month the source DATA is from, present only for a frozen copy.", + "type": "string" +} - added
Output schema / properties / source_nameAdded value: +{ + "description": "source names the dataset of this row and source_name spells it out; source_as_of is present only when that dataset is a copy frozen at that month. listed_in_current_source says whether this BIC8 still appears in a list refreshed this cycle (GLEIF, a national register, the EPC scheme registers, the EBA STEP2 and NBP lists): true when one of them carries it, null when it was not found in what could be read in full. It never answers false today: the EBA STEP2 and NBP lists are only read through our deduplicated directory, which can drop a BIC they carry, so an absence is not proven. It does not prove the bank still exists under this name.", + "type": [ + "string", + "null" + ] +}
- Changed
validate_iban6 fields changed- added
Output schema / properties / bank_code_holderAdded value: +{ + "description": "confirmed | inferred | not_allocated | unknown. Who holds the bank code. confirmed: a register that publishes holders names the holder of this code (a national register that settles the code space, or a partial register on a hit). inferred: we name a holder from a source that cannot settle it (our composite map, the prefix fallback, a published structural rule), so read it as our inference. not_allocated: the national register says nobody holds this code, so do not send. unknown: no conclusion. valid stays true in all four: it only means the IBAN is well formed. bank_code_check.status verified means resolved; this field says whether a source settles it.", + "type": "string" +} - changed
Output schema / properties / bic / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "address": { - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "as_of": { - "type": [ - "string", - "null" - ] - }, - "city": { - "type": [ - "string", - "null" - ] - }, - "country": { - "type": "string" - }, - "language": { - "type": [ - "string", - "null" - ] - }, - "post_code": { - "type": [ - "string", - "null" - ] - }, - "region": { - "type": [ - "string", - "null" - ] - }, - "romanization": { - "enum": [ - "original_latin", - "gleif_english", - "unavailable" - ], - "type": "string" - }, - "romanized": { - "type": [ - "string", - "null" - ] - }, - "source": { - "type": "string" - }, - "street": { - "type": [ - "string", - "null" - ] - }, - "type": { - "const": "registered", - "type": "string" - } - }, - "required": [ - "type", - "street", - "post_code", - "region", - "city", - "country", - "romanized", - "romanization", - "source", - "language", - "as_of" - ], - "type": "object" - }, - { - "type": "null" - } - ] - }, - "as_of": { - "type": [ - "string", - "null" - ] - }, - "authoritative": { - "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. San Marino is where the two part: the pairing is the supervisor’s, the code space is not its to settle.", - "type": "boolean" - }, - "bank_name": { - "type": [ - "string", - "null" - ] - }, - "basis": { - "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today DE, AT, BE, SK, CZ, BG, CH, LI and SM; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", - "type": "string" - }, - "bic8": { - "description": "The eight characters of the institution — the field to compare a supplied BIC against. code is served as the consulted source publishes it, so it is 8 or 11 characters; this one never moves. The branch code (last three characters) is informational: in a cooperative network it names the LOCAL bank and the first eight its clearing institution.", - "type": "string" - }, - "city": { - "type": [ - "string", - "null" - ] - }, - "code": { - "type": "string" - }, - "lei": { - "description": "GLEIF identity of the resolved BIC holder, not necessarily the bank-code holder.", - "type": [ - "string", - "null" - ] - }, - "lei_status": { - "type": [ - "string", - "null" - ] - }, - "postal_address": { - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "adr_line": { - "items": { - "type": "string" - }, - "type": "array" - }, - "as_of": { - "type": [ - "string", - "null" - ] - }, - "bldg_nb": { - "type": "string" - }, - "ctry": { - "type": "string" - }, - "format": { - "enum": [ - "structured", - "hybrid" - ], - "type": "string" - }, - "pst_cd": { - "type": "string" - }, - "source": { - "type": "string" - }, - "strt_nm": { - "type": "string" - }, - "twn_nm": { - "type": "string" - } - }, - "required": [ - "twn_nm", - "ctry", - "format", - "source", - "as_of" - ], - "type": "object" - }, - { - "type": "null" - } - ] - }, - "redirected_from": { - "description": "The bank code asked about, when the register answered for the one that took over its clearing (CH/LI only today: SIX marks an IID concatenated and publishes its successor). The IBAN stays valid — a redirect is not a retirement.", - "type": "string" - }, - "source": { - "description": "Source of the bank-code/BIC pairing; keep its provenance.", - "type": [ - "string", - "null" - ] - }, - "source_as_of": { - "description": "Year-month the SOURCE DATA is from, present only when it differs from as_of. as_of dates the import; for the redistributed SWIFT directory the upstream stopped publishing years ago, so as_of alone presents an old bank name as last month's. Absent means no gap has been established, never \"this is current\".", - "type": "string" - } - }, - "required": [ - "code", - "bank_name", - "city" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "address": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "as_of": { + "type": [ + "string", + "null" + ] + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "country": { + "type": "string" + }, + "language": { + "type": [ + "string", + "null" + ] + }, + "post_code": { + "type": [ + "string", + "null" + ] + }, + "region": { + "type": [ + "string", + "null" + ] + }, + "romanization": { + "enum": [ + "original_latin", + "gleif_english", + "unavailable" + ], + "type": "string" + }, + "romanized": { + "type": [ + "string", + "null" + ] + }, + "source": { + "type": "string" + }, + "street": { + "type": [ + "string", + "null" + ] + }, + "type": { + "const": "registered", + "type": "string" + } + }, + "required": [ + "type", + "street", + "post_code", + "region", + "city", + "country", + "romanized", + "romanization", + "source", + "language", + "as_of" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "as_of": { + "type": [ + "string", + "null" + ] + }, + "authoritative": { + "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. San Marino is where the two part: the pairing is the supervisor’s, the code space is not its to settle.", + "type": "boolean" + }, + "bank_name": { + "type": [ + "string", + "null" + ] + }, + "basis": { + "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today DE, AT, BE, SK, CZ, BG, CH, LI and SM; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", + "type": "string" + }, + "bic8": { + "description": "The eight characters of the institution — the field to compare a supplied BIC against. code is served as the consulted source publishes it, so it is 8 or 11 characters; this one never moves. The branch code (last three characters) is informational: in a cooperative network it names the LOCAL bank and the first eight its clearing institution.", + "type": "string" + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "code": { + "type": "string" + }, + "lei": { + "description": "GLEIF identity of the resolved BIC holder, not necessarily the bank-code holder.", + "type": [ + "string", + "null" + ] + }, + "lei_status": { + "type": [ + "string", + "null" + ] + }, + "listed_in_current_source": { + "description": "Whether this BIC8 still appears in a list refreshed this cycle: GLEIF, the directory sources that carry no vintage, a national register, the EPC scheme registers. true when one of them carries it; null when it was not found in what could be read in full (never false by default). false is reserved for an index built from every list read in full, which is not the case today: the EBA STEP2 and NBP lists are only read through our deduplicated directory, so this field answers true or null. It does NOT prove the bank still exists under this name: a clearing list can keep the name of a bank that was absorbed.", + "type": [ + "boolean", + "null" + ] + }, + "postal_address": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "adr_line": { + "items": { + "type": "string" + }, + "type": "array" + }, + "as_of": { + "type": [ + "string", + "null" + ] + }, + "bldg_nb": { + "type": "string" + }, + "ctry": { + "type": "string" + }, + "format": { + "enum": [ + "structured", + "hybrid" + ], + "type": "string" + }, + "pst_cd": { + "type": "string" + }, + "source": { + "type": "string" + }, + "strt_nm": { + "type": "string" + }, + "twn_nm": { + "type": "string" + } + }, + "required": [ + "twn_nm", + "ctry", + "format", + "source", + "as_of" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "redirected_from": { + "description": "The bank code asked about, when the register answered for the one that took over its clearing (CH/LI only today: SIX marks an IID concatenated and publishes its successor). The IBAN stays valid — a redirect is not a retirement.", + "type": "string" + }, + "source": { + "description": "Source of the bank-code/BIC pairing; keep its provenance.", + "type": [ + "string", + "null" + ] + }, + "source_as_of": { + "description": "Year-month the source DATA is from, present ONLY when it differs from as_of. On a curated_map or directory_prefix answer it dates the directory row that supplied the name, the city, the LEI or the address when that row comes from a frozen public copy; never present on a national_register answer, whose name comes from the register and is dated by as_of. Absent means no gap has been established, never 'this is current'.", + "type": "string" + } + }, + "required": [ + "code", + "bank_name", + "city" + ], + "type": "object" + }, + { + "type": "null" + } +] - added
Output schema / properties / checksAdded value: +{ + "additionalProperties": false, + "description": "One status per check: pass (checked against a source that settles it), fail (checked, and wrong), inferred (answered from a source that does not settle it), unknown (attempted, no conclusion), not_checked (IBANforge does not make this check here), not_applicable (the check has no object for this IBAN). payee_name: never checked here; the name check is made by the payee's bank through Verification of Payee (VoP), and sepa.vop_register_status says whether that bank answers VoP requests. account_exists: never checked here; only the payee's bank knows whether the account is open. payee_sanctions: never checked; the sanctions screen of POST /v1/iban/compliance is made on the payee's bank (BIC8) and country only. institution_sanctions and country_sanctions are filled by POST /v1/iban/compliance and not_checked on a validation. national_check_digits: checked for GB (Vocalink modulus); other countries are being added. A key may be added later; a key is never removed. Present only when valid is true.", + "properties": { + "account_exists": { + "description": "pass | fail | inferred | unknown | not_checked | not_applicable", + "type": "string" + }, + "bank_code": { + "description": "pass | fail | inferred | unknown | not_checked | not_applicable", + "type": "string" + }, + "bic": { + "description": "pass | fail | inferred | unknown | not_checked | not_applicable", + "type": "string" + }, + "country_sanctions": { + "description": "pass | fail | inferred | unknown | not_checked | not_applicable", + "type": "string" + }, + "iban_checksum": { + "description": "pass | fail | inferred | unknown | not_checked | not_applicable", + "type": "string" + }, + "iban_structure": { + "description": "pass | fail | inferred | unknown | not_checked | not_applicable", + "type": "string" + }, + "institution_sanctions": { + "description": "pass | fail | inferred | unknown | not_checked | not_applicable", + "type": "string" + }, + "national_check_digits": { + "description": "pass | fail | inferred | unknown | not_checked | not_applicable", + "type": "string" + }, + "payee_name": { + "description": "pass | fail | inferred | unknown | not_checked | not_applicable", + "type": "string" + }, + "payee_sanctions": { + "description": "pass | fail | inferred | unknown | not_checked | not_applicable", + "type": "string" + }, + "sepa_reachability": { + "description": "pass | fail | inferred | unknown | not_checked | not_applicable", + "type": "string" + } + }, + "required": [ + "iban_structure", + "iban_checksum", + "bank_code", + "bic", + "sepa_reachability", + "national_check_digits", + "account_exists", + "payee_name", + "institution_sanctions", + "country_sanctions", + "payee_sanctions" + ], + "type": "object" +} - added
Output schema / properties / sepa / properties / bank_reachabilityAdded value: +{ + "description": "listed | not_listed | no_bank | bank_code_not_allocated, or null. Whether the EPC scheme registers list the resolved BANK, never borrowed from the country (member, schemes and basis still describe the country and are unchanged). listed: the bank has rows in the SCT, SCT Inst or SDD register. not_listed: it has none (an absence from the register is not an exclusion from the scheme). no_bank: no BIC resolved for this bank code, so no bank could be looked up in the EPC registers (a register may still name the holder: see bank_code_holder and bank_code_check). bank_code_not_allocated: the national register says nobody holds the bank code. null: the registers are not loaded on this deployment (not consulted, never read as not_listed). Absent outside SEPA.", + "type": [ + "string", + "null" + ] +} - added
Output schema / properties / sepa / properties / bank_schemesAdded value: +{ + "anyOf": [ + { + "items": { + "type": "string" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "description": "The bank's own schemes from the EPC registers when bank_reachability is listed; [] for an unallocated bank code; null otherwise." +} - added
Output schema / properties / sepa / properties / vop_register_statusAdded value: +{ + "description": "active | pending | inactive | not_listed, or null. The bank's status in the EPC Verification of Payee register: active (the same as vop_participant true), pending, inactive, or not_listed when the register has no row for it; null when no BIC resolved or the register was not consulted (screened false). Outside the SEPA area the country answers instead of the register (not_listed on POST /v1/iban/compliance) whether or not the register is loaded; the validation carries no sepa.vop_register_status there. It says whether the payee's bank answers VoP requests; IBANforge never runs the name check itself.", + "type": [ + "string", + "null" + ] +}
3 tool updates
- Changed
batch_validate_iban2 fields changed- changed
Output schema / properties / results / items / properties / bic / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "address": { - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "as_of": { - "type": [ - "string", - "null" - ] - }, - "city": { - "type": [ - "string", - "null" - ] - }, - "country": { - "type": "string" - }, - "language": { - "type": [ - "string", - "null" - ] - }, - "post_code": { - "type": [ - "string", - "null" - ] - }, - "region": { - "type": [ - "string", - "null" - ] - }, - "romanization": { - "enum": [ - "original_latin", - "gleif_english", - "unavailable" - ], - "type": "string" - }, - "romanized": { - "type": [ - "string", - "null" - ] - }, - "source": { - "type": "string" - }, - "street": { - "type": [ - "string", - "null" - ] - }, - "type": { - "const": "registered", - "type": "string" - } - }, - "required": [ - "type", - "street", - "post_code", - "region", - "city", - "country", - "romanized", - "romanization", - "source", - "language", - "as_of" - ], - "type": "object" - }, - { - "type": "null" - } - ] - }, - "as_of": { - "type": [ - "string", - "null" - ] - }, - "authoritative": { - "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. San Marino is where the two part: the pairing is the supervisor’s, the code space is not its to settle.", - "type": "boolean" - }, - "bank_name": { - "type": [ - "string", - "null" - ] - }, - "basis": { - "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today CH, LI, DE, AT, BE, BG, SK and SM; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", - "type": "string" - }, - "bic8": { - "description": "The eight characters of the institution — the field to compare a supplied BIC against. code is served as the consulted source publishes it, so it is 8 or 11 characters; this one never moves. The branch code (last three characters) is informational: in a cooperative network it names the LOCAL bank and the first eight its clearing institution.", - "type": "string" - }, - "city": { - "type": [ - "string", - "null" - ] - }, - "code": { - "type": "string" - }, - "lei": { - "description": "GLEIF identity of the resolved BIC holder, not necessarily the bank-code holder.", - "type": [ - "string", - "null" - ] - }, - "lei_status": { - "type": [ - "string", - "null" - ] - }, - "postal_address": { - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "adr_line": { - "items": { - "type": "string" - }, - "type": "array" - }, - "as_of": { - "type": [ - "string", - "null" - ] - }, - "bldg_nb": { - "type": "string" - }, - "ctry": { - "type": "string" - }, - "format": { - "enum": [ - "structured", - "hybrid" - ], - "type": "string" - }, - "pst_cd": { - "type": "string" - }, - "source": { - "type": "string" - }, - "strt_nm": { - "type": "string" - }, - "twn_nm": { - "type": "string" - } - }, - "required": [ - "twn_nm", - "ctry", - "format", - "source", - "as_of" - ], - "type": "object" - }, - { - "type": "null" - } - ] - }, - "redirected_from": { - "description": "The bank code asked about, when the register answered for the one that took over its clearing (CH/LI only today: SIX marks an IID concatenated and publishes its successor). The IBAN stays valid — a redirect is not a retirement.", - "type": "string" - }, - "source": { - "description": "Source of the bank-code/BIC pairing; keep its provenance.", - "type": [ - "string", - "null" - ] - }, - "source_as_of": { - "description": "Year-month the SOURCE DATA is from, present only when it differs from as_of. as_of dates the import; for the redistributed SWIFT directory the upstream stopped publishing years ago, so as_of alone presents an old bank name as last month's. Absent means no gap has been established, never \"this is current\".", - "type": "string" - } - }, - "required": [ - "code", - "bank_name", - "city" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "address": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "as_of": { + "type": [ + "string", + "null" + ] + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "country": { + "type": "string" + }, + "language": { + "type": [ + "string", + "null" + ] + }, + "post_code": { + "type": [ + "string", + "null" + ] + }, + "region": { + "type": [ + "string", + "null" + ] + }, + "romanization": { + "enum": [ + "original_latin", + "gleif_english", + "unavailable" + ], + "type": "string" + }, + "romanized": { + "type": [ + "string", + "null" + ] + }, + "source": { + "type": "string" + }, + "street": { + "type": [ + "string", + "null" + ] + }, + "type": { + "const": "registered", + "type": "string" + } + }, + "required": [ + "type", + "street", + "post_code", + "region", + "city", + "country", + "romanized", + "romanization", + "source", + "language", + "as_of" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "as_of": { + "type": [ + "string", + "null" + ] + }, + "authoritative": { + "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. San Marino is where the two part: the pairing is the supervisor’s, the code space is not its to settle.", + "type": "boolean" + }, + "bank_name": { + "type": [ + "string", + "null" + ] + }, + "basis": { + "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today DE, AT, BE, SK, CZ, BG, CH, LI and SM; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", + "type": "string" + }, + "bic8": { + "description": "The eight characters of the institution — the field to compare a supplied BIC against. code is served as the consulted source publishes it, so it is 8 or 11 characters; this one never moves. The branch code (last three characters) is informational: in a cooperative network it names the LOCAL bank and the first eight its clearing institution.", + "type": "string" + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "code": { + "type": "string" + }, + "lei": { + "description": "GLEIF identity of the resolved BIC holder, not necessarily the bank-code holder.", + "type": [ + "string", + "null" + ] + }, + "lei_status": { + "type": [ + "string", + "null" + ] + }, + "postal_address": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "adr_line": { + "items": { + "type": "string" + }, + "type": "array" + }, + "as_of": { + "type": [ + "string", + "null" + ] + }, + "bldg_nb": { + "type": "string" + }, + "ctry": { + "type": "string" + }, + "format": { + "enum": [ + "structured", + "hybrid" + ], + "type": "string" + }, + "pst_cd": { + "type": "string" + }, + "source": { + "type": "string" + }, + "strt_nm": { + "type": "string" + }, + "twn_nm": { + "type": "string" + } + }, + "required": [ + "twn_nm", + "ctry", + "format", + "source", + "as_of" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "redirected_from": { + "description": "The bank code asked about, when the register answered for the one that took over its clearing (CH/LI only today: SIX marks an IID concatenated and publishes its successor). The IBAN stays valid — a redirect is not a retirement.", + "type": "string" + }, + "source": { + "description": "Source of the bank-code/BIC pairing; keep its provenance.", + "type": [ + "string", + "null" + ] + }, + "source_as_of": { + "description": "Year-month the SOURCE DATA is from, present only when it differs from as_of. as_of dates the import; for the redistributed SWIFT directory the upstream stopped publishing years ago, so as_of alone presents an old bank name as last month's. Absent means no gap has been established, never \"this is current\".", + "type": "string" + } + }, + "required": [ + "code", + "bank_name", + "city" + ], + "type": "object" + }, + { + "type": "null" + } +] - changed
Output schema / properties / results / items / properties / sepa / properties / vop_participant / descriptionPrevious value: -"true = resolved bank is listed as ready in the EPC VoP scheme register; null = no institution resolved."New value: +"true = resolved bank is listed as ready in the EPC VoP scheme register; null = no institution resolved, or the VoP register is not loaded (not consulted); a resolved bank outside the SEPA area is answered false from the country either way."
- Changed
check_compliance2 fields changed- changed
Output schema / properties / bic / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "address": { - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "as_of": { - "type": [ - "string", - "null" - ] - }, - "city": { - "type": [ - "string", - "null" - ] - }, - "country": { - "type": "string" - }, - "language": { - "type": [ - "string", - "null" - ] - }, - "post_code": { - "type": [ - "string", - "null" - ] - }, - "region": { - "type": [ - "string", - "null" - ] - }, - "romanization": { - "enum": [ - "original_latin", - "gleif_english", - "unavailable" - ], - "type": "string" - }, - "romanized": { - "type": [ - "string", - "null" - ] - }, - "source": { - "type": "string" - }, - "street": { - "type": [ - "string", - "null" - ] - }, - "type": { - "const": "registered", - "type": "string" - } - }, - "required": [ - "type", - "street", - "post_code", - "region", - "city", - "country", - "romanized", - "romanization", - "source", - "language", - "as_of" - ], - "type": "object" - }, - { - "type": "null" - } - ] - }, - "as_of": { - "type": [ - "string", - "null" - ] - }, - "authoritative": { - "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. San Marino is where the two part: the pairing is the supervisor’s, the code space is not its to settle.", - "type": "boolean" - }, - "bank_name": { - "type": [ - "string", - "null" - ] - }, - "basis": { - "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today CH, LI, DE, AT, BE, BG, SK and SM; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", - "type": "string" - }, - "bic8": { - "description": "The eight characters of the institution — the field to compare a supplied BIC against. code is served as the consulted source publishes it, so it is 8 or 11 characters; this one never moves. The branch code (last three characters) is informational: in a cooperative network it names the LOCAL bank and the first eight its clearing institution.", - "type": "string" - }, - "city": { - "type": [ - "string", - "null" - ] - }, - "code": { - "type": "string" - }, - "lei": { - "description": "GLEIF identity of the resolved BIC holder, not necessarily the bank-code holder.", - "type": [ - "string", - "null" - ] - }, - "lei_status": { - "type": [ - "string", - "null" - ] - }, - "postal_address": { - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "adr_line": { - "items": { - "type": "string" - }, - "type": "array" - }, - "as_of": { - "type": [ - "string", - "null" - ] - }, - "bldg_nb": { - "type": "string" - }, - "ctry": { - "type": "string" - }, - "format": { - "enum": [ - "structured", - "hybrid" - ], - "type": "string" - }, - "pst_cd": { - "type": "string" - }, - "source": { - "type": "string" - }, - "strt_nm": { - "type": "string" - }, - "twn_nm": { - "type": "string" - } - }, - "required": [ - "twn_nm", - "ctry", - "format", - "source", - "as_of" - ], - "type": "object" - }, - { - "type": "null" - } - ] - }, - "redirected_from": { - "description": "The bank code asked about, when the register answered for the one that took over its clearing (CH/LI only today: SIX marks an IID concatenated and publishes its successor). The IBAN stays valid — a redirect is not a retirement.", - "type": "string" - }, - "source": { - "description": "Source of the bank-code/BIC pairing; keep its provenance.", - "type": [ - "string", - "null" - ] - }, - "source_as_of": { - "description": "Year-month the SOURCE DATA is from, present only when it differs from as_of. as_of dates the import; for the redistributed SWIFT directory the upstream stopped publishing years ago, so as_of alone presents an old bank name as last month's. Absent means no gap has been established, never \"this is current\".", - "type": "string" - } - }, - "required": [ - "code", - "bank_name", - "city" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "address": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "as_of": { + "type": [ + "string", + "null" + ] + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "country": { + "type": "string" + }, + "language": { + "type": [ + "string", + "null" + ] + }, + "post_code": { + "type": [ + "string", + "null" + ] + }, + "region": { + "type": [ + "string", + "null" + ] + }, + "romanization": { + "enum": [ + "original_latin", + "gleif_english", + "unavailable" + ], + "type": "string" + }, + "romanized": { + "type": [ + "string", + "null" + ] + }, + "source": { + "type": "string" + }, + "street": { + "type": [ + "string", + "null" + ] + }, + "type": { + "const": "registered", + "type": "string" + } + }, + "required": [ + "type", + "street", + "post_code", + "region", + "city", + "country", + "romanized", + "romanization", + "source", + "language", + "as_of" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "as_of": { + "type": [ + "string", + "null" + ] + }, + "authoritative": { + "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. San Marino is where the two part: the pairing is the supervisor’s, the code space is not its to settle.", + "type": "boolean" + }, + "bank_name": { + "type": [ + "string", + "null" + ] + }, + "basis": { + "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today DE, AT, BE, SK, CZ, BG, CH, LI and SM; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", + "type": "string" + }, + "bic8": { + "description": "The eight characters of the institution — the field to compare a supplied BIC against. code is served as the consulted source publishes it, so it is 8 or 11 characters; this one never moves. The branch code (last three characters) is informational: in a cooperative network it names the LOCAL bank and the first eight its clearing institution.", + "type": "string" + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "code": { + "type": "string" + }, + "lei": { + "description": "GLEIF identity of the resolved BIC holder, not necessarily the bank-code holder.", + "type": [ + "string", + "null" + ] + }, + "lei_status": { + "type": [ + "string", + "null" + ] + }, + "postal_address": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "adr_line": { + "items": { + "type": "string" + }, + "type": "array" + }, + "as_of": { + "type": [ + "string", + "null" + ] + }, + "bldg_nb": { + "type": "string" + }, + "ctry": { + "type": "string" + }, + "format": { + "enum": [ + "structured", + "hybrid" + ], + "type": "string" + }, + "pst_cd": { + "type": "string" + }, + "source": { + "type": "string" + }, + "strt_nm": { + "type": "string" + }, + "twn_nm": { + "type": "string" + } + }, + "required": [ + "twn_nm", + "ctry", + "format", + "source", + "as_of" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "redirected_from": { + "description": "The bank code asked about, when the register answered for the one that took over its clearing (CH/LI only today: SIX marks an IID concatenated and publishes its successor). The IBAN stays valid — a redirect is not a retirement.", + "type": "string" + }, + "source": { + "description": "Source of the bank-code/BIC pairing; keep its provenance.", + "type": [ + "string", + "null" + ] + }, + "source_as_of": { + "description": "Year-month the SOURCE DATA is from, present only when it differs from as_of. as_of dates the import; for the redistributed SWIFT directory the upstream stopped publishing years ago, so as_of alone presents an old bank name as last month's. Absent means no gap has been established, never \"this is current\".", + "type": "string" + } + }, + "required": [ + "code", + "bank_name", + "city" + ], + "type": "object" + }, + { + "type": "null" + } +] - changed
Output schema / properties / sepa / properties / vop_participant / descriptionPrevious value: -"true = resolved bank is listed as ready in the EPC VoP scheme register; null = no institution resolved."New value: +"true = resolved bank is listed as ready in the EPC VoP scheme register; null = no institution resolved, or the VoP register is not loaded (not consulted); a resolved bank outside the SEPA area is answered false from the country either way."
- Changed
validate_iban2 fields changed- changed
Output schema / properties / bic / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "address": { - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "as_of": { - "type": [ - "string", - "null" - ] - }, - "city": { - "type": [ - "string", - "null" - ] - }, - "country": { - "type": "string" - }, - "language": { - "type": [ - "string", - "null" - ] - }, - "post_code": { - "type": [ - "string", - "null" - ] - }, - "region": { - "type": [ - "string", - "null" - ] - }, - "romanization": { - "enum": [ - "original_latin", - "gleif_english", - "unavailable" - ], - "type": "string" - }, - "romanized": { - "type": [ - "string", - "null" - ] - }, - "source": { - "type": "string" - }, - "street": { - "type": [ - "string", - "null" - ] - }, - "type": { - "const": "registered", - "type": "string" - } - }, - "required": [ - "type", - "street", - "post_code", - "region", - "city", - "country", - "romanized", - "romanization", - "source", - "language", - "as_of" - ], - "type": "object" - }, - { - "type": "null" - } - ] - }, - "as_of": { - "type": [ - "string", - "null" - ] - }, - "authoritative": { - "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. San Marino is where the two part: the pairing is the supervisor’s, the code space is not its to settle.", - "type": "boolean" - }, - "bank_name": { - "type": [ - "string", - "null" - ] - }, - "basis": { - "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today CH, LI, DE, AT, BE, BG, SK and SM; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", - "type": "string" - }, - "bic8": { - "description": "The eight characters of the institution — the field to compare a supplied BIC against. code is served as the consulted source publishes it, so it is 8 or 11 characters; this one never moves. The branch code (last three characters) is informational: in a cooperative network it names the LOCAL bank and the first eight its clearing institution.", - "type": "string" - }, - "city": { - "type": [ - "string", - "null" - ] - }, - "code": { - "type": "string" - }, - "lei": { - "description": "GLEIF identity of the resolved BIC holder, not necessarily the bank-code holder.", - "type": [ - "string", - "null" - ] - }, - "lei_status": { - "type": [ - "string", - "null" - ] - }, - "postal_address": { - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "adr_line": { - "items": { - "type": "string" - }, - "type": "array" - }, - "as_of": { - "type": [ - "string", - "null" - ] - }, - "bldg_nb": { - "type": "string" - }, - "ctry": { - "type": "string" - }, - "format": { - "enum": [ - "structured", - "hybrid" - ], - "type": "string" - }, - "pst_cd": { - "type": "string" - }, - "source": { - "type": "string" - }, - "strt_nm": { - "type": "string" - }, - "twn_nm": { - "type": "string" - } - }, - "required": [ - "twn_nm", - "ctry", - "format", - "source", - "as_of" - ], - "type": "object" - }, - { - "type": "null" - } - ] - }, - "redirected_from": { - "description": "The bank code asked about, when the register answered for the one that took over its clearing (CH/LI only today: SIX marks an IID concatenated and publishes its successor). The IBAN stays valid — a redirect is not a retirement.", - "type": "string" - }, - "source": { - "description": "Source of the bank-code/BIC pairing; keep its provenance.", - "type": [ - "string", - "null" - ] - }, - "source_as_of": { - "description": "Year-month the SOURCE DATA is from, present only when it differs from as_of. as_of dates the import; for the redistributed SWIFT directory the upstream stopped publishing years ago, so as_of alone presents an old bank name as last month's. Absent means no gap has been established, never \"this is current\".", - "type": "string" - } - }, - "required": [ - "code", - "bank_name", - "city" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "address": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "as_of": { + "type": [ + "string", + "null" + ] + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "country": { + "type": "string" + }, + "language": { + "type": [ + "string", + "null" + ] + }, + "post_code": { + "type": [ + "string", + "null" + ] + }, + "region": { + "type": [ + "string", + "null" + ] + }, + "romanization": { + "enum": [ + "original_latin", + "gleif_english", + "unavailable" + ], + "type": "string" + }, + "romanized": { + "type": [ + "string", + "null" + ] + }, + "source": { + "type": "string" + }, + "street": { + "type": [ + "string", + "null" + ] + }, + "type": { + "const": "registered", + "type": "string" + } + }, + "required": [ + "type", + "street", + "post_code", + "region", + "city", + "country", + "romanized", + "romanization", + "source", + "language", + "as_of" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "as_of": { + "type": [ + "string", + "null" + ] + }, + "authoritative": { + "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. San Marino is where the two part: the pairing is the supervisor’s, the code space is not its to settle.", + "type": "boolean" + }, + "bank_name": { + "type": [ + "string", + "null" + ] + }, + "basis": { + "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today DE, AT, BE, SK, CZ, BG, CH, LI and SM; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", + "type": "string" + }, + "bic8": { + "description": "The eight characters of the institution — the field to compare a supplied BIC against. code is served as the consulted source publishes it, so it is 8 or 11 characters; this one never moves. The branch code (last three characters) is informational: in a cooperative network it names the LOCAL bank and the first eight its clearing institution.", + "type": "string" + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "code": { + "type": "string" + }, + "lei": { + "description": "GLEIF identity of the resolved BIC holder, not necessarily the bank-code holder.", + "type": [ + "string", + "null" + ] + }, + "lei_status": { + "type": [ + "string", + "null" + ] + }, + "postal_address": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "adr_line": { + "items": { + "type": "string" + }, + "type": "array" + }, + "as_of": { + "type": [ + "string", + "null" + ] + }, + "bldg_nb": { + "type": "string" + }, + "ctry": { + "type": "string" + }, + "format": { + "enum": [ + "structured", + "hybrid" + ], + "type": "string" + }, + "pst_cd": { + "type": "string" + }, + "source": { + "type": "string" + }, + "strt_nm": { + "type": "string" + }, + "twn_nm": { + "type": "string" + } + }, + "required": [ + "twn_nm", + "ctry", + "format", + "source", + "as_of" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "redirected_from": { + "description": "The bank code asked about, when the register answered for the one that took over its clearing (CH/LI only today: SIX marks an IID concatenated and publishes its successor). The IBAN stays valid — a redirect is not a retirement.", + "type": "string" + }, + "source": { + "description": "Source of the bank-code/BIC pairing; keep its provenance.", + "type": [ + "string", + "null" + ] + }, + "source_as_of": { + "description": "Year-month the SOURCE DATA is from, present only when it differs from as_of. as_of dates the import; for the redistributed SWIFT directory the upstream stopped publishing years ago, so as_of alone presents an old bank name as last month's. Absent means no gap has been established, never \"this is current\".", + "type": "string" + } + }, + "required": [ + "code", + "bank_name", + "city" + ], + "type": "object" + }, + { + "type": "null" + } +] - changed
Output schema / properties / sepa / properties / vop_participant / descriptionPrevious value: -"true = resolved bank is listed as ready in the EPC VoP scheme register; null = no institution resolved."New value: +"true = resolved bank is listed as ready in the EPC VoP scheme register; null = no institution resolved, or the VoP register is not loaded (not consulted); a resolved bank outside the SEPA area is answered false from the country either way."
1 tool update
- Changed
check_compliance1 field changed- changed
Output schema / properties / meta / properties / sources / typePrevious value: -"string"New value: +[ + "string", + "null" +]
3 tool updates
- Changed
batch_validate_iban1 field changed- changed
Output schema / properties / results / items / properties / bic / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "address": { - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "as_of": { - "type": [ - "string", - "null" - ] - }, - "city": { - "type": [ - "string", - "null" - ] - }, - "country": { - "type": "string" - }, - "language": { - "type": [ - "string", - "null" - ] - }, - "post_code": { - "type": [ - "string", - "null" - ] - }, - "region": { - "type": [ - "string", - "null" - ] - }, - "romanization": { - "enum": [ - "original_latin", - "gleif_english", - "unavailable" - ], - "type": "string" - }, - "romanized": { - "type": [ - "string", - "null" - ] - }, - "source": { - "type": "string" - }, - "street": { - "type": [ - "string", - "null" - ] - }, - "type": { - "const": "registered", - "type": "string" - } - }, - "required": [ - "type", - "street", - "post_code", - "region", - "city", - "country", - "romanized", - "romanization", - "source", - "language", - "as_of" - ], - "type": "object" - }, - { - "type": "null" - } - ] - }, - "as_of": { - "type": [ - "string", - "null" - ] - }, - "authoritative": { - "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. San Marino is where the two part: the pairing is the supervisor’s, the code space is not its to settle.", - "type": "boolean" - }, - "bank_name": { - "type": [ - "string", - "null" - ] - }, - "basis": { - "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today CH, LI, DE, AT, BE, BG, SK and SM; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", - "type": "string" - }, - "bic8": { - "description": "The eight characters of the institution — the field to compare a supplied BIC against. code is served as the consulted source publishes it, so it is 8 or 11 characters; this one never moves. The branch code (last three characters) is informational: in a cooperative network it names the LOCAL bank and the first eight its clearing institution.", - "type": "string" - }, - "city": { - "type": [ - "string", - "null" - ] - }, - "code": { - "type": "string" - }, - "lei": { - "description": "GLEIF identity of the resolved BIC holder, not necessarily the bank-code holder.", - "type": [ - "string", - "null" - ] - }, - "lei_status": { - "type": [ - "string", - "null" - ] - }, - "postal_address": { - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "adr_line": { - "items": { - "type": "string" - }, - "type": "array" - }, - "as_of": { - "type": [ - "string", - "null" - ] - }, - "bldg_nb": { - "type": "string" - }, - "ctry": { - "type": "string" - }, - "format": { - "enum": [ - "structured", - "hybrid" - ], - "type": "string" - }, - "pst_cd": { - "type": "string" - }, - "source": { - "type": "string" - }, - "strt_nm": { - "type": "string" - }, - "twn_nm": { - "type": "string" - } - }, - "required": [ - "twn_nm", - "ctry", - "format", - "source", - "as_of" - ], - "type": "object" - }, - { - "type": "null" - } - ] - }, - "redirected_from": { - "description": "The bank code asked about, when the register answered for the one that took over its clearing (CH/LI only today: SIX marks an IID concatenated and publishes its successor). The IBAN stays valid — a redirect is not a retirement.", - "type": "string" - }, - "source": { - "description": "Source of the bank-code/BIC pairing; keep its provenance.", - "type": [ - "string", - "null" - ] - } - }, - "required": [ - "code", - "bank_name", - "city" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "address": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "as_of": { + "type": [ + "string", + "null" + ] + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "country": { + "type": "string" + }, + "language": { + "type": [ + "string", + "null" + ] + }, + "post_code": { + "type": [ + "string", + "null" + ] + }, + "region": { + "type": [ + "string", + "null" + ] + }, + "romanization": { + "enum": [ + "original_latin", + "gleif_english", + "unavailable" + ], + "type": "string" + }, + "romanized": { + "type": [ + "string", + "null" + ] + }, + "source": { + "type": "string" + }, + "street": { + "type": [ + "string", + "null" + ] + }, + "type": { + "const": "registered", + "type": "string" + } + }, + "required": [ + "type", + "street", + "post_code", + "region", + "city", + "country", + "romanized", + "romanization", + "source", + "language", + "as_of" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "as_of": { + "type": [ + "string", + "null" + ] + }, + "authoritative": { + "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. San Marino is where the two part: the pairing is the supervisor’s, the code space is not its to settle.", + "type": "boolean" + }, + "bank_name": { + "type": [ + "string", + "null" + ] + }, + "basis": { + "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today CH, LI, DE, AT, BE, BG, SK and SM; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", + "type": "string" + }, + "bic8": { + "description": "The eight characters of the institution — the field to compare a supplied BIC against. code is served as the consulted source publishes it, so it is 8 or 11 characters; this one never moves. The branch code (last three characters) is informational: in a cooperative network it names the LOCAL bank and the first eight its clearing institution.", + "type": "string" + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "code": { + "type": "string" + }, + "lei": { + "description": "GLEIF identity of the resolved BIC holder, not necessarily the bank-code holder.", + "type": [ + "string", + "null" + ] + }, + "lei_status": { + "type": [ + "string", + "null" + ] + }, + "postal_address": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "adr_line": { + "items": { + "type": "string" + }, + "type": "array" + }, + "as_of": { + "type": [ + "string", + "null" + ] + }, + "bldg_nb": { + "type": "string" + }, + "ctry": { + "type": "string" + }, + "format": { + "enum": [ + "structured", + "hybrid" + ], + "type": "string" + }, + "pst_cd": { + "type": "string" + }, + "source": { + "type": "string" + }, + "strt_nm": { + "type": "string" + }, + "twn_nm": { + "type": "string" + } + }, + "required": [ + "twn_nm", + "ctry", + "format", + "source", + "as_of" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "redirected_from": { + "description": "The bank code asked about, when the register answered for the one that took over its clearing (CH/LI only today: SIX marks an IID concatenated and publishes its successor). The IBAN stays valid — a redirect is not a retirement.", + "type": "string" + }, + "source": { + "description": "Source of the bank-code/BIC pairing; keep its provenance.", + "type": [ + "string", + "null" + ] + }, + "source_as_of": { + "description": "Year-month the SOURCE DATA is from, present only when it differs from as_of. as_of dates the import; for the redistributed SWIFT directory the upstream stopped publishing years ago, so as_of alone presents an old bank name as last month's. Absent means no gap has been established, never \"this is current\".", + "type": "string" + } + }, + "required": [ + "code", + "bank_name", + "city" + ], + "type": "object" + }, + { + "type": "null" + } +]
- Changed
check_compliance1 field changed- changed
Output schema / properties / bic / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "address": { - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "as_of": { - "type": [ - "string", - "null" - ] - }, - "city": { - "type": [ - "string", - "null" - ] - }, - "country": { - "type": "string" - }, - "language": { - "type": [ - "string", - "null" - ] - }, - "post_code": { - "type": [ - "string", - "null" - ] - }, - "region": { - "type": [ - "string", - "null" - ] - }, - "romanization": { - "enum": [ - "original_latin", - "gleif_english", - "unavailable" - ], - "type": "string" - }, - "romanized": { - "type": [ - "string", - "null" - ] - }, - "source": { - "type": "string" - }, - "street": { - "type": [ - "string", - "null" - ] - }, - "type": { - "const": "registered", - "type": "string" - } - }, - "required": [ - "type", - "street", - "post_code", - "region", - "city", - "country", - "romanized", - "romanization", - "source", - "language", - "as_of" - ], - "type": "object" - }, - { - "type": "null" - } - ] - }, - "as_of": { - "type": [ - "string", - "null" - ] - }, - "authoritative": { - "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. San Marino is where the two part: the pairing is the supervisor’s, the code space is not its to settle.", - "type": "boolean" - }, - "bank_name": { - "type": [ - "string", - "null" - ] - }, - "basis": { - "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today CH, LI, DE, AT, BE, BG, SK and SM; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", - "type": "string" - }, - "bic8": { - "description": "The eight characters of the institution — the field to compare a supplied BIC against. code is served as the consulted source publishes it, so it is 8 or 11 characters; this one never moves. The branch code (last three characters) is informational: in a cooperative network it names the LOCAL bank and the first eight its clearing institution.", - "type": "string" - }, - "city": { - "type": [ - "string", - "null" - ] - }, - "code": { - "type": "string" - }, - "lei": { - "description": "GLEIF identity of the resolved BIC holder, not necessarily the bank-code holder.", - "type": [ - "string", - "null" - ] - }, - "lei_status": { - "type": [ - "string", - "null" - ] - }, - "postal_address": { - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "adr_line": { - "items": { - "type": "string" - }, - "type": "array" - }, - "as_of": { - "type": [ - "string", - "null" - ] - }, - "bldg_nb": { - "type": "string" - }, - "ctry": { - "type": "string" - }, - "format": { - "enum": [ - "structured", - "hybrid" - ], - "type": "string" - }, - "pst_cd": { - "type": "string" - }, - "source": { - "type": "string" - }, - "strt_nm": { - "type": "string" - }, - "twn_nm": { - "type": "string" - } - }, - "required": [ - "twn_nm", - "ctry", - "format", - "source", - "as_of" - ], - "type": "object" - }, - { - "type": "null" - } - ] - }, - "redirected_from": { - "description": "The bank code asked about, when the register answered for the one that took over its clearing (CH/LI only today: SIX marks an IID concatenated and publishes its successor). The IBAN stays valid — a redirect is not a retirement.", - "type": "string" - }, - "source": { - "description": "Source of the bank-code/BIC pairing; keep its provenance.", - "type": [ - "string", - "null" - ] - } - }, - "required": [ - "code", - "bank_name", - "city" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "address": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "as_of": { + "type": [ + "string", + "null" + ] + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "country": { + "type": "string" + }, + "language": { + "type": [ + "string", + "null" + ] + }, + "post_code": { + "type": [ + "string", + "null" + ] + }, + "region": { + "type": [ + "string", + "null" + ] + }, + "romanization": { + "enum": [ + "original_latin", + "gleif_english", + "unavailable" + ], + "type": "string" + }, + "romanized": { + "type": [ + "string", + "null" + ] + }, + "source": { + "type": "string" + }, + "street": { + "type": [ + "string", + "null" + ] + }, + "type": { + "const": "registered", + "type": "string" + } + }, + "required": [ + "type", + "street", + "post_code", + "region", + "city", + "country", + "romanized", + "romanization", + "source", + "language", + "as_of" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "as_of": { + "type": [ + "string", + "null" + ] + }, + "authoritative": { + "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. San Marino is where the two part: the pairing is the supervisor’s, the code space is not its to settle.", + "type": "boolean" + }, + "bank_name": { + "type": [ + "string", + "null" + ] + }, + "basis": { + "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today CH, LI, DE, AT, BE, BG, SK and SM; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", + "type": "string" + }, + "bic8": { + "description": "The eight characters of the institution — the field to compare a supplied BIC against. code is served as the consulted source publishes it, so it is 8 or 11 characters; this one never moves. The branch code (last three characters) is informational: in a cooperative network it names the LOCAL bank and the first eight its clearing institution.", + "type": "string" + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "code": { + "type": "string" + }, + "lei": { + "description": "GLEIF identity of the resolved BIC holder, not necessarily the bank-code holder.", + "type": [ + "string", + "null" + ] + }, + "lei_status": { + "type": [ + "string", + "null" + ] + }, + "postal_address": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "adr_line": { + "items": { + "type": "string" + }, + "type": "array" + }, + "as_of": { + "type": [ + "string", + "null" + ] + }, + "bldg_nb": { + "type": "string" + }, + "ctry": { + "type": "string" + }, + "format": { + "enum": [ + "structured", + "hybrid" + ], + "type": "string" + }, + "pst_cd": { + "type": "string" + }, + "source": { + "type": "string" + }, + "strt_nm": { + "type": "string" + }, + "twn_nm": { + "type": "string" + } + }, + "required": [ + "twn_nm", + "ctry", + "format", + "source", + "as_of" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "redirected_from": { + "description": "The bank code asked about, when the register answered for the one that took over its clearing (CH/LI only today: SIX marks an IID concatenated and publishes its successor). The IBAN stays valid — a redirect is not a retirement.", + "type": "string" + }, + "source": { + "description": "Source of the bank-code/BIC pairing; keep its provenance.", + "type": [ + "string", + "null" + ] + }, + "source_as_of": { + "description": "Year-month the SOURCE DATA is from, present only when it differs from as_of. as_of dates the import; for the redistributed SWIFT directory the upstream stopped publishing years ago, so as_of alone presents an old bank name as last month's. Absent means no gap has been established, never \"this is current\".", + "type": "string" + } + }, + "required": [ + "code", + "bank_name", + "city" + ], + "type": "object" + }, + { + "type": "null" + } +]
- Changed
validate_iban1 field changed- changed
Output schema / properties / bic / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "address": { - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "as_of": { - "type": [ - "string", - "null" - ] - }, - "city": { - "type": [ - "string", - "null" - ] - }, - "country": { - "type": "string" - }, - "language": { - "type": [ - "string", - "null" - ] - }, - "post_code": { - "type": [ - "string", - "null" - ] - }, - "region": { - "type": [ - "string", - "null" - ] - }, - "romanization": { - "enum": [ - "original_latin", - "gleif_english", - "unavailable" - ], - "type": "string" - }, - "romanized": { - "type": [ - "string", - "null" - ] - }, - "source": { - "type": "string" - }, - "street": { - "type": [ - "string", - "null" - ] - }, - "type": { - "const": "registered", - "type": "string" - } - }, - "required": [ - "type", - "street", - "post_code", - "region", - "city", - "country", - "romanized", - "romanization", - "source", - "language", - "as_of" - ], - "type": "object" - }, - { - "type": "null" - } - ] - }, - "as_of": { - "type": [ - "string", - "null" - ] - }, - "authoritative": { - "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. San Marino is where the two part: the pairing is the supervisor’s, the code space is not its to settle.", - "type": "boolean" - }, - "bank_name": { - "type": [ - "string", - "null" - ] - }, - "basis": { - "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today CH, LI, DE, AT, BE, BG, SK and SM; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", - "type": "string" - }, - "bic8": { - "description": "The eight characters of the institution — the field to compare a supplied BIC against. code is served as the consulted source publishes it, so it is 8 or 11 characters; this one never moves. The branch code (last three characters) is informational: in a cooperative network it names the LOCAL bank and the first eight its clearing institution.", - "type": "string" - }, - "city": { - "type": [ - "string", - "null" - ] - }, - "code": { - "type": "string" - }, - "lei": { - "description": "GLEIF identity of the resolved BIC holder, not necessarily the bank-code holder.", - "type": [ - "string", - "null" - ] - }, - "lei_status": { - "type": [ - "string", - "null" - ] - }, - "postal_address": { - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "adr_line": { - "items": { - "type": "string" - }, - "type": "array" - }, - "as_of": { - "type": [ - "string", - "null" - ] - }, - "bldg_nb": { - "type": "string" - }, - "ctry": { - "type": "string" - }, - "format": { - "enum": [ - "structured", - "hybrid" - ], - "type": "string" - }, - "pst_cd": { - "type": "string" - }, - "source": { - "type": "string" - }, - "strt_nm": { - "type": "string" - }, - "twn_nm": { - "type": "string" - } - }, - "required": [ - "twn_nm", - "ctry", - "format", - "source", - "as_of" - ], - "type": "object" - }, - { - "type": "null" - } - ] - }, - "redirected_from": { - "description": "The bank code asked about, when the register answered for the one that took over its clearing (CH/LI only today: SIX marks an IID concatenated and publishes its successor). The IBAN stays valid — a redirect is not a retirement.", - "type": "string" - }, - "source": { - "description": "Source of the bank-code/BIC pairing; keep its provenance.", - "type": [ - "string", - "null" - ] - } - }, - "required": [ - "code", - "bank_name", - "city" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "address": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "as_of": { + "type": [ + "string", + "null" + ] + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "country": { + "type": "string" + }, + "language": { + "type": [ + "string", + "null" + ] + }, + "post_code": { + "type": [ + "string", + "null" + ] + }, + "region": { + "type": [ + "string", + "null" + ] + }, + "romanization": { + "enum": [ + "original_latin", + "gleif_english", + "unavailable" + ], + "type": "string" + }, + "romanized": { + "type": [ + "string", + "null" + ] + }, + "source": { + "type": "string" + }, + "street": { + "type": [ + "string", + "null" + ] + }, + "type": { + "const": "registered", + "type": "string" + } + }, + "required": [ + "type", + "street", + "post_code", + "region", + "city", + "country", + "romanized", + "romanization", + "source", + "language", + "as_of" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "as_of": { + "type": [ + "string", + "null" + ] + }, + "authoritative": { + "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. San Marino is where the two part: the pairing is the supervisor’s, the code space is not its to settle.", + "type": "boolean" + }, + "bank_name": { + "type": [ + "string", + "null" + ] + }, + "basis": { + "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today CH, LI, DE, AT, BE, BG, SK and SM; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", + "type": "string" + }, + "bic8": { + "description": "The eight characters of the institution — the field to compare a supplied BIC against. code is served as the consulted source publishes it, so it is 8 or 11 characters; this one never moves. The branch code (last three characters) is informational: in a cooperative network it names the LOCAL bank and the first eight its clearing institution.", + "type": "string" + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "code": { + "type": "string" + }, + "lei": { + "description": "GLEIF identity of the resolved BIC holder, not necessarily the bank-code holder.", + "type": [ + "string", + "null" + ] + }, + "lei_status": { + "type": [ + "string", + "null" + ] + }, + "postal_address": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "adr_line": { + "items": { + "type": "string" + }, + "type": "array" + }, + "as_of": { + "type": [ + "string", + "null" + ] + }, + "bldg_nb": { + "type": "string" + }, + "ctry": { + "type": "string" + }, + "format": { + "enum": [ + "structured", + "hybrid" + ], + "type": "string" + }, + "pst_cd": { + "type": "string" + }, + "source": { + "type": "string" + }, + "strt_nm": { + "type": "string" + }, + "twn_nm": { + "type": "string" + } + }, + "required": [ + "twn_nm", + "ctry", + "format", + "source", + "as_of" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "redirected_from": { + "description": "The bank code asked about, when the register answered for the one that took over its clearing (CH/LI only today: SIX marks an IID concatenated and publishes its successor). The IBAN stays valid — a redirect is not a retirement.", + "type": "string" + }, + "source": { + "description": "Source of the bank-code/BIC pairing; keep its provenance.", + "type": [ + "string", + "null" + ] + }, + "source_as_of": { + "description": "Year-month the SOURCE DATA is from, present only when it differs from as_of. as_of dates the import; for the redistributed SWIFT directory the upstream stopped publishing years ago, so as_of alone presents an old bank name as last month's. Absent means no gap has been established, never \"this is current\".", + "type": "string" + } + }, + "required": [ + "code", + "bank_name", + "city" + ], + "type": "object" + }, + { + "type": "null" + } +]
3 tool updates
- Changed
batch_validate_iban1 field changed- changed
Output schema / properties / results / items / properties / bic / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "address": { - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "as_of": { - "type": [ - "string", - "null" - ] - }, - "city": { - "type": [ - "string", - "null" - ] - }, - "country": { - "type": "string" - }, - "language": { - "type": [ - "string", - "null" - ] - }, - "post_code": { - "type": [ - "string", - "null" - ] - }, - "region": { - "type": [ - "string", - "null" - ] - }, - "romanization": { - "enum": [ - "original_latin", - "gleif_english", - "unavailable" - ], - "type": "string" - }, - "romanized": { - "type": [ - "string", - "null" - ] - }, - "source": { - "type": "string" - }, - "street": { - "type": [ - "string", - "null" - ] - }, - "type": { - "const": "registered", - "type": "string" - } - }, - "required": [ - "type", - "street", - "post_code", - "region", - "city", - "country", - "romanized", - "romanization", - "source", - "language", - "as_of" - ], - "type": "object" - }, - { - "type": "null" - } - ] - }, - "as_of": { - "type": [ - "string", - "null" - ] - }, - "authoritative": { - "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. In Switzerland the register confirms the code while the BIC still comes from our curated map.", - "type": "boolean" - }, - "bank_name": { - "type": [ - "string", - "null" - ] - }, - "basis": { - "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today DE, AT, BE, BG, SK and SM; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", - "type": "string" - }, - "city": { - "type": [ - "string", - "null" - ] - }, - "code": { - "type": "string" - }, - "lei": { - "description": "GLEIF identity of the resolved BIC holder, not necessarily the bank-code holder.", - "type": [ - "string", - "null" - ] - }, - "lei_status": { - "type": [ - "string", - "null" - ] - }, - "postal_address": { - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "adr_line": { - "items": { - "type": "string" - }, - "type": "array" - }, - "as_of": { - "type": [ - "string", - "null" - ] - }, - "bldg_nb": { - "type": "string" - }, - "ctry": { - "type": "string" - }, - "format": { - "enum": [ - "structured", - "hybrid" - ], - "type": "string" - }, - "pst_cd": { - "type": "string" - }, - "source": { - "type": "string" - }, - "strt_nm": { - "type": "string" - }, - "twn_nm": { - "type": "string" - } - }, - "required": [ - "twn_nm", - "ctry", - "format", - "source", - "as_of" - ], - "type": "object" - }, - { - "type": "null" - } - ] - }, - "source": { - "description": "Source of the bank-code/BIC pairing; keep its provenance.", - "type": [ - "string", - "null" - ] - } - }, - "required": [ - "code", - "bank_name", - "city" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "address": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "as_of": { + "type": [ + "string", + "null" + ] + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "country": { + "type": "string" + }, + "language": { + "type": [ + "string", + "null" + ] + }, + "post_code": { + "type": [ + "string", + "null" + ] + }, + "region": { + "type": [ + "string", + "null" + ] + }, + "romanization": { + "enum": [ + "original_latin", + "gleif_english", + "unavailable" + ], + "type": "string" + }, + "romanized": { + "type": [ + "string", + "null" + ] + }, + "source": { + "type": "string" + }, + "street": { + "type": [ + "string", + "null" + ] + }, + "type": { + "const": "registered", + "type": "string" + } + }, + "required": [ + "type", + "street", + "post_code", + "region", + "city", + "country", + "romanized", + "romanization", + "source", + "language", + "as_of" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "as_of": { + "type": [ + "string", + "null" + ] + }, + "authoritative": { + "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. San Marino is where the two part: the pairing is the supervisor’s, the code space is not its to settle.", + "type": "boolean" + }, + "bank_name": { + "type": [ + "string", + "null" + ] + }, + "basis": { + "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today CH, LI, DE, AT, BE, BG, SK and SM; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", + "type": "string" + }, + "bic8": { + "description": "The eight characters of the institution — the field to compare a supplied BIC against. code is served as the consulted source publishes it, so it is 8 or 11 characters; this one never moves. The branch code (last three characters) is informational: in a cooperative network it names the LOCAL bank and the first eight its clearing institution.", + "type": "string" + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "code": { + "type": "string" + }, + "lei": { + "description": "GLEIF identity of the resolved BIC holder, not necessarily the bank-code holder.", + "type": [ + "string", + "null" + ] + }, + "lei_status": { + "type": [ + "string", + "null" + ] + }, + "postal_address": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "adr_line": { + "items": { + "type": "string" + }, + "type": "array" + }, + "as_of": { + "type": [ + "string", + "null" + ] + }, + "bldg_nb": { + "type": "string" + }, + "ctry": { + "type": "string" + }, + "format": { + "enum": [ + "structured", + "hybrid" + ], + "type": "string" + }, + "pst_cd": { + "type": "string" + }, + "source": { + "type": "string" + }, + "strt_nm": { + "type": "string" + }, + "twn_nm": { + "type": "string" + } + }, + "required": [ + "twn_nm", + "ctry", + "format", + "source", + "as_of" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "redirected_from": { + "description": "The bank code asked about, when the register answered for the one that took over its clearing (CH/LI only today: SIX marks an IID concatenated and publishes its successor). The IBAN stays valid — a redirect is not a retirement.", + "type": "string" + }, + "source": { + "description": "Source of the bank-code/BIC pairing; keep its provenance.", + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "code", + "bank_name", + "city" + ], + "type": "object" + }, + { + "type": "null" + } +]
- Changed
check_compliance1 field changed- changed
Output schema / properties / bic / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "address": { - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "as_of": { - "type": [ - "string", - "null" - ] - }, - "city": { - "type": [ - "string", - "null" - ] - }, - "country": { - "type": "string" - }, - "language": { - "type": [ - "string", - "null" - ] - }, - "post_code": { - "type": [ - "string", - "null" - ] - }, - "region": { - "type": [ - "string", - "null" - ] - }, - "romanization": { - "enum": [ - "original_latin", - "gleif_english", - "unavailable" - ], - "type": "string" - }, - "romanized": { - "type": [ - "string", - "null" - ] - }, - "source": { - "type": "string" - }, - "street": { - "type": [ - "string", - "null" - ] - }, - "type": { - "const": "registered", - "type": "string" - } - }, - "required": [ - "type", - "street", - "post_code", - "region", - "city", - "country", - "romanized", - "romanization", - "source", - "language", - "as_of" - ], - "type": "object" - }, - { - "type": "null" - } - ] - }, - "as_of": { - "type": [ - "string", - "null" - ] - }, - "authoritative": { - "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. In Switzerland the register confirms the code while the BIC still comes from our curated map.", - "type": "boolean" - }, - "bank_name": { - "type": [ - "string", - "null" - ] - }, - "basis": { - "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today DE, AT, BE, BG, SK and SM; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", - "type": "string" - }, - "city": { - "type": [ - "string", - "null" - ] - }, - "code": { - "type": "string" - }, - "lei": { - "description": "GLEIF identity of the resolved BIC holder, not necessarily the bank-code holder.", - "type": [ - "string", - "null" - ] - }, - "lei_status": { - "type": [ - "string", - "null" - ] - }, - "postal_address": { - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "adr_line": { - "items": { - "type": "string" - }, - "type": "array" - }, - "as_of": { - "type": [ - "string", - "null" - ] - }, - "bldg_nb": { - "type": "string" - }, - "ctry": { - "type": "string" - }, - "format": { - "enum": [ - "structured", - "hybrid" - ], - "type": "string" - }, - "pst_cd": { - "type": "string" - }, - "source": { - "type": "string" - }, - "strt_nm": { - "type": "string" - }, - "twn_nm": { - "type": "string" - } - }, - "required": [ - "twn_nm", - "ctry", - "format", - "source", - "as_of" - ], - "type": "object" - }, - { - "type": "null" - } - ] - }, - "source": { - "description": "Source of the bank-code/BIC pairing; keep its provenance.", - "type": [ - "string", - "null" - ] - } - }, - "required": [ - "code", - "bank_name", - "city" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "address": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "as_of": { + "type": [ + "string", + "null" + ] + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "country": { + "type": "string" + }, + "language": { + "type": [ + "string", + "null" + ] + }, + "post_code": { + "type": [ + "string", + "null" + ] + }, + "region": { + "type": [ + "string", + "null" + ] + }, + "romanization": { + "enum": [ + "original_latin", + "gleif_english", + "unavailable" + ], + "type": "string" + }, + "romanized": { + "type": [ + "string", + "null" + ] + }, + "source": { + "type": "string" + }, + "street": { + "type": [ + "string", + "null" + ] + }, + "type": { + "const": "registered", + "type": "string" + } + }, + "required": [ + "type", + "street", + "post_code", + "region", + "city", + "country", + "romanized", + "romanization", + "source", + "language", + "as_of" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "as_of": { + "type": [ + "string", + "null" + ] + }, + "authoritative": { + "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. San Marino is where the two part: the pairing is the supervisor’s, the code space is not its to settle.", + "type": "boolean" + }, + "bank_name": { + "type": [ + "string", + "null" + ] + }, + "basis": { + "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today CH, LI, DE, AT, BE, BG, SK and SM; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", + "type": "string" + }, + "bic8": { + "description": "The eight characters of the institution — the field to compare a supplied BIC against. code is served as the consulted source publishes it, so it is 8 or 11 characters; this one never moves. The branch code (last three characters) is informational: in a cooperative network it names the LOCAL bank and the first eight its clearing institution.", + "type": "string" + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "code": { + "type": "string" + }, + "lei": { + "description": "GLEIF identity of the resolved BIC holder, not necessarily the bank-code holder.", + "type": [ + "string", + "null" + ] + }, + "lei_status": { + "type": [ + "string", + "null" + ] + }, + "postal_address": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "adr_line": { + "items": { + "type": "string" + }, + "type": "array" + }, + "as_of": { + "type": [ + "string", + "null" + ] + }, + "bldg_nb": { + "type": "string" + }, + "ctry": { + "type": "string" + }, + "format": { + "enum": [ + "structured", + "hybrid" + ], + "type": "string" + }, + "pst_cd": { + "type": "string" + }, + "source": { + "type": "string" + }, + "strt_nm": { + "type": "string" + }, + "twn_nm": { + "type": "string" + } + }, + "required": [ + "twn_nm", + "ctry", + "format", + "source", + "as_of" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "redirected_from": { + "description": "The bank code asked about, when the register answered for the one that took over its clearing (CH/LI only today: SIX marks an IID concatenated and publishes its successor). The IBAN stays valid — a redirect is not a retirement.", + "type": "string" + }, + "source": { + "description": "Source of the bank-code/BIC pairing; keep its provenance.", + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "code", + "bank_name", + "city" + ], + "type": "object" + }, + { + "type": "null" + } +]
- Changed
validate_iban1 field changed- changed
Output schema / properties / bic / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "address": { - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "as_of": { - "type": [ - "string", - "null" - ] - }, - "city": { - "type": [ - "string", - "null" - ] - }, - "country": { - "type": "string" - }, - "language": { - "type": [ - "string", - "null" - ] - }, - "post_code": { - "type": [ - "string", - "null" - ] - }, - "region": { - "type": [ - "string", - "null" - ] - }, - "romanization": { - "enum": [ - "original_latin", - "gleif_english", - "unavailable" - ], - "type": "string" - }, - "romanized": { - "type": [ - "string", - "null" - ] - }, - "source": { - "type": "string" - }, - "street": { - "type": [ - "string", - "null" - ] - }, - "type": { - "const": "registered", - "type": "string" - } - }, - "required": [ - "type", - "street", - "post_code", - "region", - "city", - "country", - "romanized", - "romanization", - "source", - "language", - "as_of" - ], - "type": "object" - }, - { - "type": "null" - } - ] - }, - "as_of": { - "type": [ - "string", - "null" - ] - }, - "authoritative": { - "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. In Switzerland the register confirms the code while the BIC still comes from our curated map.", - "type": "boolean" - }, - "bank_name": { - "type": [ - "string", - "null" - ] - }, - "basis": { - "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today DE, AT, BE, BG, SK and SM; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", - "type": "string" - }, - "city": { - "type": [ - "string", - "null" - ] - }, - "code": { - "type": "string" - }, - "lei": { - "description": "GLEIF identity of the resolved BIC holder, not necessarily the bank-code holder.", - "type": [ - "string", - "null" - ] - }, - "lei_status": { - "type": [ - "string", - "null" - ] - }, - "postal_address": { - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "adr_line": { - "items": { - "type": "string" - }, - "type": "array" - }, - "as_of": { - "type": [ - "string", - "null" - ] - }, - "bldg_nb": { - "type": "string" - }, - "ctry": { - "type": "string" - }, - "format": { - "enum": [ - "structured", - "hybrid" - ], - "type": "string" - }, - "pst_cd": { - "type": "string" - }, - "source": { - "type": "string" - }, - "strt_nm": { - "type": "string" - }, - "twn_nm": { - "type": "string" - } - }, - "required": [ - "twn_nm", - "ctry", - "format", - "source", - "as_of" - ], - "type": "object" - }, - { - "type": "null" - } - ] - }, - "source": { - "description": "Source of the bank-code/BIC pairing; keep its provenance.", - "type": [ - "string", - "null" - ] - } - }, - "required": [ - "code", - "bank_name", - "city" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "address": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "as_of": { + "type": [ + "string", + "null" + ] + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "country": { + "type": "string" + }, + "language": { + "type": [ + "string", + "null" + ] + }, + "post_code": { + "type": [ + "string", + "null" + ] + }, + "region": { + "type": [ + "string", + "null" + ] + }, + "romanization": { + "enum": [ + "original_latin", + "gleif_english", + "unavailable" + ], + "type": "string" + }, + "romanized": { + "type": [ + "string", + "null" + ] + }, + "source": { + "type": "string" + }, + "street": { + "type": [ + "string", + "null" + ] + }, + "type": { + "const": "registered", + "type": "string" + } + }, + "required": [ + "type", + "street", + "post_code", + "region", + "city", + "country", + "romanized", + "romanization", + "source", + "language", + "as_of" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "as_of": { + "type": [ + "string", + "null" + ] + }, + "authoritative": { + "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. San Marino is where the two part: the pairing is the supervisor’s, the code space is not its to settle.", + "type": "boolean" + }, + "bank_name": { + "type": [ + "string", + "null" + ] + }, + "basis": { + "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today CH, LI, DE, AT, BE, BG, SK and SM; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", + "type": "string" + }, + "bic8": { + "description": "The eight characters of the institution — the field to compare a supplied BIC against. code is served as the consulted source publishes it, so it is 8 or 11 characters; this one never moves. The branch code (last three characters) is informational: in a cooperative network it names the LOCAL bank and the first eight its clearing institution.", + "type": "string" + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "code": { + "type": "string" + }, + "lei": { + "description": "GLEIF identity of the resolved BIC holder, not necessarily the bank-code holder.", + "type": [ + "string", + "null" + ] + }, + "lei_status": { + "type": [ + "string", + "null" + ] + }, + "postal_address": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "adr_line": { + "items": { + "type": "string" + }, + "type": "array" + }, + "as_of": { + "type": [ + "string", + "null" + ] + }, + "bldg_nb": { + "type": "string" + }, + "ctry": { + "type": "string" + }, + "format": { + "enum": [ + "structured", + "hybrid" + ], + "type": "string" + }, + "pst_cd": { + "type": "string" + }, + "source": { + "type": "string" + }, + "strt_nm": { + "type": "string" + }, + "twn_nm": { + "type": "string" + } + }, + "required": [ + "twn_nm", + "ctry", + "format", + "source", + "as_of" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "redirected_from": { + "description": "The bank code asked about, when the register answered for the one that took over its clearing (CH/LI only today: SIX marks an IID concatenated and publishes its successor). The IBAN stays valid — a redirect is not a retirement.", + "type": "string" + }, + "source": { + "description": "Source of the bank-code/BIC pairing; keep its provenance.", + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "code", + "bank_name", + "city" + ], + "type": "object" + }, + { + "type": "null" + } +]
2 tool updates
- Added
poll_api_key - Added
request_api_key
3 tool updates
- Changed
batch_validate_iban23 fields changed- added
Output schema / properties / results / items / properties / bank_code_check / properties / check_digitAdded value: +{ + "additionalProperties": false, + "properties": { + "algorithm": { + "type": "string" + }, + "valid": { + "type": "boolean" + } + }, + "required": [ + "valid", + "algorithm" + ], + "type": "object" +} - added
Output schema / properties / results / items / properties / bank_code_check / properties / institutionAdded value: +{ + "additionalProperties": false, + "properties": { + "country": { + "type": "string" + }, + "lei": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "post_code": { + "type": [ + "string", + "null" + ] + }, + "street": { + "type": [ + "string", + "null" + ] + }, + "town": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "name", + "street", + "post_code", + "town", + "country" + ], + "type": "object" +} - changed
Output schema / properties / results / items / properties / bic / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "authoritative": { - "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. In Switzerland the register confirms the code while the BIC still comes from our curated map.", - "type": "boolean" - }, - "bank_name": { - "type": [ - "string", - "null" - ] - }, - "basis": { - "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today DE, AT, BE, BG, SK and SM; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", - "type": "string" - }, - "city": { - "type": [ - "string", - "null" - ] - }, - "code": { - "type": "string" - } - }, - "required": [ - "code", - "bank_name", - "city" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "address": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "as_of": { + "type": [ + "string", + "null" + ] + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "country": { + "type": "string" + }, + "language": { + "type": [ + "string", + "null" + ] + }, + "post_code": { + "type": [ + "string", + "null" + ] + }, + "region": { + "type": [ + "string", + "null" + ] + }, + "romanization": { + "enum": [ + "original_latin", + "gleif_english", + "unavailable" + ], + "type": "string" + }, + "romanized": { + "type": [ + "string", + "null" + ] + }, + "source": { + "type": "string" + }, + "street": { + "type": [ + "string", + "null" + ] + }, + "type": { + "const": "registered", + "type": "string" + } + }, + "required": [ + "type", + "street", + "post_code", + "region", + "city", + "country", + "romanized", + "romanization", + "source", + "language", + "as_of" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "as_of": { + "type": [ + "string", + "null" + ] + }, + "authoritative": { + "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. In Switzerland the register confirms the code while the BIC still comes from our curated map.", + "type": "boolean" + }, + "bank_name": { + "type": [ + "string", + "null" + ] + }, + "basis": { + "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today DE, AT, BE, BG, SK and SM; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", + "type": "string" + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "code": { + "type": "string" + }, + "lei": { + "description": "GLEIF identity of the resolved BIC holder, not necessarily the bank-code holder.", + "type": [ + "string", + "null" + ] + }, + "lei_status": { + "type": [ + "string", + "null" + ] + }, + "postal_address": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "adr_line": { + "items": { + "type": "string" + }, + "type": "array" + }, + "as_of": { + "type": [ + "string", + "null" + ] + }, + "bldg_nb": { + "type": "string" + }, + "ctry": { + "type": "string" + }, + "format": { + "enum": [ + "structured", + "hybrid" + ], + "type": "string" + }, + "pst_cd": { + "type": "string" + }, + "source": { + "type": "string" + }, + "strt_nm": { + "type": "string" + }, + "twn_nm": { + "type": "string" + } + }, + "required": [ + "twn_nm", + "ctry", + "format", + "source", + "as_of" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "source": { + "description": "Source of the bank-code/BIC pairing; keep its provenance.", + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "code", + "bank_name", + "city" + ], + "type": "object" + }, + { + "type": "null" + } +] - added
Output schema / properties / results / items / properties / check_digitsAdded value: +{ + "type": "string" +} - changed
Output schema / properties / results / items / properties / clearing / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "eurosic": { - "type": "boolean" - }, - "iid": { - "type": "string" - }, - "instant_payments_chf": { - "type": "boolean" - }, - "name": { - "type": "string" - }, - "qr_iid": { - "type": [ - "string", - "null" - ] - }, - "sic": { - "type": "boolean" - }, - "town": { - "type": [ - "string", - "null" - ] - }, - "type": { - "type": "string" - } - }, - "required": [ - "iid", - "name", - "type", - "town", - "sic", - "instant_payments_chf", - "eurosic", - "qr_iid" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "eurosic": { + "type": "boolean" + }, + "iid": { + "type": "string" + }, + "instant_payments_chf": { + "type": "boolean" + }, + "is_qr_iid": { + "type": "boolean" + }, + "name": { + "type": "string" + }, + "qr_iid": { + "type": [ + "string", + "null" + ] + }, + "qr_iid_source": { + "anyOf": [ + { + "enum": [ + "register", + "headquarters" + ], + "type": "string" + }, + { + "type": "null" + } + ] + }, + "qr_iids": { + "items": { + "type": "string" + }, + "type": "array" + }, + "sic": { + "type": "boolean" + }, + "town": { + "type": [ + "string", + "null" + ] + }, + "type": { + "type": "string" + } + }, + "required": [ + "iid", + "name", + "type", + "town", + "sic", + "instant_payments_chf", + "eurosic", + "qr_iid", + "qr_iid_source" + ], + "type": "object" + }, + { + "type": "null" + } +] - added
Output schema / properties / results / items / properties / clearing / descriptionAdded value: +"Swiss clearing data when country is CH or LI." - changed
Output schema / properties / results / items / properties / cost_usdc / descriptionPrevious value: -"What THIS IBAN was billed. Zero on the free MCP tier."New value: +"What THIS call was billed. Zero on the free MCP tier." - added
Output schema / properties / results / items / properties / country / properties / code / descriptionAdded value: +"ISO 3166-1 alpha-2 country code." - added
Output schema / properties / results / items / properties / formattedAdded value: +{ + "description": "IBAN with 4-char groups for display.", + "type": "string" +} - added
Output schema / properties / results / items / properties / iban / descriptionAdded value: +"Normalized IBAN (uppercase, no spaces)." - added
Output schema / properties / results / items / properties / issuer / properties / classification / descriptionAdded value: +"curated | register | default. Whether the type was established or assumed. curated = the BIC8 is in the issuer set, so this is an identification. register = an official register names the holder of this bank code and says what it is; it carries a date and an authority in psd_registration, and it only ever replaces a default. default = nothing is on file and \"bank\" is the fallback, which covers 97.9% of BIC8 (measured 29/07/2026). Count curated and register when sizing virtual-IBAN exposure, never default." - added
Output schema / properties / results / items / properties / issuer / properties / iban_issuerAdded value: +{ + "enum": [ + "confirmed", + "not_listed" + ], + "type": "string" +} - added
Output schema / properties / results / items / properties / issuer / properties / type / descriptionAdded value: +"bank | digital_bank | emi | payment_institution; null when unsubstantiated" - changed
Output schema / properties / results / items / properties / issuer / properties / type / typePrevious value: -"string"New value: +[ + "string", + "null" +] - changed
Output schema / properties / results / items / properties / list_price_usdc / descriptionPrevious value: -"Catalogue price per IBAN on the paid REST/x402 route."New value: +"Catalogue price of the same call on the paid REST/x402 route." - added
Output schema / properties / results / items / properties / modulus_checkAdded value: +{ + "additionalProperties": false, + "properties": { + "checked": { + "type": "boolean" + }, + "passed": { + "type": [ + "boolean", + "null" + ] + }, + "source": { + "type": "string" + }, + "table_fetched_on": { + "type": "string" + } + }, + "required": [ + "checked", + "passed", + "source", + "table_fetched_on" + ], + "type": "object" +} - added
Output schema / properties / results / items / properties / pra_authorisationAdded value: +{ + "additionalProperties": false, + "properties": { + "authorised": { + "const": true, + "type": "boolean" + }, + "basis": { + "type": "string" + }, + "firm_name": { + "type": "string" + }, + "frn": { + "type": "string" + }, + "list_month": { + "type": "string" + }, + "section": { + "type": "string" + }, + "source": { + "type": "string" + } + }, + "required": [ + "authorised", + "firm_name", + "frn", + "section", + "basis", + "source", + "list_month" + ], + "type": "object" +} - added
Output schema / properties / results / items / properties / processing_msAdded value: +{ + "type": "number" +} - added
Output schema / properties / results / items / properties / psd_registrationAdded value: +{ + "additionalProperties": false, + "properties": { + "as_of": { + "type": "string" + }, + "competent_authority": { + "type": "string" + }, + "country": { + "type": "string" + }, + "entity_type": { + "type": "string" + }, + "name": { + "type": "string" + }, + "registered": { + "const": true, + "type": "boolean" + }, + "source": { + "type": "string" + } + }, + "required": [ + "registered", + "entity_type", + "name", + "country", + "competent_authority", + "source", + "as_of" + ], + "type": "object" +} - added
Output schema / properties / results / items / properties / risk_indicators / properties / issuer_type / descriptionAdded value: +"Null when no institution resolved — it no longer defaults to \"bank\"." - added
Output schema / properties / results / items / properties / risk_indicators / properties / sepa_reachable_scope / descriptionAdded value: +"Scope the reachability holds at. Country-derived, not account-derived." - added
Output schema / properties / results / items / properties / sepa / properties / basis / descriptionAdded value: +"Where `schemes` came from: read at the EPC register for this bank, or defaulted from the country." - added
Output schema / properties / results / items / properties / sepa / properties / vop_participant / descriptionAdded value: +"true = resolved bank is listed as ready in the EPC VoP scheme register; null = no institution resolved."
- Changed
check_compliance26 fields changed- added
Output schema / properties / bank_code_check / properties / check_digitAdded value: +{ + "additionalProperties": false, + "properties": { + "algorithm": { + "type": "string" + }, + "valid": { + "type": "boolean" + } + }, + "required": [ + "valid", + "algorithm" + ], + "type": "object" +} - added
Output schema / properties / bank_code_check / properties / institutionAdded value: +{ + "additionalProperties": false, + "properties": { + "country": { + "type": "string" + }, + "lei": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "post_code": { + "type": [ + "string", + "null" + ] + }, + "street": { + "type": [ + "string", + "null" + ] + }, + "town": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "name", + "street", + "post_code", + "town", + "country" + ], + "type": "object" +} - added
Output schema / properties / bbanAdded value: +{ + "additionalProperties": false, + "properties": { + "account_number": { + "type": "string" + }, + "bank_code": { + "type": "string" + }, + "branch_code": { + "type": "string" + } + }, + "required": [ + "bank_code", + "account_number" + ], + "type": "object" +} - changed
Output schema / properties / bic / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "authoritative": { - "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. In Switzerland the register confirms the code while the BIC still comes from our curated map.", - "type": "boolean" - }, - "bank_name": { - "type": [ - "string", - "null" - ] - }, - "basis": { - "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today DE, AT, BE, BG, SK and SM; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", - "type": "string" - }, - "city": { - "type": [ - "string", - "null" - ] - }, - "code": { - "type": "string" - } - }, - "required": [ - "code", - "bank_name", - "city" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "address": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "as_of": { + "type": [ + "string", + "null" + ] + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "country": { + "type": "string" + }, + "language": { + "type": [ + "string", + "null" + ] + }, + "post_code": { + "type": [ + "string", + "null" + ] + }, + "region": { + "type": [ + "string", + "null" + ] + }, + "romanization": { + "enum": [ + "original_latin", + "gleif_english", + "unavailable" + ], + "type": "string" + }, + "romanized": { + "type": [ + "string", + "null" + ] + }, + "source": { + "type": "string" + }, + "street": { + "type": [ + "string", + "null" + ] + }, + "type": { + "const": "registered", + "type": "string" + } + }, + "required": [ + "type", + "street", + "post_code", + "region", + "city", + "country", + "romanized", + "romanization", + "source", + "language", + "as_of" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "as_of": { + "type": [ + "string", + "null" + ] + }, + "authoritative": { + "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. In Switzerland the register confirms the code while the BIC still comes from our curated map.", + "type": "boolean" + }, + "bank_name": { + "type": [ + "string", + "null" + ] + }, + "basis": { + "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today DE, AT, BE, BG, SK and SM; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", + "type": "string" + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "code": { + "type": "string" + }, + "lei": { + "description": "GLEIF identity of the resolved BIC holder, not necessarily the bank-code holder.", + "type": [ + "string", + "null" + ] + }, + "lei_status": { + "type": [ + "string", + "null" + ] + }, + "postal_address": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "adr_line": { + "items": { + "type": "string" + }, + "type": "array" + }, + "as_of": { + "type": [ + "string", + "null" + ] + }, + "bldg_nb": { + "type": "string" + }, + "ctry": { + "type": "string" + }, + "format": { + "enum": [ + "structured", + "hybrid" + ], + "type": "string" + }, + "pst_cd": { + "type": "string" + }, + "source": { + "type": "string" + }, + "strt_nm": { + "type": "string" + }, + "twn_nm": { + "type": "string" + } + }, + "required": [ + "twn_nm", + "ctry", + "format", + "source", + "as_of" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "source": { + "description": "Source of the bank-code/BIC pairing; keep its provenance.", + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "code", + "bank_name", + "city" + ], + "type": "object" + }, + { + "type": "null" + } +] - added
Output schema / properties / check_digitsAdded value: +{ + "type": "string" +} - added
Output schema / properties / clearingAdded value: +{ + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "eurosic": { + "type": "boolean" + }, + "iid": { + "type": "string" + }, + "instant_payments_chf": { + "type": "boolean" + }, + "is_qr_iid": { + "type": "boolean" + }, + "name": { + "type": "string" + }, + "qr_iid": { + "type": [ + "string", + "null" + ] + }, + "qr_iid_source": { + "anyOf": [ + { + "enum": [ + "register", + "headquarters" + ], + "type": "string" + }, + { + "type": "null" + } + ] + }, + "qr_iids": { + "items": { + "type": "string" + }, + "type": "array" + }, + "sic": { + "type": "boolean" + }, + "town": { + "type": [ + "string", + "null" + ] + }, + "type": { + "type": "string" + } + }, + "required": [ + "iid", + "name", + "type", + "town", + "sic", + "instant_payments_chf", + "eurosic", + "qr_iid", + "qr_iid_source" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "Swiss clearing data when country is CH or LI." +} - added
Output schema / properties / compliance / properties / reachability / properties / screenedAdded value: +{ + "type": "boolean" +} - changed
Output schema / properties / compliance / properties / reachability / requiredPrevious value: -[ - "sepa_instant", - "sct", - "sdd" -]New value: +[ + "screened", + "sepa_instant", + "sct", + "sdd" +] - added
Output schema / properties / compliance / properties / sanctions / properties / bank_screenedAdded value: +{ + "description": "False means no bank was screened; do not interpret bank_sanctioned as a finding.", + "type": "boolean" +} - changed
Output schema / properties / compliance / properties / sanctions / requiredPrevious value: -[ - "country_sanctioned", - "bank_sanctioned", - "matched_lists", - "fatf_status" -]New value: +[ + "bank_screened", + "country_sanctioned", + "bank_sanctioned", + "matched_lists", + "fatf_status" +] - added
Output schema / properties / compliance / properties / vop / properties / screenedAdded value: +{ + "type": "boolean" +} - changed
Output schema / properties / compliance / properties / vop / requiredPrevious value: -[ - "participant", - "status" -]New value: +[ + "screened", + "participant", + "status" +] - added
Output schema / properties / country / properties / code / descriptionAdded value: +"ISO 3166-1 alpha-2 country code." - added
Output schema / properties / formattedAdded value: +{ + "description": "IBAN with 4-char groups for display.", + "type": "string" +} - added
Output schema / properties / iban / descriptionAdded value: +"Normalized IBAN (uppercase, no spaces)." - added
Output schema / properties / issuer / properties / classification / descriptionAdded value: +"curated | register | default. Whether the type was established or assumed. curated = the BIC8 is in the issuer set, so this is an identification. register = an official register names the holder of this bank code and says what it is; it carries a date and an authority in psd_registration, and it only ever replaces a default. default = nothing is on file and \"bank\" is the fallback, which covers 97.9% of BIC8 (measured 29/07/2026). Count curated and register when sizing virtual-IBAN exposure, never default." - added
Output schema / properties / issuer / properties / iban_issuerAdded value: +{ + "enum": [ + "confirmed", + "not_listed" + ], + "type": "string" +} - added
Output schema / properties / issuer / properties / type / descriptionAdded value: +"bank | digital_bank | emi | payment_institution; null when unsubstantiated" - changed
Output schema / properties / issuer / properties / type / typePrevious value: -"string"New value: +[ + "string", + "null" +] - added
Output schema / properties / modulus_checkAdded value: +{ + "additionalProperties": false, + "properties": { + "checked": { + "type": "boolean" + }, + "passed": { + "type": [ + "boolean", + "null" + ] + }, + "source": { + "type": "string" + }, + "table_fetched_on": { + "type": "string" + } + }, + "required": [ + "checked", + "passed", + "source", + "table_fetched_on" + ], + "type": "object" +} - added
Output schema / properties / pra_authorisationAdded value: +{ + "additionalProperties": false, + "properties": { + "authorised": { + "const": true, + "type": "boolean" + }, + "basis": { + "type": "string" + }, + "firm_name": { + "type": "string" + }, + "frn": { + "type": "string" + }, + "list_month": { + "type": "string" + }, + "section": { + "type": "string" + }, + "source": { + "type": "string" + } + }, + "required": [ + "authorised", + "firm_name", + "frn", + "section", + "basis", + "source", + "list_month" + ], + "type": "object" +} - added
Output schema / properties / processing_msAdded value: +{ + "type": "number" +} - added
Output schema / properties / psd_registrationAdded value: +{ + "additionalProperties": false, + "properties": { + "as_of": { + "type": "string" + }, + "competent_authority": { + "type": "string" + }, + "country": { + "type": "string" + }, + "entity_type": { + "type": "string" + }, + "name": { + "type": "string" + }, + "registered": { + "const": true, + "type": "boolean" + }, + "source": { + "type": "string" + } + }, + "required": [ + "registered", + "entity_type", + "name", + "country", + "competent_authority", + "source", + "as_of" + ], + "type": "object" +} - added
Output schema / properties / sepa / properties / basisAdded value: +{ + "description": "Where `schemes` came from: read at the EPC register for this bank, or defaulted from the country.", + "enum": [ + "country_default", + "epc_register" + ], + "type": "string" +} - added
Output schema / properties / sepa / properties / vop_participantAdded value: +{ + "description": "true = resolved bank is listed as ready in the EPC VoP scheme register; null = no institution resolved.", + "type": [ + "boolean", + "null" + ] +} - changed
Output schema / requiredPrevious value: -[ - "iban", - "valid", - "compliance", - "meta", - "cost_usdc" -]New value: +[ + "iban", + "valid", + "cost_usdc", + "compliance", + "meta" +]
- Changed
validate_iban11 fields changed- added
Output schema / properties / bank_code_check / properties / check_digitAdded value: +{ + "additionalProperties": false, + "properties": { + "algorithm": { + "type": "string" + }, + "valid": { + "type": "boolean" + } + }, + "required": [ + "valid", + "algorithm" + ], + "type": "object" +} - added
Output schema / properties / bank_code_check / properties / institutionAdded value: +{ + "additionalProperties": false, + "properties": { + "country": { + "type": "string" + }, + "lei": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "post_code": { + "type": [ + "string", + "null" + ] + }, + "street": { + "type": [ + "string", + "null" + ] + }, + "town": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "name", + "street", + "post_code", + "town", + "country" + ], + "type": "object" +} - changed
Output schema / properties / bic / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "authoritative": { - "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. In Switzerland the register confirms the code while the BIC still comes from our curated map.", - "type": "boolean" - }, - "bank_name": { - "type": [ - "string", - "null" - ] - }, - "basis": { - "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today DE, AT, BE, BG, SK and SM; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", - "type": "string" - }, - "city": { - "type": [ - "string", - "null" - ] - }, - "code": { - "type": "string" - } - }, - "required": [ - "code", - "bank_name", - "city" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "address": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "as_of": { + "type": [ + "string", + "null" + ] + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "country": { + "type": "string" + }, + "language": { + "type": [ + "string", + "null" + ] + }, + "post_code": { + "type": [ + "string", + "null" + ] + }, + "region": { + "type": [ + "string", + "null" + ] + }, + "romanization": { + "enum": [ + "original_latin", + "gleif_english", + "unavailable" + ], + "type": "string" + }, + "romanized": { + "type": [ + "string", + "null" + ] + }, + "source": { + "type": "string" + }, + "street": { + "type": [ + "string", + "null" + ] + }, + "type": { + "const": "registered", + "type": "string" + } + }, + "required": [ + "type", + "street", + "post_code", + "region", + "city", + "country", + "romanized", + "romanization", + "source", + "language", + "as_of" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "as_of": { + "type": [ + "string", + "null" + ] + }, + "authoritative": { + "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. In Switzerland the register confirms the code while the BIC still comes from our curated map.", + "type": "boolean" + }, + "bank_name": { + "type": [ + "string", + "null" + ] + }, + "basis": { + "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today DE, AT, BE, BG, SK and SM; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", + "type": "string" + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "code": { + "type": "string" + }, + "lei": { + "description": "GLEIF identity of the resolved BIC holder, not necessarily the bank-code holder.", + "type": [ + "string", + "null" + ] + }, + "lei_status": { + "type": [ + "string", + "null" + ] + }, + "postal_address": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "adr_line": { + "items": { + "type": "string" + }, + "type": "array" + }, + "as_of": { + "type": [ + "string", + "null" + ] + }, + "bldg_nb": { + "type": "string" + }, + "ctry": { + "type": "string" + }, + "format": { + "enum": [ + "structured", + "hybrid" + ], + "type": "string" + }, + "pst_cd": { + "type": "string" + }, + "source": { + "type": "string" + }, + "strt_nm": { + "type": "string" + }, + "twn_nm": { + "type": "string" + } + }, + "required": [ + "twn_nm", + "ctry", + "format", + "source", + "as_of" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "source": { + "description": "Source of the bank-code/BIC pairing; keep its provenance.", + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "code", + "bank_name", + "city" + ], + "type": "object" + }, + { + "type": "null" + } +] - removed
Output schema / properties / bic / descriptionRemoved value: -"Resolved BIC/SWIFT when BBAN→BIC mapping exists. Read basis before storing it as a routing instruction: only a national_register pairing is settlement-grade." - changed
Output schema / properties / clearing / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "eurosic": { - "type": "boolean" - }, - "iid": { - "type": "string" - }, - "instant_payments_chf": { - "type": "boolean" - }, - "name": { - "type": "string" - }, - "qr_iid": { - "type": [ - "string", - "null" - ] - }, - "sic": { - "type": "boolean" - }, - "town": { - "type": [ - "string", - "null" - ] - }, - "type": { - "type": "string" - } - }, - "required": [ - "iid", - "name", - "type", - "town", - "sic", - "instant_payments_chf", - "eurosic", - "qr_iid" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "eurosic": { + "type": "boolean" + }, + "iid": { + "type": "string" + }, + "instant_payments_chf": { + "type": "boolean" + }, + "is_qr_iid": { + "type": "boolean" + }, + "name": { + "type": "string" + }, + "qr_iid": { + "type": [ + "string", + "null" + ] + }, + "qr_iid_source": { + "anyOf": [ + { + "enum": [ + "register", + "headquarters" + ], + "type": "string" + }, + { + "type": "null" + } + ] + }, + "qr_iids": { + "items": { + "type": "string" + }, + "type": "array" + }, + "sic": { + "type": "boolean" + }, + "town": { + "type": [ + "string", + "null" + ] + }, + "type": { + "type": "string" + } + }, + "required": [ + "iid", + "name", + "type", + "town", + "sic", + "instant_payments_chf", + "eurosic", + "qr_iid", + "qr_iid_source" + ], + "type": "object" + }, + { + "type": "null" + } +] - added
Output schema / properties / issuer / properties / iban_issuerAdded value: +{ + "enum": [ + "confirmed", + "not_listed" + ], + "type": "string" +} - changed
Output schema / properties / issuer / properties / type / descriptionPrevious value: -"bank | digital_bank | emi | payment_institution"New value: +"bank | digital_bank | emi | payment_institution; null when unsubstantiated" - changed
Output schema / properties / issuer / properties / type / typePrevious value: -"string"New value: +[ + "string", + "null" +] - added
Output schema / properties / modulus_checkAdded value: +{ + "additionalProperties": false, + "properties": { + "checked": { + "type": "boolean" + }, + "passed": { + "type": [ + "boolean", + "null" + ] + }, + "source": { + "type": "string" + }, + "table_fetched_on": { + "type": "string" + } + }, + "required": [ + "checked", + "passed", + "source", + "table_fetched_on" + ], + "type": "object" +} - added
Output schema / properties / pra_authorisationAdded value: +{ + "additionalProperties": false, + "properties": { + "authorised": { + "const": true, + "type": "boolean" + }, + "basis": { + "type": "string" + }, + "firm_name": { + "type": "string" + }, + "frn": { + "type": "string" + }, + "list_month": { + "type": "string" + }, + "section": { + "type": "string" + }, + "source": { + "type": "string" + } + }, + "required": [ + "authorised", + "firm_name", + "frn", + "section", + "basis", + "source", + "list_month" + ], + "type": "object" +} - added
Output schema / properties / psd_registrationAdded value: +{ + "additionalProperties": false, + "properties": { + "as_of": { + "type": "string" + }, + "competent_authority": { + "type": "string" + }, + "country": { + "type": "string" + }, + "entity_type": { + "type": "string" + }, + "name": { + "type": "string" + }, + "registered": { + "const": true, + "type": "boolean" + }, + "source": { + "type": "string" + } + }, + "required": [ + "registered", + "entity_type", + "name", + "country", + "competent_authority", + "source", + "as_of" + ], + "type": "object" +}
3 tool updates
- Changed
batch_validate_iban1 field changed- changed
Output schema / properties / results / items / properties / bic / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "authoritative": { - "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. In Switzerland the register confirms the code while the BIC still comes from our curated map.", - "type": "boolean" - }, - "bank_name": { - "type": [ - "string", - "null" - ] - }, - "basis": { - "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today DE, AT, BE and BG; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", - "type": "string" - }, - "city": { - "type": [ - "string", - "null" - ] - }, - "code": { - "type": "string" - } - }, - "required": [ - "code", - "bank_name", - "city" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "authoritative": { + "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. In Switzerland the register confirms the code while the BIC still comes from our curated map.", + "type": "boolean" + }, + "bank_name": { + "type": [ + "string", + "null" + ] + }, + "basis": { + "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today DE, AT, BE, BG, SK and SM; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", + "type": "string" + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "code": { + "type": "string" + } + }, + "required": [ + "code", + "bank_name", + "city" + ], + "type": "object" + }, + { + "type": "null" + } +]
- Changed
check_compliance1 field changed- changed
Output schema / properties / bic / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "authoritative": { - "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. In Switzerland the register confirms the code while the BIC still comes from our curated map.", - "type": "boolean" - }, - "bank_name": { - "type": [ - "string", - "null" - ] - }, - "basis": { - "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today DE, AT, BE and BG; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", - "type": "string" - }, - "city": { - "type": [ - "string", - "null" - ] - }, - "code": { - "type": "string" - } - }, - "required": [ - "code", - "bank_name", - "city" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "authoritative": { + "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. In Switzerland the register confirms the code while the BIC still comes from our curated map.", + "type": "boolean" + }, + "bank_name": { + "type": [ + "string", + "null" + ] + }, + "basis": { + "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today DE, AT, BE, BG, SK and SM; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", + "type": "string" + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "code": { + "type": "string" + } + }, + "required": [ + "code", + "bank_name", + "city" + ], + "type": "object" + }, + { + "type": "null" + } +]
- Changed
validate_iban1 field changed- changed
Output schema / properties / bic / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "authoritative": { - "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. In Switzerland the register confirms the code while the BIC still comes from our curated map.", - "type": "boolean" - }, - "bank_name": { - "type": [ - "string", - "null" - ] - }, - "basis": { - "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today DE, AT, BE and BG; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", - "type": "string" - }, - "city": { - "type": [ - "string", - "null" - ] - }, - "code": { - "type": "string" - } - }, - "required": [ - "code", - "bank_name", - "city" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "authoritative": { + "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. In Switzerland the register confirms the code while the BIC still comes from our curated map.", + "type": "boolean" + }, + "bank_name": { + "type": [ + "string", + "null" + ] + }, + "basis": { + "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today DE, AT, BE, BG, SK and SM; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", + "type": "string" + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "code": { + "type": "string" + } + }, + "required": [ + "code", + "bank_name", + "city" + ], + "type": "object" + }, + { + "type": "null" + } +]
1 tool update
- Added
check_swiss_qr_bill
6 tool updates
- Changed
batch_validate_iban14 fields changed- removed
Output schema / properties / results / items / properties / bank_code_check / properties / match / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / results / items / properties / bank_code_check / properties / match / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / results / items / properties / bank_code_check / properties / register / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / results / items / properties / bank_code_check / properties / register / typeAdded value: +[ + "string", + "null" +] - changed
Output schema / properties / results / items / properties / bic / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "authoritative": { - "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. In Switzerland the register confirms the code while the BIC still comes from our curated map.", - "type": "boolean" - }, - "bank_name": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "basis": { - "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today DE, AT, BE and BG; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", - "type": "string" - }, - "city": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "code": { - "type": "string" - } - }, - "required": [ - "code", - "bank_name", - "city" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "authoritative": { + "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. In Switzerland the register confirms the code while the BIC still comes from our curated map.", + "type": "boolean" + }, + "bank_name": { + "type": [ + "string", + "null" + ] + }, + "basis": { + "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today DE, AT, BE and BG; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", + "type": "string" + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "code": { + "type": "string" + } + }, + "required": [ + "code", + "bank_name", + "city" + ], + "type": "object" + }, + { + "type": "null" + } +] - changed
Output schema / properties / results / items / properties / clearing / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "eurosic": { - "type": "boolean" - }, - "iid": { - "type": "string" - }, - "instant_payments_chf": { - "type": "boolean" - }, - "name": { - "type": "string" - }, - "qr_iid": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "sic": { - "type": "boolean" - }, - "town": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "type": { - "type": "string" - } - }, - "required": [ - "iid", - "name", - "type", - "town", - "sic", - "instant_payments_chf", - "eurosic", - "qr_iid" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "eurosic": { + "type": "boolean" + }, + "iid": { + "type": "string" + }, + "instant_payments_chf": { + "type": "boolean" + }, + "name": { + "type": "string" + }, + "qr_iid": { + "type": [ + "string", + "null" + ] + }, + "sic": { + "type": "boolean" + }, + "town": { + "type": [ + "string", + "null" + ] + }, + "type": { + "type": "string" + } + }, + "required": [ + "iid", + "name", + "type", + "town", + "sic", + "instant_payments_chf", + "eurosic", + "qr_iid" + ], + "type": "object" + }, + { + "type": "null" + } +] - removed
Output schema / properties / results / items / properties / official_identity / properties / address / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / results / items / properties / official_identity / properties / address / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / results / items / properties / official_identity / properties / lei / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / results / items / properties / official_identity / properties / lei / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / results / items / properties / risk_indicators / properties / issuer_type / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / results / items / properties / risk_indicators / properties / issuer_type / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / results / items / properties / sepa / properties / vop_participant / anyOfRemoved value: -[ - { - "type": "boolean" - }, - { - "type": "null" - } -] - added
Output schema / properties / results / items / properties / sepa / properties / vop_participant / typeAdded value: +[ + "boolean", + "null" +]
- Changed
check_compliance15 fields changed- removed
Output schema / properties / bank_code_check / properties / match / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / bank_code_check / properties / match / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / bank_code_check / properties / register / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / bank_code_check / properties / register / typeAdded value: +[ + "string", + "null" +] - changed
Output schema / properties / bic / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "authoritative": { - "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. In Switzerland the register confirms the code while the BIC still comes from our curated map.", - "type": "boolean" - }, - "bank_name": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "basis": { - "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today DE, AT, BE and BG; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", - "type": "string" - }, - "city": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "code": { - "type": "string" - } - }, - "required": [ - "code", - "bank_name", - "city" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "authoritative": { + "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. In Switzerland the register confirms the code while the BIC still comes from our curated map.", + "type": "boolean" + }, + "bank_name": { + "type": [ + "string", + "null" + ] + }, + "basis": { + "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today DE, AT, BE and BG; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", + "type": "string" + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "code": { + "type": "string" + } + }, + "required": [ + "code", + "bank_name", + "city" + ], + "type": "object" + }, + { + "type": "null" + } +] - removed
Output schema / properties / meta / properties / fatf_as_of / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / meta / properties / fatf_as_of / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / meta / properties / sanctions_as_of / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / meta / properties / sanctions_as_of / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / official_identity / properties / address / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / official_identity / properties / address / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / official_identity / properties / lei / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / official_identity / properties / lei / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / risk_indicators / properties / issuer_type / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / risk_indicators / properties / issuer_type / typeAdded value: +[ + "string", + "null" +]
- Changed
lookup_bic12 fields changed- removed
Output schema / properties / branch_info / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / branch_info / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / city / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / city / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / country_name / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / country_name / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / institution / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / institution / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / lei / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / lei / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / lei_status / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / lei_status / typeAdded value: +[ + "string", + "null" +]
- Changed
lookup_ch_clearing14 fields changed- removed
Output schema / properties / address / properties / building_number / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / address / properties / building_number / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / address / properties / post_code / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / address / properties / post_code / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / address / properties / street / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / address / properties / street / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / address / properties / town / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / address / properties / town / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / bic / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / bic / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / qr_iid / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / qr_iid / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / sic_iid / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / sic_iid / typeAdded value: +[ + "string", + "null" +]
- Changed
validate_iban14 fields changed- removed
Output schema / properties / bank_code_check / properties / match / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / bank_code_check / properties / match / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / bank_code_check / properties / register / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / bank_code_check / properties / register / typeAdded value: +[ + "string", + "null" +] - changed
Output schema / properties / bic / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "authoritative": { - "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. In Switzerland the register confirms the code while the BIC still comes from our curated map.", - "type": "boolean" - }, - "bank_name": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "basis": { - "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today DE, AT, BE and BG; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", - "type": "string" - }, - "city": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "code": { - "type": "string" - } - }, - "required": [ - "code", - "bank_name", - "city" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "authoritative": { + "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. In Switzerland the register confirms the code while the BIC still comes from our curated map.", + "type": "boolean" + }, + "bank_name": { + "type": [ + "string", + "null" + ] + }, + "basis": { + "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today DE, AT, BE and BG; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", + "type": "string" + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "code": { + "type": "string" + } + }, + "required": [ + "code", + "bank_name", + "city" + ], + "type": "object" + }, + { + "type": "null" + } +] - changed
Output schema / properties / clearing / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "eurosic": { - "type": "boolean" - }, - "iid": { - "type": "string" - }, - "instant_payments_chf": { - "type": "boolean" - }, - "name": { - "type": "string" - }, - "qr_iid": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "sic": { - "type": "boolean" - }, - "town": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "type": { - "type": "string" - } - }, - "required": [ - "iid", - "name", - "type", - "town", - "sic", - "instant_payments_chf", - "eurosic", - "qr_iid" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "eurosic": { + "type": "boolean" + }, + "iid": { + "type": "string" + }, + "instant_payments_chf": { + "type": "boolean" + }, + "name": { + "type": "string" + }, + "qr_iid": { + "type": [ + "string", + "null" + ] + }, + "sic": { + "type": "boolean" + }, + "town": { + "type": [ + "string", + "null" + ] + }, + "type": { + "type": "string" + } + }, + "required": [ + "iid", + "name", + "type", + "town", + "sic", + "instant_payments_chf", + "eurosic", + "qr_iid" + ], + "type": "object" + }, + { + "type": "null" + } +] - removed
Output schema / properties / official_identity / properties / address / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / official_identity / properties / address / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / official_identity / properties / lei / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / official_identity / properties / lei / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / risk_indicators / properties / issuer_type / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / risk_indicators / properties / issuer_type / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / sepa / properties / vop_participant / anyOfRemoved value: -[ - { - "type": "boolean" - }, - { - "type": "null" - } -] - added
Output schema / properties / sepa / properties / vop_participant / typeAdded value: +[ + "boolean", + "null" +]
- Changed
validate_payment_reference6 fields changed- removed
Output schema / properties / scheme / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / scheme / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / source / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / source / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / valid / anyOfRemoved value: -[ - { - "type": "boolean" - }, - { - "type": "null" - } -] - added
Output schema / properties / valid / typeAdded value: +[ + "boolean", + "null" +]
4 tool updates
- Changed
batch_validate_iban3 fields changed- added
Output schema / properties / results / items / properties / cost_usdc / descriptionAdded value: +"What THIS IBAN was billed. Zero on the free MCP tier." - added
Output schema / properties / results / items / properties / list_price_usdcAdded value: +{ + "description": "Catalogue price per IBAN on the paid REST/x402 route.", + "type": "number" +} - added
Output schema / properties / results / items / properties / sepa / properties / basisAdded value: +{ + "enum": [ + "country_default", + "epc_register" + ], + "type": "string" +}
- Changed
check_compliance2 fields changed- added
Output schema / properties / cost_usdc / descriptionAdded value: +"What THIS call was billed. Zero on the free MCP tier." - added
Output schema / properties / list_price_usdcAdded value: +{ + "description": "Catalogue price of the same call on the paid REST/x402 route.", + "type": "number" +}
- Changed
lookup_ch_clearing2 fields changed- added
Output schema / properties / cost_usdc / descriptionAdded value: +"What THIS call was billed. Zero on the free MCP tier." - added
Output schema / properties / list_price_usdcAdded value: +{ + "description": "Catalogue price of the same call on the paid REST/x402 route.", + "type": "number" +}
- Changed
validate_iban3 fields changed- added
Output schema / properties / cost_usdc / descriptionAdded value: +"What THIS call was billed. Zero on the free MCP tier." - added
Output schema / properties / list_price_usdcAdded value: +{ + "description": "Catalogue price of the same call on the paid REST/x402 route.", + "type": "number" +} - added
Output schema / properties / sepa / properties / basisAdded value: +{ + "description": "Where `schemes` came from: read at the EPC register for this bank, or defaulted from the country.", + "enum": [ + "country_default", + "epc_register" + ], + "type": "string" +}
3 tool updates
- Changed
batch_validate_iban2 fields changed- added
Output schema / properties / results / items / properties / bank_code_check / properties / reasonAdded value: +{ + "description": "WHY the verdict is not verified, as one token to branch on. Absent when status is verified. not_allocated (a national register denies the code — the only value that licenses \"do not send\") | absent_from_reference_data (our composite map does not carry it; the country register was not consulted) | no_reference_data_for_country | register_names_no_holder (the register defines the code space and publishes no holder — silence, not a denial) | national_register_unavailable (the register this country is normally decided against could not be consulted) | lookup_failed (the lookup could not run: timeout, unreadable database). The last two describe IBANforge, never the beneficiary. Never escalate either into a refusal.", + "type": "string" +} - changed
Output schema / properties / results / items / properties / bic / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "bank_name": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "city": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "code": { - "type": "string" - } - }, - "required": [ - "code", - "bank_name", - "city" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "authoritative": { + "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. In Switzerland the register confirms the code while the BIC still comes from our curated map.", + "type": "boolean" + }, + "bank_name": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "basis": { + "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today DE, AT, BE and BG; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", + "type": "string" + }, + "city": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "code": { + "type": "string" + } + }, + "required": [ + "code", + "bank_name", + "city" + ], + "type": "object" + }, + { + "type": "null" + } +]
- Changed
check_compliance2 fields changed- added
Output schema / properties / bank_code_check / properties / reasonAdded value: +{ + "description": "WHY the verdict is not verified, as one token to branch on. Absent when status is verified. not_allocated (a national register denies the code — the only value that licenses \"do not send\") | absent_from_reference_data (our composite map does not carry it; the country register was not consulted) | no_reference_data_for_country | register_names_no_holder (the register defines the code space and publishes no holder — silence, not a denial) | national_register_unavailable (the register this country is normally decided against could not be consulted) | lookup_failed (the lookup could not run: timeout, unreadable database). The last two describe IBANforge, never the beneficiary. Never escalate either into a refusal.", + "type": "string" +} - changed
Output schema / properties / bic / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "bank_name": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "city": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "code": { - "type": "string" - } - }, - "required": [ - "code", - "bank_name", - "city" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "authoritative": { + "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. In Switzerland the register confirms the code while the BIC still comes from our curated map.", + "type": "boolean" + }, + "bank_name": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "basis": { + "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today DE, AT, BE and BG; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", + "type": "string" + }, + "city": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "code": { + "type": "string" + } + }, + "required": [ + "code", + "bank_name", + "city" + ], + "type": "object" + }, + { + "type": "null" + } +]
- Changed
validate_iban3 fields changed- added
Output schema / properties / bank_code_check / properties / reasonAdded value: +{ + "description": "WHY the verdict is not verified, as one token to branch on. Absent when status is verified. not_allocated (a national register denies the code — the only value that licenses \"do not send\") | absent_from_reference_data (our composite map does not carry it; the country register was not consulted) | no_reference_data_for_country | register_names_no_holder (the register defines the code space and publishes no holder — silence, not a denial) | national_register_unavailable (the register this country is normally decided against could not be consulted) | lookup_failed (the lookup could not run: timeout, unreadable database). The last two describe IBANforge, never the beneficiary. Never escalate either into a refusal.", + "type": "string" +} - changed
Output schema / properties / bic / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "bank_name": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "city": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "code": { - "type": "string" - } - }, - "required": [ - "code", - "bank_name", - "city" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "authoritative": { + "description": "Whether this BIC may be stored and settled against. Derived from basis, so the two cannot disagree. NOT bank_code_check.authoritative, which answers a different question — whether a national register was consulted about the BANK CODE. In Switzerland the register confirms the code while the BIC still comes from our curated map.", + "type": "boolean" + }, + "bank_name": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "basis": { + "description": "Where the bank code to BIC pairing came from, and therefore what may be done with the BIC. national_register (the country register publishes this BIC for this bank code — today DE, AT, BE and BG; settlement-grade) | curated_map (our maintained bank-code map, exact key, usually right and not an allocation record) | directory_prefix (the bic8 LIKE fallback, which can match several institutions — read bank_code_check.candidates). Outside a national_register basis the BIC is ADVISORY: confirm it with the beneficiary or the bank before storing it as a routing instruction.", + "type": "string" + }, + "city": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "code": { + "type": "string" + } + }, + "required": [ + "code", + "bank_name", + "city" + ], + "type": "object" + }, + { + "type": "null" + } +] - changed
Output schema / properties / bic / descriptionPrevious value: -"Resolved BIC/SWIFT when BBAN→BIC mapping exists."New value: +"Resolved BIC/SWIFT when BBAN→BIC mapping exists. Read basis before storing it as a routing instruction: only a national_register pairing is settlement-grade."
1 tool update
- Added
check_postal_address
1 tool update
- Added
validate_payment_reference
3 tool updates
- Changed
batch_validate_iban1 field changed- added
Output schema / properties / results / items / properties / official_identityAdded value: +{ + "additionalProperties": false, + "description": "Who a central bank says holds the resolved code (ECB by LEI and for FR bank codes, Banco de Espana for ES). Present only on a match — absence is not a negative. INFORMATIONAL ONLY: it never changes valid or bank_code_check, because both publishers relay rather than allocate.", + "properties": { + "address": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "One-line registered address as published." + }, + "as_of": { + "description": "Date of the list this row came from. Both lists are republished every business day.", + "type": "string" + }, + "attribution": { + "description": "The Banco de Espana citation formula, verbatim. Spanish blocks only.", + "type": "string" + }, + "authoritative": { + "description": "Always false. Neither publisher allocates bank codes.", + "type": "boolean" + }, + "category": { + "type": "string" + }, + "free_of_charge": { + "description": "Both publishers require buyers to be told, on every access, that the data is available free of charge from their own website. Relay it with the answer; do not strip it.", + "type": "string" + }, + "lei": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "matched_by": { + "description": "lei | national_code", + "type": "string" + }, + "name": { + "description": "The institution's name as the publisher writes it.", + "type": "string" + }, + "source": { + "description": "The publisher, cited as their licence requires. Relay it.", + "type": "string" + } + }, + "required": [ + "name", + "lei", + "address", + "category", + "matched_by", + "source", + "free_of_charge", + "as_of", + "authoritative" + ], + "type": "object" +}
- Changed
check_compliance1 field changed- added
Output schema / properties / official_identityAdded value: +{ + "additionalProperties": false, + "description": "Who a central bank says holds the resolved code (ECB by LEI and for FR bank codes, Banco de Espana for ES). Present only on a match — absence is not a negative. INFORMATIONAL ONLY: it never changes valid or bank_code_check, because both publishers relay rather than allocate.", + "properties": { + "address": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "One-line registered address as published." + }, + "as_of": { + "description": "Date of the list this row came from. Both lists are republished every business day.", + "type": "string" + }, + "attribution": { + "description": "The Banco de Espana citation formula, verbatim. Spanish blocks only.", + "type": "string" + }, + "authoritative": { + "description": "Always false. Neither publisher allocates bank codes.", + "type": "boolean" + }, + "category": { + "type": "string" + }, + "free_of_charge": { + "description": "Both publishers require buyers to be told, on every access, that the data is available free of charge from their own website. Relay it with the answer; do not strip it.", + "type": "string" + }, + "lei": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "matched_by": { + "description": "lei | national_code", + "type": "string" + }, + "name": { + "description": "The institution's name as the publisher writes it.", + "type": "string" + }, + "source": { + "description": "The publisher, cited as their licence requires. Relay it.", + "type": "string" + } + }, + "required": [ + "name", + "lei", + "address", + "category", + "matched_by", + "source", + "free_of_charge", + "as_of", + "authoritative" + ], + "type": "object" +}
- Changed
validate_iban2 fields changed- changed
Output schema / properties / issuer / properties / classification / descriptionPrevious value: -"curated | default. Whether the type was established or assumed. curated = the BIC8 is in the issuer set, so this is an identification. default = nothing is on file and \"bank\" is the fallback, which covers 97.9% of BIC8 (measured 29/07/2026). Count only curated when sizing virtual-IBAN exposure."New value: +"curated | register | default. Whether the type was established or assumed. curated = the BIC8 is in the issuer set, so this is an identification. register = an official register names the holder of this bank code and says what it is; it carries a date and an authority in psd_registration, and it only ever replaces a default. default = nothing is on file and \"bank\" is the fallback, which covers 97.9% of BIC8 (measured 29/07/2026). Count curated and register when sizing virtual-IBAN exposure, never default." - added
Output schema / properties / official_identityAdded value: +{ + "additionalProperties": false, + "description": "Who a central bank says holds the resolved code (ECB by LEI and for FR bank codes, Banco de Espana for ES). Present only on a match — absence is not a negative. INFORMATIONAL ONLY: it never changes valid or bank_code_check, because both publishers relay rather than allocate.", + "properties": { + "address": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "One-line registered address as published." + }, + "as_of": { + "description": "Date of the list this row came from. Both lists are republished every business day.", + "type": "string" + }, + "attribution": { + "description": "The Banco de Espana citation formula, verbatim. Spanish blocks only.", + "type": "string" + }, + "authoritative": { + "description": "Always false. Neither publisher allocates bank codes.", + "type": "boolean" + }, + "category": { + "type": "string" + }, + "free_of_charge": { + "description": "Both publishers require buyers to be told, on every access, that the data is available free of charge from their own website. Relay it with the answer; do not strip it.", + "type": "string" + }, + "lei": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "matched_by": { + "description": "lei | national_code", + "type": "string" + }, + "name": { + "description": "The institution's name as the publisher writes it.", + "type": "string" + }, + "source": { + "description": "The publisher, cited as their licence requires. Relay it.", + "type": "string" + } + }, + "required": [ + "name", + "lei", + "address", + "category", + "matched_by", + "source", + "free_of_charge", + "as_of", + "authoritative" + ], + "type": "object" +}
Related MCP Connectors
Validate IBANs in 111 countries; bank directory checks for DE, AT, BE, FR, LU, NL, PT and ES.
Cross-border payment & banking intelligence for AI agents: SWIFT/BIC, IBAN, sanctions, FX, tracking.
IBAN validation, extraction, format specs and BIC/SWIFT lookup tools for AI assistants.
OpenIBAN MCP — validate an IBAN's checksum + bank code and resolve the
Related MCP Servers
- AlicenseAqualityBmaintenanceIBAN validation, extraction, format specs, and BIC/SWIFT lookup tools for AI assistants, backed by ibanchecker.cash. Covers 90 countries; no IBAN data is stored.528 npmMIT
- AlicenseNot gradedqualityCmaintenanceValidates IBAN checksums and resolves bank codes via the OpenIBAN API.16 npmMIT
- AlicenseNot gradedqualityCmaintenanceProvides free read-only business checks for IBANs, EU VAT number format, Peppol e-invoice rules, supplier bank-detail changes, and CSV/XLSX data cleaning.MIT
- AlicenseNot gradedqualityAmaintenanceTrust Intelligence API - entity screening, sanctions, risk scoring, IBAN validation, and compliance checks via MCP1MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.