Credit unions
Credit union software that works with the core, not around it
Three core vendors run most of the industry, and your IT team is small. Every member-facing idea becomes an integration project before it becomes a feature.
What makes this vertical different
4 things that decide this
- 01Three vendors, Symitar (Jack Henry), Fiserv DNA and Corelation Keystone, run most of the core banking systems you build against, so your new feature usually starts as an integration against someone else's API or file export.
- 02Your IT team is small relative to a bank's. A handful of people are expected to run day-to-day operations and evaluate every vendor that wants access to the core.
- 03NCUA examiners review IT general controls and vendor management every exam cycle. Your new system has to produce evidence, not only work.
- 04Your members' expectations come from banking apps built by teams a hundred times the size, and your core can't deliver that experience on its own.
The core was not built to be extended
Symitar, Fiserv DNA and Corelation Keystone were built to hold the ledger and post transactions correctly. They were not built to power a modern mobile app, a loan-origination flow, or a real-time fraud alert. Those come from software built alongside the core, reading and writing through whatever API or batch export the vendor exposes that month.
Corelation publishes an open API for Keystone, but Fiserv and Jack Henry mostly gate theirs behind partner agreements. Your own developer often can't get a key without going through the vendor first. That single fact decides how much of your roadmap your small IT team actually controls.
Every build we bring to this problem carries the same discipline. A ledger that reconciles. A payment state machine that survives a timeout. An audit trail an examiner did not have to ask for twice.
Sector context
Numbers that shape the build
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)
7
Of our builds ship a Stripe payment integration
The work we take around a core
Each of these is a capability claim sourced to a named build, not a claim of credit union delivery.
Core-adjacent integration
We read and write through the API or file export your core vendor exposes, with retry and reconciliation logic that assumes the export runs late or arrives twice.
Payment flows that survive a bad day
We derive idempotency keys from your business operation and store them before the call goes out. A retry an hour later reuses the key instead of double-posting.
Sub-ledgers that stay portable
You get balances derived rather than overwritten, corrections posted as reversals, and a structure you could hand to a new core provider if the contract ever changed.
Real-time alerting on a live pipeline
Trading CoPilot moves market data and alerts for a private UK client on a live pipeline. That's event-driven engineering under time pressure, and it transfers directly to your fraud and transaction alerting.
Document AI for lending and onboarding
PremiumAudit.io reads payroll registers, tax forms and ledgers, then reconciles figures across documents with a person deciding. The same shape covers your loan files and membership onboarding.
Evidence a small IT team can hand an examiner
We model verification as a process with states, not a boolean flag. You store the method used, what it returned, when, and who ran it, as the system runs rather than assembled by hand before an exam.
- CoreSymitar, DNA or Keystone. Owns the ledger.
- Export or APIBatch file or gated partner endpoint.
- ReconciliationCatches late, duplicate or missing records.
- Sub-ledgerYour record of what the feature actually did.
- Member featureThe app, the alert, the loan flow.
- EvidenceLogged as it happens, for the next exam.
The feature a member sees is the last box on this chart. Everything before it is integration work, and skipping the reconciliation step is how a mobile app ends up showing a balance the core disagrees with.
A small IT team cannot audit every vendor by hand
NCUA's exam programme covers vendor management as a standing item. With a handful of IT staff, you have to answer for every system that touches member data, including ones built by an outside team.
The practical fix is building the evidence into your system instead of reconstructing it later: a reconciliation job that runs daily and logs its own result, a verification step that stores the method and the outcome, not a pass or fail flag. When your core's export lands overnight, your system should already show whether that run succeeded.
- Reconcile against the core daily, and give every unmatched item an owner and an age.
- Store the instant a transaction happened and the business date separately, since a core's posting day is not a timezone conversion.
- Treat a gated core API as a dependency to design around, not a detail to discover in month two.
- Log the decision path on member onboarding, because the file is what gets examined, not the outcome alone.
Document-heavy financial work we have shipped
The usual approach against ours
The core export
The usual approach
Trusted to arrive on time and once.
How we build
Treated as late, duplicate or missing until reconciliation confirms otherwise.
Vendor access
The usual approach
Discovered to be gated after the roadmap is set.
How we build
Scoped against Symitar, DNA or Keystone's actual access model up front.
Payment state
The usual approach
Success or failure, with a timeout counted as failure.
How we build
Idempotency keys sent before the first attempt, unknown states modelled explicitly.
Audit evidence
The usual approach
Assembled by hand when the exam date is set.
How we build
Emitted as the system runs, so it exists before anyone asks for it.
Vendor count
The usual approach
One more system for a small team to manage manually.
How we build
Built so reconciliation and alerts do the day-to-day watching.
What this work runs on
Trading CoPilot
- React
- FastAPI
- Supabase
- PostgreSQL
- AWS
Payments we have shipped
- Stripe
- Stripe Connect
Standards we build to
- 31 CFR 1020.220
- PCI DSS v4.0.1
- SOC 2 controls
Questions credit union IT teams ask
01Does Symitar or Fiserv DNA let outside developers connect directly?+
Usually only through a partner agreement, not an open key. Jack Henry's Symitar and Fiserv's DNA gate their APIs behind vendor relationships, so your project often starts with getting access before it gets to build anything. Corelation's Keystone publishes an open API, which changes the timeline on that core specifically. We scope the access model before your roadmap, so the vendor conversation isn't a surprise in month two.
02How do you keep a member-facing feature in sync with the core?+
We treat your core's export or API response as unreliable rather than instant. A daily reconciliation job compares your sub-ledger against what the core reports, flags unmatched items with an owner and an age, and never edits a historical entry to fix a break. That daily discipline is what stops your mobile balance from quietly drifting away from the core's number.
03What does an NCUA exam actually expect from vendor-built software?+
Evidence, not only a working feature. Examiners review IT general controls and vendor management as a standing part of the cycle, and your outside-built system has to show its own audit trail: what happened, when, and who or what triggered it. We build that logging into your system from the first version instead of trying to reconstruct it before an exam date.
04Can AI touch anything that reads member financial documents?+
Yes, as long as you check the extraction rather than trust it. PremiumAudit.io reads payroll registers, tax forms and ledgers and reconciles the figures across documents, with a person making the final call. The same pattern applies to your loan files and onboarding packets: the model proposes a read, a person confirms it.
05How would you start with a credit union?+
We start with a scoping call, which is free, to hear the core you run and what your feature actually needs to touch. Where the honest answer requires reading your existing integration, we run a paid two-week diagnostic and hand you the findings either way. Three things drive the number: which core you're on, whether its API is open or gated, and how much of the work is reconciliation against data you don't control.
Go deeper
- Professional and financial services hub →The industry hub this page belongs to.
- Banking software development →The ledger and payment engineering underneath any core-adjacent build.
- Fintech software development →Where our payments and financial-data proof actually sits.
- API integration →Connecting to a system you do not control, built to survive its bad days.
