Banking software built around the core you keep

For work beside the core rather than inside it, and only where our capability proof actually matches. Our honest pitch is product engineering with money movement, real-time data and document AI, which we can source to named builds. Need someone who has migrated a core or passed a bank's vendor risk review? We're the wrong call, and we'll say so on it. Vendors who answer this question with a case study they can't name are the ones worth worrying about.

Only for the right integration type, and the rules got broader in 2025. Your scope gets decided by how you embed the payment form, not by which processor you picked. A hosted redirect or iframe keeps you in the lightest questionnaire, while direct-post and JavaScript SDK integrations push you up a tier. Since the January 2025 version took effect on 31 March 2025, qualifying for the lightest questionnaire also means attesting that your site isn't vulnerable to script attacks. One analytics tag on your checkout page can change that position.

You need four data elements before you open an account: name, date of birth for an individual, a street address, and an identification number such as a taxpayer ID. Verification itself may happen within a reasonable time after opening, which is why your onboarding is a process with states rather than one gate. Keep identifying information and the record of how you verified it for five years after the account closes. That clock is why a deletion request must never sweep up identity records.

Derive your idempotency key from the business operation and save it before the call goes out, so a retry reuses it. Generating the key inside the retry loop is the classic bug and gives you no protection at all. Don't lean on the processor alone either. Stripe documents that keys get pruned after about 24 hours, and a key reused after pruning generates a new request. If your system can replay an operation a day later, you need your own table keyed on the operation.

Usually from a mutable balance column and a reconciliation that runs too rarely. Fees netted from payouts, refunds landing in a different period, and timezone-shifted cutoffs all produce breaks. Reconcile daily and automatically, and give every unmatched item an owner and an age. Never repair a break by editing a historical entry. A correcting entry preserves what happened, and if you find a break thirty days late, you're debugging thirty days of transactions.

We start with a scoping call, which is free, and where we mostly listen for whether this is a fit at all. Where the honest answer needs us inside your codebase, we run a paid two-week diagnostic and give you one number at the end of it, not a spread. Three things drive that number: which rails you touch, whether a sponsor bank or core vendor gates your timeline, and whether your ledger already exists.