Mustafa Myrza

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.

Client
BI Group
Role
Sole product designer
Scope
Partner research, interaction design, handoff
Team
Me, one BA, engineering
Year
2025
Screens
Redrawn in 2026 for this case. Flow and decisions as shipped.
+35%
Funded transactions, 28 days after launch
~$4M a month
More in approved mortgages over the same 28 days, from the same traffic
1 in 10 was 1 in 3
Abandoned the credit application, BI Group analytics
6 banks
One application goes to every partner bank at once
3 outcomes
Approved offers, banks still answering, or none approved

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.

BI Group's site: flats and the mortgage application in one place.
BI Group's site: flats and the mortgage application in one place.
BI Group's site: flats and the mortgage application in one place.
  • 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.

The old flow: one bank at a time, and the same details entered again after every refusal.
The old flow: one bank at a time, and the same details entered again after every refusal.
The old flow: one bank at a time, and the same details entered again after every refusal.

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.

Where buyers abandoned the application, by step. Most left after the second rejection. Illustrative, without figures.
Where buyers abandoned the application, by step. Most left after the second rejection. Illustrative, without figures.
Where buyers abandoned the application, by step. Most left after the second rejection. Illustrative, without figures.

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.

The flow as launched, from the details to three possible outcomes.
The flow as launched, from the details to three possible outcomes.
The flow as launched, from the details to three possible outcomes.
The details form, and the check running across six partner banks.
The details form, and the check running across six partner banks.
The details form, and the check running across six partner banks.

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.

Illustrative. One long form with every field any bank might ask for, sent to all of them.
Illustrative. One long form with every field any bank might ask for, sent to all of them.
Illustrative. One long form with every field any bank might ask for, sent to all of them.
Illustrative. Each bank asked for a different set of fields and formats.
Illustrative. Each bank asked for a different set of fields and formats.
Illustrative. Each bank asked for a different set of fields and formats.

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.

Three approved offers, cheapest first. Two are open to their details.
Three approved offers, cheapest first. Two are open to their details.
Three approved offers, cheapest first. Two are open to their details.

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.

Two banks in and four still checking. Next to it, every bank declined or silent.
Two banks in and four still checking. Next to it, every bank declined or silent.
Two banks in and four still checking. Next to it, every bank declined or silent.

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.

The phone number confirmed by SMS, and consent to process personal data signed in eGov.
The phone number confirmed by SMS, and consent to process personal data signed in eGov.
The phone number confirmed by SMS, and consent to process personal data 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.

A KÖRKEM offer with its timeline, then the terms after approval.
A KÖRKEM offer with its timeline, then the terms after approval.
A KÖRKEM offer with its timeline, then the terms after approval.

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 bank's decision, with the time left on the offer and the rate for each period.
The bank's decision, with the time left on the offer and the rate for each period.
The bank's decision, with the time left on the offer and the rate for each period.

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

Paying the down payment through the Halyk app.
Paying the down payment through the Halyk app.
Paying the down payment through the Halyk app.

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

The purchase agreement, and the screen after signing.
The purchase agreement, and the screen after signing.
The purchase agreement, and the screen after signing.

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.

Applying for a flat while another one is on hold.
Applying for a flat while another one is on hold.
Applying for a flat while another one is on hold.

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

Three applications in the account, each at a different step.
Three applications in the account, each at a different step.
Three applications in the account, each at a different step.

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 first step at launch, and the first step now, with approximate payments from each bank.
The first step at launch, and the first step now, with approximate payments from each bank.
The first step at launch, and the first step now, with approximate payments from each bank.

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.

Next case3D Site Plan →