Katsu Wallet Infrastructure

Katsu wallet was being built as infrastructure other businesses could use to issue and manage payment accounts for their own customers. Building a wallet wasn't the hard part.

Making one piece of infrastructure work for businesses with almost nothing else in common was. An ecommerce marketplace, a logistics company, a commodity trading platform and a fintech product can all need a wallet, and still share none of the same users, workflows, compliance obligations or appetite for risk.

A fixed wallet experience would have forced all four into one shape, built for an average business that didn't exist.

So the real question was what had to stay standard, and what had to stay configurable.

I interviewed teams from Sabi Market, Loft, Trace and Katsu Pay, four businesses already running on the platform. A teammate and I mapped the interviews into an affinity map to find where they actually agreed.

• One wallet configuration wasn't enough: every business had real, different requirements a single setup couldn't cover.
• Risk couldn't be one-size-fits-all: businesses wanted their own KYC rules and transaction limits, not ones imposed on them.
• Integration had to be self-serve: technical teams wanted to go from API keys to a working wallet without a Katsu engineer on the call.

That's what shifted the question, from how do we design a wallet, to how do we make wallet infrastructure configurable enough for genuinely different businesses without making it hard to use.

We set three focus areas: DIY integration, so a business could set up wallet services without deep technical knowledge; account management, so they could manage, approve and track every account and transaction from one back office; and configuration, so they could set their own requirements and risk-based limits.

I ran a workshop with the team to turn those three jobs into concrete MVP stories, then checked them against engineering's technical constraints before committing to any of it:

• Integration: enable the wallet service.
• Wallet Profile: a full list of every payment account created.
• Transactions: a detailed list of every transaction.
• Authorization: approve or reject payment account creation requests.
• Configuration: customize account creation requirements and set transaction limits.

We designed the workspace around the two questions a business actually asks: what's happening across every wallet we've issued, and what happened with one specific customer.

From the main workspace, a business could see and manage every wallet it had issued in one place, before it ever had to open an individual account.

From the wallet list, a business could open any single customer's account directly: account information, bank details, balance, transaction volume and value, without switching tools or asking Katsu's team for a manual export.

That's one level. The other is the gap between "what did this customer do" and "where is our money," two different questions a business asks about the same platform. So we built for both: a customer's own transaction history inside their profile, and a wallet-wide ledger covering every account the business has issued.

Katsu had two audiences: the business teams managing wallets, and the technical teams integrating the platform into their own product.

We kept that second workflow inside the platform too. Configuration is also where a business's engineers pick up their live API keys, client ID and secret, with the documentation linked right next to them, so integration doesn't depend on a Katsu engineer for routine setup.

Not every business needed the same level of verification or the same transaction limits, so I designed a tiering system each one could configure for itself.

• KYC requirements step up by tier: Tier 1 needs identity basics, Tier 2 adds address verification, and Tier 3 adds a liveness check and proof of identity.
• Defaults can be extended, not just toggled: any tier can add a requirement of its own on top of the system default.
• Limits are set independently: daily, per transaction, weekly and monthly limits, a daily withdrawal frequency, and a rate limit each have their own default, their own reset, and inline validation the moment a business sets one above what the tier allows.

The pilot ran across four businesses, each with its own configuration and risk requirements.

100% of pilot businesses adopted the platform

50% faster integrations for the teams wiring Katsu into their own products

30% lower setup time, from first API key to a working wallet

Four businesses, four different approaches to risk and configuration. That's the clearest argument yet that this had to flex rather than ship as a template.

• Fit beats a fixed template. Every pilot business had a different risk appetite. The win wasn't the wallet. It was giving each one a setup it could actually trust.
• Interviews get you started, not finished. The research moved us off a fixed wallet model, but we're watching real usage in Mixpanel to keep refining configuration, since actual behavior surfaces needs interviews don't.
• Infrastructure is still an experience. Businesses don't meet a platform through its architecture. They meet it through a dashboard, a set of API keys and a configuration screen, and those decide whether the architecture underneath ever gets used well.