Frequently Asked Questions
Do we need a financial licence to launch?
It depends on the product and jurisdiction. Payment facilitation, money transmission and banking products have specific licence requirements in most jurisdictions. Many early-stage FinTech products launch under a BaaS provider's licence (Unit, Railsbank, Stripe Treasury) or as a non-custodial payment facilitator that does not require a money transmitter licence. We map the regulatory requirements for your specific product and geography in the first engagement week and recommend the appropriate structure.
What is the difference between a PSP, a bank and a payment gateway?
A payment gateway handles transaction transmission and authorisation — the technical layer between the merchant and the acquirer. A PSP (payment service provider) combines gateway, merchant account and settlement in one product. A bank (or BaaS-backed neobank) holds deposits, issues accounts and can originate ACH and wire transfers. The architecture you need depends on whether you are facilitating payments for third parties, holding user funds, or providing accounts. These have different regulatory requirements.
How do you implement KYC and AML?
KYC implementation: document upload + liveness check via a managed provider (Synaps, Onfido, Jumio), results stored in your identity database, onboarding gated on KYC pass. AML implementation: transaction monitoring rules (velocity, amount thresholds, geographic patterns) plus continuous sanctions screening against OFAC, UN and EU watchlists. Suspicious activity triggers a human review queue and potentially a SAR filing. The exact requirements depend on jurisdiction and product type.
Do we need to build a core banking ledger?
Most early-stage FinTech products should not build a custom core banking ledger. BaaS providers (Unit, Synapse) provide ledgering as part of their offering. The right time to build in-house is when BaaS constraints are limiting product features, the per-transaction cost at scale is prohibitive, or specific accounting requirements (multi-currency, custom waterfall logic) cannot be expressed in the BaaS model. We design a migration path from BaaS to in-house ledger when the business case is proven.
How do we support multiple currencies?
Multi-currency requires: a ledger designed with currency as a first-class entity on every balance and transaction record, FX conversion logic with rate sourcing and spread management, settlement in each currency or conversion strategy, multi-currency reconciliation and tax reporting considerations per jurisdiction. The architectural decision is whether to settle in a single base currency (simpler accounting, FX risk at conversion) or maintain balances in each currency (more complex, no conversion risk until payout).
How do you detect fraud at early stage when you have no data?
Early-stage fraud detection relies on rule-based systems while you accumulate the transaction data needed for ML models. Start with: velocity rules (5+ transactions in 10 minutes), device fingerprinting, IP geolocation checks, card BIN validation and known bad actor list screening. Integrate a managed fraud provider (Sardine, Sift) for their industry-wide signals. As your transaction volume grows past 50,000/month, your own ML fraud model becomes viable. The architecture must support this evolution without a rebuild.
What does PCI DSS compliance require?
PCI DSS compliance scope depends on how you handle card data. If you tokenise at point of entry using a managed provider (Stripe, Adyen) and never store raw card data, your PCI scope is SAQ A — the lightest tier. If you process raw card data, you face SAQ D or a full QSA assessment. Architecture decisions — tokenisation strategy, network segmentation, cardholder data environment boundary — determine PCI scope. Scope minimisation is an engineering goal, not a compliance afterthought.
How do you approach open banking and API integration?
Open banking integrations (Plaid, TrueLayer, Tink, direct PSD2 APIs) provide read access to account data and initiation of payments from user bank accounts. Implementation requires: OAuth2 connection flow for user authorisation, webhook handling for account updates, normalisation layer across different bank API formats, token refresh management and error handling for the high rate of open banking API failures. We design open banking integrations as first-class infrastructure, not a third-party API call.
How does reconciliation work for a FinTech product?
Reconciliation is the process of proving that every transaction in your ledger matches a real movement of money confirmed by the payment provider. It runs at settlement: compare your internal transaction records against the provider's settlement file, flag mismatches, investigate discrepancies and resolve any unmatched transactions. At early stage this can run daily. As volume grows, real-time reconciliation with automated discrepancy alerting is required. A FinTech product without automated reconciliation will have undetected errors.
How long does a FinTech product take to build?
A production payment product with KYC, ledger, fraud detection and compliance reporting takes 16-28 weeks from architecture to go-live. BaaS-backed products launch faster (10-16 weeks) because the banking infrastructure is abstracted. Products requiring custom card issuing or money transmission licensing take longer due to the compliance review cycles. We deliver in milestone-based sprints with staging environment demos at each stage.
