Mortgage Broker
BI Group's buyers could apply for a mortgage without leaving the site, but the flow made them pick one bank at a time and start over after every rejection. A third abandoned the application.
- BI Group
- Sole product designer
- Partner research, interaction design, handoff
- Me, one BA, engineering
- 2025
- Redrawn in 2026 for this case. Flow and decisions as shipped.
Impact · Outcome
~$4M a month, from the same traffic
Funded mortgage transactions rose 35% in the first 28 days after launch, and over the same 28 days approved mortgages grew by roughly $4M a month. Traffic didn't change. The same people were finishing a flow that used to break on them.
Abandonment at that step went from a third of buyers to a tenth. The rejection loop is gone.
All three come from BI Group analytics, comparing like-for-like periods before and after launch. Transactions and approvals are counted over the first 28 days.
Context
A credit application built for the banks
BI Group is the largest property developer in Kazakhstan. Their platform lets buyers browse flats, tour floor plans, and apply for mortgage financing through partner banks without going anywhere else.
That was the promise. The credit application inside it had never been designed around the buyer, though. It was built to satisfy the banks' technical requirements.

- Sole product designer on the flow
- One business analyst, Alinur, and the engineering team
- Research through to handoff
Discover
One in three buyers abandoned the credit application
The old flow made the buyer pick a bank before knowing anything about it. Enter the ID, wait, get rejected, go back, pick another bank, enter the ID again, wait again.
There was no way to tell which banks might approve them. Choosing was guesswork. Every rejection sent the buyer back to the start.

What the data showed
A third of started applications were abandoned. Abandonment peaked after the second rejection rather than the first, which told us people were willing to try again. They just ran out of patience before they ran out of banks.

Define
The capability that was already there
Partner research went back to the banks to work out when in the process they actually decide. It came out of a few conversations between me, the BA and the banks.
The answer was that every partner already offered a pre-scoring API: a preliminary yes or no before a full application. Nobody on our side was using it. The platform was running full sequential applications when it could have been scoring every bank at once.
The API was a product finding, and the BA and the banks found it with me. My part started after that: details entered once instead of once per bank, every partner checked at once, and a form that appears only once the buyer knows they're approved.


What else the research surfaced
- The same personal data was re-entered for every attempt, and the friction compounded with each failure
- Bank choice was arbitrary, with nothing to base it on
- Each rejection cost trust in BI Group, not in the bank
- Anyone who exhausted every bank hit a dead end
What we couldn't change
- Every bank had its own API contract, fields and response format. The design had to absorb that and present one experience on top of it.
- ID verification was a regulatory requirement and couldn't be deferred.
- We shipped inside an existing sprint cadence with a fixed team, so it had to arrive in phases.
Develop · Rejected
The universal form I built and threw away
The first idea was one form that collected every field any bank might need and submitted to all of them at once. One form, one submission. It looked elegant on a whiteboard.
It fell apart on contact with the banks' contracts. Each wanted different fields, in different formats, with different validation. A universal form meant months of backend work and a UI where many questions applied to some banks and not others. It would have been longer and more intimidating than the flow it replaced.


Develop
Pre-scoring first, form second
Pre-scoring sidesteps the problem. The buyer enters their details once, and every partner bank is checked against them at the same time.
The full form only appears for the bank they choose, after they already know they're approved. It arrives in a success context, which is a very different thing to fill in than a form the buyer might fail.
A single pass ends in one of three states. Some banks approved and their offers are on the screen. Some are still answering. Or none approved, and the buyer is told what to change.
What the API didn't solve
The API made pre-scoring possible. The design work was in presenting it to someone under financial pressure.
Offers side by side
The first outcome is approved offers, four to six at once, and they had to be comparable at a glance. Every card shows the monthly payment, in the same place for every bank, so offers can be compared without opening them. A table assumes the buyer is comfortable reading financial tables. A lot of buyers aren't.
The rest sits under Show details. A step-rate mortgage gets its rate for each period, so the payment that rises in year four is on the screen before anyone signs.

While banks answer, and when none says yes
Banks answer one at a time. In the second outcome, while some are still checking, the screen fills in as they do and Continue waits for the first approval.
In the third, pre-scoring returns nothing. The buyer is frustrated and still wants the flat. So that state doesn't end on a bare refusal. It shows what would raise the score, so the buyer knows what to change before trying again.

Asking for an ID number
Handing over an ID number to be checked against several banks is a lot to ask. The phone number is confirmed with an SMS code, and consent to process personal data is signed in eGov.

Programmes that change halfway
Some programmes, like Freedom Bank's KÖRKEM, start as a loan plus a savings deposit and switch to a cheaper housing loan later. On a phone the offer shows that as a timeline: what the buyer pays now, the month it changes, the month the loan closes. Once a bank approves, the down payment and term can still be adjusted.

Develop · After approval
From an offer to a signed agreement
Choosing an offer isn't the end of it. The bank confirms its decision, the buyer pays the down payment, and the purchase agreement gets signed.
The three steps share one frame: the steps along the top, and on the left the flat, the terms and the down payment, which stay put from one step to the next.

The down payment is paid from a banking app by QR code, with the steps for the selected app printed beside the code.

The agreement is read on the site and signed there. On a phone, signing ends on a single confirmation.

One flat at a time
A buyer can hold one flat at a time. Applying for a second one asks which to keep, and shows how long the current hold has left.

Every application stays in the account with its status and the one thing to do next.

Deliver
What testers did before we shipped
We ran informal walkthroughs with colleagues and a small group of real users. Three things came up every time.
- Everyone paused before typing their ID.
- Asked what they looked at first on the offers screen, every tester pointed at the monthly payment. They read the rate afterwards, to check the payment.
- The zero-offers wording read as cold. We warmed it before launch.
Impact · After launch
The terms moved to the first step
At launch the flow opened on the buyer's details. The terms came next, meaning the price, the down payment and the term, and only after that could they see what each bank offered.
Going by how people behaved after launch, we swapped the order. The buyer now sets the terms first and straight away sees approximate monthly payments from each bank and which banks could finance the flat. Their details come after that, to turn those estimates into real approvals.

The buyer sees what they can get before being asked for anything, and entering their details is the one step left. That version stayed, and it's the one live on the site today.
Reflection
What I'd do differently
The zero-offers state deserved its own sprint
Someone who gets scored and comes back with nothing is frustrated and still wants to buy. We treated that as an edge case and shipped something functional and generic. It was the most emotionally loaded moment in the flow and it got the least attention.





