Digital Onboarding Solutions for Banks: Build, Buy, or Configure?
An evaluation guide to digital onboarding solutions for banks — the three routes (build in-house, buy SaaS, configure a deployable product), the total cost of each, and the questions that expose the differences before you commit.
Every bank now agrees that account opening should be digital. The disagreement — and the risk — is in how to get there. Onboarding sits at an awkward intersection: it is customer-facing (so experience matters), compliance-critical (so evidence matters), operationally intense (so workflow matters), and it handles the most sensitive data a bank collects before a relationship even exists (so data residency matters).
This guide maps the three realistic routes to a digital onboarding solution, what each actually costs over five years, and the evaluation questions that expose the differences before contracts are signed. It complements our bank account opening software guide, which covers the capability checklist in depth.
First, agree on what "onboarding" must cover
Scope creep kills onboarding projects late; scope honesty saves them early. A bank-grade onboarding solution must handle:
- Every customer kind you serve — business and corporate, personal, group (chamas and savings groups), and joint accounts. If the solution was designed for one kind, ask hard questions about the others; a digital business account opening tool does not automatically generalise.
- KYC/AML capture at source — declarations, beneficial owners, and a screening process that covers every person involved, as described in KYC onboarding in banks.
- A staged back-office workflow — queues, separation of duties, SLA timers, and decisions with recorded reasons.
- Form change without projects — regulations and products change; your forms will too, quarterly at least.
- Audit-grade records — the whole journey reconstructable, years later.
With that scope on the table, the three routes look like this.
Route 1 — Build it in-house
The promise: exactly your process, your brand, your integrations, no vendor.
The reality: an onboarding platform is not one application but several — a customer portal, a form engine, a compliance module, document management, workflow, notifications, audit — and the estimates that get approved rarely include all of them. Realistic in-house builds run 18–24 months to first production for a serious scope, and the organisation then owns a permanent product: every new regulation, every form change, every framework upgrade, forever.
When it makes sense: you are a tier-1 institution with a standing product engineering organisation and onboarding is a strategic differentiator you intend to keep investing in — or your requirements are genuinely unlike anything on the market.
The question that tests it: who changes the FATCA section in year three, and what does that cost?
Route 2 — Buy SaaS
The promise: live in weeks, no infrastructure, always current.
The reality: functionally, the strong SaaS onboarding platforms are good. The friction is structural: your applicants' identity documents, ownership registers and declarations live in the vendor's multi-tenant cloud, in the vendor's jurisdiction, under the vendor's keys. For many boards, regulators and central banks — particularly across Africa, the Gulf and parts of Asia — that is somewhere between "difficult" and "no." Data-protection localisation rules, outsourcing guidelines and supervisory expectations all push the same direction: sensitive banking data inside infrastructure the institution controls.
When it makes sense: your regulator and board are comfortable, your volumes are modest, and speed beats control.
The question that tests it: ask the vendor to put in writing where the data lives, who can access it, and what happens to it if you leave.
Route 3 — Configure a deployable product
The promise: product economics with in-house data residency — the software ships as a package into infrastructure you control, and is then configured to your forms, brands and workflow.
The reality: this model has matured fast, largely because cloud marketplaces industrialised it. An Azure Managed Application, for example, deploys the vendor's full stack into your Azure subscription: the data never leaves your tenancy, while the vendor operates, updates and supports the software through controlled publisher access — no VPNs, no shared credentials. The same products typically offer an on-premises variant (Kubernetes in your datacenter) for institutions whose regulators require it.
Configuration is the load-bearing word. The difference between a good and bad experience on this route is how much of your process is configuration rather than customisation: forms your team edits in a no-code form builder, products and branches defined in an admin console, brands added as tenants — versus change requests to the vendor's delivery team.
When it makes sense: you want a product's cost profile and roadmap, your data must stay in your environment, and you want form and process changes in your own hands.
The question that tests it: ask for a live demonstration of a business user changing a published form — and what happens to applications already in flight.
How do the three routes compare on total cost?
Think in five-year totals, not year-one prices:
| Cost line | Build | SaaS | Deployable product |
|---|---|---|---|
| Up-front | Very high (18–24 months of a team) | Low | Low–moderate (deployment + configuration) |
| Recurring | Your engineering payroll | Per-seat or per-application fees that scale with success | Flat plan fee + your own infrastructure |
| Form/process changes | Your backlog, your cost | Vendor tickets or professional services | Your admin users, near zero |
| Exit | N/A (you own it) | Data export negotiation | Data already in your database |
As a public reference point on the third route: BAOS lists flat monthly plans on Azure Marketplace ($1,500–$6,000/month by tier), with Azure infrastructure billed separately on the bank's own subscription — typically $40–80/month for entry deployments. Whatever solution you evaluate, get its numbers into this table shape and extend to five years; SaaS per-application pricing in particular reorders the ranking as volumes grow.
What should be on the evaluation scorecard?
Beyond cost, six criteria separate the field:
- Account-kind coverage. All four kinds — business, personal, group, joint — enabled per your product set.
- Compliance depth. Structured declarations, derived screening populations with coverage tracking, per-person document slots, officer sign-off on the record.
- Change ownership. Who edits forms, checklists, products, branches and brands — you or the vendor? Under what controls (versioning, maker-checker, preview)?
- Operational instrumentation. Stage-level SLA timers, breach alerts, funnel analytics per form step — the numbers behind turnaround time.
- Evidence quality. Append-only audit with before-and-after values; applications rendered exactly as submitted, on the form version they were filled on.
- AI posture. Assistants that guide applicants and pre-check documents are valuable; AI that can approve, verify or submit is a governance red flag. The distinction is drawn sharply in AI in bank customer onboarding.
The shape of the decision
Most institutions land the same way once the table is honest: building is reserved for those who want to be in the software business; SaaS is constrained by where the data may live; and the deployable-product route — marketplace-deployed into the bank's own cloud, or containers in its own datacenter, configured rather than customised — captures the middle that most banks actually occupy.
That is the route BAOS — the Bank Account Opening System takes: an Azure Managed Application in your own subscription (or on-premises on Kubernetes), four account kinds, a bilingual no-code form builder, a six-stage SLA-tracked workflow, and flat, public plan pricing. Book a demo and bring your hardest evaluation question to it.
