← Back to blog Published on 25th of May 2026 by Unigox Team
A year and a half ago we showed up at a hackathon in Chicago with a stack of ideas about crypto and AI, and walked out convinced we were going to fix peer-to-peer trading with zero-knowledge proofs.
Twelve months later we're shipping NeoBank-as-a-Service. This is the story of what happened in between, and what we wish someone had told us before we started.
TL;DR
- Building a neobank yourself takes roughly eighteen months and $300K+ in compliance and engineering before your first transaction settles.
- The hard part isn't writing code, it's stitching together twenty+ providers, four kinds of compliance coverage, and an App Store review cycle.
- Modern fintechs win by automating the back office, not by having more rails than anyone else.
- If you have an audience already waiting, time-to-market beats margin every time.
- We built
NeoBank-as-a-Servicefor the audience-first case: branded app on the App Store in about four weeks, on the same rails Unigox runs on.
The first idea: kill fraud in P2P with ZK-TLS #
The pitch was beautiful. Anyone who's traded on a P2P exchange knows the painful part: the seller releases crypto from escrow only after manually confirming the fiat arrived. That gap is where scams happen, where disputes pile up, and where merchants get burned.
ZK-TLS (zero-knowledge transport layer security) lets you prove cryptographically that a fiat payment landed in a bank account, without exposing the bank login or the account contents. Plug that into a P2P flow and the manual "yes I got the money" step disappears. Trustless, instant, automated. We were going to put peer-to-peer trading on rails.
Three things killed it.
ZK-TLS only works against banks with a web interface. No web banking, no proof. We started in developing markets, and the users there overwhelmingly bank from their phones. Nobody trusts the browser. We could have shipped to the US where everyone has Zelle and Cash App, but those are exactly the markets where P2P doesn't matter.
Every bank integration was bespoke. Nigeria alone has thousands of microfinance banks. Each one needs its own ZK-TLS harness. We did the math: the scaling curve is sand.
The market we were saving was already shrinking. While we were heads-down building, central banks across our target geographies were quietly legalizing crypto on/off-ramps. The big exchanges followed, and now we ourselves have a corporate bank account in Nigeria to buy and sell crypto directly. The thing that made P2P necessary, the lack of any other path, was going away.
There was a poetic twist. We built a system to protect P2P users from getting scammed, and then spent months getting pen-tested by people trying to scam us. Lost real money trying to help people not lose money. Pink glasses, as we called them later.
What we learned about the actual market #
Once we stopped defending the original idea and looked around, the bigger market was sitting right next to us: cross-border payments and branded neobanks running on stablecoin rails.
The pattern we kept seeing:
- A founder with real distribution. A community, a following, a niche audience that already trusts them.
- An obvious money-movement use case for that audience. Remittances. Tuition payments. Commodity settlement. Local-to-local FX.
- Zero appetite to spend eighteen months wiring up compliance, KYC, AML, ramps, custody, App Store reviews before serving a single user.
These people don't want to build payment infrastructure. They want to launch a branded app and start onboarding the audience they already have.
The hidden anatomy of "just integrating an API" #
Here's the part that surprised us the most, and the part that almost nobody talks about publicly.
When you say "I'm going to build a neobank," you imagine: pick a payment API, plug it in, ship an app. In reality you're looking at a checklist that runs something like:
- A legal opinion for App Store submission
- A compliance officer and a written AML program
- A regulatory license, or partnership with someone who holds one
- A KYC vendor for user onboarding
- A KYT vendor for ongoing blockchain transaction monitoring
- One or more fiat on/off-ramp partners, often different ones per corridor
- An IBAN-issuing partner for receiving and sending fiat
- A custody model (custodial or non-custodial, each with different obligations)
- Liquidity prefunding across every chain and every fiat account you operate
- A rebalancing system so you don't run out of inventory where users want to withdraw
- A back office that can review flagged transactions in hours, not days
- And then the actual app, with payments UX, error states, and customer support
Before you process your first transaction, you're already six figures into legal, compliance, and integration work. The 18-month figure isn't dramatic. It's what it took us.
The provider gauntlet #
The compliance side is hard. The vendor side is worse.
Every payment partner hides their pricing. Every conversation starts with "what's your monthly volume" because they're triaging whether you're worth talking to. Setup fees range from zero to $12,000 for premium virtual accounts. Monthly minimums hover around five thousand dollars regardless of whether you're processing anything yet, which means a startup pre-revenue is paying for capacity it can't use.
You talk to twenty providers to find out who works in your corridors. Three months pass. You finally pick one and discover their flow doesn't match yours. Some settle instantly when you deposit stablecoins. Others want you to pre-fund and manually request quotes for each top-up, with prices locked the moment you commit. Some don't operate on weekends.
We were ignored entirely by a few of the biggest providers when we were starting out. They wanted to see volume before they'd send a reply. We had nothing to show because we couldn't process anything until we'd integrated.
Should you build your own neobank? #
We're not going to pretend the answer is "everyone should use us." It isn't. Build this yourself if:
- You enjoy the process of stitching together a complex stack and have the runway to spend twelve to eighteen months on infrastructure before launch.
- You have very specific compliance requirements that don't fit anyone's off-the-shelf license.
- Or you're already at the volume where you can negotiate directly with the major providers and the savings on margin justify the build.
Don't build it yourself if you're optimizing for time-to-market and you have an audience waiting. The opportunity cost of those eighteen months is almost always larger than the cost of buying the infrastructure.
What we ended up shipping #
So we did the obvious thing. We packaged the stack we'd built for ourselves.
One abstraction higher than the API-only crowd
The companies we admire most in this space (Bridge and DvNK before their acquisitions) are API-only. Beautiful margins, clean abstraction, but you still build the app. You still wrap the compliance. You still survive Apple's review cycle. That's where the months go.
We went one abstraction higher. Tell us your brand. Pick a tier. In about four weeks, you have your own branded app on the App Store, running on the same rails we run on, with KYC and KYT and AML coverage already in place.
The three tiers
Full Bundle. We host the rails and the compliance umbrella. You launch a brand.Tech License. You have your own license. We provide the tech stack.Embed Unigox. Pure API, pay per transaction. For when you really do want only the API.
Graduation, not lock-in
If you grow past the point where our shared infrastructure makes sense, we help you migrate to your own provider deals. We'd rather have a happy customer at every stage of their life than lock anyone into a stack they've outgrown.
Who we're actually talking to #
A few customer shapes have shown up in the first few weeks:
Influencers and community leaders in Asia and Africa. Sometimes literally a famous athlete with a hundred thousand fans who can't reliably move money between countries. Their audience is the distribution. They don't have a payments team and shouldn't need one.Niche remittance. A YC-style company focused only onIndianor Filipino students paying European tuition. The corridor is specific, the compliance story is clean, the audience is well-defined.Commodity-payment operators. Oil and gas factoring where a delayed payment means thousands of dollars in warehouse penalties per day. Traditional banks queue transactions for human review for up to four days. There's a clear case for stablecoin rails plus modern back-office automation.Existing crypto wallets adding payments. Every wallet team we know is hiring a payments director right now. They've all seen that wallets are becoming neobanks, with debit cards, QR payments, fiat balances. They want to ship that without rebuilding the rails.
We have a debit card company backed by Tether already using us for payouts. We'll get them on the podcast to share their side of the story.
Why modern fintechs can run leaner #
There's a thing the new fintech wave does that the legacy banks structurally can't: automate the back office.
In a traditional bank, a flagged transaction enters a human review queue. A compliance analyst eventually opens it, checks one source about the customer, opens another tab to research the counterparty, double-checks for mistakes, makes a call. That cycle is what makes payments take three to five days.
In a well-built modern fintech, the same flag triggers a parallel pull from multiple data sources, runs through risk-scoring rules, and surfaces an AI-assisted judgment with one model checking another's reasoning. A human still signs off on the edge cases, but the routine ones clear in seconds. The seamless experience that users feel on the front end is almost entirely back-office work that nobody sees.
This is also what lets us offer better terms to early-stage clients. The reason most providers charge a five-thousand-dollar monthly minimum is that their operating cost per active customer is high. Automate the back office and that floor moves.
A note on the multi-chain trap #
If you're building this yourself, here's the engineering trap that bit us hardest: liquidity rebalancing across chains and providers. A user deposits ten thousand on Solana. Another user wants to withdraw ten thousand on Base. If everyone's depositing on the popular chain of the week and withdrawing on a different one, you run out of inventory on the withdrawal side fast. Now you need a rebalancer that moves funds across chains automatically, plays the bridge fees against the user's perception of "instant," and never lets a provider's prefunded account hit zero on a weekend when nobody answers the phone.
Multi-chain support sounds like a feature flag. It's a system.
What's next #
We're going to keep doing these episodes. Forty minutes feels right. We'll bring on customers, including the debit card team, to talk about how cards actually make money (and how cashback economics work when you're giving away ten percent). We'll go deeper on compliance, on the rebalancing system, on what we're seeing in specific corridors.
If you're somewhere in the middle of building your own neobank right now, drop us a note about what you're stuck on. Some of those will become future episodes.
And if you have an audience waiting and you'd rather skip the eighteen-month detour, that's what we built [NeoBank-as-a-Service](https://www.unigox.com/neobank-as-a-service) for.
[unigox.com/neobank-as-a-service](https://www.unigox.com/neobank-as-a-service)
Frequently asked questions #
How long does it take to launch a branded neobank with Unigox?
Roughly four weeks from contract signature to a branded app on the App Store, for the Full Bundle tier. The Tech License tier is faster on the engineering side because you're keeping your existing compliance stack, but App Store review still anchors the timeline. Compare that against the twelve-to-eighteen months a full DIY build typically takes.
What's the difference between Unigox NaaS and an API-only provider like Bridge?
API-only providers give you primitives: on-ramps, off-ramps, custody, sometimes IBANs. You still build the app, wrap the compliance, and own the App Store relationship. NeoBank-as-a-Service goes one abstraction higher. You get the branded mobile app, the compliance umbrella, and our existing licenses already in place. If you want the API-only path, that's our Embed Unigox tier.
What's included in the Full Bundle tier?
A branded mobile app on the App Store and Google Play under your account, KYC and KYT (transaction monitoring), AML coverage under our license, the same fiat corridors Unigox runs on, non-custodial wallet infrastructure, and the back-office automation that lets us settle in hours instead of days. Pricing is public on the NaaS page.
How does the graduation program work?
If you outgrow our shared infrastructure (typically once monthly volume crosses a few million dollars and you can negotiate direct provider deals at better rates than ours), we help you migrate. We provide the engineering hand-off and runbook. You keep the same users, the same brand, the same app. We'd rather you graduate happily than stay stuck on a stack you've outgrown.
Which stablecoins and chains are supported?
Multi-chain by default. You can launch on a single chain (Solana, Base, etc.) or run multi-chain from day one. USDC and USDT are both supported. The non-obvious piece is liquidity rebalancing across chains, which we handle so you don't end up with deposits on one network and withdrawal demand on another.
Who is this not for?
If you're already at the volume where you can negotiate directly with the major providers, or you have very specific compliance requirements that don't fit any off-the-shelf license, build it yourself. We go into the trade-offs in the "Should you build your own neobank?" section above.
About the authors #
Artur Schaback is the co-founder of Paxful, which grew to 12 million users and over $6 billion in settled volume. He is ACAMS-certified and has been building crypto-to-fiat infrastructure since 2015. Today he is Director at Unigox.
Aleksandr Vinogradov is Unigox's technical co-founder. He started as a P2P trader on Paxful and has spent the past decade building high-load financial systems at the intersection of Web2 and Web3.
If you're building in this space and want to compare notes, both of us read replies on LinkedIn. Written by Unigox Team