Escrow Accounts: one product, two interfaces

Context

An escrow account protects a buyer’s money when they buy a flat in a new building or a house from a contractor. The bank holds the funds until the developer completes the home, and only then releases them

At Sber the same product lives in two places:

• Customers open and manage escrow accounts themselves in the mobile app: opening, additional agreements, refunds and changing the refund account
• Bank staff handle everything else in SBOL.pro, the bank’s internal branch system on tablet and web, usually with the customer sitting in front of them: opening, top-up, assignment of rights, closing, statements and more

Staff have a double job. They need to know the next system step, and they need to explain to the customer what is happening and what the customer has to do. So the staff interface is also a script for a conversation

Problem

I joined Escrow in November 2025 and became its design owner in December. There was no handover. Design files were scattered and out of date, some design work had been done by business analysts, and teams relied on Confluence pages to know how the product behaved

Every change started with reconstructing what already existed. At the same time the product had to move to a new design system, and several regulatory changes were in the queue

The question was how to keep shipping while making the product understandable again, for me and for everyone working on it

Constraints

• Regulation. Escrow is governed by federal law. Closing an account works differently depending on the law the deal falls under (Federal Law No. 214-FZ or Federal Law No. 186-FZ), on whether a representative acts for the customer, and on whether state maternity capital was used
• Two platforms, two design systems. One business logic has to behave correctly in a mobile app and in an internal system on tablet and web
• Shared ownership. Some entry points and screens belong to other teams, so part of the work was agreeing where our control ends
• Missing components. The design system had no patterns for some complex registry and account views

The bank’s internal staff system is fully under NDA, so only customer app screens are shown here

Rebuilding the source of truth

Before changing anything, I restructured the product files around real journeys instead of separate screens: entry point, steps, confirmation, statuses, error and edge states, operation history. Each flow got notes for business and for engineering inside the file

For the registries (accounts, contracts, documents) I built a frontend reference showing how similar lists and cards differ: names, attributes, visual states. Engineering got one place to compare patterns, and I could maintain them as a system

The files became a working tool for other teams. Business, engineering and QA now comment directly on the flows and find process logic there, so part of the cross-team questions get resolved without waiting for me

Migration as a redesign, not a reskin

Moving to the new design system was a chance to fix the product, not just repaint it. For each process I reviewed states, validations, copy and tablet and web layouts. Additional Agreement, for example, existed in the business logic but had never been properly designed. I rebuilt it end to end and added an SMS telling the customer when a new agreement is ready to sign, once the product could send one

Where the design system had no fitting pattern, I designed custom widgets using an atomic structure so they could be reused. After review, one of them was added to the shared component library

1. 1Entry point

   Changing the contract terms starts from the account page

   
2. 2New terms from the developer

   The customer checks what the developer changed. From here they can continue, report a mistake or decline

   
3. orReport a mistake

   Mark the wrong details or leave a comment. An empty report is blocked with a clear message

   
4. orDecline the changes

   A reason is required: the empty field turns into an error

   
5. 3Sign

   The new terms once more, with consent and a link to the agreement itself

   
6. 4Done

   Documents are one tap away

   
7. 5Status in history

   Every request keeps its status in the operation history: changed, declined, or agreement ready to sign at a branch

   

‹›

×

Key decisions

Opening: a way forward instead of a dead end

When a customer’s profile data didn’t match the contract, opening simply stopped. The employee had nothing to offer except asking the customer to come back

Any version of the recovery path needed work on the contract factory, the system where contracts are stored, so it was not a quick fix. Together with the business analyst I initiated releasing this branch of the process as part of the design system migration instead of leaving it for later

Refund: calculating the amount for the employee

Together with a business analyst I started a refund calculator. The interface now shows the maximum refundable amount, lets the employee refund everything in one action, and validates the amount against the contract’s restrictions, so the employee doesn’t have to work it out by hand

Top-up: fixing logic, not just the screen

The top-up flow had incorrect logic. I reworked it so the employee first chooses cash or transfer, with a hand-off to the relevant banking product

Closing with maternity capital: turning law into speech

An escrow account can be opened using state maternity capital. When the account closes, only the bank can return that money to the state fund, and it needs the customer’s consent to process personal data. Without consent, the customer can’t get the capital back later

I added a separate consent step to closing and wrote the direct speech the employee reads to the customer: why consent is needed and what happens without it. For representatives the wording is impersonal but keeps the main point

The hard part wasn’t the screen. It was putting a complicated legal requirement into a few sentences an employee can say out loud and a customer can understand

Tax residency on two platforms

A new regulatory requirement made a tax residency step mandatory when opening an escrow account. It had to work in both the staff system and the customer app

I owned where the step sits in each flow, how it behaves, its states, its copy and the final UI, and took it through review with the designer responsible for design system consistency. The change went through a full development cycle in about two months

• Staff system: live on 6 April 2026
• Customer app: live on 30 April 2026

Explaining tax residency in plain words

On both platforms the hardest part was the text: how to explain to a customer what tax residency is and why the bank asks for it. I solved it differently for each context

The opening flow in the customer app

Here is how opening looks in the app with the new step in place, from checking the conditions to the success screen

1. 1Check the conditions

   The customer reviews the contract terms. If something is wrong, they can report it instead of getting stuck

   
2. 2Refund account

   Where the money goes if the deal falls through. Only perpetual accounts qualify, or an account in another bank

   
3. 3Tax residency

   The new mandatory step. A one-sentence subtitle explains it; Russia is prefilled, other countries come from a searchable list

   
4. 4Confirm

   Every term, the refund account and tax residency in one place before signing

   
5. 5Done

   The account opens shortly. The signed documents are one tap away

   

‹›

×

Edge and validation states

If the conditions don’t match the contract, the customer isn’t left at a dead end. It’s the same idea as the recovery path in the staff system, applied to the customer app

1. 1Report a mistake

   The customer marks which contract details are wrong or leaves a comment. The developer fixes them and the bank sends the conditions again

   
2. 2Validation

   An empty report can’t be sent: the message says exactly what to do

   

‹›

×

Outcome

Adding a mandatory step to opening risked more people dropping out. Comparing customer app data for April 2026 (before the step went live) and August 2026, more customers reached a successful opening, and the success audience grew faster than the audience that saw the opening conditions

The backend team fixed status handling during the same period, so this isn’t a clean A/B result. What it shows is that the new mandatory step didn’t hurt completion

Beyond the numbers:

• Every change described here is in production in the app or the staff system
• The product files became the shared reference for business, engineering and QA
• A widget I designed for Escrow is now part of the shared design system library

What’s next

The staff system is about five years old and carries UX and process debt. I’m running a research programme on it: product analytics and clickstream first, then contextual inquiry in branches, then moderated usability tests measuring completion, errors, time on task and ease (SEQ). The findings will decide what we fix first