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.