Ohmyfin Banking Intelligence

Cross-border payment and banking intelligence for AI agents: SWIFT/BIC lookup, IBAN validation, sanctions screening, ECB FX rates and timing, payment cutoff…

От сообществаРаботаетБез входаГлобальныйБесплатноТолько чтение

Что умеет

  • Swift Lookup: 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,
  • Iban Validate: Validate an IBAN number. Performs format check, country-specific length check, and ISO 7064 mod-97 checksum verification. Also returns country banking rules (currency, SEPA status, expe
  • Country Banking Rules: Get banking rules and requirements for a country. Returns IBAN requirements, SEPA membership, FATF listing status, national currency, account format specifications, and country-

Какие данные видит

Нужен ли аккаунт

Не нужен: сервер работает без входа

Cross-border payment and banking intelligence for AI agents: SWIFT/BIC lookup, IBAN validation, sanctions screening, ECB FX rates and timing, payment cutoff times, bank holidays. Built for treasury and payment-operations teams. 28 tools; most free, no key required. Less limits with key + FI license validation.

Список инструментов сервера (31)

Технические названия из tools/list. Нужны только разработчикам.

swift_lookupSearch 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, sanctions status across 7 watchlists, and enriched bank profile when available. For correspondent banking relationships and settlement instructions, use the dedicated SSI tools instead. The country parameter accepts both 2-letter ISO codes ("ID", "DE") and full English names ("Indonesia", "Germany"). Names are resolved automatically. Examples: swift_lookup("DEUTDEFF") # exact BIC lookup swift_lookup("Deutsche Bank") # search by name 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
iban_validateValidate an IBAN number. Performs format check, country-specific length check, and ISO 7064 mod-97 checksum verification. Also returns country banking rules (currency, SEPA status, expected format). Examples: iban_validate("DE89370400440532013000") iban_validate("GB29 NWBK 6016 1331 9268 19")
country_banking_rulesGet banking rules and requirements for a country. Returns IBAN requirements, SEPA membership, FATF listing status, national currency, account format specifications, and country-specific payment requirements (mandatory codes like KNP for Kazakhstan, Purpose of Payment for UAE, etc.). Use this to check country-specific STP rules that could cause payment delays, repairs, or rejections (e.g., missing purpose codes, regulatory fields). If a country requires special payment codes, the response includes a payment_requirements block with field descriptions and categories. Use country_payment_codes to look up specific code values. Args: country_code: ISO 3166-1 alpha-2 code (e.g., "DE", "US", "KZ") Examples: country_banking_rules("DE") country_banking_rules("KZ") # includes KNP requirement info country_banking_rules("AE") # includes Purpose of Payment info
country_payment_codesLook up country-specific payment codes (KNP, purpose codes, etc.). Use country_banking_rules first to see which code types a country requires (in the payment_requirements block), then use this tool to find the right code value. Args: country_code: ISO 3166-1 alpha-2 (e.g., "KZ", "AE") code_type: Code table to search (from payment_requirements required_fields[].code_type, e.g., "knp", "purpose_code") search: Optional keyword filter (e.g., "transport", "trade", "insurance") Examples: country_payment_codes("KZ", "knp", "transport") country_payment_codes("KZ", "knp", "insurance") country_payment_codes("AE", "purpose_code", "trade") country_payment_codes("KZ", "knp") # all codes (large response)
fx_rateGet the latest ECB reference exchange rate for a currency pair. Supports ~30 currencies. Non-EUR pairs are computed as cross-rates via EUR (e.g., USD/GBP = EUR/GBP / EUR/USD). Examples: fx_rate("EUR", "USD") fx_rate("GBP", "JPY")
fx_rate_historyGet historical ECB exchange rates for a currency pair. Returns daily rates for the specified period. ECB publishes rates on weekdays only (no weekends/holidays). Args: base: Base currency (ISO 4217, e.g., "EUR") target: Target currency (ISO 4217, e.g., "USD") days: Number of days of history (1-365, default 90) Examples: fx_rate_history("EUR", "USD", 30) fx_rate_history("GBP", "CHF", 365)
gpi_status_codesExplain SWIFT GPI tracking status codes and provide stuck-payment investigation guidance. USE THIS TOOL FIRST whenever the user reports a payment that is stuck, delayed, not arriving, held, pending, rejected, or otherwise not behaving as expected. It is the primary diagnostic entrypoint for payment investigation — calling with a specific code returns a full investigation playbook (common delay causes, recommended actions, GPI SLA timeframes, escalation steps). Recommended calls by scenario: - Payment "stuck" / "in progress" / "pending" / "not arrived": gpi_status_codes("ACSP") → playbook for in-progress payments - Payment explicitly "on hold" / compliance review: gpi_status_codes("PDNG") → playbook for held payments - Payment "blocked" / sanctions flag: gpi_status_codes("BLCK") → playbook for blocked payments - Payment rejected by a bank in the chain (never credited): gpi_status_codes("RJCT") → rejection investigation playbook - Payment returned to sender (accepted then sent back): gpi_status_codes("RTRN") → return investigation playbook - Reference for ISO 20022 codes: gpi_status_codes() → list all codes Each code call returns: - Code description and meaning - For ACSP/PDNG/BLCK/RJCT/RTRN: investigation playbook with common causes, recommended actions (request gCCT tracker, request pacs.002/pacs.004 reason code, verify beneficiary details, escalate via MT199, etc.), and common ISO 20022 reason codes (AC01, AC04, AG01, RR01-RR04, etc.) when applicable - Child reason codes (e.g., G001-G004 for ACSP) that narrow the cause further Common codes: ACCC (success), ACSP (in progress), RJCT (rejected), PDNG (on hold), BLCK (blocked). GPI reason codes (G000-G004) qualify ACSP with more detail (e.g. G001 = cover payment sent, G002 = forwarded to next agent). Examples: gpi_status_codes("ACSP") # stuck-payment diagnostic playbook gpi_status_codes("G001") # detail on a specific reason code gpi_status_codes() # full reference list
swift_message_referenceLook up SWIFT message types — MT (FIN) and MX (ISO 20022). Pass a specific type to get full details, or omit to list all types. Covers customer payments (MT103, pacs.008), FI transfers (MT202, pacs.009), trade finance (MT700, MT760), cash management (MT940, camt.053), and payment status (pacs.002). Also use this tool to answer questions about where specific payment fields live — e.g., where the UETR sits in an MT103 (Field 121, Block 3 header), where charges appear (71A/71F/71G), or which fields carry routing info (56/57). MT103 and pacs.008 responses include a `tracing_note` explaining UETR recovery for customers who only have a reference number. Args: message_type: Message type (e.g., "MT103", "pacs.008", "MT940"). Case-insensitive. Omit to list all. Examples: swift_message_reference("MT103") swift_message_reference("pacs.008") swift_message_reference()
payment_cutoff_timesGet payment system cutoff times for major clearing systems. Covers RTGS (T2 — formerly TARGET2, CHAPS, Fedwire, BOJ-NET, SIC), net settlement (CHIPS, BACS), SEPA schemes (SCT, SCT Inst, OCT Inst, SDD Core, SDD B2B), FX settlement (CLS, FXYCS), and other systems (CIPS, SPEI, FAST). For same-day EUR guidance: filter by currency="EUR" to retrieve all SEPA schemes plus T2 in one call — the scheme-level view is usually what treasurers need. Underlying CSMs (TIPS, RT1, EURO1, STEP2) are referenced in scheme notes. Args: system: System name (e.g., "T2", "TARGET2", "FEDWIRE", "CHAPS"). Case-insensitive. "TARGET2" and "T2" both resolve to the same entry (T2 is the post-March 2023 name). Omit to list all or filter by currency. currency: ISO 4217 currency code to filter by (e.g., "USD", "EUR"). Examples: payment_cutoff_times(system="T2") payment_cutoff_times(currency="EUR") payment_cutoff_times(currency="USD") payment_cutoff_times()
fx_volatilityGet realized FX volatility for a currency pair. Computes 30-day and 90-day annualized volatility from historical ECB reference rates (standard deviation of daily log returns, annualized by sqrt(252)). Returns a qualitative bucket: LOW (<5%), MEDIUM (5-15%), HIGH (15-25%), VERY_HIGH (>25%), PEGGED (currency peg — near-zero volatility, e.g., USD/AED, USD/HKD). Also returns practical daily/weekly movement estimates and a settlement_risk_note explaining what the volatility means over a typical T+2 settlement period — use these to advise users on FX risk for their specific payment. Args: base: Base currency (ISO 4217, e.g., "EUR") target: Target currency (ISO 4217, e.g., "TRY") Examples: fx_volatility("EUR", "USD") fx_volatility("USD", "TRY")
fx_timing_advisorGet FX trading windows — essential for understanding conversion delays and optimal execution timing. Returns market sessions and liquidity windows for a currency. Use this to understand: - **Delay diagnosis**: Payments arriving outside FX market hours for the target currency are held until the next trading session, adding hours or overnight delays. Critical for restricted currencies (INR, BRL, CNY, etc.). - **Rate optimization**: Higher liquidity = tighter spreads = better rates. Execute during peak windows to minimize conversion costs. Pass a currency code to get its optimal window, or omit to get all market sessions and overlap windows. Args: currency: ISO 4217 currency code (e.g., "EUR", "JPY"). Omit to get all sessions and overlaps. Examples: fx_timing_advisor("EUR") fx_timing_advisor("JPY") fx_timing_advisor("INR") # Check INR conversion windows fx_timing_advisor()
payment_method_compareCompare payment methods and investigate fee deductions for a country pair. Evaluates SEPA vs SWIFT vs domestic options. Also explains SWIFT charge options (OUR/SHA/BEN) and fee investigation — use this when the beneficiary received less than expected to understand where the money went and which MT103 fields reveal each deduction. Returns cost, speed, requirements, charge options, and step-by-step fee investigation guidance. Args: source_country: ISO 3166-1 alpha-2 code (e.g., "DE", "US") dest_country: ISO 3166-1 alpha-2 code (e.g., "GB", "TR") Examples: payment_method_compare("DE", "FR") # Both SEPA — will recommend SCT payment_method_compare("US", "TR") # Non-SEPA — will recommend SWIFT payment_method_compare("GB", "GB") # Domestic — will show CHAPS/FPS payment_method_compare("US", "VN") # Fee investigation — why beneficiary got less
bank_holidaysGet bank/public holidays for a country with payment impact analysis. Returns all public holidays plus a 'payment_impact' section that shows: - Whether today is a business day or holiday in this country - Upcoming holidays in the next 14 days - Recent holidays in the last 14 days — for diagnosing a payment that is ALREADY stuck ("in progress for N days", "sent X days ago"): subtract these (plus weekends) from the elapsed calendar time before judging whether the delay is abnormal. An empty list affirmatively means no recent holiday explains the delay — do not invent one from training data. - Next business day and how many consecutive non-business days remain This context helps determine if holidays are causing payment delays. Args: country_code: ISO 3166-1 alpha-2 code (e.g., "US", "DE", "GB") year: Year (default: current year). Range: 2020-2030. Examples: bank_holidays("US") bank_holidays("DE", 2026) bank_holidays("GB", 2025)
is_business_day_checkCheck if a specific date is a business day in a country. Accounts for weekends (country-specific) and public holidays. Returns whether the date is a business day, and if not, why (weekend or specific holiday name) and the next business day. Args: country_code: ISO 3166-1 alpha-2 code (e.g., "US", "DE") check_date: Date in ISO format (YYYY-MM-DD) Examples: is_business_day_check("US", "2026-12-25") is_business_day_check("DE", "2026-03-12") is_business_day_check("GB", "2026-01-01")
value_dateCalculate the value/settlement date for a payment. Determines when a payment will settle based on: - Source and destination country holiday calendars - Weekend conventions (Sat/Sun or Fri/Sat) - Currency center holidays (if FX conversion involved) - Settlement convention (T+0, T+1, T+2) Args: source_country: Sender's country (ISO 3166-1 alpha-2, e.g., "US") dest_country: Receiver's country (ISO 3166-1 alpha-2, e.g., "DE") settlement_type: One of "wire" (T+0 domestic / T+1 international), "fx_spot" (T+1 or T+2 based on pair), "sepa" (D+1), "sepa_instant" (T+0) base_currency: Base currency for FX (ISO 4217, e.g., "USD"). Required when settlement_type is "fx_spot". target_currency: Target currency for FX (ISO 4217, e.g., "EUR"). Required when settlement_type is "fx_spot". from_date: Start date in ISO format (YYYY-MM-DD). Default: today. Examples: value_date("US", "DE") value_date("US", "DE", "fx_spot", "USD", "EUR") value_date("DE", "FR", "sepa") value_date("US", "US", "wire", from_date="2026-07-03")
mcp_registerRegister for an Ohmyfin API key to use paid tools. Creates an account and sends a 6-digit verification code to your email. After receiving the code, call mcp_verify to complete registration and get your API key. By setting accept_terms to true, you confirm acceptance of the Ohmyfin Terms & Conditions (https://ohmyfin.ai/terms) on behalf of your operator, including the API/MCP access terms (Section 3A), sanctions screening terms (Section 3B), and financial data disclaimer (Section 3C). Args: email: Your email address. organization_name: Your company or project name. accept_terms: Must be true. Confirms acceptance of the Ohmyfin Terms & Conditions at https://ohmyfin.ai/terms. Examples: mcp_register("agent@example.com", "Acme Corp", true)
mcp_verifyVerify your email and receive your API key. After calling mcp_register, check your email for the 6-digit code and pass it here. On success, returns your production and test API keys. You must subscribe at ohmyfin.ai/subscription to activate paid tools. Args: email: The email you registered with. code: The 6-digit verification code from your email. Examples: mcp_verify("agent@example.com", "123456")
sanctions_screenScreen a name against global sanctions and watchlists. FREE TIER: 3 screens per day without an API key. PAID: Unlimited screens with an API key. Checks the name against US SDN (OFAC), EU, UK, Canada, Switzerland, Australia, and New Zealand sanctions lists. Returns matching entities with similarity scores. Args: name: The person or entity name to screen. api_key: Your Ohmyfin API key (prod-...). Can also be passed via KEY header or Authorization: Bearer header. Optional — free tier allows 3 screens/day without a key. threshold: Minimum match score 0-100 (default 85). Examples: sanctions_screen("Acme Trading Ltd") sanctions_screen("John Smith", threshold=90) sanctions_screen("Acme Trading Ltd", api_key="prod-abc123...")
eccn_lookupLook up an Export Control Classification Number (ECCN). Pure reference tool — returns classification details, controlled jurisdictions, and license requirements for the given ECCN. ECCNs are alphanumeric codes (e.g. "5A001") used under export control regimes (US EAR, EU Dual-Use Regulation, Wassenaar Arrangement) to classify items that may require an export license. Args: eccn: The ECCN to look up (e.g. "5A001", "3A001", "1C351"). Examples: eccn_lookup("5A001") # Telecommunications security equipment eccn_lookup("3A001") # Electronic components eccn_lookup("1C351") # Human pathogens, zoonoses, toxins
country_export_controlsLook up export control restrictions for a specific country. Returns embargo status, sanctioned programs, control reasons, and restriction details across jurisdictions (US EAR, EU, UN, etc.) for the given country. Response also includes a payment_jurisdiction_note explaining when each listed restriction actually applies to a payment (US controls only bind when there's a US nexus, etc.). IMPORTANT: Each jurisdiction's controls only bind a payment when the payment has a nexus to that jurisdiction. Use the jurisdiction filter when you know the payment's actual jurisdictional touchpoints (sender country, clearing currency, intermediary banks). For a CHF/EUR payment with no US bank in the chain, US export controls are informational only — do NOT cite them as compliance blockers without confirming a US nexus. Args: country_code: ISO 3166-1 alpha-2 country code (e.g. "RU", "CN", "DE"). jurisdiction: Optional filter by jurisdiction (e.g. "US", "EU"). When omitted, returns restrictions from all jurisdictions. Examples: country_export_controls("RU") # Russia — heavily embargoed country_export_controls("CN") # China — partial restrictions country_export_controls("DE") # Germany — minimal controls country_export_controls("RU", "US") # Russia, US jurisdiction only Use case: 'What export restrictions apply to shipping to Russia?'
federal_register_changesGet recent US regulatory changes from BIS and OFAC. Returns Federal Register publications including entity list updates, rule changes, country policy shifts, and new sanctions programs. Args: agency: Filter by agency — "BIS" (Bureau of Industry and Security) or "OFAC" (Office of Foreign Assets Control). Omit for both. category: Filter by change category — "entity_list", "rule_change", "country_policy", or "sanctions". Omit for all categories. severity: Filter by severity — "critical", "high", "medium", or "low". Omit for all severity levels. days: Number of days to look back (1–365). Default: 30. limit: Maximum number of results to return. Default: 50. Examples: federal_register_changes() # Last 30 days, all federal_register_changes(agency="OFAC", days=7) # OFAC changes this week federal_register_changes(category="entity_list", severity="critical") Use case: 'Any new entity list additions affecting China?'
track_paymentTrack a SWIFT payment by UETR or reference number. Basic SWIFT payment tracking enriched by data from certain banks in the correspondent chain. Returns the overall payment status and, when available, per-bank details showing which banks reported information about this payment. IMPORTANT — UETR vs Reference: The UETR (Unique End-to-End Transaction Reference) is a UUID assigned to every SWIFT gpi payment. Tracking by UETR succeeds ~80% of the time. Tracking by reference number alone succeeds less than 1% of the time because most banks only index by UETR. → Always provide the UETR if available. → The reference number is Field 20 of the MT103 (or the equivalent <InstrId>/<EndToEndId> in pacs.008). It is the sender's transaction reference. Still valuable — provide it alongside the UETR when you have both. WHEN THE USER HAS ONLY A REFERENCE AND NO UETR ("how do I find / trace my payment?", "I have a reference number but no UETR, where is it?"): This is exactly the scenario this tool can attempt — do NOT answer from general knowledge. A reference-based trace cannot be run from the reference alone; you MUST first collect three things from the user: 1. amount — the exact amount as sent 2. currency — ISO 4217 (e.g. "USD") 3. date — the send date (within the last 90 days) Then call track_payment(reference=..., amount=..., currency=..., date=...). State the expectation up front: reference-only tracing succeeds less than 1% of the time. In parallel, tell the user how to recover the UETR for a reliable (~80%) trace: ask the SENDING bank for the MT103 confirmation — the UETR is in Block 3, tag {121:} (a UUID v4), stored by every gpi-enabled bank against the payment. Re-run with uetr= once they have it. (swift_message_reference("MT103") returns the full field/UETR-recovery reference if you need to cite specifics.) IMPORTANT — Interpreting bank details: Each entry in the 'details' array represents a bank that reported data about this payment. The bank could be the SENDER, the BENEFICIARY, or ANY INTERMEDIARY/CORRESPONDENT in the chain. Do NOT assume a bank is an intermediary just because it appears in the list — we only know the payment passed through that bank. The bank's role is only known when it self-reports via push API (indicated by a non-null 'role' field). Requires an API key with an active FI subscription. To get started: call mcp_register → mcp_verify → subscribe to an FI plan at https://ohmyfin.ai/subscription. Args: uetr: UETR (UUID v4 format, e.g. "eb6305c8-0710-4e41-84ad-f58db3083e82"). Strongly recommended — tracking without UETR rarely returns results. This is the Unique End-to-End Transaction Reference assigned to every SWIFT gpi payment. reference: Sender's bank reference number (MT103 Field 20 / pacs.008 InstrId). Useful alongside UETR for cross-referencing, but alone it rarely produces results. Required only if uetr is not provided. amount: Transaction amount as sent (e.g. 15000.00). Must match the original payment amount — even small differences may prevent tracking from finding the payment. currency: ISO 4217 currency code (e.g. "USD", "EUR", "GBP"). date: Transaction date. Preferred format: YYYY-MM-DD (ISO 8601). Also accepted: DD.MM.YYYY or DD-MM-YYYY (European format). Must be within the last 90 days. api_key: Your Ohmyfin API key (prod-...). Can also be passed via KEY header or Authorization: Bearer header. Returns a dict with: status: Overall payment status — one of: "success" — payment delivered to beneficiary (final) "in progress" — payment is being processed (may update) "returned" — payment was canceled/returned after processing (final) "rejected" — payment was refused (final) "on hold" — temporarily held, e.g. compliance review "future" — scheduled for a future value date "unknown" — no tracking data available yet status_raw: ISO 20022 status code (ACCC/ACSP/RJCT/PDNG) or null status_reason: ISO 20022 reason code if available, or null lastupdate: Date of last status change (YYYY-MM-DD) or null details: Array of bank-level tracking entries (see role_explanation in each entry for how to interpret the bank's role) not_found_guidance: Present only when nothing was found — concrete next steps (UETR recovery, exact-match checks). Relay these to the user instead of improvising; a miss on a reference-only trace is the expected outcome and does NOT mean the payment failed. Examples: track_payment(uetr="eb6305c8-0710-4e41-84ad-f58db3083e82", amount=15000, currency="USD", date="2026-03-10") track_payment(uetr="eb6305c8-0710-4e41-84ad-f58db3083e82", reference="FT2603100123", amount=15000, currency="USD", date="2026-03-10") track_payment(reference="FT2603100123", amount=5000, currency="EUR", date="12.03.2026")
ssi_lookupLook up correspondent banking / settlement instructions (SSI) for a bank. Returns the correspondent banks (nostro accounts) that a given bank uses to settle payments in a specific currency, including account numbers (when available) and intermediary chains. Essential for payment routing and pre-validation. Each correspondent is annotated with a clearing_note indicating whether it can clear the currency directly (located in a home country for that currency) or needs its own correspondent. If the note suggests a further lookup, call ssi_lookup on the correspondent's SWIFT code to find the full clearing chain. IMPORTANT — known data gaps to respect: - Account numbers may be empty for some/all correspondents. The response surfaces an `account_availability_note` in those cases. Do NOT invent account numbers. Use swift_lookup() to find the bank's own published correspondent banks page when accounts are missing. - `is_preferred` is rarely populated — its absence is a DATA gap, not a signal. When `preferred_correspondent_note` is present (all flags false), do NOT infer a "preferred"/"natural" correspondent, and equally do NOT tell the user the bank "has no preference" or "rotates" — do not draw attention to the flag at all. Any listed BIC is a valid clearing route. - `intermediaries` is almost always empty in our dataset — an empty list does NOT mean the payment is direct. - `asset_category` per correspondent is COMMERCIAL (for customer MT103 credit transfers) or FINANCIAL (for bank-own-account / interbank MT202/pacs.009 settlements). The `asset_category_note` summarises the split — match the listed correspondents to the user's flow type (customer payment vs treasury/interbank). Always inspect the response's top-level `next_steps` array — it chains the swift_lookup / country_banking_rules / bank_holidays calls that complete a settlement-instruction answer. Requires an API key with an active PRO, VIP, or FI subscription. To get started: call mcp_register → mcp_verify → subscribe to a PRO/VIP/FI plan at https://ohmyfin.ai/subscription. Args: swift: SWIFT/BIC code of the bank (e.g., "DEUTDEFF", 8 or 11 chars). currency: ISO 4217 currency code (e.g., "USD", "EUR", "GBP"). api_key: Your Ohmyfin API key (prod-...). Can also be passed via KEY header or Authorization: Bearer header. Examples: ssi_lookup("DEUTDEFF", "USD") # Deutsche Bank USD correspondents ssi_lookup("HSBCHKHH", "EUR") # HSBC HK EUR correspondents ssi_lookup("DEUTDEFF", "USD", api_key="prod-abc123...")
banks_using_correspondentReverse SSI lookup — find banks that use a given correspondent for a currency. Given a correspondent BIC, currency, and origin country, returns the banks in that country that have a declared nostro at the correspondent for that currency. Inverse of ssi_lookup. Returns only swift + name per bank — to retrieve the account number, intermediary chain, or other SSI details for a specific bank from the result list, call ssi_lookup(bank_swift, currency) on it. Country and currency are required (not optional) — both bound the result set and the query is rejected without them. Requires an API key with an active PRO, VIP, or FI subscription. Tight per-account daily caps apply (5/day on PRO, 10/day on VIP/FI/trial). Args: correspondent_swift: BIC of the correspondent bank (e.g. "IRVTUS3N"). currency: ISO 4217 (e.g. "USD"). country: ISO 3166-1 alpha-2 of the client banks (e.g. "AE"). name_prefix: Optional prefix on bank name (e.g. "AL"). page: 1–4. Defaults to 1. api_key: Your Ohmyfin API key (prod-...). Can also be passed via KEY header or Authorization: Bearer header. Examples: banks_using_correspondent("IRVTUS3N", "USD", "AE") banks_using_correspondent("CITIUS33", "USD", "SA", name_prefix="AL")
company_search_personEXPERIMENTAL — Search company registries for a person's directorships, officer roles, and shareholdings. Searches worldwide company registries to find where a person holds director, officer, or shareholder positions. Every person and company found is automatically screened against sanctions lists. You MUST specify at least one jurisdiction. "ALL" is not supported. Available jurisdictions: UK, NO, FR, DE, CH, NL, AT, BE, DK, EE, LV, FI, SE, IS, IE, CA, AU, NZ, SG, JP, KR, IN, AM. Args: name: Person name to search for. jurisdictions: Country codes to search (required, e.g. ["UK", "NO"]). "ALL" is not supported — specify individual countries. include_sanctions_check: Auto-screen results against sanctions DB (default: true). include_inactive_roles: Include resigned/ceased roles (default: true). api_key: Your Ohmyfin API key (prod-...). Can also be passed via KEY header or Authorization: Bearer header. Examples: company_search_person("John Smith", jurisdictions=["UK", "NO"]) company_search_person("Jane Doe", jurisdictions=["DE"])
company_search_companyEXPERIMENTAL — Search company registries for a company with its officers and shareholders. Find company registrations across worldwide registries, including directors, officers, and beneficial owners (PSC/shareholders). Every entity found is automatically screened against sanctions lists. You MUST specify at least one jurisdiction. "ALL" is not supported. Available jurisdictions: UK, NO, FR, DE, CH, NL, AT, BE, DK, EE, LV, FI, SE, IS, IE, CA, AU, NZ, SG, JP, KR, IN, AM. Args: name: Company name to search for. jurisdictions: Country codes to search (required, e.g. ["UK"]). "ALL" is not supported — specify individual countries. include_sanctions_check: Auto-screen results against sanctions DB (default: true). include_officers: Include directors and officers (default: true). include_shareholders: Include PSC/beneficial owners (default: true). include_only_active: Filter to active companies only (default: false). api_key: Your Ohmyfin API key (prod-...). Can also be passed via KEY header or Authorization: Bearer header. Examples: company_search_company("Equinor", jurisdictions=["NO"]) company_search_company("Acme Corp", jurisdictions=["UK", "DE"], include_only_active=True)
company_search_resultEXPERIMENTAL — Retrieve cached company search results by search ID. Every company_search_person and company_search_company call returns a search_id. Use this tool to retrieve those results again without re-running the search. Args: search_id: The search_id from a previous company search response. api_key: Your Ohmyfin API key (prod-...). Can also be passed via KEY header or Authorization: Bearer header. Examples: company_search_result("abc123-def456")
company_registriesEXPERIMENTAL — List available company registries and supported jurisdictions. Returns the list of company registries that can be searched, along with the jurisdiction codes you can use in company_search_person and company_search_company. No API key required. Examples: company_registries()
bcc_list_accountsList all accounts accessible via the customer's BCC API credentials. Returns a list of objects: {iban, description}. Per-user: only works for a user with a provisioned BCC secret and an allow grant.
bcc_get_balanceGet balance and status for a specific IBAN. Args: iban: The IBAN to query (e.g. KZ12345678901234567890). Returns: {iban, type, status, dateOpened, currency, balance, availableFunds, blockedBalance}. Per-user: only works for a user with a provisioned BCC secret and an allow grant.
bcc_get_statementGet the transaction statement for an IBAN over a date range. Args: iban: IBAN to query (e.g. KZ12345678901234567890). start_date: Start date in dd-mm-yyyy format (e.g. 01-05-2025). end_date: End date in dd-mm-yyyy format (e.g. 31-05-2025). currency: Optional ISO currency filter (e.g. KZT or USD). Leave empty to retrieve all currencies. Returns: statement v2 structure — {inBalance, outBalance, transactions[]}. Per-user: only works for a user with a provisioned BCC secret and an allow grant.
Ohmyfin Banking Intelligence: подключить к Claude, ChatGPT, Cursor · Connectors.fun