settlement_eta

ai.ohmyfin/banking-intelligence · Verify this server

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. The estimate itself costs no credits (tracking a payment does cost credits; never describe tracking as free). Args: uetr: UETR of a tracked payment (preferred for mid-flight questions) currency: 3-letter currency (pre-trade path; ignored when uetr resolves) sender_bic: Sender bank BIC or name (pre-trade path) receiver_bic: Receiver bank BIC or name (pre-trade path) intermediary_bic: Known intermediary BIC (optional) current_status: GPI status like ACSP (pre-trade/no-uetr path only) elapsed_business_days: Business days already in flight (pre-trade path only) amount: Payment amount (improves delay-risk assessment). A plain number is fine — 50000 and "50,000.00" are both accepted. sender_country: ISO2 country of the sender bank (optional) receiver_country: ISO2 country of the receiver bank (optional) arrive_by_date: 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. api_key: Optional API key (internal calls ride the MCP secret)