Card, lending and ledger systems and AI agents, for banks, card issuers and lenders

Own your core. Own your AI. Compound your edge.

Banks rented their cores because building one was slow and risky. AI has made software quick to write. It has not made it easy to trust. Trust comes from knowing what must be true about the money, and checking those rules on every change. Our team has built and run core systems for two decades, in earlier roles. We build in your environment and hand over the source code, controls and tests. Your team can run and change the system after our work ends. What you learn next goes into a system you own.

Book an architecture review

A 30-minute call with a founder about one system or one job. If building is not right for you, we will say so.

Try a core demo: lose a response

Three ways to start

01 · Core + AIA new core, with its AI.
For a launch or a rebuild where agents will run named jobs from the start. We build the system around your rules, with its agents, permission checks, approvals and tests.
See Engines and Harness
02 · Core onlyA new core, on its own.
For changing a card, lending or ledger system now, and deciding on agents later. We build the system and its tests.
See Engines and Why own it
03 · AI on your coreAI on the core you run.
For keeping your current core and cutting the investigation work between systems. We check what it can support, then build agents for the jobs you choose.
See Eight checks and One job

In all threeYou keep the source · your team runs it · we can stay on for support

Software enforces your money rules.Authorizations, interest and ledger entries run as ordinary code. No AI agent sits inside them.Engines → Your team sets the limits.We build the permission checks, approval steps and tests around them. That software is the harness.Harness → Agents do the work between systems.They gather records, investigate differences and prepare corrections. Your systems confirm the result.What changes → You keep the source.You receive the source for everything we deliver, including the engines and the harness. No Xenomi fee per transaction.Why own it →

AI-first core systems

Card, lending and ledger systems.

We build the systems that run your cards, loans and ledger. That is what we mean by core, whether you rent yours or run it yourself. An AI-first core starts from one rule: the model is the part you trust least.

A bank already knows how to work with someone it cannot fully vouch for. It gives them a name, a limit and a supervisor, and keeps its own record of what they did. We build the core to treat a model the same way. Your rules set what an agent may read, send and change. The harness enforces them from outside the model. The engines refuse an entry that breaks the money. Your systems keep the record, your team can stop an agent and take over, and tests run on every change.

You can rent the model. You own the rules.

Every box opens. Select one.

Your core · in your infrastructure and your repository

Cards

Lending

Shared by cards and lending

Engines · what must be true about the money

What you run: people, agents, systems, rules and recordsWhat keeps it right: harness, engines and testsWhat the core connects toLit: what the selected box runs onBar: systems that run on the selected engine

Engines

What must be true about the money.

Each engine holds what we know about one part of a money system: the rules it must never break, and tests for the failures that break them. There are four: transaction processing, loan lifecycle, accounting, and security. We build these rules and tests into your system, alongside your product rules and integrations. Try one case in each.

Engine · cards

Transaction processing

Card network messaging, authorization, reversal and clearing. Every financial event carries one lasting reference, so a repeated request does not create a second hold and a late reversal finds the right transaction.

Try it: lose a response

A small working model that runs in your browser, on sample data. It shows the rule we build to. It is not a client’s system.

With one lasting reference

5,000.00available · 0 holds

Without it: matching on amount

5,000.00available · 0 holds

The rule, in four lines

Every request carries a reference.
A reference seen before gets its first answer again.
A reversal releases only the hold with its reference.
A reversal with no matching hold changes nothing.

Read the model

This is the code running above. It leaves out storage, restarts, timers and two messages arriving at once. A real engine has to keep the rule through all of them.

Amounts in USDBoth sides run the same checks

Engine · lending

Loan lifecycle

What must be true before money moves, and the states a loan passes through after it does. Each requirement is a recorded fact with its source, its date and how long it stays valid. Your credit policy makes each decision and stays yours.

Try it: supply the facts in any order

Scripted example with sample data. Timings and outcomes are illustrative.

blocked

Engine · cards and lending

Accounting

The accounting software records ledger entries and calculates interest, fees, statements and payment allocation. Any balance can be traced back to its entries, and an entry can be previewed before it is made.

Try it: correct a payment’s effective date

Scripted example with sample data. Timings and outcomes are illustrative.

The payment’s effective date is the 12th Example: 2,500.00 paid, posted on the 17th and due on the 14th. Simple daily interest at 24% APR on a 365-day year, with a 35.00 late fee already charged. A payment effective by the due date reverses that fee. Amounts in USD.

Engine · every system

Security and cyber defense

Who may do what, for every person, service and agent, and keys that stay in your hardware security module. We build agents to investigate alerts and take permitted protective actions. Unresolved cases go to your security team.

Try it: an attack, contained

Scripted example with sample data. Timings and outcomes are illustrative.

Action taken

What happens next

What a defense agent may do

On its own

Narrow, timed blocks and holds

Needs your team

Reissuing a card, reversing a posting

Never

Touching a key, switching off a control

Amounts in USDEvery action above is logged

Harness

Bank controls, applied to agents.

A bank already limits what each person may do, who must approve it and what gets recorded. The harness is the software we build to hold AI agents to the same rules: permitted actions, limits, approvals, a case history, and tests before any change goes live.

Five parts. Select one. Each links to an example on this page

While we build
A senior engineer reviews every change.

We build with AI coding agents. A senior engineer reviews their changes, and the agreed tests run before release.
In production
Your team sets the rules. The controls enforce them.

Your agents, and agents your customers bring, go through the agent gateway, which is part of the harness. It checks permissions, asks for approvals and records each action. The model underneath can change without changing any of that.
After handover
Your team keeps the same tests.

Your engineers change the system and run the tests we built it with. They receive the tests and the instructions for building, running and changing the software.

You receive the system together with the controls and tests it was built with.

Their agent. Your agent. Your rules.

Your rules apply to every agent request.

Your team sets the permissions and approval limits. We build an agent gateway: software that checks each request before your system carries it out and records the result. The same checks apply to your own agents and to agents your customers bring.

Agent gateway permitted

Scripted example with sample data. Timings and outcomes are illustrative.

Amounts in USDFor existing systems, we first assess the connections and controls needed

Permissions are stored records.

Who an agent acts for, for what purpose, up to what limit and until when. They are checked on every request and can be withdrawn in one place.
Consent comes from the customer.

You capture it, with its purpose and its date. An agent can carry a request for consent. It cannot give the answer.
Every action is logged.

What was asked, the action taken, what was checked and what the system recorded. Your auditors read the same log your engineers do.

Each agent request is checked against its permissions and your approval rules before it runs.

Tests

Test the change and check the result.

We build tests for normal work, known failures, requests agents must refuse and actions that need approval. Your team receives the tests and their results to help review later changes.

1
For your systems.
Scenarios taken from real operations: the duplicate request, the reversal that arrives late, the settlement file that never arrives. Each one states what must be true about the money afterward.
2
For your agents.
Each agent is tested on the jobs it has to do, the requests it must refuse and the approvals it must wait for. What an agent must refuse gets as much care as what it must do.
3
For finished jobs.
A job that reports success is checked against the records: the mismatch closed without a cause, the decision made on stale evidence, the job interrupted after its posting had already succeeded.
4
For what you already run.
We also run tests against systems and agents we did not build, so you can see where you stand before you change anything.

Test run release held

Scripted example with sample data. Timings and outcomes are illustrative.

What changed

Every run is kept for your risk team, auditors and examiners

What changes

Less manual work between systems.

We build agents to gather records, investigate differences and prepare corrections. Your team sets what they may do and when they need approval. Unresolved cases reach your team with the evidence collected so far.

Automated
Moving information between systems.

Copying a reference from one screen to another. Re-keying what a customer already said. Typing in what a credit bureau already holds. Agents can do this work.
Agents investigate
Working out why something is off.

Why a total differs. Whether an alert is real. Agents check likely causes and prepare corrections supported by the evidence. What they cannot settle goes to your team.
Stays
Approvals and waiting.

An adjustment must be permitted, and your rules set when a person must approve it. Funds wait for the settlement bank. These stay, and the system records that each one happened.

Approvals, new kinds of problems and policy changes stay with your team.

One authorization

Scripted example with sample data. Timings and outcomes are illustrative.

Beforeagents work here

Insideno agent in this path

Afteragents work here

Amounts in USD0100 request · 0110 response

One job, start to finish

Investigate a settlement mismatch.

A settlement total differs from the ledger. The agent checks the files, looks for a supported cause and prepares a correction. It carries out a permitted correction, asks for approval when required, or leaves the case open when the evidence is insufficient.

What the job has established

Terms in this job: purchase recordpostingpreview

Illustrative workflow

running

Scripted example with sample data. Timings and outcomes are illustrative.

Amounts in USDClosed only when the ledger agrees

Is this job worth an agent?

Check the simpler fix first. If better matching rules would clear most of these cases, fix the rules. An agent is for what is left: cases where someone has to look across systems and work out a cause.

Then use your own numbers. Your core stays, so the agent cannot pay for itself out of vendor fees. It has to earn its place in analyst time and in older cases cleared.

One kind of case, your numbers Example values. Move them to yours.

Cases of this kind each month 1,200 Count every eligible case, not only the easy ones.

Analyst time on each case 25 min Hands-on time: finding records, working out the cause, getting approval. Not the days spent waiting on a settlement bank.

Cases the agent finishes or fully prepares Start with an estimate. Check it on past cases, then during supervised work.

Analyst time left on each of those cases 5 min Include review, approval and correction. Other cases are assumed to take today’s time, with no added work from failed attempts.

Set against it

Build and integrationone-time

Model useper case

Hosting, support and upkeepongoing

Vendor feesunchanged

Capacity, not a budget savingWaiting on a settlement bank does not get shorter

We agree with you on how to measure correct resolutions and reopened cases. A high closure rate on its own can hide bad decisions.

The core underneath

Can your existing system support the work?

We look at what your system lets other software do, what records it gives back, and what happens when a request fails or is sent twice. Then we agree with you on which jobs agents can handle and what changes are needed.

Check the core you run

Example answers are shown. Clear them, then check what your own core does today. Each line left open is something to look into.

Eight checks for the job you want to automateA starting point for discussion, not a diagnosis

Areas to investigate

Book an architecture review

Bring this list. We’ll use it to discuss your priorities.

Why own it

Built once. Yours to keep.

Rent a system, and the fee usually grows as you grow. We build you one for a fee agreed before we start. When we finish, your engineers take it over. You still pay for your own servers, AI model use, outside services and the people who run the system. Maintenance and support from Xenomi after handover are optional.

Three ways to get a core system By kind of supplier, not by name

Question	Rent a platform	License a platform’s source	Commission a build what we do
What you get	Use of a running product.	A finished product’s code, to run yourself.	A system built to an agreed scope, around your rules.
What you can change	What the vendor exposes: settings, and on some platforms your own product logic. The platform stays theirs.	What your license allows. Any vendor update you adopt needs checking against your changes.	The delivered system, under the agreed terms.
Who keeps it running	The vendor or your team, depending on the service.	Your team, with vendor support if you buy it.	Your team, or the firm under a support agreement.
To start, you pay	A setup fee. Often a contract for several years.	A license fee, one-time or annual, and the work to install and adapt it.	A fixed price, time spent, or payment by milestone. A change in scope costs extra.
Each year, you pay	A subscription, or fees per account, card or transaction. Often with a minimum.	The license fee again, if it is annual. Maintenance for fixes and upgrades, usually a share of the license fee. Plus your own team and hosting.	Your own team and hosting. A maintenance contract with the firm, if you want one.
As you grow	The total rises with volume, though the price per unit often falls in steps.	Depends on the license. Where it is not tied to volume, each transaction can cost less as you grow.	Usually nothing more to the firm. Each transaction can cost less as you grow, if your running costs rise more slowly than your volume.
To leave	Often a termination fee, and a fee to hand your data back.	With a one-time license, the code keeps running, but without maintenance you lose fixes and upgrades. With an annual license, your right to use it can end when you stop paying.	Nothing, if you hold the code and your team can run it.
Choose it when	The platform and the changes it allows meet your needs.	Its existing features fit, and you want to run and adapt the code.	You need a system built around your own rules, by a firm that has built one before.

A general comparisonYour contract and your numbers decide

We are the third kind: a firm you commission.

Here are four things to ask any such firm, with our answers.

Have you built this kind of system before?: Yes. Our team built and ran card, lending and ledger systems for two decades, in earlier roles. It is all we work on. Ask us where, on a call.
What do we pay you?: A build fee for an agreed scope. After handover, a maintenance contract with us is optional. Nothing is tied to your volume.
Who runs it when you step back?: Your team. Before we go, one of your engineers who did not write the code makes a change we agree on, runs the tests and releases it.
What if we stop working together?: Nothing changes. The system is already yours, and your team or another firm can carry on.

Put what you learn into the systems you own.

You have spent years learning who to lend to, how to price risk and when to step in. That know-how is becoming lending rules, agent workflows and AI that serves your customers. When the system is yours, your team can act on what it learns. For example, a mismatch that keeps coming back can show a rule is wrong. Your team changes the rule, a test checks the fix, and the better rule and its test stay with you.

Know-how

Who to lend to
How to price risk
When to step in

Software

Lending rules
Agent workflows
AI that serves your customers

Keep it in your environment.

We work in your environment. We do not copy your code or records into Xenomi’s systems. Your team chooses the AI model, and approves any data sent to an outside model service it chooses.

Add the next product yourself.

With the source and the tests in your repository, your engineers can add a product, a rule or a new system, and test it before release, on the same ledger as everything else. Your team can change the underlying source code as well as the product rules.

Illustrative cost comparison In multiples of what you pay in rent today

Your volume grows by 30% a year In this example, vendor fees are charged per transaction, account or loan.

Building and migrating costs 2.5× a year’s rent The build fee, first-year setup and the cost of running the new system during the move.

Running it yourself costs 0.40× a year Infrastructure, model use and the people who run and maintain the system.

This example assumes vendor fees rise with volume, you keep paying rent through year one while you build and migrate, and your running costs grow at one-quarter of volume growth from year two. It leaves out a support contract, and fees that are the same on both paths.

Estimated costs cross in 3.2 years

Keep renting Build and own

Show the numbers

Illustrative costs, excluding supportWe can discuss which costs a fuller comparison needs

What you pay, and what you get.

A build fee for the agreed scope. No Xenomi fee per transaction. No Xenomi license that grows with volume.

You still budget for infrastructure, model use, card network fees, third-party services and the people who run and maintain the system. We compare those costs with what you pay to rent, using your volumes and your plans.

What you pay

Build feeagreed scope

Fee per transactionnone

License that grows with volumenone

Maintenance and support after handoveroptional, paid

What you get

Source for the software Xenomi supplies, in your repositoryincluded

Engines and harness, to keep and change without usincluded

Tests, documentation and trainingincluded

What happens if things change

Scripted example with sample data. Timings and outcomes are illustrative.

With Xenomi

Ask any vendor

Your contract sets the exact terms

How we work

Start with one system or one job.

Your team works alongside ours from the start. The code, the knowledge and the ability to keep building all come with the system.

We build it with you

01
Blueprint
Choose one system or one recurring job, such as one kind of settlement mismatch or dispute. Review your current systems, compare building with renting, and agree on the scope, the cost, the timeline and how a correct result will be measured.
02
Build
Build the agreed software and tests in your repository, around your rules and integrations. Deploy on your infrastructure, with your team involved throughout.
03
Test and connect
Run the tests on normal operations, duplicate requests and recovery from failures. Complete the integrations and the certification work the system requires.
04
Launch
Your team runs the system in its own environment. We work alongside your engineers through launch, help with problems and train your team. Before we step back, one of your engineers who did not write the code makes a change we agree on, runs the tests and releases it.

You take it from there

05
Take it over
Your team takes over with the source code, the tests, documentation and operating procedures, and runs and changes the system from then on.
You can retain Xenomi for maintenance and support, with our engineers working in your codebase inside your environment. A separate support contract sets the covered work and response times.

The first thing you approve is a Blueprint.

A Blueprint is a short written study. It tells you what to build first and what it will take, and it helps you decide whether to go ahead with the build.

You keep the findings, proposed scope and next steps, whether or not you continue with us.

What a Blueprint gives you

See a sample page

Sample for one job: settlement mismatches on a rented card processor. The data is made up.

Gap	What we saw	What it blocks	Fix
The same request can post twice	The adjustment interface took a repeated request and made two entries.	Any correction an agent carries out	Make a repeated request return the first result without posting again
An entry cannot be tried first	An adjustment can be made, but not previewed.	Checking a correction before it posts	Add a preview that changes nothing
Balances are a day old	The reporting copy refreshes overnight.	Cases that depend on today’s position	Get a current balance through an approved interface, or leave these cases out

Recommendation: start a pilot in which the agent investigates duplicate purchase records and an analyst reviews each case. Hold automated corrections until repeated requests are safe and entries can be previewed, and both are tested. Leave out cases that need a current balance until one is available.

A decision document, not a working systemYours to keep

Agents start with small limits.

We test agents on past cases, observe their work and require approval before allowing specific actions within agreed limits.

We agree with you on the results an agent must meet before it gets more permission.

Our experience

Two decades of building and running these systems.

In earlier roles, our team built and ran card, lending and payment systems, including transaction processing, reconciliation and card network certification.

We do not publish employer or client names on this page. Ask us on the call, and we will tell you where our team has worked and what it built.

Secured and unsecured lending
Credit cards
Transaction processing
Reconciliation
Card network certification
Authentication and tokenization

Bring us one system or one job.

In a 30-minute call with a founder, we’ll discuss the work, your current systems and a sensible next step.

Book an architecture review

If building is not right for you, we will say so.

Own your core. Own your AI. Compound your edge.

Card, lending and ledger systems.

Cards

Lending

Shared by cards and lending

Engines · what must be true about the money

What must be true about the money.

Transaction processing

With one lasting reference

Without it: matching on amount

Loan lifecycle

Accounting

Security and cyber defense

Action taken

What happens next

Bank controls, applied to agents.

A senior engineer reviews every change.

Your team sets the rules. The controls enforce them.

Your team keeps the same tests.

Your rules apply to every agent request.

Permissions are stored records.

Consent comes from the customer.

Every action is logged.

Test the change and check the result.

For your systems.

For your agents.

For finished jobs.

For what you already run.

Less manual work between systems.

Moving information between systems.

Working out why something is off.

Approvals and waiting.

Investigate a settlement mismatch.

What the job has established

Is this job worth an agent?

Can your existing system support the work?

Built once. Yours to keep.

We are the third kind: a firm you commission.

Put what you learn into the systems you own.

Know-how

Software

Keep it in your environment.

Add the next product yourself.

What you pay, and what you get.

With Xenomi

Ask any vendor

Start with one system or one job.

Blueprint

Build

Test and connect

Launch

Take it over

The first thing you approve is a Blueprint.

Agents start with small limits.

Two decades of building and running these systems.

Bring us one system or one job.