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. The estimate itself costs no credits (tracking a payment does cost credits; never describe tracking as free).

Args: bank_swift: Sending bank BIC (8 or 11 chars) amount: Transfer amount currency: 3-letter transfer currency charge_type: SHA (default), OUR or BEN. Ask the user rather than guessing beneficiary_bic: Receiving bank BIC; needed for a total channel: online | branch | mobile_app | any customer_segment: individual | business | financial_institution - the SENDER beneficiary_segment: individual | business | financial_institution - the party being PAID. Omitted, it mirrors customer_segment customer_sub_segment: standard | premium | private_banking | vip api_key: Optional API key (internal calls ride the MCP secret)