Transfer UX: explain the fee before the customer sends

The customer enters $1,000. The next screen shows €920 and a $5 fee. Does the fee come out of the $1,000, or will the account be charged $1,005?

Both arrangements are possible. A transfer interface needs to say which one applies before asking the customer to send. The same screen must explain the amount being converted, the rate used and what the recipient is expected to receive.

The Fintech Design Director includes payment and fee clarity in its review guidance. A useful review follows the numbers across the quote and confirmation screens, then checks what happens when one of them changes.

Decide which amount the customer is fixing

Someone paying an invoice may need the recipient to receive an exact amount. Someone moving savings may have a fixed amount available to spend. Those are different starting points.

Wise’s explanation of exact-amount transfers makes that distinction explicit: a customer can set the amount they send or the amount the recipient gets. Its guidance also explains that rate guarantees depend on meeting the stated payment conditions. These are examples of one provider’s behavior, not rules that every transfer product shares.

In your own flow, make the chosen constraint visible. Label the input “Total you pay” if it includes the fee. If the customer is fixing the recipient amount instead, explain how that affects the sender’s total. “Amount” alone leaves the most consequential part unstated.

Make the arithmetic readable

Consider two fictional quotes. Both use an illustrative exchange rate of $1 = €0.92 and a $5 fee. There are no other charges in this simplified example. These are not live rates or advertised fees.

The difference is €4.60 at the receiving end, or $5 at the sending end. A small label determines which calculation the customer believes they approved.

For the first quote, useful review-screen copy would be:

You pay $1,000 in total. This includes a $5 transfer fee. We convert $995 at $1 = €0.92. The recipient receives €915.40.

Use the final sentence only when the service can support that certainty. If another institution may deduct charges, explain the uncertainty beside the recipient amount and use wording appropriate to the actual route. A precise-looking number should not conceal an estimate.

Keep the quote and approval in agreement

Follow the customer through a change of payment method. Does that alter the fee? If it does, recalculate the affected amounts and show the revised total before approval. Carry the selected recipient and currency forward so the person can inspect the complete instruction.

Now let the quote expire. A useful expired state identifies that the old quote is no longer available and lets the customer review a refreshed one. Preserve the information that remains valid. Avoid making the person re-enter a recipient merely because the price needs updating.

The precise expiration behavior belongs to the product and payment system. Do not add a decorative countdown or a “rate locked” label unless there is a real guarantee behind it. If the guarantee depends on funds arriving by a deadline, explain that condition where the customer chooses how to pay.

For an AI assistant preparing the transfer, there is another boundary to check: whether the person is approving the final payment instruction. The AI payment confirmation guide covers that action boundary. The quote review here focuses on the amounts and conditions attached to it.

Give the review skill a complete quote

A screenshot with three numbers may be enough to spot ambiguity. It is not enough to determine the correct commercial terms.

Provide the entry screen, quote, final approval and expired-quote state. Attach the confirmed fee rules, rounding behavior and relevant payment-method differences. Use test values. Then give the Fintech Design Director a bounded request:

Review this transfer quote for fee and exchange-rate clarity. Check whether a customer can distinguish the total debit, fee, amount converted and recipient amount. Trace an edit to the payment method and an expired quote. Use the supplied calculation rules. Flag missing information instead of inventing rates, guarantees or legal requirements.

Ask for each finding to name the screen, the ambiguity and the smallest proposed correction. “Move the fee above the button” is incomplete unless it explains what the current placement causes the customer to misunderstand.

The skill can propose wording and a layout. Product and engineering must verify the numbers against the actual quote response. Any required market disclosures belong with the responsible policy team.

Test the customer’s calculation

Give a participant the fictional fixed-total quote and ask how much leaves their account and how much reaches the recipient. Then change the payment method or refresh the rate and ask the same questions. Do not explain which field changed first.

Check whether the person understands the revised quote before proceeding. A faster tap is not an improvement if they approve an amount they cannot explain.

Keep the calculation and the explanation together in the design handoff. Include the normal quote, changed fee, expired quote and any estimated recipient amount as separate examples. Verify formatting and rounding in the implemented flow, too; a correct design file cannot guarantee correct displayed values.

Start with one transfer route in the Fintech Design Director. The review is useful when the customer can answer, before sending, “What leaves my account, what arrives, and what could still change?”