CurrencyGuard Guard Pricing

Use when a user asks whether a Guard is worth it, how it compares with a forward contract from their bank or provider, or what happens if they do nothing. ASK BEFORE YOU CALL. The forward side of this comparison should be the customer's own numbers, not CurrencyGuard's guesses. Ask three things first: (1) the forward rate their provider last quoted them for this payment, (2) whether the provider gives them an unsecured line with no deposit, or asks for an initial margin and at what percentage, and (3) at what adverse move the provider demands more cash. Pass what they give you as providerForwardRate, initialMarginPct (0 for an unsecured line) and marginCallThresholdPct. Only call with none of them when the customer cannot answer, and then say in your answer that the forward figures are illustrative defaults. DO NOT RANK. Present every row in the order the output gives it: rates, home-currency amount, cash up front, cash demanded under adverse moves, outcomes under favourable and adverse moves, cancellation, market improvement, worst case. Do not say which one wins, which looks bad, which is cheaper overall, or which the customer should choose. State the numbers. The decision is the customer's. cashNature says what kind of money each figure is: the Guard fee is spent, a forward's deposit and margin calls are held and returned at settlement. Say so when you show them. Held cash is not a cost. outcomes runs each move in both directions. In the favourable rows the Guard lapses and the fee is spent for nothing, and the forward is locked out of the better rate. Show both directions, not only the adverse one. READ OUT comparability.protection AND comparability.pricing beside the cost row, every time. A Guard and a forward are different kinds of protection, and the Guard rate here is mid-market while a payment provider may apply a margin to it or to the fee. The cost row is therefore not a like-for-like price comparison. If a tenor like '3 months' is given, call resolve_se…

Explain the Guard product using CurrencyGuard's approved product and FAQ content. Covers: what the Guard is, how it works, who it is for, how it compares to forwards or options, and legal, regulatory, accounting, or eligibility questions.

Use when you need a forward FX rate. tenor accepts either a period such as 1W, 1M, 3M, 6M, 1Y, or an exact date in ISO form YYYY-MM-DD. Use an exact date whenever you need the forward for the same day a Guard settles: a period resolves to the forward curve's own date, which can be several days away, and a comparison across two different dates is misleading. Rates are taken from the market forward curve, rounded, and for illustration purposes only — not for execution. Returns: forwardRate (indicative mid outright rate for that date), spotMid (indicative spot mid rate for comparison), settlementDate (the date the rate is for). A forwardRate below spotMid means the forward is cheaper than spot for the base currency; above means dearer. Example: base=GBP, quote=USD, tenor=2026-12-29 returns the GBPUSD forward for that day.

Analyze historic best/worst FX performance for a currency pair over a Guard's duration. Uses Bank of England historic rates. Returns a 'performances' array with 6 entries — BEST and WORST for each of three lookback periods (5, 10, 25 years). Each entry contains: performanceType (BEST or WORST), periodInYears (5, 10 or 25), windowSizeInDays, startDate/endDate, startRate/endRate, performancePercentage, startAmount, finalAmount, deltaAmount (in the window's own money), finalAmountToday, deltaAmountToday (the same move applied to today's amount). For Guard-Pay: negative delta = cost decreased = BEST; positive delta = cost increased = WORST. For Guard-Receive: positive delta = receipt increased = BEST; negative delta = receipt decreased = WORST. When there is a preceding price_guard call, the parameters must match it, including payReceive (PAY or RECEIVE). WHEN TO CALL. Only when the user asks for historic performance, best or worst cases, or historic context. Never to answer "what can I do" or "what would you do". If there is no price_guard quote, leave guardAmount empty; do not call price_guard only to fill it. IF IT FAILS. A result with valid: false has no data. Say that historic figures are unavailable and stop. Do not show the table and do not estimate any figure.

Get an indicative spot FX rate for a currency pair. Returns a rounded indicative mid rate, for illustration purposes only — not for execution. Example: base=GBP, quote=USD returns the GBPUSD rate.

List the currency pairs currently available for Guard pricing. Always call this rather than assuming which pairs are supported — the list is configuration-driven and changes.

Net an SME's open foreign-currency bills and invoices, so that a receipt due on or before a payment in the same currency is shown as funding it. Returns the residual on every bill and invoice, a trace of which invoice funds which bill and for how much, per-bucket totals, dependency statements, and series for a ladder chart. It prices nothing: call price_guard on each residual separately, with the item's own due date as settlementDate. Never offsets across currencies. Items in base_currency are ignored. Cancelled items are excluded. Overdue items are listed separately and never netted. Set carry to true only when the client keeps receipts in a wallet or account in that currency, so a surplus can fund a later payment. If you do not know, ask the user whether they hold an account in each foreign currency before calling; do not guess. If their accounting platform is connected, offer to look up its bank accounts and their currencies there, and use what you find. If the answer is "not sure", call the tool twice, carry true and carry false, and show both charts; each carries its own scenario title, and chart_series.scenario holds the same words. THE RESULT HAS TWO PARTS: the JSON, then a PNG of the ladder chart rendered by the service. Show that image to the user as it is. PRESENTING THE RESULT: chart_series.currencies[ccy].open[] is the exposure. Present each open item on its own due date, with its label. Never add open items into one net figure, and never convert them to the base currency at spot. Do not call price_guard or show a Guard price unless the user asks for a price. If the user asks what they can do, lay out three things as facts and stop: do nothing (the amount stays exposed until paid), a forward from a bank or a payment provider (fixes the rate, provider margin inside the rate, an obligation that may need initial margin and margin calls, settled even if the payment does not happen), a Guard (fee known up front, market rate used if better, nothing further to…

Price a Guard — CurrencyGuard's FX protection product for real future payments or receipts. If a tenor like '3 months' is given, call resolve_settlement_date first to get the exact date, then call this tool. THE AMOUNT. Give exactly ONE of foreignAmount and netGuardAmount, never both. Give foreignAmount when the customer has an invoice or bill in the foreign currency and wants to know what it is worth in their own currency: "I have to pay USD 50,000 in March" is foreignAmount 50000, PAY. Give netGuardAmount when the customer names the amount they want in their OWN currency after the fee, and asks what to invoice or how much they can cover: "I need GBP 100,000 from Marco, he pays in euros, what do I quote him?" is netGuardAmount 100000, RECEIVE, guardCurrency GBP, foreignCurrency EUR. With netGuardAmount the server solves for the foreign amount, so the foreignAmount in the response IS THE ANSWER: the amount to invoice (RECEIVE) or the amount covered (PAY). Read it out as the answer to the question. Returns: guardType (Guard-Pay or Guard-Receive), guardRate, guardFee (in the home currency), guardFeePct (a FRACTION: 0.0096 means 0.96%), guardFeePercent (the same figure written as a percentage, e.g. "0.96%" — quote this one), effectiveRate, guardAmount (the foreign amount converted at the Guard rate, in the home currency, WITHOUT the fee), foreignAmount, spotRate, settlementDate, settlementWindowFrom (the first day the Guard rate can be used; the window runs from there to settlementDate. It opens 14 business days before settlementDate on the trading calendar, which is about three weeks in calendar days. Say "14 business days", never "14 days", and read both dates out as given), payLaterCreditFee (the extra for paying the fee at settlement instead of up front. This tool asks for a pay-now quote, so the server returns 0 here. 0 does NOT mean Pay Later is free: say that a small credit fee applies and that it is not in this quote), valid, errors, stale. Also returns netGua…

Get an indicative price for extending a Guard to a later settlement date. Use it when a customer asks what it costs to extend a Guard. Returns: extensionCost, what the customer pays to extend, in the home currency. Show it as the answer: "Extending to [date] costs [extensionCost]". It is one figure; there is no breakdown. Also the currencies, the direction, the foreign amount, both dates, valid, errors, stale. Both dates are moved to the next business day when needed, and a note says so. Parameters: guardCurrency, foreignCurrency, payReceive, foreignAmount, originalSettlementDate, extendedSettlementDate. There is no Guard rate input: the server prices the extension at today's market rate, not at the rate of the Guard the customer holds. Say that the figure is indicative for that reason too.

Find out whether Guards can be bought through a particular payment provider or bank. A Guard is always bought through a payment provider, so this cannot be answered without knowing which one the user pays through — CurrencyGuard checks and replies. ASK BEFORE CALLING. Tell the user plainly that their provider, and their email address if they give one, will be sent to CurrencyGuard so they can answer. Call this only after they say yes. The email address is optional: the provider on its own is a complete enquiry, and without an address there is simply no one to reply to. Never take an email address from earlier in the conversation — only one the user has just given for this purpose. Never call this more than once in a conversation, and never after the user has declined.

Resolve a relative time period (tenor) to a valid business settlement date for a currency pair. Use this when a user says '3 months', '6 months', '1 year', etc. instead of an exact date. The tenor format is: 1D (days), 1W (weeks), 1M (months), 1Y (years). Examples: '3M' = 3 months, '6M' = 6 months, '1Y' = 1 year. The returned date accounts for weekends and public holidays in both currencies' financial centres. Use the returned settlementDate as the exact date parameter for price_guard.