What happens when you want to build on Griffin
A look at customer solution design—account structures, flow of funds, and how to sequence an embedded banking build the right way.
Most fintechs that come to us have done some research. They have a rough sense of what they want to build, they've read our docs, gone through our use cases, explored the sandbox, and spoken with a regulator (or consultant). What they're less clear on is what happens between that first conversation and actual go-live. This blog is for them.
The first conversation isn't a sales call
When someone reaches out to Griffin, the conversation rarely starts where they'd expect it to. They come in saying "we want to offer savings" or sometimes "we want to launch a card programme." Our first response to these is always the same: tell us about your business.
We start by understanding what you do, who your customers are, how you make money, and what you're trying to give your customers that they can't get elsewhere. That conversation, before we talk about products at all, usually surfaces things neither side had fully thought through.
And there's a good reason we do it this way. The decisions you make at the start—your account structure, how money moves through your platform or product, how you separate your money from your customers' money—are the hardest to reverse later. We'd rather go back to first principles early, when it costs nothing to get it right.
Understanding your product is the foundation
One of the most important things to understand about building a financial product is that nothing exists in isolation.
Want to launch a card? You need an account to spend from. To open an account, you need KYC. To do KYC, you need a bank that understands your customer base. Every piece depends on the one before it. The decisions you make about account structure affects what kind of KYC you need. The KYC you run affects what kinds of customers you can onboard. The customers you can onboard affect what your product can be.
This is why that first conversation matters. For example, when a founder asks to launch a business account product, we want to make sure we've both thought through the whole chain of requirements. A business account product for example will typically involve an account structure, a ledger, reporting requirements, KYC and onboarding configuration—among many other things. Getting any one of these wrong can mean months of rework.
Our process is consultative, we've done this multiple times and we can figure out your requirements and the need for partners (if any) in a single conversation. But, that advantage only materialises if we've properly understood your use case first.
Yuval and Greg discuss designing customer solutions
The starting point
Once we understand your business, we start to think about which Griffin product is most relevant. At the moment, these tend to fall into one of these three areas:
Regulated activities. If you're an electronic money institution (EMI) or authorised payment institution, you need to safeguard customer funds. If you're operating under CASS, you need client money accounts. These are regulatory requirements, not product choices, and we can help you meet them efficiently—without the typical delays of approaching a traditional bank. Most customers here will either use our Safeguarding or Client Money accounts.
Retention activities. If you want to embed a banking product to drive retention, savings accounts are often the right place to start. It's lower risk to operate, requires less compliance infrastructure to stand up, and gives you something tangible to put in front of customers while you build out more complex layers. FSCS-protected savings accounts, offered under Griffin's banking licence, can often go live way faster than many founders expect.
Operations activities. Our Embedded bank account product which also happens to be our most used product firmly operates here. An account owned by your end customer—business or individual—that can receive and hold funds, make and receive payments, and integrate with other parts of your product via API. The versatility is the point. What it does depends entirely on how you build on it. This product can be used as a wallet, a payment account for a card product, an operational account to move money between products or even a collections account for tenant rent payments.
Most of our customers start with one activity and expand into others over time. The first conversation typically reveals which one to start with.
Your flow of funds is the most important document you'll produce
At some point in almost every conversation with a prospect, we end up with a flow of funds diagram that shows how money moves through the product. This needs to answer four questions: how does money enter, what can customers do with it once it's there, how do you keep your money separate from your customers' money, and how does money leave? This article by Integrated finance explains how to design a great flow of funds.
When your flow of funds document is done well, the conversation moves very quickly to "how do we get this live?" The quality of a flow of funds tells us a lot about where a founder is in their thinking. Not because it needs to be technically perfect, but because drawing it out forces answers to questions that are impossible to avoid in a live product.
A few things in a typical Griffin use case that we've seen some flow of funds documents miss:
Failure paths. What happens when a payment fails? Where does the money sit while it can't move forward? A diagram that only shows the happy path tells us you've not thought about where and how things could go wrong.
Collections/Fee sweeps. Where does your revenue come from, and when does it separate from your customer's money? This moment has to be explicit. Money that sits in a client account a moment longer than it needs to is a compliance finding waiting to be written up.
Book (Griffin-to-Griffin) transfers. If your product involves moving money between Griffin accounts, internal transfers are faster and cheaper than external payment rails. Most founders don't know to ask about this until we mention it—and it can materially change the unit economics of their models.
We work through the flow of funds collaboratively, often across multiple sessions so that the final output shows a clear understanding of exactly how the product will operate.
Sequencing your build matters more than you think
One of the most common patterns we see is a founder who knows exactly where they want to end up but isn't sure how to get there in the right order. They want savings, and embedded accounts, and card issuing, and maybe lending down the line.
All of it is achievable. But you have to manage your build with the right go-live expectations.
Cards, for example, take longer to set up than most founders expect. You need a card processor, a BIN sponsor, a card scheme agreement, and time for all of those onboarding processes to run. That doesn't mean you shouldn't build a card product. It means you probably want to start with integrating an embedded bank account first. It gets something live. It generates real transaction data. It starts building the compliance and operational muscle your business needs before you add the more complex products on top.
Part of what we do is help you think through this sequencing. Not as consultants who are going to charge you for the advice, but as a bank that has worked with enough fintechs to know where the sequencing goes wrong and what the consequences look like. We'll share what we know. The decisions are yours to make.
What changes once you go live
The conversation doesn't end at go-live. For most customers, that's where the relationship becomes most valuable. The best outcome is a customer who's so comfortable with the platform and so clear on what they can do that they barely need us. When weekly calls become quarterly calls, that's a sign the product is working and the integration is stable. We know what they're building. They know how to build on us.
Underneath that, there's ongoing work that never stops. Transaction monitoring, AML checks, assurance reviews, and product marketing reviews don't pause once you're live—and we're actively involved in making sure your product continues to operate within the boundaries we've agreed together.
But we're also the first call when things change. Businesses pivot—in fintech, often significantly. The compliance and operational infrastructure you've already put in place can usually flex to accommodate a new direction, but only if someone helps you see how. We'd rather be involved in that conversation early than find out about the pivot after the fact.
What to think about before you reach out
If you're considering working with Griffin, here are the questions worth having answers to before your first conversation. You don't need perfect answers. But the further along you are, the more useful the conversation will be.
What are you building, and for whom? Consumer or business? New product or existing product with a financial layer? What's the core thing you're offering your customers?
What's your regulatory status? Are you regulated, applying for regulation, or planning to operate under a partner's licence? This affects which products are relevant and what the timeline looks like.
How does money move through your product? Even a rough sketch is better than nothing. Where does it come from, what happens to it while it's with you, where does it go, and how do you separate your money from your customers'?
What's your phase one? If you could only launch one thing, what would it be? The answer to this question often determines everything else.
Try it first
If you want to understand what Griffin can do before speaking to anyone, our sandbox is free, requires no NDA, and gives you access to the API. You can open accounts, move money, and test the mechanics of your product without a contract or a sales call.
When you're ready to talk, we're here.