# ai.ohmyfin/banking-intelligence (remote · mcp.ohmyfin.ai)

Cross-border payment & banking intelligence for AI agents: SWIFT/BIC, IBAN, sanctions, FX, tracking.

- Trust score: 62/100 (medium)
- Change this week: +7
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- remote · `mcp.ohmyfin.ai`: 62/100 (this document), [markdown](https://verifymcp.io/servers/ai-ohmyfin-banking-intelligence/mcp.md), [page](https://verifymcp.io/servers/ai-ohmyfin-banking-intelligence/mcp)

## Channel facts

- Endpoint: `https://mcp.ohmyfin.ai/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `1.0.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-03.

- **Endpoint Security**: 63/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation not fully verified: no authorisation is required to call this server, and 33 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe.
  - HTTPS is enforced; there's no plaintext access path.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 51/100
  - AI-judged instruction clarity (good).
  - Context-footprint check failed: tool/resource definitions use about 11718 tokens (~355/item across 33 items; 33 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 27/100
  - Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 71/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 0% of tool parameters carry a description.
  - Structured output schemas are declared (100% of tools); any adoption earns full credit.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http ai-ohmyfin-banking-intelligence https://mcp.ohmyfin.ai/mcp
```

### Codex

```toml
[mcp_servers.ai-ohmyfin-banking-intelligence]
url = "https://mcp.ohmyfin.ai/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "ai-ohmyfin-banking-intelligence": {
      "type": "remote",
      "url": "https://mcp.ohmyfin.ai/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add ai-ohmyfin-banking-intelligence --url https://mcp.ohmyfin.ai/mcp --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  ai-ohmyfin-banking-intelligence:
    url: "https://mcp.ohmyfin.ai/mcp"
```

### Other

```json
{
  "mcpServers": {
    "ai-ohmyfin-banking-intelligence": {
      "type": "http",
      "url": "https://mcp.ohmyfin.ai/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-03 (score 62, +1)

No change was recorded against any check on this day. Stability & Change Management went from 23 to 27. That category is still filling its 30-day observation window: 7 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-08-02 (score 61, +9)

- [functional improvement] Schema quality: unverified → good

### 2026-08-01 (score 52, −8)

- [functional regression] Schema quality: good → unverified

### 2026-07-31 (score 60, +3)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-30 (score 57, +1)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-28 (score 56, +1)

No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-27 (score 55, +1)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-26 (score 54)

First indexed and scored.

## MCP tools (33)

### `swift_lookup` (~320 tokens)

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.

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

Input parameters:

- `country`
- `limit` (integer)
- `query` (string, required)

### `iban_validate` (~168 tokens)

Validate an IBAN number.

Performs format check, country-specific length check, and
ISO 7064 mod-97 checksum verification. Also returns COUNTRY-level
banking rules for the IBAN's country prefix (national currency,
SEPA status, expected format).

An IBAN encodes country + bank + account number and carries NO
currency information. `country_currency` is the country's national
currency, NOT this account's denomination — never infer a currency
mismatch or a "resend in X" recommendation from it (see
\`currency_note` in the response).

Examples:
  iban_validate("DE89370400440532013000")
  iban_validate("GB29 NWBK 6016 1331 9268 19")

Input parameters:

- `iban` (string, required)

### `country_banking_rules` (~357 tokens)

Get 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.).

The `fatf_listing` block is the authoritative answer to "is this country
grey-listed / black-listed / under FATF increased monitoring". Both FATF
public lists are held in full, so a `not_listed` status is a positive
determination and not missing data. Use it instead of training data for any
FATF question, and note that the coarse `fatf` field is a separate, weaker
signal about regional-body membership that says nothing about listing.

Everything here is COUNTRY-level. `currency` is the country's national
currency, not the denomination of any beneficiary account — never pair it
with the payment currency to diagnose a currency mismatch (see
\`currency_note` in the response).

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

Input parameters:

- `country_code` (string, required)

### `country_payment_codes` (~223 tokens)

Look 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)

Input parameters:

- `code_type` (string, required)
- `country_code` (string, required)
- `search`

### `fx_rate` (~337 tokens)

Get the latest available reference (mid-market) exchange rate for a pair.

Rates are the official ECB euro foreign-exchange reference rates where the
ECB publishes the currency; pairs whose currency the ECB does not cover
(e.g. VND, NGN, PKR, KZT, MAD) fall back to a market data feed. ALWAYS
check the `source` field before describing provenance: "ecb" = official
ECB reference rate; "market" = indicative mid-market rate, NOT an ECB
fixing — never call it "the ECB rate". The `source_note` field in the
result states this explicitly. Supports ~30 currencies. Non-EUR pairs are
computed as cross-rates via EUR (e.g., USD/GBP = EUR/GBP / EUR/USD), so
they are indicative mid-rates, not dealable/executable rates.

BOTH currencies are required. Always pass the exact pair you intend.
There is no implicit default pair: a call that omits or mis-names a
currency returns a "missing required argument" error rather than a
silently-wrong rate. Never assume EUR/USD when the user asked about a
different pair such as USD/VND.

Args:
    base: Base currency (ISO 4217, e.g., "USD")
    target: Target currency (ISO 4217, e.g., "VND")

Examples:
  fx_rate("EUR", "USD")
  fx_rate("GBP", "JPY")
  fx_rate("USD", "VND")

Input parameters:

- `base` (string, required)
- `target` (string, required)

### `fx_rate_history` (~183 tokens)

Get historical ECB exchange rates for a currency pair.

Returns daily rates for the specified period. ECB publishes rates
on weekdays only (no weekends/holidays).

BOTH currencies are required. Always pass the exact pair you intend.
There is no implicit EUR/USD default: an omitted or mis-named currency
errors rather than returning the wrong pair's history.

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)

Input parameters:

- `base` (string, required)
- `days` (integer)
- `target` (string, required)

Output parameters:

- `result` (array)

### `gpi_status_codes` (~534 tokens)

Explain 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 specif…

Input parameters:

- `code`

Output parameters:

- `result`

### `swift_message_reference` (~260 tokens)

Look 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()

Input parameters:

- `message_type`

Output parameters:

- `result`

### `payment_cutoff_times` (~417 tokens)

Get 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.

DST-observing systems also carry `season_now` and `operative_cutoff_today`
fields computed for the current date. cutoff_utc/cutoff_local are the
STANDARD-TIME (winter) values; summer_offset holds the DST value. Quote the
cutoff that `operative_cutoff_today` points at for TODAY's season — do not
default to the winter figure when DST is currently in force (e.g. the T2
customer cutoff is 15:00 UTC in summer, not the 16:00 UTC winter value).

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()

Input parameters:

- `currency`
- `system`

Output parameters:

- `result`

### `fx_volatility` (~218 tokens)

Get 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")

Input parameters:

- `base` (string, required)
- `target` (string, required)

### `fx_timing_advisor` (~359 tokens)

Get FX trading windows for FX execution timing and spread / rate optimization.

Returns market sessions and liquidity windows for a currency. Use this
to understand:
\- **Rate optimization** (primary, reliable use): higher liquidity means
  tighter spreads and better rates. Execute during peak windows to minimize
  conversion costs.
\- **Delay diagnosis** (use with care): the FX market session is when a
  currency TRADES. It is NOT a guaranteed processing schedule for an inbound
  foreign-currency payment that the beneficiary bank converts on arrival.
  Conversion timing is beneficiary-bank-specific (some convert in real time
  during the session, others batch once or twice daily), so do NOT tell the
  user a payment is "held until the next session" and do not quote specific
  hold durations ("adds X hours", "overnight delay"); those are bank policy
  and are not in our data. For the binding delivery-side cutoff that gates the
  converted local-currency leg, call country_banking_rules(destination) and
  read local_clearing.systems. When a currency is restricted, this tool's own
  output carries an inbound_processing_note with the accurate framing to quote.

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()

Input parameters:

- `currency`

### `payment_method_compare` (~244 tokens)

Compare 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

Input parameters:

- `dest_country` (string, required)
- `source_country` (string, required)

### `bank_holidays` (~321 tokens)

Get 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"). A recent
  holiday only counts if it falls INSIDE the payment's own window (on or
  after the send date); one that predates the send date is irrelevant and
  must NOT be subtracted. An empty list affirmatively means no recent
  holiday explains the delay — do not invent one from training data.
\- elapsed_business_days_by_send_date — the AUTHORITATIVE elapsed
  business-day count keyed by send date (weekends + this country's
  holidays already excluded). Use it verbatim instead of hand-counting.
\- 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)

Input parameters:

- `country_code` (string, required)
- `year`

### `is_business_day_check` (~168 tokens)

Check 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")

Input parameters:

- `check_date` (string, required)
- `country_code` (string, required)

### `value_date` (~372 tokens)

Calculate 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")

Input parameters:

- `base_currency`
- `dest_country` (string, required)
- `from_date`
- `settlement_type` (string)
- `source_country` (string, required)
- `target_currency`

### `settlement_eta` (~895 tokens)

BETA. Estimate when a SWIFT payment will arrive: a corpus-grounded
arrival window with an honest tail, computed from real completed payments
we have tracked, projected onto the currency's banking calendar.

This estimator is in BETA and still calibrating. Say so when you present a
number: call it an estimate or a typical window, never a commitment, and
never let a user plan an irreversible decision (a cutoff, a contractual
settlement date) on it without that caveat. The payload carries beta=true
while this holds.

Two modes:
\- Forward (default): "when will it land" — returns P50/P90/P95 arrival
  dates, sample size, confidence, competing non-arrival risk, delay-risk
  factors, and (where validated) the most likely correspondent route.
\- Reverse: pass arrive_by_date (YYYY-MM-DD) — returns the latest send
  date such that arrival by that day is likely ("send by Thursday to
  land by month-end").

INPUT DISCIPLINE (important):
\- Mid-flight payment: pass ONLY the uetr (from TrackingContext or
  track_payment). The server resolves the current status, currency and
  elapsed time deterministically from the tracking record. NEVER compute
  elapsed_business_days yourself.
\- Pre-trade question ("how long will a USD wire from X to Y take?"):
  pass currency + sender_bic/receiver_bic (8 or 11 chars, or bank names).
  current_status / elapsed_business_days are for this path only.

Reading the answer honestly (relay these to the user):
\- basis.n is the sample size and confidence reflects it; when confidence
  is "low", present the window as a rough range, never a promise.
\- route.confirmed=false means the route is INFERRED from settlement
  instructions on file, not confirmed by GPI — say so.
\- basis.route_adjusted=true means we hold no completed payments for this
  exact pair and the window was lifted to a route-composed estimate:
  the SSI-implied correspondent chain (route.intermediaries hops) with
  typical processing time per hop. Present it as a route-based estimate,
  not…

Input parameters:

- `amount`
- `api_key`
- `arrive_by_date`
- `currency`
- `current_status`
- `elapsed_business_days`
- `intermediary_bic`
- `receiver_bic`
- `receiver_country`
- `sender_bic`
- `sender_country`
- `uetr`

### `mcp_register` (~219 tokens)

Register 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)

Input parameters:

- `accept_terms` (boolean, required)
- `email` (string, required)
- `organization_name` (string, required)

### `mcp_verify` (~120 tokens)

Verify 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")

Input parameters:

- `code` (string, required)
- `email` (string, required)

### `sanctions_screen` (~208 tokens)

Screen 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...")

Input parameters:

- `api_key`
- `name` (string, required)
- `threshold` (integer)

### `eccn_lookup` (~181 tokens)

Look 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

Input parameters:

- `eccn` (string, required)

### `country_export_controls` (~318 tokens)

Look 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?'

Input parameters:

- `country_code` (string, required)
- `jurisdiction` (string)

### `export_controls_screen` (~449 tokens)

Screen goods for export-control restrictions to a destination country.

Combines the goods classification with the destination's restriction status
and returns whether a license is required, the risk level, applicable
license policies (e.g. presumption of denial), control reasons (NS, MT, NP,
CB, AT), and proliferation/dual-use flags. Identify the goods by ANY of:
ECCN, HS code, or a free-text description (English or Russian).

IMPORTANT — jurisdiction nexus: each jurisdiction's controls only bind a
payment/shipment when there is a nexus to that jurisdiction (US EAR binds
US persons, USD-clearing, and US-origin items; EU/UK/JP bind their persons,
currencies, and origin). Use jurisdiction="ALL" for a comprehensive
multi-jurisdiction view, or pick the one matching the actual touchpoints.

Args:
    destination_country: ISO 3166-1 alpha-2 destination code (e.g. "RU", "CN").
    eccn: Optional Export Control Classification Number (e.g. "3A001").
    hs_code: Optional Harmonized System code, 4-8 digits (e.g. "854231").
    goods_description: Optional free-text goods description (EN or RU).
    jurisdiction: "US" (default), "EU", "UK", "JP", "ITAR", or "ALL".

Provide at least one of eccn / hs_code / goods_description.

Examples:
  export_controls_screen("RU", eccn="3A001")                       # electronics → Russia
  export_controls_screen("CN", eccn="3A090")                       # advanced computing → China
  export_controls_screen("IR", goods_description="industrial valves")
  export_controls_screen("RU", goods_description="drone", jurisdiction="ALL")
  export_controls_screen("DE", hs_code="854231")                   # → Germany (allied)

Use case: 'Can we ship integrated circuits to Russia?'

Input parameters:

- `destination_country` (string, required)
- `eccn` (string)
- `goods_description` (string)
- `hs_code` (string)
- `jurisdiction` (string)

### `hs_code_lookup` (~311 tokens)

Reverse-lookup an HS code → mapped export-control classifications (ECCNs).

For customs brokers / shippers who have an HS (Harmonized System) code and
need to know which export-control classifications may apply. Returns the
mapped ECCNs with confidence levels, control reasons, sensitivity, and the
governing international regime (Wassenaar, MTCR, NSG, etc.).

A 4-digit HS heading is accepted, but mappings are richest at the 6-digit
subheading level (e.g. "854231" rather than "8542"). An empty mapping list
means no export-control mapping is on file for that code — it is NOT a
guarantee the goods are uncontrolled; confirm with goods_classify or a
formal classification.

Args:
    hs_code: 4-6 digit HS code (e.g. "854231", "8411"). Dots/spaces are ok.
    jurisdiction: Optional filter — "US", "EU", "UK", or "JP".

Examples:
  hs_code_lookup("854231")          # semiconductors → 3A001 / 3A090 ...
  hs_code_lookup("841112")          # turbojet engines → 9A001 ...
  hs_code_lookup("854231", "US")    # US mappings only

Use case: 'What export controls might apply to HS code 854231?'

Input parameters:

- `hs_code` (string, required)
- `jurisdiction` (string)

### `goods_classify` (~323 tokens)

Classify goods for export control from a description (or HS code).

Bilingual (English / Russian, auto-detected) goods classifier. Returns the
best-matching HS code (with EN+RU descriptions), related ECCNs, control
reasons (NS, MT, NP, CB, AT...), an export-control level (high/medium/low/
none), a confidence score, and alternative matches for review.

This is destination-agnostic — it identifies WHAT the goods are and whether
they are controlled in principle. To get the license decision FOR A SPECIFIC
destination, pass the result into export_controls_screen.

Args:
    description: Goods description, min 2 chars (e.g. "uranium centrifuge",
        "центрифуга для урана"). Required.
    hs_code: Optional known HS code (4 or 6 digits) for a direct lookup.
    language: Optional hint — "en" or "ru" (auto-detected if omitted).

Examples:
  goods_classify("uranium centrifuge")                 # → HS 840120, ECCN 0B001
  goods_classify("центрифуга для обогащения урана")    # Russian query, same result
  goods_classify("semiconductor manufacturing equipment")
  goods_classify("", hs_code="840120")                 # direct HS lookup

Use case: 'Is a semiconductor lithography machine export-controlled?'

Input parameters:

- `description` (string, required)
- `hs_code` (string)
- `language` (string)

### `federal_register_changes` (~274 tokens)

Get 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?'

Input parameters:

- `agency` (string)
- `category` (string)
- `days` (integer)
- `limit` (integer)
- `severity` (string)

### `track_payment` (~1355 tokens)

Track 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…

Input parameters:

- `amount` (number)
- `api_key`
- `currency` (string)
- `date` (string)
- `reference`
- `uetr`

### `tracking_history` (~381 tokens)

Show how a SWIFT payment's tracking results changed over time.

Returns the DISTINCT tracking results recorded for a payment (by UETR or
reference), deduplicated so ten identical re-tracks collapse to one entry
while any change — a new last-update, a status change, or new bank data —
appears as its own entry. Each entry includes what was ENTERED when the
search was run (amount, currency, date) alongside the banks that reported
data and their confirmed amount / value date.

WHEN TO USE THIS:
  \- The user says the page shows different data than you see, or asks why a
    bank line (e.g. JP Morgan) "disappeared" or a value date differs.
  \- You need to reconcile an amount discrepancy. Correspondent banks such as
    JP Morgan return their confirmation ONLY when the tracked amount exactly
    matches the payment, so a search run with the wrong amount silently drops
    their line. Comparing entries here — same UETR, different entered amounts,
    different bank data — is how you spot that the amount was the problem.
  \- Before concluding "the record was consolidated" or "the bank stopped
    reporting", check the history: the earlier result you're being asked
    about is usually still here, under a different entered amount.

Only results for the current user (plus system tracks with no owner) are
returned; other users' searches of the same UETR are never shown.

Requires an API key with an active FI subscription.

Args:
    uetr: UETR (UUID v4) of the payment. Strongly preferred.
    reference: Sender's reference (MT103 Field 20) — used when no UETR.

Input parameters:

- `api_key`
- `reference`
- `uetr`

### `ssi_lookup` (~824 tokens)

Look 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). Read `asset_categories`
  (the full list) rather than the single `asset_category`, which
  shows the commercial view only: one entry is one BIC+account and
  the same account is often published under BOTH categories, so the
  single field can never establish what an account may NOT be used
  for. The `asset_category_note` summarises the split — match the
  listed correspondents to the user's flow type (customer payment…

Input parameters:

- `api_key`
- `currency` (string, required)
- `swift` (string, required)

### `banks_using_correspondent` (~379 tokens)

Reverse 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")

Input parameters:

- `api_key`
- `correspondent_swift` (string, required)
- `country` (string, required)
- `currency` (string, required)
- `name_prefix`
- `page` (integer)

### `company_search_person` (~308 tokens)

EXPERIMENTAL — 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"])

Input parameters:

- `api_key`
- `include_inactive_roles` (boolean)
- `include_sanctions_check` (boolean)
- `jurisdictions` (array, required)
- `name` (string, required)

### `company_search_company` (~351 tokens)

EXPERIMENTAL — 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)

Input parameters:

- `api_key`
- `include_officers` (boolean)
- `include_only_active` (boolean)
- `include_sanctions_check` (boolean)
- `include_shareholders` (boolean)
- `jurisdictions` (array, required)
- `name` (string, required)

### `company_search_result` (~125 tokens)

EXPERIMENTAL — 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")

Input parameters:

- `api_key`
- `search_id` (string, required)

### `company_registries` (~67 tokens)

EXPERIMENTAL — 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()

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/ai-ohmyfin-banking-intelligence/mcp#diagnostics

## Score history

- 2026-08-03: 62
- 2026-08-02: 61
- 2026-08-01: 52
- 2026-07-31: 60
- 2026-07-30: 57
- 2026-07-29: 56
- 2026-07-28: 56
- 2026-07-27: 55
- 2026-07-26: 54

## Links

- Remote endpoint: https://mcp.ohmyfin.ai/mcp
- Website: https://mcp.ohmyfin.ai/
- Changelog RSS feed: https://verifymcp.io/servers/ai-ohmyfin-banking-intelligence/mcp/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/ai-ohmyfin-banking-intelligence/mcp/changelog.json
- HTML version of this page: https://verifymcp.io/servers/ai-ohmyfin-banking-intelligence/mcp