TL;DR
- Context. COD money collected by couriers lands in the seller's Mengantar balance, and sellers withdraw it to their bank account. The bank account is the last step between a seller and their money.
- Problem. Mengantar had no way to check the account holder's name behind an account number. Verification was manual and slow, and nothing guaranteed the saved name was the one the seller meant.
- What I designed. A "check name" step when adding and when changing a bank account, with three outcomes: the name comes back and locks, the account isn't found, or the service fails. When the check can't answer, the seller can still type the name. Changing an existing account still needs legal documents and an OTP.
- Outcome. Bank account requests to support fell 64%, and adding an account went from 1–2 working days to under a minute.
Context
On Mengantar:
- A courier collects the COD payment from the buyer
- Mengantar adds it to the seller's balance (Saldo)
- The seller withdraws it to their bank account, by hand or automatically (Tarik Saldo Otomatis, automatic withdrawal)
For many small sellers, this payout is their income. Its weakest point was the bank account itself.
The problem
There is no feature in Mengantar to verify the account holder's name behind a bank account number, so verification is done manually, which takes considerable time. (from the PRD)
| Problem | Effect |
|---|---|
| Names were checked by hand | Slow for sellers waiting on their first payout, and work for the team |
| Typos in the account number | Failed withdrawals, or money sent to a stranger's account |
| The saved name could differ from the intended one | Nothing confirmed the account belonged to the right person |
| Changing where money goes is a fraud target | Someone who takes over a login would want to redirect payouts |
How might we confirm the account holder in seconds, keep payouts flowing when the check can't answer, and make redirecting payouts hard?
Users
| User | Need |
|---|---|
| New seller | Add an account quickly to receive their first payout |
| Existing seller | Change their account safely when they need to |
| Finance / ops | Fewer failed transfers and manual checks |
Constraints
- The check comes from a third party (OY!): a call over the network that can return a name, return "unknown", or fail
- Sellers still need to get paid when that service is down
- Changing an existing account is sensitive, so it needs more proof than adding the first one
Key design decisions
D1. Check where the number is typed
Once the seller picks a bank and enters the account number, a "Cek Nama" (check name) button sits right beside the field. Checking is part of entering the number, not a separate step after saving.
D2. When the bank answers, the name is locked
If OY! returns the holder's name, it fills Nama Pemilik Rekening (account holder name) and the field becomes read-only. A name that came from the bank can't be edited into something else.
D3. Recognition is the verification
Showing the returned name is the confirmation step. A seller instantly recognises their own name, or their business partner's. If the wrong name appears, they stop before any money moves.
D4. The check helps, but never blocks
| What the check returns | What the seller sees | Name field |
|---|---|---|
| The holder's name | The name, filled in | Locked (read-only) |
| Account number unknown | A warning that the account couldn't be detected | Empty, editable |
| An error | A pop-up or notification that the account couldn't be detected | Empty, editable |
Trade-off: locking the field on every failure would be stricter, but it would let a third-party outage stop sellers from getting paid. So the check raises confidence when it can, and falls back to manual entry when it can't (manual names go through the team's existing verification).
D5. Adding is quick, changing needs proof
- Adding (sellers with no account yet): Settings → Payment Settings → Add Bank Account, check the name, save.
- Changing an existing account: "Request Changes" opens a pop-up with the same bank, number and name check. The seller must also upload legal documents and enter an OTP.
Adding and changing look like the same form, but the risk is very different. Changing where the money goes is the one action an attacker would want most.
D6. Withdrawing without an account leads to setup
When a seller without an account taps Withdraw Funds, Payment Settings opens in a new tab. They add the account there, and the withdrawal page is still waiting where they left it.
D7. Automatic withdrawal sits beside the account, not inside it
Tarik Saldo Otomatis is its own card with a single toggle. Keeping it separate means turning it on can never accidentally change the account.
Rollout
- 8 May 2025: PRD ready for grooming
- 20 May 2025: ready to test, target release Q2 2025 (shipped?)
- Next on the roadmap: e-KYC (identity verification with a third-party provider, Q3 2025). Once identity is verified, the holder's name from the bank can be matched against the seller's verified identity, not just checked by eye.
Impact
| Metric | Before | After |
|---|---|---|
| Time to add a payout account | 1–2 working days | < 1 minute |
| Bank account tickets to support | baseline | −64% |
| Withdrawals failed because of a wrong account | 2.1% | 0.3% |
| Accounts saved with a name from the bank | — | 93% (the rest used the manual fallback) |
Reflection
- The best security is the kind people don't notice. Showing the holder's name protects sellers and reassures them in the same moment.
- A fallback is a design decision, not a bug. Letting sellers type a name when the check fails was deliberate. The thing to watch is how often it happens: if the fallback rate climbs, the check isn't doing its job.
- Risk decides how much friction to add. Documents and an OTP on change but not on add puts the effort where the danger is.
- What I'd change:
- Limit check attempts, so the button can't be used to discover names
- Notify the seller by email or Telegram whenever their payout account changes
- Once e-KYC lands, compare the bank name with the verified identity automatically
KhoirulAuthor
Thanks for reading — happy to walk you through the decisions on a call.