Skip to main content
Glama

banking-intelligence

by ai.ohmyfin
OverviewDiscussionsAdmin

Payment Arrival Estimate (Beta)

settlement_eta
Read-only

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 as observed statistics, and never quote the faster currency-pool average alongside it as if corridor-specific.

  • mode="outlier" means the payment is already slower than ~90% of similar payments: stop quoting a window, explain the usual manual causes (compliance review, repair/RFI, missing cover) and pivot to the stuck-payment diagnostic flow.

  • non_arrival.p_reject is the share of similar payments that were returned or rejected rather than delivered.

  • "Delivered" (ACCC) means delivered to the beneficiary bank per GPI; funds can become usable in the account slightly later.

Available on every surface to any caller with an active subscription.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
uetrNoUETR of a tracked payment, UUID v4 (e.g. "eb6305c8-0710-4e41-84ad-f58db3083e82"). Preferred for a payment already in flight; see INPUT DISCIPLINE in the description.
amountNoPayment amount; it improves the delay-risk assessment. A plain number is fine: 50000 and "50,000.00" are both accepted.
api_keyNoYour Ohmyfin API key (prod-...). Optional here: it can be sent instead as a KEY header or an Authorization: Bearer header. What the tool requires of the key is in its description.
currencyNo3-letter ISO 4217 currency, for the pre-trade path. Ignored when the uetr resolves.
sender_bicNoSending bank's BIC (8 or 11 characters) or bank name, for the pre-trade path.
receiver_bicNoReceiving bank's BIC (8 or 11 characters) or bank name, for the pre-trade path.
arrive_by_dateNoYYYY-MM-DD; switches to reverse send-by mode. You do not know today's date: a deadline stated as "the 20th" or "by month-end" must be resolved against the `today` block returned by bank_holidays / value_date / is_business_day_check, not against your own sense of the current date. A date in the past is rejected.
current_statusNoStatus code such as ACSP, for the path without a uetr only.
sender_countryNoOptional ISO 3166-1 alpha-2 country code of the sending bank.
intermediary_bicNoOptional BIC of a known intermediary bank.
receiver_countryNoOptional ISO 3166-1 alpha-2 country code of the receiving bank.
elapsed_business_daysNoBusiness days already in flight, for the path without a uetr only.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed12 schema fields changed
    • addedInput schema / properties / amount / description
      Added value: +"Payment amount; it improves the delay-risk assessment. A plain number is fine: 50000 and \"50,000.00\" are both accepted."
    • addedInput schema / properties / api_key / description
      Added value: +"Your Ohmyfin API key (prod-...). Optional here: it can be sent instead as a KEY header or an Authorization: Bearer header. What the tool requires of the key is in its description."
    • addedInput schema / properties / arrive_by_date / description
      Added value: +"YYYY-MM-DD; switches to reverse send-by mode. You do not know today's date: a deadline stated as \"the 20th\" or \"by month-end\" must be resolved against the `today` block returned by bank_holidays / value_date / is_business_day_check, not against your own sense of the current date. A date in the past is rejected."
    • addedInput schema / properties / currency / description
      Added value: +"3-letter ISO 4217 currency, for the pre-trade path. Ignored when the uetr resolves."
    • addedInput schema / properties / current_status / description
      Added value: +"Status code such as ACSP, for the path without a uetr only."
    • addedInput schema / properties / elapsed_business_days / description
      Added value: +"Business days already in flight, for the path without a uetr only."
    • addedInput schema / properties / intermediary_bic / description
      Added value: +"Optional BIC of a known intermediary bank."
    • addedInput schema / properties / receiver_bic / description
      Added value: +"Receiving bank's BIC (8 or 11 characters) or bank name, for the pre-trade path."
    • addedInput schema / properties / receiver_country / description
      Added value: +"Optional ISO 3166-1 alpha-2 country code of the receiving bank."
    • addedInput schema / properties / sender_bic / description
      Added value: +"Sending bank's BIC (8 or 11 characters) or bank name, for the pre-trade path."
    • addedInput schema / properties / sender_country / description
      Added value: +"Optional ISO 3166-1 alpha-2 country code of the sending bank."
    • addedInput schema / properties / uetr / description
      Added value: +"UETR of a tracked payment, UUID v4 (e.g. \"eb6305c8-0710-4e41-84ad-f58db3083e82\"). Preferred for a payment already in flight; see INPUT DISCIPLINE in the description."
  2. Changed1 schema field changed
    • changedInput schema / properties / amount / anyOf
      Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
  3. Added
  4. Removed
  5. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint/openWorldHint; the description adds far more — beta payload flag, mandatory caveat language, what mode="outlier" implies, route.confirmed=false meaning inference not GPI confirmation, basis.route_adjusted meaning no observed corridor data, and the distinction between ACCC delivery and funds usability. That is exactly the behavioral context annotations cannot carry.

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?

Long but front-loaded: the BETA caveat and the use-it-honestly instruction come first, then modes, then input discipline, then answer-reading. Every section is actionable, though the BETA warning and the confidence caveat are restated in more than one place, costing a little economy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter, two-mode statistical estimator with an output schema, the description covers mode selection, input hygiene, contractual caveats, and interpretation of each returned field. Nothing an agent needs in order to call it correctly or relay the result honestly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so each parameter is already documented at baseline. The description nevertheless adds cross-parameter meaning the schema cannot: which parameter set applies to which path, the prohibition on self-computing elapsed_business_days, and the rule that arrive_by_date deadlines must be resolved against the today block. Some of this duplicates schema text, which keeps it below 5.

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 — 'Estimate when a SWIFT payment will arrive' — and immediately separates the two operating modes (forward arrival vs reverse send-by). It is clearly distinguishable from siblings like track_payment (which supplies the uetr) and value_date/bank_holidays (which supply the calendar basis), both named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit routing rules: pass ONLY the uetr for mid-flight payments, currency+sender_bic/receiver_bic for pre-trade, and arrive_by_date for reverse mode. It also names exclusions and alternatives ('elapsed_business_days are for this path only', 'pivot to the stuck-payment diagnostic flow' on mode="outlier"), so an agent knows when not to use it.

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

All banking-intelligence toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources