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.
- `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)