banking-intelligence

track_payment

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 — every trace needs four things: amount, currency, date, and an identifier (uetr, or reference when there is no UETR). amount, currency and date are required parameters, on the UETR path too: there is no UETR-only lookup, so never tell the user the UETR alone is enough to run one. Ask for whatever is missing before calling, and never guess a value.

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 / 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: REQUIRED. Transaction amount as sent (e.g. 15000.00). Must match the original payment amount — even small differences may prevent tracking from finding the payment, so ask the user for the exact figure rather than estimating or rounding one. currency: REQUIRED. ISO 4217 code of the currency the payment was SENT in (e.g. "USD", "EUR", "GBP"). Ask if you do not know it; do not assume the sender's or the beneficiary's home currency. date: REQUIRED. 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")

Input Schema

TableJSON Schema

Name	Required	Description	Default
`date`	Yes
`uetr`	No
`amount`	Yes
`api_key`	No
`currency`	Yes
`reference`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and delivers richly: it discloses success rates (~80% UETR, <1% reference-only), the need for exact amount/currency/date, the interpretation caveat that 'details' banks may be sender/beneficiary/intermediary and role is only known via self-report, and the behavior of not_found_guidance. This goes far beyond a basic safety profile and fully informs the agent of behavioral nuances.

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 description is long, but well-structured with clear sections (IMPORTANT, Args, Returns, Examples) that make it navigable. It earns most of its length due to the tool's complexity. However, there is some repetition — e.g., the required-ness of amount/currency/date appears both in the 'every trace needs four things' warning and in the Args section, and the UETR concept is explained multiple times. A moderately tighter version would earn 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?

Given the tool's complexity (6 parameters, multiple status outcomes, bank-detail interpretation, auth requirements, and recovery paths), the description is remarkably complete. It covers required parameters, exceptions, return value semantics, failure handling (not_found_guidance), and concrete examples. The presence of an output schema is a plus, but the description still goes beyond it by explaining status meanings and per-bank role interpretation, leaving no major gap for the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate — and it does. Every parameter receives detailed semantics: UETR format and UUID v4 example, reference as MT103 Field 20 / pacs.008 InstrId, amount exactness and warning against rounding, currency ISO 4217 and 'as sent' requirement, date formats and 90-day window, and api_key alternatives (KEY header or Authorization). Examples further illustrate correct usage. This is exemplary parameter documentation.

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 opens with 'Track a SWIFT payment by UETR or reference number', a specific verb+resource statement that clearly distinguishes this from sibling tools like swift_lookup or tracking_history. It further clarifies the scope ('enriched by data from certain banks in the correspondent chain') and the primary identifier (UETR), making the tool's function unmistakable.

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 description provides explicit when-to-use guidance, including a dedicated 'WHEN THE USER HAS ONLY A REFERENCE AND NO UETR' section that tells the agent exactly what to collect and how to set expectations. It also names alternatives (recover UETR via MT103, use swift_message_reference for details) and gives onboarding steps (mcp_register → mcp_verify → subscribe), making usage context exceptionally clear.

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

All banking-intelligence tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0

Disambiguation4/5

Most tools have distinct purposes, but some overlapping areas (goods_classify vs hs_code_lookup vs eccn_lookup; fx_rate vs fx_rate_history vs fx_volatility) require close reading of descriptions to select correctly. The detailed descriptions help, but the shear number of lookup tools creates mild ambiguity.

Naming Consistency3/5

Names mix verb-first (track_payment, mcp_verify) and noun-first patterns (iban_validate, fx_rate, ssi_lookup), with some phrase-like names (banks_using_correspondent, is_business_day_check). While readable, there is no single consistent convention.

Tool Count3/5

33 tools is heavy, but the server's broad scope (payments, FX, sanctions, export controls, company registries, SWIFT) justifies most of them. A few marginal tools (mcp_register, mcp_verify, company_search_result) add bulk without core value.

Completeness5/5

The tool set covers the payment lifecycle end-to-end: tracking, settlement, FX, compliance, sanctions, and company due diligence. There are no obvious dead ends; the tools chain together via next_steps and search_id flows.

Resources

Need Help?