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 credit unions build against, so a new feature usually starts as an integration against someone else's API or file export.
- 02IT teams are small relative to a bank's. A staff of a handful of people is 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. A new system has to produce evidence, not only work.
- 04Member expectations come from banking apps built by teams a hundred times the size, and the core cannot 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. Fiserv and Jack Henry mostly gate theirs behind partner agreements. A credit union's own developer often cannot get a key without going through the vendor first. That single fact decides how much of the roadmap a 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
22
Production systems shipped across fintech, real-time data and document-heavy compliance work
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
Reading and writing through the API or file export a core vendor exposes, with retry and reconciliation logic that assumes the export runs late or arrives twice.
Payment flows that survive a bad day
Idempotency keys derived from the business operation and stored before the call goes out. A retry an hour later reuses the key instead of double-posting.
Sub-ledgers that stay portable
Balances derived rather than overwritten, corrections posted as reversals, and a structure that could be handed 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 is event-driven engineering under time pressure, and it transfers directly to 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 loan files and membership onboarding.
Evidence a small IT team can hand an examiner
Verification modelled as a process with states, not a boolean flag. The method used, what it returned, when, and who ran it, stored 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. A credit union with a handful of IT staff has to answer for every system that touches member data, including ones built by an outside team.
The practical fix is building the evidence into the 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 the core's export lands overnight, the 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
| Criterion | The usual approach | How we build |
|---|---|---|
| The core export | Trusted to arrive on time and once. | Treated as late, duplicate or missing until reconciliation confirms otherwise. |
| Vendor access | Discovered to be gated after the roadmap is set. | Scoped against Symitar, DNA or Keystone's actual access model up front. |
| Payment state | Success or failure, with a timeout counted as failure. | Idempotency keys sent before the first attempt, unknown states modelled explicitly. |
| Audit evidence | Assembled by hand when the exam date is set. | Emitted as the system runs, so it exists before anyone asks for it. |
| Vendor count | One more system for a small team to manage manually. | Built so reconciliation and alerts do the day-to-day watching. |
What this work runs on
Trading CoPilot
Payments we have shipped
Standards we build to
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. A 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 the roadmap, so the vendor conversation is not a surprise in month two.
02How do you keep a member-facing feature in sync with the core?
By treating the core's export or API response as unreliable rather than instant. A daily reconciliation job compares your sub-ledger against what the core reports. It 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 a 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. An outside-built system has to show its own audit trail: what happened, when, and who or what triggered it. We build that logging into the 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, with the extraction checked rather than trusted. 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 loan files and onboarding packets: the model proposes a read, a person confirms it.
05How would you start with a credit union?
A scoping call, which is free, to hear the core you run and what the 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 are on, whether its API is open or gated, and how much of the work is reconciliation against data you do not control.
