Koncierge: matching every bank deposit to the right customer in Japan

Foreign brokers can't hold local bank accounts in Japan directly. Customer deposits go through licensed local agents, and one agent account is often shared by many customers. When money lands in a shared account, the platform has to work out which customer, under which merchant, it belongs to. It has to do that under Japan's strict anti-money-laundering rules, with full customer data on record.

So the hard part was the data. The team summed up the core as the data, the data structure and the API structure, with a thin interface on top. A wrong data model would break every dashboard, settlement and withdrawal built on it. The build also had a one-month window, three kinds of users with different rights, and a launch that hung on one real merchant going live end to end.

We built the core first and the screens last.

How it went:

1. Paid discovery, June 2025: the scope was fixed and written up before any build.
2. Data model, December 2025: we checked the domain before writing any feature. Agents own bank accounts, providers manage agents and merchants, merchants serve customers.
3. API first: the pipeline from bank feed to matched deposit worked before any interface sat on top of it.
4. January to February 2026: the portals, the Cashier widget, withdrawals and the first merchant integration, then a retro and handover in February.

The client asked for daily deployments, and we shipped every day. A few small bugs were a fair price for checking daily that the developers read the business rules right. Clickable demos, first in Miro and then in a live back office, kept everyone on the same page.

We wrote and reviewed the backend by hand and used AI tools to speed up the frontend. Stories, acceptance criteria and the API reference lived in Jira and Confluence.

The Rocketech team:

• Project Manager
• Business Analyst
• Backend Developer
• Frontend Developer
• UI/UX Designer
• QA Engineer

Bank events come in through BDRS, a data layer that puts payments from Japanese banks into one format. The engine finds the agent account each payment landed in, then the customer and the merchant. It creates the transaction and tells the merchant by webhook.

It handles two kinds of accounts. An IPK virtual account belongs to one customer, so the match is direct. A shared account is matched on the account number plus the customer's payment reference. Anything that doesn't match waits for a person to assign it.

• One merchant API: merchants connect once instead of building to each provider's format.
• Incoming deposits: matched from the bank feed to the right customer, with a webhook to the merchant.
• Withdrawals: batches of up to 1,000, exported as a CSV file for the provider to process.
• Cashier widget: the merchant drops it into its own site to show deposit details and take payments.

• Provider, merchant and agent views: dashboards, transactions and settlement sign-offs for each role.
• Need-to-know access: each party sees only its own data. Merchants never see who works at the provider.
• Bank directory: search across 19,735 banks.

• Soft delete: records are never erased, so the history stays complete.
• Full customer data: customers created from a withdrawal need full details, including a name in Latin letters.
• Unmatched deposits: held until a person assigns them by hand.

The risk sat at the edges: bank data coming in and the widget going out. The first bank feed relied on a fragile webhook. We moved to a more direct, queue-based feed and moved validation upstream, so broken or unmappable payments were stopped before they reached the matching logic.

The Cashier widget was the other hard part. A signed-in iframe with styles for each merchant is fiddly, and it was on the path to launch. We gave it to one developer full-time and ran a full test from the merchant's side before handover. A real merchant then went through staging and into production with only minor issues, which we fixed.