Skip to main content
Glama

Bank and BIC Directory Search

swift_lookup
Read-only

Search banks and financial institutions by name, SWIFT/BIC code, or country.

Covers both SWIFT-connected banks and non-SWIFT financial institutions (e-money issuers, payment processors, MFOs, brokerages, VASPs, etc.).

Returns: SWIFT/BIC code (if any), name, city, country, institution type, GPI membership, a coarse sanctions FLAG across 7 hard-sanctions watchlists (OFAC SDN, EU, UK, CA, CH, AU, NZ — see sanctions_note; this is NOT a full screen, use sanctions_screen for a compliance verdict), and enriched bank profile when available.

EVERY BANK COMES BACK SAYING WHETHER WE HOLD ITS CORRESPONDENT CHAIN. Read settlement_instructions on each bank: on_file: true with a currencies_on_file count means we hold that BIC8's actual correspondent BIC, nostro account number and national clearing ID, and read_with is the exact ssi_lookup call that returns them. on_file: false means we hold none in any currency — a gap in our data, not a finding about the bank. A null is "not established yet" and is neither. This is the answer to "which intermediary bank do I put on the instruction?", and it is a fact we either have or do not have — never one to recall from training data.

A BIC IDENTIFIES AN OFFICE, NOT A BRAND, AND THE DIFFERENCE IS PRICED. A name search returns ONE representative office per bank, elected by BIC convention rather than by relevance to the payment, and office_note says so whenever the bank holds more than one. Published tariffs, correspondent chains and settlement instructions are filed per BIC, so the choice changes the answer: transfer_cost("COBADEFF") returns Commerzbank's published 0.15% sending fee and transfer_cost("COBADEBB") refuses for want of a filed tariff, and both of those are Commerzbank AG in Germany. So:

  • If the user named a CITY, put it in the query — "Commerzbank Frankfurt" resolves to the Frankfurt office, and the plain name cannot.

  • If they did not, ask which BIC is on their statement or payment instruction before pricing or routing, and say which office you used.

  • Never present a representative office's BIC as "the bank's BIC".

Examples: swift_lookup("DEUTDEFF") # exact BIC lookup swift_lookup("Deutsche Bank") # search by name swift_lookup("Commerzbank Frankfurt") # bank + city -> that office's BIC swift_lookup("TBC PAY") # find non-SWIFT payment processor swift_lookup("bank", country="KZ") # explore banks in a country swift_lookup("Halyk", country="KZ") # find specific bank in country swift_lookup("Bank Mandiri", country="Indonesia") # full country name OK

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of banks to return, 1-100 (default 20). Values outside the range are clamped.
queryYesBank name, BIC, or bank name plus city ("Commerzbank Frankfurt"). A BIC may be 8 or 11 characters; an 11-character BIC ending in XXX is searched as its 8-character form. The 12-character address in an MT message header (BIC8 + terminal letter + branch) is not a BIC: pass its first 8 characters.
countryNoOptional country filter: an ISO 3166-1 alpha-2 code ("ID", "DE") or a full English name ("Indonesia", "Germany"). Names are resolved automatically.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / country / description
      Added value: +"Optional country filter: an ISO 3166-1 alpha-2 code (\"ID\", \"DE\") or a full English name (\"Indonesia\", \"Germany\"). Names are resolved automatically."
    • addedInput schema / properties / limit / description
      Added value: +"Maximum number of banks to return, 1-100 (default 20). Values outside the range are clamped."
    • addedInput schema / properties / query / description
      Added value: +"Bank name, BIC, or bank name plus city (\"Commerzbank Frankfurt\"). A BIC may be 8 or 11 characters; an 11-character BIC ending in XXX is searched as its 8-character form. The 12-character address in an MT message header (BIC8 + terminal letter + branch) is not a BIC: pass its first 8 characters."
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint and openWorldHint, so the description carries the rest and does so richly: it discloses the representative-office election behavior, the sanctioned-watchlist FLAG being coarse rather than a screen, and the tri-state semantics of settlement_instructions (on_file true / false / null, where null is 'not established yet'). It also warns that a name search returns only one office per bank and that BIC choice changes pricing, which is behavior an agent cannot infer.

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 critical scoping facts are front-loaded, but the body is heavy: all-caps emphasis lines, aphoristic asides ('never one to recall from training data'), and eight partly-overlapping examples pad the length. Most sentences carry information, but the styling and repetition keep it from being tight.

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?

Although an output schema exists and return values need not be described, the definition goes further and explains settlement_instructions and office_note semantics, which is exactly the interpretive context an agent needs. Nothing required 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.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already documents BIC length handling and the country filter, so the baseline is 3. The description adds genuine operational meaning beyond the schema by instructing that a user-named city belongs in the query string and by explaining why office selection inside the query changes the result.

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 ('Search banks and financial institutions by name, SWIFT/BIC code, or country') and explicitly scopes the corpus to SWIFT and non-SWIFT institutions. It distinguishes itself from siblings by name, routing compliance verdicts to sanctions_screen and correspondent data retrieval to ssi_lookup.

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?

Gives explicit when-to-use coverage with eight concrete call examples, plus when-not guidance ('this is NOT a full screen, use sanctions_screen for a compliance verdict'), a rule for including a city in the query, and a fallback instruction to ask the user for the BIC on their statement. Alternatives and exclusions are both spelled out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources