The neobank ledger is not a database. It is an immutable record of financial truth — and every entry must be correct forever.
Traditional banks failed on user experience. Neobanks are winning on it. But the user experience is built on top of a financial infrastructure that must be correct to the penny, available 99.99% of the time, compliant with regulations across every market you operate in, and auditable for years after every transaction. The core ledger, the payment rail integration, the reconciliation system and the compliance infrastructure are not backend details — they are the product. A neobank with a beautiful mobile app and a broken ledger will lose customer funds and regulatory licences. PROPELOO builds neobanking infrastructure where the ledger is correct, the payments are reliable, and the compliance is built in.
Frequently Asked Questions
Do we need a banking licence to build a neobank?
In most jurisdictions, holding customer funds requires a licence. Options: partner with a licensed institution (BaaS model — Railsr, Unit, Synapse act as the regulated entity), obtain an E-Money Institution licence (EU/UK — 6-18 months, enables payment accounts but not deposit-taking), or obtain a full banking licence (1-3 years, enables loans and deposit insurance). Most neobanks start with a BaaS partner to validate product-market fit, then obtain their own licence as volume justifies the cost.
What is event sourcing and why use it for a ledger?
Event sourcing stores every state change as an immutable event rather than updating state in place. For a ledger: instead of "update balance = $500," you store "credit $100 at timestamp T, debit $50 at timestamp T+1, credit $450 at timestamp T+2." The balance is derived from replaying events. Benefits: complete audit trail (required by regulators), ability to rebuild any past state, reconciliation from first principles, and error correction via compensating entries rather than data mutation. The tradeoff is query complexity for current state — typically solved with a read model that materialises current balances.
What is PSD2 and does it affect our platform?
PSD2 (Payment Services Directive 2) is EU regulation that requires banks to provide API access to account information and payment initiation for licensed third parties (Open Banking). If you are a licensed payment institution operating in the EU, you are required to maintain an API that third-party providers can use to initiate payments from customer accounts (with consent) and access account information. PSD2 compliance requires a dedicated developer portal, production sandbox, and API that meets the RTS (Regulatory Technical Standards) specifications.
How do you handle multi-currency accounts?
Multi-currency requires currency-specific ledger accounts (one account per currency per customer), FX conversion engine with rate source (Reuters, ECB, proprietary spread), settlement in the correct currency via appropriate rail (SEPA for EUR, ACH for USD, SWIFT for others), and currency risk management if you are taking FX risk between customer transaction and settlement. FX spread revenue model requires regulatory approval as a financial product in most jurisdictions.
What does AML transaction monitoring require technically?
AML transaction monitoring requires: a rule engine that evaluates every transaction against configurable rules (structuring detection — multiple transactions just below reporting threshold, velocity rules, geographic risk scoring), case management system for flagged transactions, workflow for analyst review and disposition, SAR (Suspicious Activity Report) filing infrastructure, and audit trail that shows every rule evaluation. Commercial platforms (Unit21, ComplyAdvantage) provide this. Building internally requires ongoing regulatory updates as FATF guidance evolves.
