Bancor Currency Exchange, case study by Santiago Castillo

35%abandoned the legacy flow at the transaction form

3 → 1screens of input to complete an operation

9banks and wallets benchmarked

What changed

Bancor already let customers buy dollars in the app. Reaching the operation meant passing three screens before an amount could be typed, and the last of them was a form with ten things to resolve: the operation type again, two account selectors, a radio pair asking which currency you were thinking in, the amount, and five derived lines underneath.

I rebuilt the input as a single card. The rate sits above the fields, pesos and dollars are a mirrored pair that resolve each other, and the field that leads is always the one being debited. Buy and sell became two entry points rather than a dropdown, so the operation is chosen by tapping instead of declared in a form.

Nobody asked for this project. I built the case for it from the drop-off in the form and what users said they wanted, and took it to the product owner.

The problem

A form standing in front of a one-figure decision

Buying dollars is the most emotionally loaded transaction in Argentine retail banking. It is how people protect a salary against inflation, and they arrive with a number already decided. The legacy flow met that with a form.

35%left at the form

Abandonment was not at the entry point and not at the confirmation. It concentrated on the one screen that asked the most of the user.

1 Home
2 Rate of the day
3 Operation type
4 The form
5 Confirmation
6 Result
7 Receipt

Seven screens. The operation type was chosen twice, and three passed before an amount could be typed.

The legacy transaction form with dropdowns, a radio pair and five derived amount lines — Operation type, two account dropdowns, a currency radio pair, one amount field, and five derived lines. The screen continues below the fold.

The redesigned amount screen with mirrored peso and dollar fields — The same task in one card, with both figures visible at once and nothing derived that the user did not ask for.

The drop-off had an address

Analytics put the loss on a specific screen. That turned an unarguable complaint about the dollar flow into a design problem with a location.

Users described the fix themselves

Asked what they wanted from the app, they were explicit: the exchange resolved in one step, on one screen, the way the apps they already use resolve it.

The form told on itself

It carried a warning that the amounts on screen were indicative and might differ from what was actually debited. The product was telling users not to trust the numbers in front of them.

The convention already existed

Across nine banks and wallets, the exchange was resolved on one screen with a live two-way conversion. What users asked for was not a preference. It was something they had already learned everywhere else.

The argument I built

Nobody handed me a retention target. Connecting the drop-off with what users were saying gave one: people who wanted dollars were still getting them, and a friction problem inside one flow was a retention problem for foreign-currency balances. That framing is mine, built from the two pieces of evidence above, and it is what justified the project to the product owner.

Constraints that shaped the work

Four of them, and none were negotiable. They explain why the obvious fix was not simply a shorter form.

A trading window

The operation is only available Monday to Friday, 8:00 to 15:00. Outside it the flow cannot simply fail.

A dollar account is required

Without a savings account in USD there is no operation, and part of the audience arrives without one.

Terms as a sworn statement

Full legal text, accepted before every operation. Not negotiable in length or content.

An existing design system

Built inside the bank's component library, with no new components beyond what the conversion required.

The tax lines, and what they made possible

The legacy form carried PAÍS tax and an ARCA withholding as two of its five derived lines. Both left through regulatory change, not through design. It is worth saying plainly because it is what made a legible single-screen conversion possible: five derived figures could not have coexisted with a two-way amount field. Part of the work was being ready for the room that opened.

Three rules I held to

1

Certainty before commitment

Nobody confirms without seeing the rate applied, the amount in both currencies, and both accounts by number. In an operation between two accounts it is tempting to leave them implied. Showing them is what makes a confirmation a check rather than a formality.

2

Meet the figure they arrived with

Half the people come thinking in pesos and half in dollars. Forcing one direction makes the other half do arithmetic before they can operate. The interface adapts to whichever figure is already in their head.

3

Lead with what leaves the account

The field on top is always the one being debited. Buying, that is pesos. Selling, that is dollars. In a transaction with savings, the anxiety sits on what you hand over, not on what you receive.

The redesign

Amount, confirmation, proof

One input screen, then a confirmation that names both accounts, then a receipt that makes the operation demonstrable rather than merely confirmed.

Amount→ Confirmation→ Result→ Receipt

Selling dollars, the mirror

Amount

Confirmation

Receipt

Selling mirrors buying. Same architecture, same components, same positions. Only the conversion direction and the applied rate change, so anyone who has bought once already knows how to sell.

Three decisions

The part worth reading is not what the screens look like. It is what was argued about.

Decision 01

The operation is chosen by tapping, not declared

Before

Operation type was picked on its own screen, then repeated as a dropdown at the top of the form, alongside two account selectors.

What I did

Buy and sell became two entry points in the hub, each carrying its own rate. Choosing the operation and seeing its price became the same gesture, and the account selector moved inside the amount card where its balance is useful.

Why

A dropdown asks a question the previous screen already answered. Removing it took a decision away from the user without taking away any control.

The buy and sell entry points in the hub, each carrying its own rate — Two entry points, each carrying its own rate. Choosing the operation and seeing its price is one gesture.

Decision 02

Two fields that resolve each other

Before

A radio pair asked the user to declare whether they were thinking in pesos or in dollars, before typing anything. One amount field followed, valid only for the currency chosen above.

What I did

Both currencies became a mirrored pair with a swap control between them. Typing in either resolves the other. A shortcut covers the most frequent intent, which is all of it.

Why

The radio pair was not asking for a preference, it was asking the user to translate their own intention into the system's terms before the system would help them. Every benchmarked product showed both figures at once instead.

The mirrored peso and dollar fields with the swap control between them — The swap control sits between the fields, not above them, so it reads as a relationship rather than a setting.

Decision 03

The debited amount leads, in both directions

The disagreement

The squad wanted the dollar figure on top in both flows, on the grounds that dollars are what the section is about and consistency would be easier to learn. I argued for the debited amount on top instead: pesos when buying, dollars when selling.

What settled it

Of the five apps where I could reach the amount screen, four lead with the debited amount: Mercado Pago, ARQ, Supervielle and Naranja X. Santander is the only one that leads with dollars in both directions.

Why it matters

Both are consistency rules. Theirs was consistency of position, mine was consistency of meaning: the top field is always the account being emptied. In an operation with savings, the figure people check first is what leaves.

Buy and sell amount cards side by side, showing pesos first when buying and dollars first when selling — Buying leads with pesos, selling leads with dollars. The rule is the account being debited, not the currency.

The unhappy paths are most of the work

A trading window, a required account and a legacy core mean a large share of sessions never reach the happy path. Each case got a designed screen rather than a generic error, at both the hub level and inside the flow.

Hub outside trading hours — **Outside trading hours, at the hub.** Rates and balance stay visible, and the window is named: Monday to Friday, 8:00 to 15:00.

Buy flow outside trading hours — **And again inside the flow.** Someone who tapped through before the window closed gets the same answer where they are.

Hub without a dollar account — **No dollar account.** Rates stay visible and the balance slot becomes the account opening, free and enabled on the spot.

Hub with a zero dollar balance — **Zero balance.** The account exists and buying is available, but there is nothing to sell yet.

Amount over balance validation — **Amount over balance.** Validated in the field, at the moment, without discarding what was typed.

Hub when the service is unavailable — **Service unavailable.** When rates or balances cannot be retrieved, the flow says so without blaming the user. Also solved at both levels.

Operation failed after confirmation — **Failure after confirming.** The most delicate case gets its own screen, stating that no money moved.

Receipt marked as not completed — **And the receipt carries the state.** Same document, reporting what actually happened rather than asserting success.

History, with the constraint made visible

Purchases and sales in one list with the direction of each movement, filterable by a custom period. The backend caps the range at 30 days, so that limit surfaces as validation when the filter is applied rather than hiding in help text nobody reads.

What went to development

Eighteen screens and states, a branching diagram, and notes for the functional analysts where behaviour cannot be read from the design: numeric keypad rather than alphanumeric on the amount fields, and the full legal text rather than a summary.

Operation history listing purchases and sales — History. Purchases and sales in one list, each carrying the direction of the movement.

Period filter sheet over the history screen — The period filter, where the 30-day cap surfaces as validation.

What I decided not to build

Three decisions where the interesting part is not the design. It is what I chose to give up, and what it costs.

Opening the dollar account inside the flow

A customer without a USD account hits a wall at the moment of highest intent. Opening it right there went out of scope for the first release, so the hub sends them to the accounts module.

What it costs. The person leaves the flow at exactly the wrong moment, and I have no data on how many come back. This is the weakest point of the release and it is tagged in the file as the first thing to revisit.

The movements tab in the hub

The hub shows the four most recent operations with a link to full history. A dedicated tab was designed and deferred.

What it costs. Very little for now. Four entries cover the common case, and the full history is one tap away. It earns its place only if people start using the section to reconcile rather than to transact.

The symmetric field order the squad wanted

Dollars on top in both directions, which would have made the two screens look identical. I argued against it and the debit-first rule shipped.

The argument against my own decision. Someone who thinks in dollars now finds their figure in the second field, and needs the swap control to put it first. That is a real cost, paid by a real group of users, to protect the certainty of the larger one. The swap control exists because of it, and if usage shows people reaching for it constantly, the squad was right and I was wrong.

The outcome

What changed, and what I am not going to claim

The flow is designed, specified and handed over. What I can report is structural, not behavioural: the input collapsed from three screens to one, the ten things the form asked for became two fields and an account selector, and the operation now carries its rate from the entry point through to a receipt with a transaction code.

There is no post-launch number here, and I am not going to manufacture one. The honest version of this section is the measurement plan, agreed as the way this work gets judged rather than described after the fact.

1Drop-off at the amount step, compared against the 35% baseline that started the project. It is the only true before-and-after available.

2Completion per session: of the people who open the hub, how many finish an operation.

3Use of the swap control, which is the direct test of decision 03. Heavy use means the field order is wrong.

4Dollar balances that stay in the bank after the exchange, which is the retention argument the project was built on.

What those numbers will not carry

Even a clean improvement in completion would not prove the retention argument. Someone can finish an operation here and still move the dollars out the next day, and the exchange rate moves for reasons that have nothing to do with this flow. Metric four is the one that matters and the one this design controls least.

Next case

Bancor Currency Exchange. Three screens into one.