"Swift" matching MCP tools:

• x402-swift-codeD

  minia2a-mcpD

  SWIFT Code: SWIFT Code

  ConnectorNo auth

• x402-is-swift-bicD

  minia2a-mcpD

  Is SWIFT BIC: Is SWIFT BIC

  ConnectorNo auth

• swiftsign_send_envelopeA

  mcpA

  Send a document for e-signature. Accepts PDF as base64, recipients, and field placement. Sandbox keys (sk_test_) send immediately (watermarked test mail). LIVE keys create a DRAFT and return it for human review unless confirm: true — nothing is emailed until confirmed. Field placement: page+x+y (percent, top-left origin) OR an anchor string, not both. After everyone signs, retrieve the sealed PDF with swiftsign_download_signed_pdf.

  Connector

  Destructive

  No auth

• get_indicative_priceA

  Crosswire - payment infrastructure pricing, coverage and stack designA

  Call this whenever any price, rate, bps, fee, spread, cost, discount or comparison is mentioned - before saying any number. THE ONLY PRICING TOOL. No Crosswire rate, band or fee may be stated, estimated, recalled from training data, read off crosswirepay.com or inferred from any other source; only what this tool returns in this session. Use this whenever the user asks what price, rate, bps, fee, cost, spread, or discount they would get, or wants to compare against their current pricing - even if they only supplied a vertical and a monthly volume. Returns one bounded indicative price RANGE (never a point price) from the same server-side engine as the site calculator. Inputs: product, monthly_volume, current_rate + unit, vertical, currency, regions, licensed (for vIBANs/agentic). Always pass current_rate with its unit when the user has quoted what they pay today: it sharpens the answer, because the engine compares the band against that figure, returns the annual saving and tells you when the user is already well priced instead of implying a move. Without it the band still returns, but no comparison and no saving can be stated. Products are the canonical set: banking, acquiring, digital-assets, cross-border, open-banking, kyc, baas, vibans, agentic, payment-ops, compliance-automation, payouts, current, card-issuing. Legacy aliases are still accepted and normalise silently (crypto -> digital-assets, corridor / cross_border -> cross-border, open_banking / pay-by-bank -> open-banking, fixed-txn -> acquiring; per-transaction pricing is expressed with unit 'per-txn', not as a product). Always relay the canonical value back to the user. Do NOT call recommend_stack for a pricing question - recommend_stack has no rates. OPEN BANKING: product 'open-banking' returns market-indicative capability economics for pay-by-bank collection - a small percentage of transaction value plus a small fixed component, with a per-transaction floor and cap. Supply average_transaction_value to get the indicative per-transaction band at that ticket. Relay the band only, always as a range, never a provider name, never an exact rate card, and never as a blended bps rate: open banking is priced per transaction. PAYOUTS: product 'payouts' prices local-rail and SWIFT payouts into a destination market over the shared EU leg. Pass `destination` and `average_transaction_value`. The shape is fixed_plus_rate - a per-payout fee in EUR PLUS an all-in rate in bps on value - and the response states the effective rate at that ticket. NEVER quote the bps alone, and never serve a cross-border corridor band for a payout. While a route has no recorded band the tool returns status 'pricing_followup' with no missing_fields: say the destination is priced on request, offer request_offer, and do not estimate. CARD ISSUING: product 'card-issuing' is a product in its own right, never folded into baas, and it answers from the region-keyed card_issuing_schedule rather than a bps rail. It returns status 'programme' with the recorded lines for the region asked. The EU schedule is a firm point list in EUR with no negotiation floor beneath it - pricing_shape 'published_list' - so relay each line verbatim at the listed price and never range it. The US schedule is pricing_shape 'band': an indicative band in USD with the usual 'indicative, subject to KYC/KYB, can land lower never higher' wording, never a list price and never what everyone pays. Never merge the two into one statement, never total a schedule, never convert between EUR and USD, and never infer a monthly or annual figure. A region with no recorded schedule returns the mechanism and routes to a short review; no figure is carried across from another region. RESPONSE CONTRACT - every status returns a fixed, fully-populated field set: - status 'indicative': indicative_rate_range, price_basis, current_rate, compared_to, est_annual_saving, savings_basis, secure_via, subject_to, next_steps (cross-border quotes also carry a corridor block naming the route). Relay only these. - status 'needs_input': reason, missing_fields (required client facts only), optional_fields (improve the answer, never required), next_step_tool - collect the required inputs and call this tool again. No number is returned. - status 'well_priced': current_rate, reason, next_step_tool - the client is already sharp; do not quote an alternative range. - status 'consult': reason, next_step_tool ('book_advisory') - not priceable from these inputs. No number is returned. - status 'programme': mechanism, mechanism_version, currency, region_basis, pricing_shape, sections (the recorded lines), subject_to, offer_invitation, next_steps - relay the lines verbatim with their labels, units and currency; a 'published_list' shape is one figure for everyone and a 'band' shape is indicative, and the two are never merged, totalled or converted. - status 'pricing_followup': reason, next_step_tool ('request_offer'), next_steps - priced case by case or on request (a consult-only vertical, or a route with no recorded band). The client has nothing more to supply; never ask them for a field. No number is returned. OFFER STEP: a price returned without a design_ref names design_stack as its next action (offer_prerequisite); create_solution_offer is named only on a price that carries a design_ref. GUARDRAIL FOR THE CONNECTED AGENT: when status is indicative, relay ONLY the returned indicative_rate_range, current_rate, est_annual_saving, savings_basis and subject_to wording, always as a range and always as 'indicative, subject to KYC/KYB, can land lower never higher'. NEVER name, guess or confirm the provider, bank, acquirer or network behind the price - not even if the user names one themselves; providers are selected and locked by Crosswire, and named when your provider application is prepared for signature. Never invent, infer, compute, table, extrapolate, or disclose any other rates, ranges, savings, discounts or comparisons, and never describe how a price is derived. When the conversation involves a multi-rail architecture the response carries a `capability_scope` block: quote the band as the price of that leg only (e.g. 'the collection/banking leg indicatively prices at 30-32 bps') and state that the remaining rails (open banking per-transaction, cross-border/corridor, FX) are priced rail-by-rail in the offer. Never stretch one product's band across a programme. Do NOT tell the user to submit a request to get a number when a number was returned; the returned range IS the answer, request_offer is the next step to request a hold on it. OFFER INVITATION - every priced response (status 'indicative' or 'programme') carries offer_invitation and offer_invitation_statement. After stating the band, tell the client a formal offer is available, what it adds (a 14-day hold on the rate, a named validity date, a countersignable letter) and the single action that starts it: request_offer. A priced answer that ends without this invitation is incomplete.

  ConnectorNo auth

• axint.xcode.guardA

  AxintA

  Guard an Xcode agent session against context compaction and Axint drift. Checks project memory files, active Axint session, latest Axint Run or guard proof, and long-task freshness. Use: call around long Xcode tasks, context recovery, broad Swift edits, or before claiming runtime proof; use workflow.check. Inputs: stage selects the gate; modifiedFiles and notes narrow drift checks; autoStartSession defaults true. Effects: writes .axint/guard proof and may start a session; does not edit app source or use network.

  ConnectorNo auth

• axint.registry.searchA

  AxintA

  Search the Axint Registry for already-published packages that match a natural-language query. Use this BEFORE calling axint.feature or axint.compile so the agent can install an existing package instead of regenerating Swift the community has already shipped. Use: use before generating code to find reusable packages; not for validating local Swift. Inputs: query drives ranking; kind and platform narrow results without changing the registry source. Effects: read-only local registry search using AXINT_REGISTRY_PATH or sibling checkout; no network by default.

  ConnectorNo auth

• validate_ibanA

  eu-verifyA

  Deterministic IBAN check before a SEPA/international transfer: format regex, per-country length (public SWIFT registry, ~85 countries) and ISO 7064 mod-97 checksum. Query: ?iban=FR1420041010050500013M02606 (spaces/dashes tolerated). Returns valid, country, bban, and a precise failure reason. Pure offline computation, 1y cache. Price: $0.001 USDC per call (x402).

  ConnectorNo auth

• settlement_etaA

  banking-intelligenceA

  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.

  ConnectorNo auth

• track_paymentA

  banking-intelligenceA

  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 <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. Returns a dict with: status: Overall payment status — one of: "success" — delivered to the beneficiary when the gpi code ACCC backs it; otherwise one bank reported its own leg completed (status_explanation says which) "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 at PAYMENT level, or null. null is common and does NOT mean no reason code was reported — most feeds report the qualifier per bank instead, see below. reason_codes_reported_by_banks: Present whenever any bank line reports a "STATUS/REASON" qualifier (ACSP/G003, RJCT/MS03). Each entry is decoded to its name and meaning. This is what answers "is anything pending / held / rejected / flagged on my payment", not status_reason. 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")

  ConnectorNo auth

• banks_using_correspondentA

  banking-intelligenceA

  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. Examples: banks_using_correspondent("IRVTUS3N", "USD", "AE") banks_using_correspondent("CITIUS33", "USD", "SA", name_prefix="AL")

  ConnectorNo auth

• validate_ibanA

  eu-verifyA

  Deterministic IBAN check before a SEPA/international transfer: format regex, per-country length (public SWIFT registry, ~85 countries) and ISO 7064 mod-97 checksum. Query: ?iban=FR1420041010050500013M02606 (spaces/dashes tolerated). Returns valid, country, bban, and a precise failure reason. Pure offline computation, 1y cache. Price: $0.001 USDC per call (x402).

  ConnectorNo auth

• swiftui_colorA

  Craftery Developer ToolsA

  Generate every SwiftUI Color initializer for a color: Color(red:green:blue:), opacity variant, Color(.sRGB), Color(.displayP3), HSB, hex-extension call, #colorLiteral, UIColor/NSColor bridges — plus a reusable `extension Color` snippet and Asset Catalog Contents.json.

  ConnectorNo auth

• admin_set_bank_transferA

  KaikuA

  Administrators only, and this one CHANGES things: state where bank transfers are to be sent. Send the WHOLE set every time — anything left out is cleared, not kept, because details half of one bank and half of another are money sent to a mixture of two. Read admin_bank_transfer first and repeat what you are not changing. Switching the method on is refused while anything a payment needs is missing (beneficiary, account, swift, and a purpose line carrying {invoice}), and the refusal names the field; switching it off is never refused. 'minimumUsd' is a floor under the METHOD and not under the debt: a bill below it is offered the other ways to pay, and what is owed does not change. The change is recorded against the calling administrator. Bills already issued keep the details they were issued with.

  ConnectorNo auth

• iso20022_legacy_and_scheme_mappingsA

  ISO 20022 NavigatorA

  Use for ANY question about what replaces or corresponds to a legacy payment message (SWIFT MT such as MT103, MT202, MT940; NACHA; CHAPS), or which payment schemes use an ISO 20022 message (pacs.008, pain.001, pain.008, camt.053; SEPA, NPP, CHAPS, Lynx, CIPS and others). Call it even when the answer seems well known: it returns sourced, current mappings with status and caveats. For "which schemes use X", call once with only the message: the response lists every recorded scheme (without descriptions, to keep it compact). Omit `standard` unless the user names one scheme; with `standard`, the response includes that scheme's description. - Legacy input (MT103, 940, ACH Statement): returns its ISO 20022 equivalent(s) in legacy_equivalents. - ISO 20022 input (pacs.008): returns legacy_equivalents (legacy messages that map to it) and used_by_schemes (schemes that use it). Mappings are message-level only; this tool does not map individual fields and has no information about a message's structure, elements or rules. Do not cite it for those. ISO 20022 messages that have been retired are returned flagged with iso20022_deactivated_in, not hidden.

  ConnectorNo auth

• axint.validateA

  AxintA

  Validate a TypeScript intent definition without generating Swift. Runs the full Axint validation pipeline (134 diagnostic rules) and returns a JSON array of diagnostics: { severity: 'error'|'warning', code: 'AXnnn', line: number, column: number, message: string, suggestion?: string }. Returns an empty array [] when validation passes. Use: use for TypeScript DSL diagnostics before Swift output; use swift.validate for existing Swift. Inputs: source is TypeScript DSL text; strictness options affect diagnostics only and never emit Swift. Effects: read-only diagnostics; writes no files and uses no network.

  ConnectorNo auth

• axint.schema.compileA

  AxintA

  Compile a minimal JSON schema directly to Swift, bypassing the TypeScript DSL entirely. Supports intents, views, components, widgets, and full apps via the 'type' parameter. Uses ~20 input tokens vs hundreds for TypeScript — ideal for LLM agents optimizing token budgets. Use: use for token-light JSON-to-Swift generation; use compile for full TypeScript DSL control and scaffold for TS starters. Inputs: schema kind selects intent, view, widget, or app output; options add companion metadata. Effects: read-only Swift generation; writes no files and uses no network.

  ConnectorNo auth

• lookup_bicA

  ibanforgeA

  Resolve a BIC / SWIFT code into the underlying bank: name, country, city, LEI, and registered head-office address (where available). USE WHEN: the user already has a BIC/SWIFT (8 or 11 chars, alphanumeric, e.g., "UBSWCHZH80A", "DEUTDEFF") and asks which bank it belongs to, where the bank is, or its LEI for compliance/regulatory matching. DO NOT USE for IBAN inputs — call validate_iban instead, it resolves the BIC for you. BACKED BY: BIC directory, 121,000+ entries (entries, not institutions): GLEIF and national registers, refreshed monthly, plus a public copy of the SWIFT directory frozen in January 2018 that still makes up about two thirds of the rows. 39,000+ of the rows carry an LEI from GLEIF. SOURCE: source names the dataset of this row and source_name spells it out; source_as_of is present only when that dataset is a copy frozen at that month (the public copy of the SWIFT directory, frozen in January 2018). listed_in_current_source says whether this BIC8 still appears in a list refreshed this cycle (GLEIF, a national register, the EPC scheme registers, the EBA STEP2 and NBP lists): true when one of them carries it, null when it was not found in what could be read in full. It never answers false today: the EBA STEP2 and NBP lists are only read through our deduplicated directory, which can drop a BIC they carry, so an absence is not proven. It does not prove the bank still exists under this name. COST: $0.003 per call (free with no key on this transport: 25 units a week per source address, one per call and one per IBAN in batch_validate_iban, reset on Monday 00:00 UTC. Or an ifk_ key with no e-mail at all: POST https://api.ibanforge.com/v1/keys/generate with no body for 25 calls/month, on the REST API or on this transport, and POST /v1/keys/claim lifts that same key to 200 a month. Send the key here as Authorization: Bearer ifk_… (or X-API-Key) and each call counts against it exactly as on the REST API).

  ConnectorNo auth

• swift_lookupA

  banking-intelligenceA

  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. EVERY BANK COMES BACK SAYING WHETHER WE HOLD ITS CORRESPONDENT CHAIN. Read `settlement_instructions` on each bank: `on_file: true` with a `currencies_on_file` count means we hold that BIC8's actual correspondent BIC, nostro account number and national clearing ID, and `read_with` is the exact ssi_lookup call that returns them. `on_file: false` means we hold none in any currency — a gap in our data, not a finding about the bank. A null is "not established yet" and is neither. This is the answer to "which intermediary bank do I put on the instruction?", and it is a fact we either have or do not have — never one to recall from training data. A BIC IDENTIFIES AN OFFICE, NOT A BRAND, AND THE DIFFERENCE IS PRICED. A name search returns ONE representative office per bank, elected by BIC convention rather than by relevance to the payment, and `office_note` says so whenever the bank holds more than one. Published tariffs, correspondent chains and settlement instructions are filed per BIC, so the choice changes the answer: transfer_cost("COBADEFF") returns Commerzbank's published 0.15% sending fee and transfer_cost("COBADEBB") refuses for want of a filed tariff, and both of those are Commerzbank AG in Germany. So: - If the user named a CITY, put it in the query — "Commerzbank Frankfurt" resolves to the Frankfurt office, and the plain name cannot. - If they did not, ask which BIC is on their statement or payment instruction before pricing or routing, and say which office you used. - Never present a representative office's BIC as "the bank's BIC". Examples: swift_lookup("DEUTDEFF") # exact BIC lookup swift_lookup("Deutsche Bank") # search by name swift_lookup("Commerzbank Frankfurt") # bank + city -> that office's BIC 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

  ConnectorNo auth

• validate_ibanA

  ibanchecker-mcpA

  Validate a single International Bank Account Number (IBAN) against the official ISO 13616 structure for its country. What it checks: the country code, total length for that country, the national BBAN structure, and the MOD-97 check digits. When the bank/branch code maps to a known institution, the response also includes the bank name, BIC/SWIFT code, and country. Returns JSON with `valid` (boolean), `iban`, `formatted`, `country`, `country_name`, `check_digits`, `bban`, and, when the bank is recognized, `bank_name`, `bic`, `bank_code`, `bank_city`, `sepa` and `national_check_valid`. An invalid IBAN still returns a result, with `valid: false`, an `error` message and an `error_code` (e.g. INVALID_CHECKSUM, INVALID_LENGTH, UNKNOWN_COUNTRY); it does not throw. Use this when you have one account number to verify. For many IBANs prefer `validate_bulk_ibans`; to pull IBANs out of prose use `extract_ibans_from_text` first. No account data is stored; validation runs in memory and is discarded. Requires an API key; a free key from ibanchecker.cash/api-docs covers 100 requests a month.

  ConnectorNo auth

• transfer_costA

  banking-intelligenceA

  BETA. Estimate what a cross-border payment will COST, split by WHO PAYS: the sending bank's published fee (the sender's side), what correspondents deduct in transit and what the beneficiary's own bank charges to credit it (the beneficiary's side), and what actually lands. This estimator is in BETA. Present every number as a typical case and a high case, never as a quote, and never let a user commit to a contractual amount on it. The payload carries beta=true while this holds. HOW TO READ THE ANSWER (relay these honestly): - `answered=false` means we REFUSED. The most common reason is that we hold no published tariff rule for the sending bank, in which case there is deliberately no total and no "recipient receives" figure. Say we do not know what that bank charges. Do NOT add up the parts yourself and present a total: treating the unknown fee as zero is the exact defect this tool was built to remove. - The correspondent fee is a RANGE (`p50` typical, `p90` high case), not a point. The spread is real: SWIFT tracking never reveals whether a payment was sent OUR, SHA or BEN, so a single cohort mixes all three. - THREE FEES, THREE DIFFERENT PAYERS, AND THEY ARE NOT INTERCHANGEABLE. `sending_fee` is billed to the SENDER by their own bank. `correspondent_fee` comes out of the payment in transit, so the BENEFICIARY bears it. `beneficiary_fee` is what the RECEIVING bank charges its own customer to credit the payment, so the beneficiary bears that too - and it is frequently the largest of the three (measured 2026-08-22 on one live corridor: 35.26 USD of sender-side cost against a 245.68 USD beneficiary bank fee). Never quote one of them as "the cost", and never call the beneficiary bank's fee a correspondent charge. `total` is the sending fee plus the transit deduction; `total_both_sides` adds the beneficiary bank's fee and is the all-in figure. - WHERE EACH NUMBER COMES FROM. The correspondent fee is OBSERVED, from payments we have tracked. `beneficiary_fee.source` is `tariff` (or `tariff_fallback`, see below) and never `observed`: a beneficiary bank deducts after the last bank that reports to GPI, so no tracking data can see it, and we read it off that bank's published incoming tariff instead. Say which is which when the user leans on a figure. - `beneficiary_fee.known=false` means WE HOLD NO INCOMING TARIFF for that bank (we hold one for roughly two thirds of beneficiary banks). Its charge is then missing from every figure, `total_both_sides` is null, and `recipient_receives.typical` is an UPPER BOUND - `recipient_receives.beneficiary_fee_known` says so. Do not fill that gap with a zero, a guess or a typical figure; say the receiving bank's own charge is not included and point the user at that bank's tariff. - `beneficiary_fee.applies=false` under OUR / OUR-OUR: the instruction says the sender covers every downstream charge, so the bank claims it back rather than taking it off the credit. The figure is reported but NOT subtracted. Our data ends before the account is credited, so we can neither confirm nor refute that it was honoured on a given payment. - `beneficiary_fee.segment` says which of the bank's incoming price lists was read. `segment_fallback=true` means the account type asked for had no usable schedule so the other one answered - which can only happen when `beneficiary_segment` was NOT supplied, i.e. when we were assuming the beneficiary matches the sender. Say that you assumed it. - `beneficiary_fee.reason='other_segment_only'` means you DID supply `beneficiary_segment`, and that bank publishes an incoming tariff for the other account type only (`beneficiary_fee.other_segment` names it). We decline to quote it. Do NOT report this as "we hold no tariff for that bank": we hold one, for a different kind of account. Tell the user which, because it is often the useful half of the answer. - `basis.n` is how many observed payments back the correspondent figure and `confidence` reflects it. At "low", present the range as rough. - `basis.level` says how specific the evidence is: `corridor` is this correspondent into this destination country, `correspondent` is that bank overall, and `currency` or `global` mean we hold nothing specific and are quoting a pool. Say so when it is a pool. - ON A REFUSAL `basis` IS NULL, and the same two figures are still on each entry of `correspondent_fee.legs[]` as `level` and `n`. Read them there. Do not read a missing `basis` as corridor-specific evidence: on a measured DE->AM screen the legs said `level: "currency", n: 146`, a currency-wide pool, and the answer described it as a single well-priced hop because the top-level key was absent. - `assumptions` is a list of plain sentences explaining what shaped the number (SEPA, OUR honoured, PSD2, a modelled BEN uplift, a stale tariff). Relay the ones that matter to the user's question. - under OUR the correspondent leg carries `our_breach`: the measured share of OUR payments that lose a charge in transit anyway, and what that costs. p50 is 0 and p90 is that loss. Quote BOTH - "the beneficiary should receive the full amount, and in about 7% of the OUR payments we can follow end to end they do not" - never the p50 alone as a promise. - `chain.status` = `no_chain` means the pair settles on local rails (SEPA, domestic, same banking group) with NO correspondent deduction at all. IMPORTANT ON CHARGE TYPE: charge_type is an INPUT and is never inferred from tracking. OUR is a real instruction and usually holds - of 150 payments whose own MT103 declared OUR and which we could follow from the instructed amount to the settled one, 139 reached the beneficiary intact, against 6 of 52 under SHA. It is NOT a guarantee: the other 11 lost a flat correspondent charge in transit, and we find no evidence that this depends on the destination country or on a US correspondent being in the chain, so do not tell a user that OUR is safe everywhere except the US. BEN is materially more expensive than SHA and our high case models it rather than measuring it. If the user has not said which they will use, ask, or state which one you assumed. Pass `beneficiary_bic` whenever the user knows the receiving bank: without it there is no correspondent chain to price and no beneficiary bank to read a tariff from, so the answer is the sending fee alone and no total. `customer_segment` selects which side of the SENDING bank's published price list is read. It is not cosmetic: of 30 banks publishing both schedules, 9 of the 17 that answered on both quote a different fee, one of them 220 PLN for a company against free for a person. It defaults to `individual` here; pass `business` when the payer is a company, and say which you assumed. `beneficiary_segment` does the same for the RECEIVING side, which is a different bank's price list and not a restatement of the sender's. Of 120 banks publishing both schedules, 28 quote a different incoming fee (measured 2026-08-24), and it runs both ways: Hipotekarna banka (HBBAMEPG) credits a 100,000 EUR payment free of charge to a company and takes 0.1% of it from a person, while Nordea charges a person 60 SEK and a company 250. Omit it and we assume the beneficiary matches the sender, which is what this tool did before 2026-08-24 - so if you omit it, say you assumed it. Supply it when the user has told you who is being paid, and prefer asking over guessing when the amount makes the difference material. Available to any caller with an active subscription.

  ConnectorNo auth

• screen_eventsA

  Ticker: Live Event Ticket MarketA

  Use this to find and rank many events by analytics signals: price, demand, inventory, rank. Use search_events instead to look an event up by name, venue or date, and get_event_analytics for every column of one event you already have. Screen the live event universe with a predicate over analytics columns. Returns matching events with their joined analytics snapshot (event_analytics + event + performer_analytics), including cross-sectional percentile/MAD-z columns. A plan limit is never missing data: a reading the account's plan does not include is refused with a plan_required error (`entitled` false, `required_tier` the plan that unlocks it, a one line `message`), and a column or field the plan strips from an answer is named in a top level `withheld` list with the same three fields. `null`, an empty list and `available` false mean the data does not exist. NON-ADMISSION SKUs ARE ALWAYS EXCLUDED: parking and shuttle / no-admission passes (sub_category_id 75, or an event_name matching '%parking%') never appear in a screen, and there is no parameter that lets them in. A screen that asks for sub_category_id 75 alone is refused with an error that says so. EVERY ROW IS ALREADY LINKED: each row carries `event_id` (the Ticker id every tool here accepts) and `event_url` (its page), whatever you project. Never call search_events to find the link or the id for a row this tool returned. The row has both, and a second lookup by name can attach a DIFFERENT event. An unknown name in `columns` is REJECTED with the valid spelling, not dropped, so fix it and call again. A page too large for one tool result comes back as the first rows plus `meta.truncated` and `meta.total_rows`; narrow the predicate, project fewer columns, or page, rather than repeating the call. Also screenable: marketplace demand levels/changes (ea.interest*, ea.sales*; young series, gate freshness on ea.demand_asof_date), PERFORMER-grain demand (pa.interest*, pa.sales*, pa.demand_asof_date; a separate performer-resource reading, NOT a rollup of that performer's events; filtering on it selects every event of a matching performer, so use it to find hot performers and ea.demand_* to pick among their events; gate on pa.demand_asof_date), performer popularity-rank momentum (pa.popularity_rank*; positive change = climbing), and sale-timing/ops columns: e.presale1_date and e.onsale_date (timestamptz; NULL = unknown/TBD and NULL never matches a range predicate; negative days_ago means the FUTURE: 'on sale in the next 7 days' is {"all":[{"col":"e.onsale_date","op":">=","val":{"days_ago":0}},{"col":"e.onsale_date","op":"<=","val":{"days_ago":-7}}]}) and e.monitoring_priority (the priority tier P1 to P10, stored as 1 to 10; P1 is read most often). Count changes come as counts (ea.listings_delta_*, ea.tickets_delta_*) AND as percents (ea.listings_pct_1d/_7d, ea.tickets_pct_1d/_7d): 'listings down 10%' is ea.listings_pct_7d <= -10, never a count of 10. ea.median_price_7d_ago is the median of 7 days earlier, a past level. ea.tm_tickets_pct_3d is the primary book's 3-day percent change (-100 = none left after some 3 days ago), and e.tm_sells is true when TM sells the event as its own primary sale ('not on TM' is false); both are primary-market columns. ONLY EVENTS DATED TODAY OR LATER (UTC) ARE SCREENED, whatever active_only says. A screen whose e.local_date range ended two or more days ago is refused with an error that says so. active_only=false adds inactive events in that window; their rows can be FROZEN at the last computation (ea.days_to_event stops counting, often stuck at -1) or hollow (returned with partial_row=true in the snapshot: treat their nulls as unknown, not zero). Don't rank frozen rows against live ones. For a past event's per-day history use get_event_price_chart / get_event_analytics_history. EMPTY RESULTS ARE EXPLAINED, NOT GUESSED AT: when a screen returns nothing you also get a `diagnostics` block (see the `diagnostics` param): `rows_evaluated` (how many events the predicate was actually measured against, AFTER the active/parking/economic-floor/freshness gates), `system_gates` (how many survived each of those gates, so you can see a scope flag did the damage), `root` and a per-leg `passed`/`failed`/`null` breakdown. Read the `warnings` before answering: ALL_NULL means that column is NULL for EVERY row evaluated, so the leg can never be true and the screen is broken; that is NOT a real no-match, and the honest reply is 'this signal isn't computed for these events' (offer a different column), never 'no events match'. A real no-match has legs with non-zero `passed` and null counts well under `rows_evaluated`: the filters worked, the combination is just too tight, so loosen the thresholds. HIGH_NULL_RATE (>50% NULL) is the middle ground: the results are real but cover only part of the universe, so say so. NO_ROWS_EVALUATED means nothing reached the predicate at all: the scope flags, not the predicate, are the problem. Each leg's `marginal` is how many more rows you'd get by dropping that one leg (null under an `any`/OR group, where dropping a member is meaningless). Legs include whole `any`/`all` groups as well as single comparisons; `kind` tells them apart. If `diagnostics.status` is "unavailable" the analysis could not be run; the events themselves are still correct. ABSORPTION IS DELISTING, NOT SALES: ea.absorption_count_1d/7d, ea.absorption_rate_7d and ea.listings_added_count_* count listings that LEFT (or joined) the marketplace: a broker withdrawal, a move to another exchange, or an expiry counts the same as a sale. NEVER report them as tickets bought or as sales volume; say 'absorbed' / 'delisted'. Whenever your predicate or sort touches an absorption column, ea.absorption_data_quality, ea.absorption_grain and ea.absorption_asof_date are auto-added to the projection; quote the quality and the as-of day with any absorption number. The as-of day is yesterday (UTC) for every covered event; an event without seat block ledger coverage is NULL in every absorption column, never 0. Quality is captured days / 7 times a block identity weight, so it tops out at 1.0. A provisional exit counts at once and a later return takes it back, so a published day can go down. Predicate DSL (recursive JSON): a leaf is {col, op, val}; composites are {all:[...]} (AND) or {any:[...]} (OR). Columns are prefixed: "ea." = event_analytics, "e." = events, "pa." = performer_analytics, "p." = performers (p.name, the act the row is about), "v." = venues (v.venue_name, the venue's name; v.city, v.state, v.country_code, v.capacity). Ops: =, !=, >, >=, <, <=, between (val=[lo,hi]), in (val=[...]), contains (case-insensitive substring on a TEXT column; val is a plain string), not_contains (removes the rows whose TEXT column holds val as a case-insensitive substring; a row with no value stays; % and _ in val match themselves, while contains reads them as wildcards). Example: {"all":[{"col":"ea.price_self_z_7d_xs_z_subcat_tte","op":">=","val":2},{"col":"ea.days_to_event","op":"between","val":[7,60]}]}. NAMED ACTS / TEAMS / PERFORMERS, use p.name. When the user names the act the events are BY (a musician like 'Taylor Swift', a team like 'Lakers', a comedian, a touring show), filter the performer column: {col:'p.name', op:'contains', val:'Taylor Swift'}. p.name is the act the row is KEYED on. e.event_name is the TITLE, which reads 'A at B' for a sports event and so also returns the opponent's home games, and for a concert also returns parking and support billings. A performer or team ask NEVER goes to e.event_name. Keep writing 'contains' for an act name. When what was typed IS a whole act name in the catalog, the server rewrites that leaf to op '=' and says so; anything else stays a substring. REMOVING ROWS BY A WORD. 'NOT Little', 'not the Lakers', 'without Taylor', 'excluding Hamilton' remove every row whose title contains the word: {col:'e.event_name', op:'not_contains', val:'Little'}. Never write '!=' for a word: '!=' compares the WHOLE value, so e.event_name != 'Manilow' removes nothing. A MISSPELLED superlative is still a superlative. 'htotest', 'hotest', 'bigest movers', 'chepest', 'lowset price' read as the word they intend and take the ordering that word takes. A ranking word is NEVER a name: never put it in a 'contains' leaf on e.event_name or p.name, and never answer with sort null because the spelling was odd. ECONOMIC FLOOR. The server already ANDs ea.listings_current >= 25 AND ea.median_price_current >= 40 into every screen. Do NOT add a book-depth floor of your own. A column whose name ends in d1 or 1d is a ONE-DAY CHANGE, not yesterday's value. 'Inventory dropping' or 'listings falling' is a SEVEN-DAY change or an absorption column, never a one-day ratio. A stale row, or an event that is not active, is NEVER a move: its numbers describe the last day it was priced. Gate a movement ask on ea.last_price_snapshot_date with a relative date. The economic floor CAN be turned off at the call site (apply_floor=false, or apply_economic_floor=false on a rule), only when you explicitly want the raw universe. A freshness gate is NOT applied by default, so supply it yourself: {"col":"ea.last_price_snapshot_date","op":">=","val":{"days_ago":1}} means "priced within the last day" and compiles to CURRENT_DATE - 1, re-evaluated every tick, where a literal date string silently rots. The {"days_ago": N} value form is valid on any date/timestamp column. Authoritative validation runs in SQL; an invalid predicate returns a clear error.

  ConnectorOAuth