Banking
Banking software built around the core you keep
Most of the value sits in the ledger, the payment states and the evidence trail. That is the work we take, and it is where a programme is won or lost.
A core banking platform holds the balances and answers to the regulator. What surrounds it decides whether your product works: ledgers that reconcile to the penny, payment flows that survive a timeout, onboarding that produces evidence an examiner can follow. We build that layer. Seven production builds with Stripe, real-time pipelines on Trading CoPilot, and document-heavy AI on PremiumAudit.io and IRS Escape Plan all run on the same discipline a banking programme needs.
Three worlds that cannot share one page
A chartered institution, a fintech renting a licence and a payments company face such different compliance burdens that one pitch cannot serve them honestly. The chartered buyer runs a vendor risk review and asks which banks we have worked with. Our answer there is none, and that answer usually ends it.
So the fit is narrower than the keyword suggests. To a bank or credit union we are useful as a product team beside the core. Usually that means a line of business whose internal queue is too long. The better fit is a fintech or platform, where the work is product engineering with money movement, real-time data and AI.
- 01Regulated institutions buy something that passes internal audit and the next exam.
- 02Fintechs and platforms buy something that passes the sponsor bank's diligence and reconciles to the penny.
- 03Both get senior engineers who have argued about idempotency keys in production.
Sector context
Numbers that shape the architecture
5 years
Retention for identity records after an account closes (31 CFR 1020.220)
~24 hours
How long Stripe keeps an idempotency result before pruning it (Stripe docs)
60 days
Window for an unauthorised ACH return on a personal account (Stripe docs)
7
Of our builds ship a Stripe payment integration
The work we take around a core
Each of these is a capability claim we can source to a named build, or a standard we can cite. Neither is a claim of bank delivery.
Ledgers that answer point-in-time questions
Append-only entries, balance derived rather than stored, corrections posted as reversals instead of edits, and balancing per currency. A ledger is correct because of its constraints, not because of its code.
Payment flows that survive a bad day
Idempotency keys derived from the business operation and persisted before the call. Handlers built as state machines that reject impossible transitions, because webhook delivery is out of order by design.
Real-time data pipelines
Trading CoPilot moves market data and alerts for a private UK client on a live pipeline. That is event-driven engineering under time pressure, and it transfers directly to payments and monitoring work.
Hold and release on a marketplace
WorkMateAI uses Stripe Connect to hold funds and release them on completion. Stripe documents that a transfer fails when it exceeds the available balance and is not retried automatically, so the flow has to be designed for that.
Document AI for onboarding and review
PremiumAudit.io reads payroll registers, tax forms and ledgers, then reconciles figures across documents. The same shape covers onboarding packets and diligence files, with a person deciding.
Evidence that survives an exam
Verification modelled as a process with states and evidence, not a boolean flag. Store the method used, what it returned, when, and who ran it. Examiners ask how, not whether.
- CorePosts in a nightly batch
- CutoffRead-only window, memo balances
- Sub-ledgerWho owns which share
- ReconcileDaily, breaks owned and aged
- EvidencePoint-in-time, reproducible
Legacy cores post overnight, so today's balance is a memo balance until it clears. A real-time product on a batch core ends up building its own ledger plus reconciliation, which means you build the thing the core was supposed to be. Deciding that deliberately is cheaper than arriving at it in month six.
Succeeded does not always mean the money is yours
On a card payment, success is close to final. On bank debits it is provisional. Stripe documents a dispute window of 60 calendar days for personal accounts and two business days for business accounts. It describes both as final, with no appeal process.
So a product that treats a bank debit as settled at day three is carrying two months of unhedged exposure per transaction. The fix is not clever. Make provisioning rail-aware, so what you release on a card is not what you release on ACH. Stripe also warns that with separate charges and transfers it does not automatically reverse a transfer when an async payment later fails. Your balance gets debited and you reverse it yourself.
- A balance you update is not a ledger. If it is a column you overwrite, you cannot say what it was at 2pm on 3 March.
- Stripe prunes idempotency keys after about 24 hours, so a retry a day later is a new charge.
- Store money as integer minor units and carry the currency. An integer with no currency is not money.
- Store the instant and the business date separately. A payment's banking day is not a timezone conversion.
Systems where money and records have to agree
Trading CoPilot
Real-time AI trading alerts and execution companion for forex traders.
Read the case study →
WorkMateAI
Dispute resolution, payments, and compliance for Australia's on-demand trades.
Read the case study →
PremiumAudit.io
AI automation for smarter insurance premium audits.
Read the case study →
“I am extremely happy with the results and would highly recommend Hashlogics to anyone.”
Daniel Khin · CEO, PremiumAudit.io
The usual approach against ours
| Criterion | The usual approach | How we build |
|---|---|---|
| The core | Treated as something to work around, or replace. | Treated as the system of record. We design co-existence against how batch cores actually behave. |
| The sub-ledger | Balances derived from whatever the processor last said. | Double-entry, append-only, reconciled daily and portable enough to hand to a bank tomorrow. |
| Payment state | Success or failure, with a timeout counted as failure. | An unknown state is modelled explicitly, with idempotency keys sent before the first attempt. |
| Onboarding | Collect the identity fields and move on. | Capture the evidence and the decision path, because the file is what gets examined later. |
| Audit evidence | Assembled by hand when the date is set. | Emitted as the system runs, so the evidence exists before anyone asks for it. |
| Vendor risk | Assumed to sit with the sponsor bank. | Reconciliation you can see, and a sub-ledger that stays yours if a programme ends. |
What this work runs on
Trading CoPilot
Payments we have shipped
Standards we build to
Questions banks and fintechs ask
01You have no bank clients. Why would we hire you?
For work beside the core rather than inside it, and only where our capability proof actually matches. The 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 are the wrong call, and we will say so on it. Vendors who answer this question with a case study they cannot name are the ones worth worrying about.
02Does using Stripe put us outside PCI scope?
Only for the right integration type, and the rules got broader in 2025. Your scope is 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 is not vulnerable to script attacks. One analytics tag on the checkout page can change that position.
03What does customer identification actually require in the build?
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 onboarding is a process with states rather than one gate. Keep identifying information for five years after the account closes. Descriptions of how you verified run for five years after the record is made. That clock is why a deletion request must never sweep up identity records.
04How do you stop a customer being double charged?
Derive an 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 no protection at all. Do not lean on the processor alone for this. Stripe documents that keys can be pruned after about 24 hours, and that 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.
05Our balances disagree with the bank statement. Where does that come from?
Usually from a mutable balance column and a reconciliation that runs too rarely. Fees netted from payouts, refunds landing in a different period, events processed out of order and timezone-shifted cutoffs all produce breaks. Reconcile daily and automatically. Give every unmatched item an owner and an age. Never repair a break by editing a historical entry, because a correcting entry preserves what happened. Finding a break thirty days late means debugging thirty days of transactions.
06How would you start with us?
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. You get one number at the end of it, not a spread. Three things drive that number. Which rails you touch and how final they are. Whether a sponsor bank or core vendor gates the timeline, since that is procurement rather than engineering. And whether your ledger already exists or has to be built underneath what you have.
