A
licenseA
qualityA
maintenanceIBAN validation, extraction, format specs, and BIC/SWIFT lookup tools for AI assistants, backed by ibanchecker.cash. Covers 90 countries; no IBAN data is stored.
5
75 npm
MIT
ibanforge
Server Details
Check the bank behind an IBAN before you pay: bank-code check, BIC with source, bank-level sanctions
If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 73.4% over 81 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- cammac-creator/ibanforge
- GitHub Stars
- 3
- Server Listing
- IBANforge
- ChatGPT
- –
- Claude
- –
TDQS
A4.4/5.0
Scored across 11 tools
Disambiguation4/5
Each tool targets a distinct artifact (IBAN, BIC, Swiss IID, postal address, QR-bill payload, payment reference) and descriptions explicitly redirect overlapping cases (e.g. lookup_bic says use validate_iban for IBANs). Remaining overlap is modest: validate_iban vs batch_validate_iban is only a batching difference, check_compliance re-runs much of validate_iban plus risk, and lookup_ch_clearing's clearing block also appears inside validate_iban's CH/LI output.
Naming Consistency5/5
Strict verb_noun snake_case throughout: validate_iban, batch_validate_iban, lookup_bic, lookup_ch_clearing, check_compliance, check_postal_address, check_swiss_qr_bill, validate_payment_reference, request_api_key, poll_api_key, send_feedback. The verbs are semantically consistent (validate/check/lookup) and predictable.
Tool Count4/5
11 tools is a reasonable size for a validation/lookup service covering several data domains. Slightly heavy in that three of the eleven (request_api_key, poll_api_key, send_feedback) are account/support plumbing rather than data operations, but each is justified by the paid/x402 model.
Completeness4/5
The read-only validation surface is broad: single and batch IBAN validation, BIC resolution, CH clearing/IID, compliance triage, postal address, payment reference and Swiss QR-bill checks. Minor gaps exist — no lookup by bank name/institution search, no country/format catalog, and no payee name verification (acknowledged as out of scope rather than missing).
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 calls/month, on the REST API or on this transport, and POST /v1/keys/claim lifts that same key to 200 a month. Send the key here as Authorization: Bearer ifk_… (or X-API-Key) and each call counts against it exactly as on the REST API).
| 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. |
| valid_count | Yes | Number of results whose valid is true. |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description goes well beyond them by disclosing the pricing model, per-source free-tier quota with reset time, and the exact auth header format for API keys. The key-provisioning digression (POST endpoints for generating/claiming keys) is operational detail that dilutes rather than sharpens the tool's behavior, keeping this short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose, USE WHEN, and RETURNS blocks are front-loaded and efficient, but the COST paragraph balloons into nested parentheticals about key generation and claim endpoints that belong in documentation, not a tool description. Roughly half the text is billing/onboarding detail that no invocation decision depends on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, yet the description still summarizes { results, count, valid_count }. Combined with cost, auth, and quota disclosure, an agent has everything needed to call it; only the absence of any guidance on invalid/malformed IBANs in the batch response keeps it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter's 1-100 bounds are already encoded as minItems/maxItems, so the schema carries the semantics. The description's 'up to 100 IBANs' restates that bound without adding format guidance (spacing, country mix, handling of invalid entries).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource with a hard scope bound ('Validate up to 100 IBANs in a single call') and immediately differentiates itself from the sibling validate_iban by per-unit cost. An agent can distinguish it from validate_iban without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
An explicit 'USE WHEN' block enumerates concrete triggers (pasted list, CSV cleanup, dedupe, payout triage) plus a quantitative routing rule: use this whenever validate_iban would be called more than 2-3 times in a row. That is a named alternative with a stated selection condition.
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 calls/month, on the REST API or on this transport, and POST /v1/keys/claim lifts that same key to 200 a month. Send the key here as Authorization: Bearer ifk_… (or X-API-Key) and each call counts against it exactly as on the REST API).
| 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), ES (DC) and DE (the account-number check digit, by the method the Bundesbank lists for the bank code), with the proof in the national_check_digits block, and for GB (Vocalink modulus), with the proof in modulus_check; not_checked elsewhere. In DE it is not_checked when the bank code is not in the Bundesbank file or its method is not checked here, and not_applicable when the bank uses no check digit (method 09); national_check_digits.verified_by says whether a German verdict rests on the Bundesbank test numbers or on an independent implementation only. 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, ES or DE (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), de_pruefziffer (DE: the check digit of the 10-digit account number, computed by the method the Deutsche Bundesbank lists for the bank code in its Bankleitzahlendatei, named in method; the IBAN check digits already cover the whole BBAN, this says whether that bank could have issued the account number). 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: a BBAN without the national layout, which a valid IBAN never has, or in DE a bank that uses no check digit (method 09) or a method that defines none for that range of account numbers. not_checked (DE only): the check did not run on our side, because the bank code is not in the Bundesbank file or its method is not checked here (method 44, and methods no bank uses); it says nothing about the beneficiary. verified_by (DE only, whenever the method ran): bundesbank_test_numbers (the method gives the expected answer on every test number and worked example the Bundesbank publishes; a fail adds the blocking step national_check_digits_failed) or independent_implementation (the Bundesbank publishes no test number for the method, which was verified against an independent implementation only; a fail adds the warning step national_check_digits_suspect and never stops a payment). detail, present on fail, not_applicable and not_checked, says which digits disagree or why nothing was checked; it never gives the expected key. In DE the block also carries method (the Bundesbank method code), verified_by, source (with the credit line the Bundesbank asks for) and table_fetched_on (the day the method table was read). checks.national_check_digits repeats status. |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses cost ($0.02/call, free-tier quotas and reset schedule), what is and is not screened (bank BIC8 and country, never the payee's name; payee_screened always false), and precise null semantics for institution_listed, reachability and vop fields. These are exactly the caveats an agent needs to interpret results correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The USE WHEN / CHECKS / RETURNS / COST labeling is well front-loaded, but the COST paragraph balloons into key-generation URLs and monthly quota mechanics that dwarf the tool's actual behavior. Much of the RETURNS section duplicates the output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only triage tool with an output schema, every decision an agent needs is present: when to call, what is screened, what null fields mean, what the risk score range signifies, and the cost model. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter with 100% schema coverage, so the schema already carries the semantics and the baseline of 4 applies. The description adds that the IBAN is checked for validity and that the name portion is never used, but does not add format/syntax detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Run a pre-flight compliance triage on an IBAN') plus the scope it layers on top of validate enrichment, so an agent can tell it apart from validate_iban and batch_validate_iban without opening schemas. The CHECKS enumeration makes the exact scope concrete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
An explicit USE WHEN block names four triggering situations (pre-payment triage, sanctions questions, SEPA Instant reachability, risk scoring for approval workflows). It also states when NOT to use it ('NOT A REGULATED AML/CFT PRODUCT') and names concrete alternatives (Refinitiv, Acuris, ComplyAdvantage).
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 check conformity with the named document BEFORE submitting. Timetables differ: SPS 2026 in force 14 Nov 2026 requires town and country whenever an address is given, but SIC does not validate addresses and each bank decides what it still accepts. Fedwire moved its release to November 2027. The fetched T2 R2026.NOV does not forbid an AddressLine-only address; the MyStandards usage guideline could not be read. DO NOT USE to verify that a street or a building exists: the findings check conformity with the message format rules, and no street is looked up. For a Swiss or Liechtenstein address (ctry CH or LI, with pst_cd and twn_nm), the separate postcode_locality block says whether postcode and town go together in the official directory of localities of swisstopo (©swisstopo, version date in as_of); it is informative and does not change conforms. 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 calls/month, on the REST API or on this transport, and POST /v1/keys/claim lifts that same key to 200 a month. Send the key here as Authorization: Bearer ifk_… (or X-API-Key) and each call counts against it exactly as on the REST API).
| 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. |
| postcode_locality | Yes | Swiss and Liechtenstein addresses with a postcode and a town: whether the two go together in the official directory of localities of swisstopo. Informative, beside the format verdicts: it does not change conforms or valid. The street is not checked. null for any other address. |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, and the description adds substantial context beyond them: pass/fail/not_applicable verdict semantics, conforms being true only if nothing failed, the reason cbpr+ is deliberately absent, timetable caveats (SPS 2026, Fedwire 2027, SIC non-validation), and rate-limit/auth details. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose, USE WHEN, and DO NOT USE are front-loaded correctly, but the description is very long and includes an extended cost/free-tier/auth paragraph that is noisy for tool selection. The key operational guidance earns its place; the repeated quota and key instructions do not.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the nested address object and a shipped output schema, the description covers everything needed to call correctly: scheme meanings, verdict semantics, the role of source citations, limitations (no street lookup), and schedule caveats. Output values are explained in the schema, so no gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters and the address fields. The description still adds value by explaining what 'sps', 'hvps_plus' and 'fedwire' actually mean and why no cbpr+ enum exists, plus the CH/LI postcode block nuance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: checks a structured ISO 20022 postal address against a named payment rail's published rules, rule by rule, with cited sources. It distinguishes itself from sibling tools (validate_iban, lookup_bic) and from the informative postcode_locality block, so an agent knows exactly what this tool is for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit USE WHEN clause (assembling pain.001/Fedwire/T2 messages, before submission) and an explicit DO NOT USE clause (verifying that a street exists). It also names the alternative path for CH/LI postcode/town checks, which is full routing guidance.
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): type K has not been permitted since 21.11.2025, and the banks guarantee payment of a type K QR-bill only until the end of September 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. For a type S address in CH or LI, sps_check.postcode_locality compares postcode and town with the official directory of localities of swisstopo (©swisstopo, version date in as_of). A warning (postcode_town_mismatch, postcode_other_country, postcode_not_listed) comes back when the directory lists the postcode for other towns or in the other country, or lists neither the postcode nor the town in that postal area; never an error, and valid does not change. A postcode missing from the directory, while the town is listed there under another postcode of the same postal area (likely a post-office box postcode), comes back not_verifiable, without a warning: the absence of a warning does not mean the pair was verified. 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 calls/month, on the REST API or on this transport, and POST /v1/keys/claim lifts that same key to 200 a month. Send the key here as Authorization: Bearer ifk_… (or X-API-Key) and each call counts against it exactly as on the REST API).
| 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). The name is kept for compatibility and is not a deadline: type K has not been permitted since 21.11.2025, and the banks guarantee payment of a type K QR-bill only until the end of September 2026. |
| unstructured_message | Yes | |
| ultimate_creditor_empty | Yes |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, yet the description adds substantial behavior: warnings vs errors semantics (postcode_town_mismatch and friends never flip 'valid'), the not_verifiable state and its silent failure mode, the proposed_structured fix field, source-string citation requirement, and cost/quota terms. No contradiction with the read-only annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well front-loaded with USE WHEN / DO NOT USE / RETURNS / COST headers, and most content is load-bearing. But the COST block runs several sentences deep into key generation endpoints and monthly quotas that duplicate the request_api_key / poll_api_key siblings, which dilutes a tool description for a zero-argument-cost read.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an existing output schema, the description pre-digests the return shape (creditor_iban sub-fields, findings, next_steps) and explains the non-obvious fields (sps_check, proposed_structured, not_verifiable). Nothing an agent needs to call it correctly or interpret the result is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema's own payload description enumerates the full line layout in more detail than the prose does, so the description adds little parameter-level meaning beyond 'the text a QR-bill's code carries (starts with SPC)'. Baseline 3 applies when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Check a Swiss QR-bill payload') and immediately scopes it: the QR text beginning with SPC, checked rule by rule with SIX-cited findings. An agent can distinguish it from validate_iban, check_postal_address and validate_payment_reference without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit USE WHEN scenario (scanned or generated QR-bill, before paying or issuing) plus an explicit DO NOT USE that names the alternative tool (validate_iban) and the question it answers instead (bank holding the account, payment-rail participation). The when/when-not pair is as clear as it gets.
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 calls/month, on the REST API or on this transport, and POST /v1/keys/claim lifts that same key to 200 a month. Send the key here as Authorization: Bearer ifk_… (or X-API-Key) and each call counts against it exactly as on the REST API).
| 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. |
| note | No | Present only when found is false and the part of the directory served from a private file (EBA STEP2, NBP and OeNB records) is not loaded on this deployment: the absence was not looked up there. |
| 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. |
| address | No | Registered head-office address of the legal entity, from the same directory row as GET /v1/bic/:code and the bic.address of validate_iban, with its source and as_of (the date the entity last filed it, usually older than the bank name beside it). Null when the source publishes no address for this BIC. It is the seat of the legal entity, not the branch, so address.city may differ from city. |
| 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 | |
| address_available | No | True when address is not null. |
| 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
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is covered; the description goes well beyond by disclosing coverage (121k rows, 39k with LEI), staleness (SWIFT directory copy frozen January 2018 comprising ~two thirds of rows), and the important caveat that listed_in_current_source is never false today because absences are unproven. That caveat is exactly the kind of trust signal an agent needs. It loses a point only because this disclosure is entangled with a long pricing/API-key aside that is billing, not tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Use/do-not-use guidance is front-loaded, which is good, but the back half is bloated: a long paragraph on source/source_as_of/listed_in_current_source semantics that largely restates output-schema territory, plus a lengthy parenthetical on free-tier quotas and generating an ifk_ key via REST endpoints. The $0.003 cost line earns its place; the multi-sentence key-provisioning detour does not.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter lookup with an output schema and full annotation coverage, this is more than adequate: input format, data provenance, provenance caveats, and cost are all present. The only shortfall is allocation rather than omission — field-level return semantics for source/list flags are elaborated in the description where the output schema could carry them, while the billing detail crowds out nothing useful but adds noise.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter is already documented as an 8-or-11-char code. The description adds concrete format guidance and worked examples ("UBSWCHZH80A", "DEUTDEFF") plus the alphanumeric constraint, which marginally exceeds the schema but does not discuss normalization or what happens to malformed input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Resolve a BIC / SWIFT code into the underlying bank") and enumerates the returned fields (name, country, city, LEI, head-office address). It also explicitly distinguishes itself from the sibling that handles a related but different input (validate_iban), so an agent can pick correctly without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Contains explicit USE WHEN conditions (user already holds an 8/11-char BIC and asks which bank it belongs to, where it is, or its LEI) and an explicit DO NOT USE clause routing IBAN inputs to validate_iban. Both the positive and negative case are named, with the alternative tool identified.
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, re-read weekly). 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 calls/month, on the REST API or on this transport, and POST /v1/keys/claim lifts that same key to 200 a month. Send the key here as Authorization: Bearer ifk_… (or X-API-Key) and each call counts against it exactly as on the REST API).
| 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 | |
| qr_iids | No | Every QR-IID SIX allocates to the institution, present only when there is more than one; qr_iid carries the lowest. |
| sic_iid | No | |
| valid_on | No | |
| cost_usdc | No | What THIS call was billed. Zero on the free MCP tier. |
| is_qr_iid | No | Present (true) only when the IID asked about is a QR-IID (SIX QR-bill range 30000-31999); iid then carries the standard IID of the institution and qr_iid the QR-IID asked about. |
| institution | No | |
| qr_iid_source | No | How qr_iid was obtained. register = SIX BankMaster publishes this pairing; headquarters = inherited from the head office (headquarters_iid), an inference and not a published SIX pairing. Null when qr_iid is null. |
| list_price_usdc | No | Catalogue price of the same call on the paid REST/x402 route. |
| redirected_from | No | |
| state_guarantee | No | Present for the 24 Swiss cantonal banks only, matched by head-office IID; a branch or QR-IID takes its head office's entry. A description of the institution, not an assessment of the bank or of any account. |
| payment_services | No |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the readOnly/idempotent annotations by disclosing data provenance and freshness (1,100+ SIX BankMaster entries, re-read weekly), coverage breadth (all six BankMaster IIDs, full payment-rail participation), rate limits (25 units/week per source address, Monday 00:00 UTC reset), and auth handling (Authorization: Bearer ifk_… or X-API-Key).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose, USE WHEN, coverage and RETURNS blocks are well front-loaded and information-dense. However, the COST section is a long run-on sentence with nested parentheses containing key-generation URLs and quota arithmetic that crowds out tool-selection information and makes the definition hard to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Everything an agent needs is present: what it resolves, when to call it, what the returned fields are (institution, address, bic, payment_services, sic_iid, qr_iid, valid_on), geographic applicability, and cost constraints. An output schema and annotations exist, so the description need not go further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single 'iid' property already documents 'Swiss IID (1-5 digit number)'; the description only restates the 1-to-5-digit constraint. No additional semantics (e.g. leading zeros, padding, error behavior for unknown IIDs) are added, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource: 'Resolve a Swiss BC-Nummer / IID ... into the underlying institution', and spells out the mapping direction. It clearly differs from siblings like lookup_bic, validate_iban or check_swiss_qr_bill by naming the clearing-code resource and the institution-resolution output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE WHEN' block enumerates concrete triggers (BC-Nummer/IID mention, CH/LI IBAN clearing code, SIC/euroSIC routing questions, QR-IID resolution, bank vs PFS classification). It also states the negative scope: 'Only relevant for CH and LI accounts'.
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, or the header "Authorization: Bearer " for the hosted server; 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
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only give generic hints (readOnly=false, idempotent=false, openWorld=false). The description goes well beyond them: it discloses the ~30s server wait, the polling cadence, that 'approved' returns the key exactly once and never again, what each status string means, fallback behavior on expired/invalid grants, and that the call is free and does not consume the free allowance. That is unusually rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is long but front-loaded and segmented into USE WHEN / HOW TO CALL / WHAT THE ANSWERS MEAN blocks, so it scans well and every sentence carries operational content. It is slightly denser than strictly necessary, which keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema existing (so return values need not be explained), the description still maps each likely status to an agent action, gives retry timing, and covers terminal failure fallbacks. For a polling tool with tricky one-shot credential semantics, nothing needed to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the sole optional parameter is already documented there. The description's 'leave device_code empty to reuse the last request from this session' merely restates the schema text, adding no new syntax or format detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: collect/poll the IBANforge API key once a human has approved the corresponding request. It explicitly distinguishes itself from the sibling request_api_key, which opens the request rather than collecting the result, so an agent can route between the two without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit precondition ('USE WHEN: you have called request_api_key and shown the code to your human'), names the prerequisite sibling, and adds exclusions/limits such as calling once per minute, never in a tight loop, and at most one more request or poll on failure. Nothing about when to use or when to stop is left to inference.
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 your human a free IBANforge API key, without any e-mail address. The key does not unlock this session: it works once your human puts it in the MCP client configuration and reconnects, or sends it to the REST API, so tell them where it goes when you hand it over: config_line (returned by poll_api_key) for Claude Code with the npm package; for the hosted server https://api.ibanforge.com/mcp, the header "Authorization: Bearer ", which Claude and Claude Desktop take under Request headers when the custom connector is added; ChatGPT sends no key to a connector, so in ChatGPT the key serves on the REST API only. USE WHEN: you used up the free allowance, a call answers 402, or your human is 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
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (readOnly=false, idempotent=false, destructive=false), leaving the operational behavior to the description, which delivers richly: the key does not unlock the current session, it requires a human reconnect or REST use, status must be read first, display_to_human must be shown verbatim, the agent must not open the link or invent an e-mail, and the call does not consume the free allowance. These are non-obvious traits an agent would otherwise get wrong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and trigger are front-loaded in the first sentence and the 'USE WHEN' / 'WHAT YOU MUST DO' structure is easy to scan. It is nonetheless long, embedding client-specific configuration detail (config_line, Authorization header, ChatGPT caveat) that is useful but dense; slightly more than strictly needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-optional-param tool with an output schema, the description covers everything an agent needs: the trigger conditions, the status/display_to_human handling contract, the human hand-off protocol, and the follow-up call. Return-value mechanics are deferred appropriately to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters (reason, client_name) are fully documented there as optional strings shown on the approval page. The description never references them, so it adds no meaning beyond the schema; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource — 'Start the process that gives your human a free IBANforge API key' — and immediately scopes it ('without any e-mail address'), which distinguishes it from poll_api_key, the sibling it explicitly hands off to. An agent can tell what this does and what it does not do (unlock the current session) without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger list: 'USE WHEN: you used up the free allowance, a call answers 402, or your human is about to run more than a handful of validations.' It also names the required follow-up call (poll_api_key) and states the tool is free and works after the allowance is spent, so the agent knows both when to call it and what to do next.
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.
| 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
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false), the description discloses high-value behavior: the call is free, does not consume the free allowance, still works after the allowance is spent, and is read by a human. The quota interaction is exactly the kind of context an agent cannot infer from structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then usage conditions, then the quota-exemption note — a sensible order with little waste. The capitalized 'PAYING' and the parenthetical blocker list are slightly emphatic but carry real information about accepted report types.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Seven parameters with full schema coverage plus an output schema mean the description needn't explain fields or returns; it concentrates on when to call and the allowance exemption, which is what an agent cannot get elsewhere. Nothing needed to invoke correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every field including the error_type enum. The description's category list loosely mirrors that enum, but it adds no syntax, format, or bundling guidance beyond the schema, so the baseline applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and target: 'Report a problem or a need directly to the IBANforge operators', then enumerates the exact report categories (wrong validation, stale BIC, latency, blockers). An agent can immediately distinguish this from sibling validation/lookup tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The explicit 'USE WHEN' clause gives concrete triggering conditions (wrong result, missing data, hitting a wall on quota/payment/capability). It does not name alternatives such as validate_iban or lookup_bic as the tools to use instead for normal work, so it stops short of full when-not guidance.
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 | not_applicable | not_checked, detail?, method?, verified_by? } (FR, MC, BE, IT, SM, ES and DE only): the national key inside the BBAN; fail means the account number cannot have been issued as written, and valid stays true; in DE a fail with verified_by independent_implementation is a warning (national_check_digits_suspect), not a stop, and not_checked means the bank code or its Bundesbank method is not covered here. 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 calls/month, on the REST API or on this transport, and POST /v1/keys/claim lifts that same key to 200 a month. Send the key here as Authorization: Bearer ifk_… (or X-API-Key) and each call counts against it exactly as on the REST API).
| 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), ES (DC) and DE (the account-number check digit, by the method the Bundesbank lists for the bank code), with the proof in the national_check_digits block, and for GB (Vocalink modulus), with the proof in modulus_check; not_checked elsewhere. In DE it is not_checked when the bank code is not in the Bundesbank file or its method is not checked here, and not_applicable when the bank uses no check digit (method 09); national_check_digits.verified_by says whether a German verdict rests on the Bundesbank test numbers or on an independent implementation only. 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, ES or DE (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), de_pruefziffer (DE: the check digit of the 10-digit account number, computed by the method the Deutsche Bundesbank lists for the bank code in its Bankleitzahlendatei, named in method; the IBAN check digits already cover the whole BBAN, this says whether that bank could have issued the account number). 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: a BBAN without the national layout, which a valid IBAN never has, or in DE a bank that uses no check digit (method 09) or a method that defines none for that range of account numbers. not_checked (DE only): the check did not run on our side, because the bank code is not in the Bundesbank file or its method is not checked here (method 44, and methods no bank uses); it says nothing about the beneficiary. verified_by (DE only, whenever the method ran): bundesbank_test_numbers (the method gives the expected answer on every test number and worked example the Bundesbank publishes; a fail adds the blocking step national_check_digits_failed) or independent_implementation (the Bundesbank publishes no test number for the method, which was verified against an independent implementation only; a fail adds the warning step national_check_digits_suspect and never stops a payment). detail, present on fail, not_applicable and not_checked, says which digits disagree or why nothing was checked; it never gives the expected key. In DE the block also carries method (the Bundesbank method code), verified_by, source (with the credit line the Bundesbank asks for) and table_fetched_on (the day the method table was read). checks.national_check_digits repeats status. |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond annotations: discloses cost ($0.005/call), free-tier limits, key auth, the critical caveat that valid=true only means well-formed, that bic:null is ambiguous and must be read via bank_code_check, and that authoritative registers are only DE/AT/BE/SK/CZ/BG/CH/LI. This is unusually rich behavioral context; it loses a point only because the pricing/key-generation paragraph is operational noise rather than tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded purpose and USE WHEN are good, but the RETURNS section is a massive field-by-field re-specification of an output schema that already exists, and the COST block walks through key-generation endpoints that do not belong in a tool description. Structure is present but the piece is far longer than needed for an agent to invoke it correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite redundancy, nothing an agent needs is missing: it covers the valid-vs-bank_code_holder distinction, the null-BIC pitfall, authoritative source list, limitations (does not confirm account existence), and cost. Completeness is not a gap here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter, fully documented in the schema (spaces/hyphens stripped automatically), so the schema carries the parameter burden. The description adds no parameter-level detail beyond the schema, but with 100% coverage and a single input the baseline is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource+scope: verify IBAN validity plus enrich with bank, compliance and routing data across 89 countries. It is clearly distinguishable from siblings like lookup_bic and batch_validate_iban, which do narrower or batched work.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit USE WHEN enumeration (user pastes an IBAN, asks about issuing bank, neobank vs traditional, SEPA reachability, VoP) and an explicit PREFER OVER LOCAL VALIDATION rule explaining why mod-97 is insufficient. No ambiguity about when to select this tool.
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 calls/month, on the REST API or on this transport, and POST /v1/keys/claim lifts that same key to 200 a month. Send the key here as Authorization: Bearer ifk_… (or X-API-Key) and each call counts against it exactly as on the REST API).
| 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
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only/idempotent/non-destructive, but the description goes far beyond: scheme-by-scheme behaviour, the null/unverifiable_without_creditor_config outcome for KID/OCR, the warning never to relay those as invalid, the QRR/QR-IBAN pairing legality rule, and the independence of valid vs pairing. This is exactly the behavioural context an agent cannot get from structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads purpose and is organised under clear headers (USE WHEN / DO NOT USE / SCHEMES / AMBIGUITY / PAIRING / COST), but it is very long. The COST block, including key-generation URLs and weekly/monthly quota mechanics, is disproportionately verbose for a tool definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a checksum tool with an output schema, the description covers everything an agent needs: supported schemes, ambiguity resolution, pairing semantics, the unverifiable case, and the auditability fields (source/as_of) referenced for relay. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 real meaning on top: iban triggers a pairing verdict (not just a field), and reference_type is explained as a disambiguator for the 12-digit OGM/Finnish collision, with `also_valid_as` as the fallback reading.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (validate a structured payment reference, plus the IBAN pairing decision) and explicitly scopes it against validate_iban. The scope is unambiguous and distinguishes it from every sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit USE WHEN triggers (assembling a payment instruction, Swiss IBAN + reference, pasted 'RF...'/27-digit/+++ block) and an explicit DO NOT USE routing to validate_iban. Alternative-selection guidance is complete.
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.
4 tool updates
- Changed
check_postal_address2 fields changed- added
Output schema / properties / postcode_localityAdded value: +{ + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "as_of": { + "description": "Version date of the directory (YYYY-MM-DD).", + "type": [ + "string", + "null" + ] + }, + "detail": { + "description": "What was compared and what came out of it.", + "type": "string" + }, + "localities": { + "description": "The entries the directory gives for this postcode; empty when it has none.", + "items": { + "additionalProperties": false, + "properties": { + "canton": { + "description": "null in Liechtenstein.", + "type": [ + "string", + "null" + ] + }, + "country": { + "description": "CH | LI", + "type": "string" + }, + "municipality": { + "type": "string" + }, + "name": { + "description": "The locality as the directory writes it.", + "type": "string" + } + }, + "required": [ + "name", + "municipality", + "canton", + "country" + ], + "type": "object" + }, + "type": "array" + }, + "source": { + "description": "The directory, its version and the credit ©swisstopo that its terms require.", + "type": "string" + }, + "status": { + "description": "match | town_mismatch | other_country | postcode_not_listed | not_verifiable | directory_unavailable. not_verifiable: the postcode is not in the directory, which lists territory only, while the town is listed under other postcodes of the same postal area (a post-office box or business postcode is likely).", + "type": "string" + } + }, + "required": [ + "status", + "localities", + "detail", + "source", + "as_of" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "Swiss and Liechtenstein addresses with a postcode and a town: whether the two go together in the official directory of localities of swisstopo. Informative, beside the format verdicts: it does not change conforms or valid. The street is not checked. null for any other address." +} - changed
Output schema / requiredPrevious value: -[ - "scheme", - "conforms", - "findings", - "note" -]New value: +[ + "scheme", + "conforms", + "findings", + "postcode_locality", + "note" +]
- Changed
check_swiss_qr_bill2 fields changed- changed
Output schema / properties / creditor / properties / sps_check / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "conforms": { - "type": "boolean" - }, - "findings": { - "items": { - "additionalProperties": false, - "properties": { - "detail": { - "type": "string" - }, - "rule": { - "type": "string" - }, - "source": { - "type": "string" - }, - "verdict": { - "type": "string" - } - }, - "required": [ - "rule", - "verdict", - "detail", - "source" - ], - "type": "object" - }, - "type": "array" - }, - "note": { - "type": "string" - }, - "scheme": { - "type": "string" - } - }, - "required": [ - "scheme", - "conforms", - "findings", - "note" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "conforms": { + "type": "boolean" + }, + "findings": { + "items": { + "additionalProperties": false, + "properties": { + "detail": { + "type": "string" + }, + "rule": { + "type": "string" + }, + "source": { + "type": "string" + }, + "verdict": { + "type": "string" + } + }, + "required": [ + "rule", + "verdict", + "detail", + "source" + ], + "type": "object" + }, + "type": "array" + }, + "note": { + "type": "string" + }, + "postcode_locality": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "as_of": { + "description": "Version date of the directory (YYYY-MM-DD).", + "type": [ + "string", + "null" + ] + }, + "detail": { + "description": "What was compared and what came out of it.", + "type": "string" + }, + "localities": { + "description": "The entries the directory gives for this postcode; empty when it has none.", + "items": { + "additionalProperties": false, + "properties": { + "canton": { + "description": "null in Liechtenstein.", + "type": [ + "string", + "null" + ] + }, + "country": { + "description": "CH | LI", + "type": "string" + }, + "municipality": { + "type": "string" + }, + "name": { + "description": "The locality as the directory writes it.", + "type": "string" + } + }, + "required": [ + "name", + "municipality", + "canton", + "country" + ], + "type": "object" + }, + "type": "array" + }, + "source": { + "description": "The directory, its version and the credit ©swisstopo that its terms require.", + "type": "string" + }, + "status": { + "description": "match | town_mismatch | other_country | postcode_not_listed | not_verifiable | directory_unavailable. not_verifiable: the postcode is not in the directory, which lists territory only, while the town is listed under other postcodes of the same postal area (a post-office box or business postcode is likely).", + "type": "string" + } + }, + "required": [ + "status", + "localities", + "detail", + "source", + "as_of" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "Swiss and Liechtenstein addresses with a postcode and a town: whether the two go together in the official directory of localities of swisstopo. Informative, beside the format verdicts: it does not change conforms or valid. The street is not checked. null for any other address." + }, + "scheme": { + "type": "string" + } + }, + "required": [ + "scheme", + "conforms", + "findings", + "postcode_locality", + "note" + ], + "type": "object" + }, + { + "type": "null" + } +] - changed
Output schema / properties / ultimate_debtor / properties / sps_check / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "conforms": { - "type": "boolean" - }, - "findings": { - "items": { - "additionalProperties": false, - "properties": { - "detail": { - "type": "string" - }, - "rule": { - "type": "string" - }, - "source": { - "type": "string" - }, - "verdict": { - "type": "string" - } - }, - "required": [ - "rule", - "verdict", - "detail", - "source" - ], - "type": "object" - }, - "type": "array" - }, - "note": { - "type": "string" - }, - "scheme": { - "type": "string" - } - }, - "required": [ - "scheme", - "conforms", - "findings", - "note" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "conforms": { + "type": "boolean" + }, + "findings": { + "items": { + "additionalProperties": false, + "properties": { + "detail": { + "type": "string" + }, + "rule": { + "type": "string" + }, + "source": { + "type": "string" + }, + "verdict": { + "type": "string" + } + }, + "required": [ + "rule", + "verdict", + "detail", + "source" + ], + "type": "object" + }, + "type": "array" + }, + "note": { + "type": "string" + }, + "postcode_locality": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "as_of": { + "description": "Version date of the directory (YYYY-MM-DD).", + "type": [ + "string", + "null" + ] + }, + "detail": { + "description": "What was compared and what came out of it.", + "type": "string" + }, + "localities": { + "description": "The entries the directory gives for this postcode; empty when it has none.", + "items": { + "additionalProperties": false, + "properties": { + "canton": { + "description": "null in Liechtenstein.", + "type": [ + "string", + "null" + ] + }, + "country": { + "description": "CH | LI", + "type": "string" + }, + "municipality": { + "type": "string" + }, + "name": { + "description": "The locality as the directory writes it.", + "type": "string" + } + }, + "required": [ + "name", + "municipality", + "canton", + "country" + ], + "type": "object" + }, + "type": "array" + }, + "source": { + "description": "The directory, its version and the credit ©swisstopo that its terms require.", + "type": "string" + }, + "status": { + "description": "match | town_mismatch | other_country | postcode_not_listed | not_verifiable | directory_unavailable. not_verifiable: the postcode is not in the directory, which lists territory only, while the town is listed under other postcodes of the same postal area (a post-office box or business postcode is likely).", + "type": "string" + } + }, + "required": [ + "status", + "localities", + "detail", + "source", + "as_of" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "Swiss and Liechtenstein addresses with a postcode and a town: whether the two go together in the official directory of localities of swisstopo. Informative, beside the format verdicts: it does not change conforms or valid. The street is not checked. null for any other address." + }, + "scheme": { + "type": "string" + } + }, + "required": [ + "scheme", + "conforms", + "findings", + "postcode_locality", + "note" + ], + "type": "object" + }, + { + "type": "null" + } +]
- Changed
lookup_bic2 fields changed- added
Output schema / properties / addressAdded value: +{ + "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" + } + ], + "description": "Registered head-office address of the legal entity, from the same directory row as GET /v1/bic/:code and the bic.address of validate_iban, with its source and as_of (the date the entity last filed it, usually older than the bank name beside it). Null when the source publishes no address for this BIC. It is the seat of the legal entity, not the branch, so address.city may differ from city." +} - added
Output schema / properties / address_availableAdded value: +{ + "description": "True when address is not null.", + "type": "boolean" +}
- Changed
lookup_ch_clearing4 fields changed- added
Output schema / properties / is_qr_iidAdded value: +{ + "description": "Present (true) only when the IID asked about is a QR-IID (SIX QR-bill range 30000-31999); iid then carries the standard IID of the institution and qr_iid the QR-IID asked about.", + "type": "boolean" +} - added
Output schema / properties / qr_iid_sourceAdded value: +{ + "anyOf": [ + { + "enum": [ + "register", + "headquarters" + ], + "type": "string" + }, + { + "type": "null" + } + ], + "description": "How qr_iid was obtained. register = SIX BankMaster publishes this pairing; headquarters = inherited from the head office (headquarters_iid), an inference and not a published SIX pairing. Null when qr_iid is null." +} - added
Output schema / properties / qr_iidsAdded value: +{ + "description": "Every QR-IID SIX allocates to the institution, present only when there is more than one; qr_iid carries the lowest.", + "items": { + "type": "string" + }, + "type": "array" +} - added
Output schema / properties / state_guaranteeAdded value: +{ + "additionalProperties": false, + "description": "Present for the 24 Swiss cantonal banks only, matched by head-office IID; a branch or QR-IID takes its head office's entry. A description of the institution, not an assessment of the bank or of any account.", + "properties": { + "as_of": { + "description": "The day the text was read (YYYY-MM-DD).", + "type": "string" + }, + "canton": { + "description": "Two-letter canton code.", + "type": "string" + }, + "guaranteed": { + "description": "True when the cantonal law makes the canton liable for the bank's liabilities where the bank's own funds fall short (Staatsgarantie, garantie de l'État).", + "type": "boolean" + }, + "note": { + "description": "Present where the guarantee ended (BEKB, BCGE: what the law kept and until when) or where the law has none (BCV).", + "type": "string" + }, + "source": { + "description": "The law, its number in the cantonal collection, and the article. The exclusions the law writes (for example subordinated debt) are in that law; where they sit in another article, that article is cited too.", + "type": "string" + }, + "url": { + "description": "The text that was read.", + "type": "string" + } + }, + "required": [ + "guaranteed", + "canton", + "source", + "url", + "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": { - "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, SM, ME, RS, IL and MN; 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" - } -]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, SM, ME, RS, IL, MN and RU; 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" + } +]
- 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 DE, AT, BE, SK, CZ, BG, CH, LI, SM, ME, RS, IL and MN; 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" - } -]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, SM, ME, RS, IL, MN and RU; 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" + } +]
- 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 DE, AT, BE, SK, CZ, BG, CH, LI, SM, ME, RS, IL and MN; 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" - } -]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, SM, ME, RS, IL, MN and RU; 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" + } +]
3 tool updates
- Changed
batch_validate_iban3 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 DE, AT, BE, SK, CZ, BG, CH, LI, SM, ME and RS; 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" - } -]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, SM, ME, RS, IL and MN; 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 / sepa / properties / register_as_ofAdded value: +{ + "description": "The day the EPC registers served were extracted (YYYY-MM-DD), with register_source.", + "type": [ + "string", + "null" + ] +} - added
Output schema / properties / results / items / properties / sepa / properties / register_sourceAdded value: +{ + "description": "Present only when the EPC registers (schemes or VoP) were read for this bank: \"Source: European Payments Council\".", + "type": "string" +}
- Changed
check_compliance7 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 DE, AT, BE, SK, CZ, BG, CH, LI, SM, ME and RS; 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" - } -]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, SM, ME, RS, IL and MN; 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 / compliance / properties / reachability / properties / as_ofAdded value: +{ + "description": "The day the EPC registers served were extracted (YYYY-MM-DD), with source.", + "type": [ + "string", + "null" + ] +} - added
Output schema / properties / compliance / properties / reachability / properties / sourceAdded value: +{ + "description": "Present only when the EPC scheme registers were read: \"Source: European Payments Council\".", + "type": "string" +} - added
Output schema / properties / compliance / properties / vop / properties / as_ofAdded value: +{ + "description": "The day the EPC register served was extracted (YYYY-MM-DD), with source.", + "type": [ + "string", + "null" + ] +} - added
Output schema / properties / compliance / properties / vop / properties / sourceAdded value: +{ + "description": "Present only when the EPC VoP register was read: \"Source: European Payments Council\".", + "type": "string" +} - added
Output schema / properties / sepa / properties / register_as_ofAdded value: +{ + "description": "The day the EPC registers served were extracted (YYYY-MM-DD), with register_source.", + "type": [ + "string", + "null" + ] +} - added
Output schema / properties / sepa / properties / register_sourceAdded value: +{ + "description": "Present only when the EPC registers (schemes or VoP) were read for this bank: \"Source: European Payments Council\".", + "type": "string" +}
- Changed
validate_iban3 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 DE, AT, BE, SK, CZ, BG, CH, LI, SM, ME and RS; 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" - } -]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, SM, ME, RS, IL and MN; 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 / sepa / properties / register_as_ofAdded value: +{ + "description": "The day the EPC registers served were extracted (YYYY-MM-DD), with register_source.", + "type": [ + "string", + "null" + ] +} - added
Output schema / properties / sepa / properties / register_sourceAdded value: +{ + "description": "Present only when the EPC registers (schemes or VoP) were read for this bank: \"Source: European Payments Council\".", + "type": "string" +}
1 tool update
- Changed
batch_validate_iban2 fields changed- added
Output schema / properties / valid_countAdded value: +{ + "description": "Number of results whose valid is true.", + "type": "number" +} - changed
Output schema / requiredPrevious value: -[ - "results", - "count" -]New value: +[ + "results", + "count", + "valid_count" +]
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 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" - } -]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, SM, ME and RS; 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" + } +]
- 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 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" - } -]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, SM, ME and RS; 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" + } +]
- 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 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" - } -]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, SM, ME and RS; 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" + } +]
1 tool update
- Changed
check_swiss_qr_bill1 field changed- changed
Output schema / properties / ready_for_2026_11_14 / descriptionPrevious value: -"valid AND every present address is structured (type S): what banks require from 14.11.2026."New value: +"valid AND every present address is structured (type S). The name is kept for compatibility and is not a deadline: type K has not been permitted since 21.11.2025, and the banks guarantee payment of a type K QR-bill only until the end of September 2026."
3 tool updates
- Changed
batch_validate_iban9 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: 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."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), ES (DC) and DE (the account-number check digit, by the method the Bundesbank lists for the bank code), with the proof in the national_check_digits block, and for GB (Vocalink modulus), with the proof in modulus_check; not_checked elsewhere. In DE it is not_checked when the bank code is not in the Bundesbank file or its method is not checked here, and not_applicable when the bank uses no check digit (method 09); national_check_digits.verified_by says whether a German verdict rests on the Bundesbank test numbers or on an independent implementation only. 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." - changed
Output schema / properties / results / items / properties / national_check_digits / descriptionPrevious value: -"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."New value: +"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, ES or DE (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), de_pruefziffer (DE: the check digit of the 10-digit account number, computed by the method the Deutsche Bundesbank lists for the bank code in its Bankleitzahlendatei, named in method; the IBAN check digits already cover the whole BBAN, this says whether that bank could have issued the account number). 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: a BBAN without the national layout, which a valid IBAN never has, or in DE a bank that uses no check digit (method 09) or a method that defines none for that range of account numbers. not_checked (DE only): the check did not run on our side, because the bank code is not in the Bundesbank file or its method is not checked here (method 44, and methods no bank uses); it says nothing about the beneficiary. verified_by (DE only, whenever the method ran): bundesbank_test_numbers (the method gives the expected answer on every test number and worked example the Bundesbank publishes; a fail adds the blocking step national_check_digits_failed) or independent_implementation (the Bundesbank publishes no test number for the method, which was verified against an independent implementation only; a fail adds the warning step national_check_digits_suspect and never stops a payment). detail, present on fail, not_applicable and not_checked, says which digits disagree or why nothing was checked; it never gives the expected key. In DE the block also carries method (the Bundesbank method code), verified_by, source (with the credit line the Bundesbank asks for) and table_fetched_on (the day the method table was read). checks.national_check_digits repeats status." - changed
Output schema / properties / results / items / properties / national_check_digits / properties / detail / descriptionPrevious value: -"Present on fail and not_applicable only."New value: +"Present on fail, not_applicable and not_checked." - added
Output schema / properties / results / items / properties / national_check_digits / properties / methodAdded value: +{ + "description": "DE only: the Bundesbank check-digit method code of the bank code.", + "type": "string" +} - changed
Output schema / properties / results / items / properties / national_check_digits / properties / scheme / descriptionPrevious value: -"fr_rib_key | be_mod97 | it_cin | es_dc"New value: +"fr_rib_key | be_mod97 | it_cin | es_dc | de_pruefziffer" - added
Output schema / properties / results / items / properties / national_check_digits / properties / sourceAdded value: +{ + "description": "DE only: the source, with the credit line the Bundesbank asks for.", + "type": "string" +} - changed
Output schema / properties / results / items / properties / national_check_digits / properties / status / descriptionPrevious value: -"pass | fail | not_applicable"New value: +"pass | fail | not_applicable | not_checked" - added
Output schema / properties / results / items / properties / national_check_digits / properties / table_fetched_onAdded value: +{ + "description": "DE only: the day the method table was read (YYYY-MM-DD).", + "type": "string" +} - added
Output schema / properties / results / items / properties / national_check_digits / properties / verified_byAdded value: +{ + "description": "DE only: bundesbank_test_numbers (a fail is blocking) | independent_implementation (a fail is a warning, national_check_digits_suspect).", + "type": "string" +}
- Changed
check_compliance9 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: 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."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), ES (DC) and DE (the account-number check digit, by the method the Bundesbank lists for the bank code), with the proof in the national_check_digits block, and for GB (Vocalink modulus), with the proof in modulus_check; not_checked elsewhere. In DE it is not_checked when the bank code is not in the Bundesbank file or its method is not checked here, and not_applicable when the bank uses no check digit (method 09); national_check_digits.verified_by says whether a German verdict rests on the Bundesbank test numbers or on an independent implementation only. 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." - changed
Output schema / properties / national_check_digits / descriptionPrevious value: -"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."New value: +"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, ES or DE (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), de_pruefziffer (DE: the check digit of the 10-digit account number, computed by the method the Deutsche Bundesbank lists for the bank code in its Bankleitzahlendatei, named in method; the IBAN check digits already cover the whole BBAN, this says whether that bank could have issued the account number). 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: a BBAN without the national layout, which a valid IBAN never has, or in DE a bank that uses no check digit (method 09) or a method that defines none for that range of account numbers. not_checked (DE only): the check did not run on our side, because the bank code is not in the Bundesbank file or its method is not checked here (method 44, and methods no bank uses); it says nothing about the beneficiary. verified_by (DE only, whenever the method ran): bundesbank_test_numbers (the method gives the expected answer on every test number and worked example the Bundesbank publishes; a fail adds the blocking step national_check_digits_failed) or independent_implementation (the Bundesbank publishes no test number for the method, which was verified against an independent implementation only; a fail adds the warning step national_check_digits_suspect and never stops a payment). detail, present on fail, not_applicable and not_checked, says which digits disagree or why nothing was checked; it never gives the expected key. In DE the block also carries method (the Bundesbank method code), verified_by, source (with the credit line the Bundesbank asks for) and table_fetched_on (the day the method table was read). checks.national_check_digits repeats status." - changed
Output schema / properties / national_check_digits / properties / detail / descriptionPrevious value: -"Present on fail and not_applicable only."New value: +"Present on fail, not_applicable and not_checked." - added
Output schema / properties / national_check_digits / properties / methodAdded value: +{ + "description": "DE only: the Bundesbank check-digit method code of the bank code.", + "type": "string" +} - changed
Output schema / properties / national_check_digits / properties / scheme / descriptionPrevious value: -"fr_rib_key | be_mod97 | it_cin | es_dc"New value: +"fr_rib_key | be_mod97 | it_cin | es_dc | de_pruefziffer" - added
Output schema / properties / national_check_digits / properties / sourceAdded value: +{ + "description": "DE only: the source, with the credit line the Bundesbank asks for.", + "type": "string" +} - changed
Output schema / properties / national_check_digits / properties / status / descriptionPrevious value: -"pass | fail | not_applicable"New value: +"pass | fail | not_applicable | not_checked" - added
Output schema / properties / national_check_digits / properties / table_fetched_onAdded value: +{ + "description": "DE only: the day the method table was read (YYYY-MM-DD).", + "type": "string" +} - added
Output schema / properties / national_check_digits / properties / verified_byAdded value: +{ + "description": "DE only: bundesbank_test_numbers (a fail is blocking) | independent_implementation (a fail is a warning, national_check_digits_suspect).", + "type": "string" +}
- Changed
validate_iban9 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: 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."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), ES (DC) and DE (the account-number check digit, by the method the Bundesbank lists for the bank code), with the proof in the national_check_digits block, and for GB (Vocalink modulus), with the proof in modulus_check; not_checked elsewhere. In DE it is not_checked when the bank code is not in the Bundesbank file or its method is not checked here, and not_applicable when the bank uses no check digit (method 09); national_check_digits.verified_by says whether a German verdict rests on the Bundesbank test numbers or on an independent implementation only. 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." - changed
Output schema / properties / national_check_digits / descriptionPrevious value: -"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."New value: +"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, ES or DE (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), de_pruefziffer (DE: the check digit of the 10-digit account number, computed by the method the Deutsche Bundesbank lists for the bank code in its Bankleitzahlendatei, named in method; the IBAN check digits already cover the whole BBAN, this says whether that bank could have issued the account number). 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: a BBAN without the national layout, which a valid IBAN never has, or in DE a bank that uses no check digit (method 09) or a method that defines none for that range of account numbers. not_checked (DE only): the check did not run on our side, because the bank code is not in the Bundesbank file or its method is not checked here (method 44, and methods no bank uses); it says nothing about the beneficiary. verified_by (DE only, whenever the method ran): bundesbank_test_numbers (the method gives the expected answer on every test number and worked example the Bundesbank publishes; a fail adds the blocking step national_check_digits_failed) or independent_implementation (the Bundesbank publishes no test number for the method, which was verified against an independent implementation only; a fail adds the warning step national_check_digits_suspect and never stops a payment). detail, present on fail, not_applicable and not_checked, says which digits disagree or why nothing was checked; it never gives the expected key. In DE the block also carries method (the Bundesbank method code), verified_by, source (with the credit line the Bundesbank asks for) and table_fetched_on (the day the method table was read). checks.national_check_digits repeats status." - changed
Output schema / properties / national_check_digits / properties / detail / descriptionPrevious value: -"Present on fail and not_applicable only."New value: +"Present on fail, not_applicable and not_checked." - added
Output schema / properties / national_check_digits / properties / methodAdded value: +{ + "description": "DE only: the Bundesbank check-digit method code of the bank code.", + "type": "string" +} - changed
Output schema / properties / national_check_digits / properties / scheme / descriptionPrevious value: -"fr_rib_key | be_mod97 | it_cin | es_dc"New value: +"fr_rib_key | be_mod97 | it_cin | es_dc | de_pruefziffer" - added
Output schema / properties / national_check_digits / properties / sourceAdded value: +{ + "description": "DE only: the source, with the credit line the Bundesbank asks for.", + "type": "string" +} - changed
Output schema / properties / national_check_digits / properties / status / descriptionPrevious value: -"pass | fail | not_applicable"New value: +"pass | fail | not_applicable | not_checked" - added
Output schema / properties / national_check_digits / properties / table_fetched_onAdded value: +{ + "description": "DE only: the day the method table was read (YYYY-MM-DD).", + "type": "string" +} - added
Output schema / properties / national_check_digits / properties / verified_byAdded value: +{ + "description": "DE only: bundesbank_test_numbers (a fail is blocking) | independent_implementation (a fail is a warning, national_check_digits_suspect).", + "type": "string" +}
4 tool updates
- Changed
batch_validate_iban1 field changed- changed
Output schema / properties / results / items / properties / sepa / properties / bank_reachability / descriptionPrevious value: -"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."New value: +"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, or no bank was resolved because the bank-code check itself is unavailable (not consulted, never read as not_listed or no_bank). Absent outside SEPA."
- Changed
check_compliance1 field changed- changed
Output schema / properties / sepa / properties / bank_reachability / descriptionPrevious value: -"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."New value: +"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, or no bank was resolved because the bank-code check itself is unavailable (not consulted, never read as not_listed or no_bank). Absent outside SEPA."
- Changed
lookup_bic1 field changed- added
Output schema / properties / noteAdded value: +{ + "description": "Present only when found is false and the part of the directory served from a private file (EBA STEP2, NBP and OeNB records) is not loaded on this deployment: the absence was not looked up there.", + "type": "string" +}
- Changed
validate_iban1 field changed- changed
Output schema / properties / sepa / properties / bank_reachability / descriptionPrevious value: -"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."New value: +"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, or no bank was resolved because the bank-code check itself is unavailable (not consulted, never read as not_listed or no_bank). Absent outside SEPA."
3 tool updates
- Changed
batch_validate_iban3 fields changed- changed
Output schema / properties / results / items / properties / bank_code_check / properties / retired / descriptionPrevious value: -"True when an authoritative register is withdrawing the code. Still a verified result: it WAS allocated."New value: +"True when a register says the code is leaving (DE, authoritative) or has been struck off (IT, authoritative false, with retired_on). Still a verified result: it WAS allocated. Never a refusal." - added
Output schema / properties / results / items / properties / bank_code_check / properties / retired_onAdded value: +{ + "description": "YYYY-MM-DD, with retired where the register dates it (IT): the last day it lists this code for its last holder.", + "type": "string" +} - changed
Output schema / properties / results / items / properties / bank_code_check / properties / superseded_by / descriptionPrevious value: -"The bank code that takes over. Re-paper the beneficiary against it."New value: +"The bank code that takes over. DE: the successor the register designates, re-paper against it. IT: the legal successor by merger or incorporation, not necessarily the bank now holding the account."
- Changed
check_compliance3 fields changed- changed
Output schema / properties / bank_code_check / properties / retired / descriptionPrevious value: -"True when an authoritative register is withdrawing the code. Still a verified result: it WAS allocated."New value: +"True when a register says the code is leaving (DE, authoritative) or has been struck off (IT, authoritative false, with retired_on). Still a verified result: it WAS allocated. Never a refusal." - added
Output schema / properties / bank_code_check / properties / retired_onAdded value: +{ + "description": "YYYY-MM-DD, with retired where the register dates it (IT): the last day it lists this code for its last holder.", + "type": "string" +} - changed
Output schema / properties / bank_code_check / properties / superseded_by / descriptionPrevious value: -"The bank code that takes over. Re-paper the beneficiary against it."New value: +"The bank code that takes over. DE: the successor the register designates, re-paper against it. IT: the legal successor by merger or incorporation, not necessarily the bank now holding the account."
- Changed
validate_iban3 fields changed- changed
Output schema / properties / bank_code_check / properties / retired / descriptionPrevious value: -"True when an authoritative register is withdrawing the code. Still a verified result: it WAS allocated."New value: +"True when a register says the code is leaving (DE, authoritative) or has been struck off (IT, authoritative false, with retired_on). Still a verified result: it WAS allocated. Never a refusal." - added
Output schema / properties / bank_code_check / properties / retired_onAdded value: +{ + "description": "YYYY-MM-DD, with retired where the register dates it (IT): the last day it lists this code for its last holder.", + "type": "string" +} - changed
Output schema / properties / bank_code_check / properties / superseded_by / descriptionPrevious value: -"The bank code that takes over. Re-paper the beneficiary against it."New value: +"The bank code that takes over. DE: the successor the register designates, re-paper against it. IT: the legal successor by merger or incorporation, not necessarily the bank now holding the account."
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" + } +]
Related MCP Connectors
Validate IBANs and bank codes, verify payee names, and screen names against sanctions lists.
Validate IBANs in 111 countries; bank directory checks for DE, AT, BE, FR, LU, NL, PT and ES.
LEI lookups with parent companies (GLEIF), IBAN validation and UK sort code checks
Validate IBANs, generate test IBANs with real bank codes, look up BICs and bank codes (IBANgen).
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceValidates IBAN checksums and resolves bank codes via the OpenIBAN API.443 npmMIT
- AlicenseNot gradedqualityCmaintenanceEnables AI assistants to validate IBANs and bank codes across multiple countries, verify payee names against account holders, and screen names against major global sanctions lists. It connects clients to a hosted banking reference-data service over OAuth-authenticated HTTP.MIT
- AlicenseAqualityAmaintenanceEnables AI agents to validate IBANs, generate synthetic checksum-valid test IBANs, and look up bank registry records by BIC or domestic identifier, with optional paid capabilities for bank, BIC, and SEPA Instant/VoP reachability.643 PyPIMIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.