AI ERP with agents inside the systems you run
AI phone and voice agents for real calls
LLM.coPrivate, self-hosted LLM deployments
Legal AI infrastructure for firms
AI RFP discovery and response drafting
Automatic.coBusiness process automation
CyberAttack.aiThreat detection and defense
Secure AI virtual data rooms3
Core providers running most of the industry
FIS, Fiserv, and Jack Henry
0
Core replacements we'd recommend lightly
It's a multi-year decision, not a sprint
12+ yrs
Integrating around core banking platforms
Since 2013
100%
BSA/AML logging built into the architecture
Not a report generated after the fact
The systems you build around
Six realities of building software for a bank or credit union
None of these are unique to any one institution — they're structural to the industry, and a vendor who hasn't built around them before will discover them, expensively, partway through your project, usually right after a fixed-price estimate was already agreed to.
The core banking platform
FIS, Fiserv, and Jack Henry collectively run the accounts, transactions, and general ledger for most banks and credit unions in the country. Your core is the system of record whether or not it's modern, and almost everything you build has to read from it or write to it correctly.
Digital banking channels
Online and mobile banking usually run through a core vendor's own digital banking product or a third-party layer like Q2, Alkami, or NCR — sitting on top of the core rather than replacing it. Custom work here is differentiation and workflow, not rebuilding balance and transaction display from scratch.
BSA/AML compliance tooling
The Bank Secrecy Act and anti-money-laundering requirements mean transaction monitoring, suspicious activity reporting, and currency transaction reporting aren't optional features — they're regulatory obligations with real deadlines and real examiner scrutiny attached to how well they're documented.
Member and customer onboarding
Opening an account digitally means identity verification, OFAC screening, and core account creation happening in sequence, often across three different vendors that weren't designed to hand off to each other cleanly. This is usually the first place a digital transformation project actually gets stuck.
Fraud detection and prevention
Real-time transaction monitoring, device fingerprinting, and behavioral analysis sit on top of or beside the core, usually through a dedicated fraud vendor rather than built from scratch, because fraud pattern data is the vendor's actual product and it updates faster than any in-house team could track alone.
FFIEC guidance and examiner expectations
The Federal Financial Institutions Examination Council's guidance shapes what examiners expect around IT risk management, vendor due diligence, and cybersecurity — not a specific technical spec, but a set of expectations that architecture and documentation need to be built to satisfy, and that a well-run exam treats as a conversation rather than a surprise.
Core vendor lock-in
What's realistically changeable around a core you're not replacing
Every institution running FIS, Fiserv, or Jack Henry has, at some point, wanted their core to do something it doesn't do well. The useful question isn't whether to replace it — for almost everyone, that's not on the table — it's what can actually be built around it, and how much of that is technical versus contractual.
The core's own API or file interface sets the ceiling
Some cores expose modern REST APIs for real-time integration; others still rely on nightly batch files. What's realistically buildable around your core depends entirely on which one you have, and that answer needs confirming with your specific contract and configuration, not assumed from the vendor's marketing.
The digital experience layer is genuinely yours to build
Member-facing features — a better mobile app, a custom loan application flow, a specific reporting dashboard — can be built independently of the core's own limitations, as long as the integration layer reading from and writing to the core is solid. This is where most of the real differentiation happens.
Data you can extract, you can build on
If your core exposes transaction and account data through an API or a reliable batch export, you can build analytics, personalization, or reporting on top of it without touching the core itself. If it doesn't, that extraction work becomes the first project, not an afterthought.
Switching cores is a multi-year decision, not a project line item
A core conversion touches every system that integrates with it, requires extensive data migration and reconciliation, and carries real member-facing risk during cutover. It's sometimes the right call, but it should be decided as a strategic, board-level choice — not defaulted into because a vendor's sales team made it sound routine.
Negotiate contract terms before you build around limitations
Some core limitations are contractual, not technical — a data access fee, a restricted API tier, a required use of the vendor's own digital banking product. Renegotiating those terms is sometimes cheaper than engineering around them, and it's worth checking before committing to a workaround that a contract amendment could have made unnecessary.
What it costs
Banking and credit union software development pricing
Real ranges for the engagements we actually run. The variable that sets the timeline is not the feature list — it's what your specific core actually exposes, and how much of the integration surface is a modern API versus a legacy batch file that only updates once a day.
| Engagement | Commitment | Timeline | What's included |
|---|---|---|---|
| Core integration assessment | Fixed scope | 2 – 4 weeks | Confirm what your specific core contract and configuration actually exposes — API, batch file, or both — and produce a costed integration plan against it. |
| Digital onboarding build | Fixed scope | 10 – 16 weeks | Identity verification, OFAC screening, and account creation wired together across vendors and the core, with the handoff logic that keeps an application from stalling mid-process. |
| Fraud & BSA/AML tooling integration | Fixed scope | 8 – 14 weeks | Transaction monitoring and suspicious activity reporting wired to a named fraud or compliance vendor, with the audit logging an examiner will actually ask to see. |
| Member-facing digital experience | Fixed scope | 10 – 18 weeks | Custom mobile or web banking features built on top of your core's data — loan applications, personalized dashboards, reporting — without touching the core itself. |
| Embedded engineering, ongoing | Ongoing retainer | Ongoing | A senior team inside your program who already understand core banking integration patterns and FFIEC documentation expectations, rather than learning them on your clock. |
Ranges assume US-based senior engineers and include the compliance-relevant architecture — audit logging, access control, documentation an examiner can review — as part of the build. A quote that hasn't asked which core you run, and what it actually exposes, hasn't scoped a real integration, and the number attached to it should be treated as a placeholder rather than a plan.
Compliance as architecture
BSA/AML and FFIEC guidance shape the build, not just the paperwork
Compliance in banking isn't a report generated at the end of a project. It's a set of logging, monitoring, and access-control decisions made in the architecture, because an examiner reviewing your systems will ask about the decisions, not just the outcome, and 'the vendor handled that' is rarely a satisfying answer in that conversation.
Suspicious activity reporting needs a real audit trail
A SAR filing has to be traceable back to the transaction data and the analyst decision that triggered it, retained on the schedule BSA requires. Building this logging in from the start is materially cheaper than reconstructing an audit trail after an examiner asks for one that doesn't exist.
Vendor due diligence is an FFIEC expectation, not a courtesy
Examiners expect documented due diligence on every third-party vendor with access to member data or systems — the fraud tool, the digital banking layer, the cloud host. That documentation needs to exist and be current, not assembled retroactively when an exam is scheduled.
Access control needs to match job function, not convenience
A teller and a compliance officer need different system access, and role-based permissions that reflect actual job function — not a shared admin account because it was faster to set up — are part of what an IT risk management exam reviews directly.
Data encryption and network segmentation are baseline, not advanced
Member financial data encrypted at rest and in transit, with the systems that handle it segmented from general-purpose infrastructure, is the expected baseline under FFIEC cybersecurity guidance, not a differentiator worth marketing.
Incident response has to be a runbook, not an idea
A documented incident response plan, tested rather than theoretical, is part of what examiners expect to see, and building it after an actual incident is both the wrong order of operations and a bad look during the exam that follows — the plan needs a named owner and a rehearsed sequence, not just a page in a policy binder.
Build vs. buy
Where custom development earns its place alongside your core
Core vendors sell modules for much of what a smaller institution needs, and those are a reasonable floor. The value we add sits in the gaps: the workflows that differentiate you, the integrations the modules do not cover, and the member experience your core was never going to ship. Knowing which is which before anyone writes code is the point of a scoping conversation.
Start from what your core already covers
We map your requirement against what FIS, Fiserv or Jack Henry already licenses you before proposing anything. That keeps the build scoped to what the modules genuinely do not do, which is also where the return is — nobody gets value from a custom replacement of software they are already paying for.
Build when the workflow is your competitive differentiator
A specific underwriting process, a member experience your institution has built its reputation on, or a reporting requirement unique to your regulator — these are worth custom engineering because no vendor module was built for your specific situation.
The integration layer is real work either way
Buying a module doesn't eliminate integration work — connecting it to your core, your identity verification vendor, and your existing systems is still a project. Underestimating that layer is the most common reason an 'off-the-shelf' rollout still takes longer than the sales conversation implied.
Smaller institutions get the most from targeted work
A community bank or credit union without a large in-house engineering team generally gets more value from a well-configured vendor module than from a custom build it will struggle to maintain after the vendor that built it moves on to the next project.
In practice it is almost always a mix
Most institutions buy the commodity functions from their core vendor or a specialist and build custom only where it's genuinely differentiated. The mistake is treating the decision as all-or-nothing instead of making the call feature by feature, based on what the vendor actually offers today rather than what its roadmap slide promised two years ago.
How an engagement runs
From core assessment to a system your team owns
Week one confirms exactly what your specific core contract and configuration expose — a modern API, a legacy batch file, or some combination — because that answer sets the ceiling on what's realistically buildable and shapes every estimate that follows, often changing it materially from whatever number was floated before anyone looked at the actual interface. The weeks after build the integration layer against the core alongside the compliance-relevant architecture — audit logging, access control, vendor due diligence documentation — rather than treating compliance as a separate phase at the end. Handover includes the codebase, the core integration documentation, and a written record of every compliance-relevant decision, formatted so your next exam has something concrete to point to.
Related
Related
Banking software touches regulation, integration, and security at once. These pages go deeper on each.
Questions
Frequently asked questions
What teams ask before a first call.
Digital onboarding, fraud and BSA/AML tooling integration, and a member-facing experience built on top of your core are all substantial builds, and a core integration assessment in front of any of them usually pays for itself. The table above sets out the shapes.
The integration surface sets the number, not the application. What your core vendor exposes, what it charges for access, and how long their queue is will move a schedule and a quote more than anything on your own side.
Almost never as a first move, and rarely as a solo engineering decision. A core conversion touches every system integrated with it, requires extensive data migration and reconciliation, and carries real member-facing risk during cutover — it's a multi-year, board-level decision, not a project you back into because one integration was frustrating. The institutions that go through it successfully treat it as a strategic initiative with its own governance, not an IT project with a due date.
Most of what institutions want from a 'better core' can actually be built around the existing one: a modern digital experience layer, custom reporting, better onboarding. Confirm what your current core's API or file interface actually supports before assuming a full replacement is the only path to the outcome you want.
FIS, Fiserv, and Jack Henry between them run most of the industry, and we build against whichever interface your specific contract and configuration actually expose — a modern REST API where one exists, a batch file process where that's what's available. The integration pattern differs meaningfully between the two, and the estimate reflects which one you have.
Smaller or regional core providers exist too, and the same principle applies: confirm the actual interface before scoping the work, rather than assuming a generic 'core integration' estimate applies across every vendor.
Transaction monitoring that can flag suspicious activity, a documented and auditable path from a flagged transaction to a filed suspicious activity report, and currency transaction reporting where thresholds are met — all retained on the schedule BSA requires and reviewable by an examiner on request.
This needs to be architecture, not an after-the-fact report. Logging who reviewed what, when, and what decision was made has to be built into the system from the start; reconstructing that trail after an examiner asks for it is a considerably worse position to be in than having it already documented.
Buy when the vendor's own module — digital banking, loan origination, fraud tooling — covers your actual requirement at a price your institution can absorb. For a lot of credit unions, especially smaller ones without a large in-house engineering team, that's the more sustainable long-term answer, since maintaining a custom build after launch is its own ongoing cost.
Build custom where the workflow is genuinely your competitive differentiator — a specific underwriting approach, a member experience central to your reputation, a reporting need unique to your regulator. The decision is rarely all-or-nothing; most institutions buy the commodity functions and build custom only where a vendor module doesn't fit.
Because the application logic — screens, workflows, business rules — is usually the predictable part of the estimate. What varies enormously is how the core, the identity verification vendor, and the fraud tool actually expose their data, and whether that's a modern API or a nightly file drop that introduces a full day of latency into every decision a member is waiting on.
Two institutions asking for the identical feature list can have estimates that differ by months, purely because one core exposes real-time data and the other doesn't. Confirming the integration surface in week one, before committing to a timeline, is what keeps that difference from surfacing as a missed deadline instead of a line item in the original scope.