The system-of-record mocks — a walkthrough
63 of 63 sections walked · 50 screenshots · 0 gaps. Regenerate with
pnpm walkthrough:build.
What this is. A stateful mock of the core systems three credit unions run on, and a walk through what it does. Applications read from it and write to it exactly as they would read from and write to the real systems, against those vendors' own published specifications — but it answers in milliseconds, on a laptop, with no vendor environment to book and no vendor to wait for. Stripe ships the same thing for its own API, and for the same reason: a team building against it can get on with building.
Stateful is the word that matters. A conventional mock returns a canned answer, so the second call knows nothing about the first. This one remembers. Create a loan application and it is there when you ask for it; decide it and it reads as decided; book it and the account number the lending system minted is the one you get back. That is what lets a team rehearse a real customer journey rather than a sequence of disconnected replies.
What the walk shows. One loan followed from end to end through the systems that own it — created as an application, read back, found on the feed, noted, decided, booked as a real loan account, and finally the account number written back onto the application. The journey is explained once, and then walked three times, once for each credit union.
Who it is for. The system integrators planning this work, and the people they report to. It exists so the end state can be seen and agreed before it is built: which system owns which fact, what a loan actually touches on its way from application to booked account, and the single place where the three credit unions diverge. Read it to plan; then, if you want, send the same calls yourself — everything here is a request you can make in twenty minutes, and none of it needs the code.
What it is for, beyond reading. This document is the human-in-the-loop input to Alvera's agentic platform. The agents build against what is written and approved here, so a sentence corrected on this page is a correction to what gets built — and a section nobody has walked is marked as such rather than left to look finished. It is a plan the machines read too.
What it is not. Not how the mock is built — its design, its API surface and how to run and prove it are README.md, beside this file. Not the desk and not the Alvera platform: nothing here goes near either. And not a substitute for the vendors' own documentation — where a call is strange, this guide says which vendor made it strange, not how to fix it.
Every call in this guide has been sent. The values in chapters 4, 5 and 6 are what came back from a database that had just been created, and every screenshot is the client that sent them. Where a screenshot has not been taken yet the page says so, in place of the picture.
Where this page lives. At mss-demo.alvera.ai, once the demonstrator is published. Until then the copy in the project is the only one, and any preview link you have been sent is a draft under review rather than the page itself.
Before you start
Read this once. These are the words the rest of the guide is built out of, the shape of the three systems, and how every section is laid out. Nothing here is the mock's vocabulary — it is the lending industry's and the vendors', which is why it is worth learning once.
The words
| Word | What it means here |
|---|---|
| System of record | The vendor system that owns a fact. The application is owned by the origination system; the loan account is owned by the lending system. Nothing is true because some other database says so, which is why the account number has to be written back at the end rather than just remembered |
| Origination system | Where a loan application lives while it is being decided. Temenos Originations, for all three credit unions |
| Lending system | Where the loan account lives once it is booked. Fiserv DNA at Greylock; Temenos Transact Lending at the other two. This is the only place the three credit unions differ |
| Application | The loan request while it is being decided. The origination system mints its identifier on creation, and that identifier is what every later call names it by |
| Member | The person borrowing. Fiserv's word for one is a party, and DNA mints a PersonNum for it — see the glossary |
| Loan account | What booking mints: the real account the money moves through. Fiserv DNA calls its number an AcctId; Temenos Transact calls its number an accountReference |
| The mock | One service standing in for all three vendor systems at once, and remembering everything sent to it. Ask for something back and you get what was put there, not a canned answer |
| One address, three systems | All three vendor systems answer on one address, told apart by the first part of the path. Everything after that is the vendor's own, unchanged — which is what lets the same request reach a vendor's own environment by changing the address and the credentials, and nothing else |
| Adding a credit union | A data change and nothing more — one row saying which vendor identifiers belong to the new lender, applied as a migration. No code is written, no request changes, and nothing is redeployed |
| Adding a vendor system | Development. A fourth core, or an origination system none of the three run today, is new work: its paths, its envelopes and its own idea of a customer all have to be built. This is the line worth knowing when the fourth credit union arrives — which side of it they fall on decides the cost |
| The vendor's own name for a call | How this guide names calls, so anything here can be found in the vendor's own documentation. Temenos names them — Application_GetObject, getLoanBalances. Fiserv does not, so a Fiserv call is named by where it sits in Fiserv's own collection — Party Service · 1.1 Add Party |
| Environment | The base URL and the credentials your REST client sends, held apart from the requests. Switching from the mock to a vendor sandbox is a change of environment and nothing else: not a path, not a body, not a header, not an assertion |
| A setter and a getter | The order every folder is in. One request writes, the next one reads back what it wrote. Nothing is pre-loaded, so a read can only be returning what a write earlier in the same run put there — which is the whole difference between state and shape |
A member's loan, start to finish
This is what the guide walks, and it is the journey a Member Support Services credit union already runs today. Five of the six stages are identical at all three credit unions — the same system, the same calls, the same answers. One stage differs, and it is the one where the loan account is actually opened.
No credit union appears in any of those paths. Each vendor separates its customers with a field it already carries, and the mock reads that same field:
| System of record | The credit union comes from | Where it travels |
|---|---|---|
| Fiserv DNA | EFXHeader.OrganizationId | a header, on every single call |
| Temenos Originations | the ApiKey presented at POST /login | a body field, then the session token it returns |
| Temenos Transact Lending | companyId | a header, on every single call |
The three credit unions
Member Support Services serves these three. They are real credit unions, and the guide uses their real names throughout — nothing here is a stand-in for someone else.
| Credit union | Where an application lives | Where the loan account is opened |
|---|---|---|
| Greylock Federal Credit Union | Temenos Originations | Fiserv DNA |
| United Teletech Financial | Temenos Originations | Temenos Transact Lending |
| Credit Union of New Jersey | Temenos Originations | Temenos Transact Lending |
One column differs, and that difference is the whole reason this guide walks the journey three times rather than once. Everything to the left of it is identical: the same request, the same body, the same response shape, for all three.
How to read a section
| Getting there | the call, and the vendor's own name for it |
| What you are looking at | what the call is for, in plain terms |
| What comes back | what the response says, and what it proves |
Chapter 1 — Where the collections come from
A collection is a set of ready-made requests: the calls a system will accept, saved in a file so anyone can send them and see what comes back. Vendors publish them so their customers can try the system before building anything against it.
Nothing in this guide was written to make the mock look good, and that is the whole argument. Fiserv's requests are Fiserv's own file, downloaded from Fiserv and run without a single edit. Temenos publishes written specifications rather than a ready-made file, so those requests were built from the specifications. A request that came from the vendor, and works against the mock, is a request that will work against the vendor.
1.1 The Fiserv collection, from Developer Studio
Fiserv publishes the requests for its lending system on its own developer site, developer.fiserv.com → Banking Hub → Resources. The line that matters reads "Download API Sample Collection (Postman) for DNA Core". An account, a download, and the file is on your machine: 106 requests, covering members, accounts, the relationships between them, and notes.
Two things were changed in that file, and they are both addresses. One says where the system is; the other says where to get a credential. Nothing else was touched — not a request, not a field, not a check.
That restraint is deliberate, and it is the strongest evidence in this document. Running the vendor's own file, unedited, against our mock, and getting the vendor's own answers back, is what makes the claim credible. It is not our test of our own work; it is Fiserv's test, and the mock passes it.
96 requests, 48 checks, no failures — against a database created moments earlier with nothing in it.
1.2 The Temenos requests, from the published interface specifications
Temenos publishes differently, and the difference matters.
What it publishes is a specification — a written definition of every call, every field that goes in, and everything that comes back. Temenos Originations defines 319 calls; Temenos Transact Lending defines 33. The definitions are exact and they are downloadable, but they are not something you can press Send on.
There is a Postman collection for Temenos Core Banking, and it is worth being precise about what it is: a link that copies the collection into a Postman account. It is not a file, it cannot be downloaded, it does not cover Originations, and it needs a Postman account to open at all. So there was nothing of Temenos's to run unedited the way there was for Fiserv.
A loan needs a small number of these calls. Thirteen from Originations and four from Transact Lending were built from the published definitions, and those are the ones this guide walks.
This is weaker evidence than Fiserv's, and it is worth saying so plainly. These requests came from us, not from Temenos. What makes them trustworthy is that every one was written from the vendor's own definition and nothing in them was invented — the page below is that definition for the call that ends the journey, and the field the loan account number is written into is on it. When a Temenos environment becomes available, the same requests are pointed at it and the claim is settled either way.
The catalogue, on developer.temenos.com:
And the definition of a single call — the one that writes the loan account number back onto the application, at the very end of the journey. The bearer token, the path, and the AccountNumber field are all Temenos's own:
1.3 The three Bruno collections, one per credit union
Three sets of requests, one for each credit union, and each one tells a single member's loan from the day they ask to the day the money moves.
They are held in Bruno, a free and open tool for sending requests of this kind. The files sit with the project rather than in someone's account, so anyone joining the work has them immediately — nothing to buy, nothing to sign up for, nothing to upload.
Each set is five folders, and the folders are the five stages of the loan. The vendor is not a folder and never appears as one. It shows up once, inside the stage where the loan account is opened, because that is the only stage where the three credit unions differ at all.
| Requests | |
|---|---|
| Greylock Federal Credit Union | 21 |
| United Teletech Financial | 18 |
| Credit Union of New Jersey | 18 |
57 requests, 57 checks, no failures, in about four seconds, from an empty database.
Greylock's, opened up. Read the left-hand column top to bottom and it is the loan: the credit union is named, a member applies, an officer reviews and notes it, the officer approves it, the loan account opens, and the money moves. Stage 4 is the only one that would look different at another credit union.
Chapter 2 — Setting up
Two things and nothing else: the mock running, and a client pointed at it. Both take a few minutes and neither needs a vendor, an account or a network.
Get the second one right and no request in this guide ever has to be touched again — including the day they are pointed at a vendor's own system instead of the mock.
2.1 Bring the mock up
One command. It creates the database, applies the changes that give it its shape, and starts answering on the laptop at localhost:4010.
pnpm devNothing leaves the machine. There is no vendor account, no network call to anyone, and no environment to book.
And almost nothing is loaded into it, deliberately. It starts holding one small set of records that Fiserv's own collection expects to find, and nothing else — no demo members, no sample loans. That matters for everything that follows: every value read anywhere in this guide was put there by a request made earlier in the same run. A read cannot be returning something that was sitting there already, because nothing was.
2.2 Open the collections
Bruno is a free, open tool for sending requests of this kind. It is what every screenshot in this guide shows, though nothing here depends on it.
There is nothing to import. The three collections are files that live with the project, so pointing Bruno at the folder is the whole of it — no upload, no account, no export from someone else's machine, and no copy that can quietly fall behind the original.
2.3 Point the environment at the mock
Each collection carries two environments and the name says which is which: mock is the copy on the laptop, sandbox is the vendor's own.
Read that list, because it is short and it is the argument:
- One address.
http://localhost:4010, and the three lines under it are built from it. Point that one line somewhere else and every request follows. - This credit union's own identifiers —
999950001andmss-greylockfor Greylock. These are not invented for the mock; they are the fields Fiserv and Temenos already use to tell their customers apart. No credit union appears in any address, here or anywhere else in the guide. - The credentials read
local-mock-no-secret, and that is not laziness. The mock accepts any credential, because what decides whose data a call can see is the credit union's own field, not the password. In the sandbox environment every credential is read from the machine it runs on, so no real one is ever written down.
Switching from the mock to the vendor is changing this one selection. Not a path, not a request body, not a header, not a single check. That is the rule the mock exists to keep, and it is the reason work done against it is not thrown away later.
Chapter 3 — The journey, once
One loan, explained once, with no credit union in it. Every call below is here because the vendors' APIs make it necessary, and each one is worth a heading because it decides something or proves something. The calls that do neither are named in passing and never again: Fiserv's OAuth2 token call, which says nothing about who is calling; and the read-backs after a decision is committed, which repeat reads you have already met.
This chapter is the why. Chapters 4, 5 and 6 are this same journey three times over with real values in it, and they point back here rather than explaining anything twice.
3.1 Authenticating — the credential that is the credit union, and the one that is not
Nobody signs in. Both systems are talked to by another machine, and the credential is presented once at the start of a run and never thought about again. What is worth a heading is that the two vendors mean different things by it.
Temenos Originations: the credential is the credit union. A key and a secret go in and a session token comes back. That key is the only thing in the whole conversation that says which lender is being talked about — present Greylock's key and every call afterwards is in Greylock's book of business. There is no lender in any address, no lender in any request, and no way to ask for a different one.
Fiserv: the credential is not the credit union. A single credential returns a token that says nothing at all about who is calling. So Fiserv carries the lender separately, in a header that rides on every single call. Drop the header and the call is refused.
That difference is not a detail, it is the shape of the thing. It is why adding a credit union is a row of data rather than a piece of work: whichever way the vendor spells it, the lender is a value the system already carries, so a new lender is a new value.
3.2 Create the application
One call carries everything the application is: the product, the amount asked for, the term, the rate, the officer it is assigned to, and the member asking. It goes in as one request.
What comes back is an identifier — the number the credit union's staff will say out loud for the rest of this loan's life. It is minted from that credit union's own counter, so two credit unions running side by side never collide and neither can guess at the other's numbering.
Nothing has been decided. The application exists and it is waiting.
3.3 Read it back
A separate call, on a separate connection, asking only for the identifier that was just minted.
The amount, the term and the member's name come back exactly as they were sent, and the application reads not yet decided.
This is the whole point of the exercise. A mock that only knew the right shape would answer this with a perfectly plausible application — right fields, right types, wrong loan. This one answers with the application, because it kept it. Every read in this guide is here for that reason, and it is why each stage is a pair: something is written, and then it is read back by a different call.
3.4 Find it on the feed
A date range goes in and a list comes back, and the application created a moment ago is in it.
This is the call that matters most to anyone planning the integration, because it is how work arrives. Nothing pushes; the platform asks what has changed and finds the new application waiting, the same way it will against the real system.
Nothing is seeded anywhere in this guide, so the list holds exactly what this run put there and nothing else.
3.5 Note it, and read the note back
An officer types a note against the application — the sort of line that gets written a hundred times a day, "title and insurance received, ready for decision" — and a second call reads the notes back. The one just written is among them.
Two calls, because the proof is the pair. One call proves the note was accepted. Only the second proves it was kept.
3.6 Write the verdict
The officer's decision is recorded: approve or decline, the amount approved, the term, and the name of the person who decided it. That last part is what makes it a record rather than a state change — a decision in a lending system belongs to a named human being.
Nothing on the application moves. Read it now and it still says not yet decided. The verdict has been written down; it has not been acted on.
3.7 Commit the decision
A second call commits it — and this is the call that surprises people, so it is worth being plain about.
Its request carries no verdict. Not the decision, not the amount, not the officer. One field, about whether to push past warnings, and that is all. The outcome comes from the verdict written in the previous stage, and the application picks it up from there.
Commit with no verdict recorded and it is refused.
Deciding therefore takes two calls, and it takes two calls because the vendor takes two calls. A mock that folded them into one would be easier to use and would be teaching you something false — and the day the same requests were pointed at the real system, the integration would break exactly here.
3.8 Book the loan account — the fork
This is the one stage where the three credit unions differ, and it is the only one. Everything before it and everything after it is the same system, the same calls, the same requests, whichever credit union is being served.
Whichever lending system it is, the same thing happens: a loan account is opened for the approved amount, at the approved rate, for the approved term, tied back to the application it came from, and an account number is minted.
What differs is what the account is opened against. One vendor books an account against a member, so the member has to exist there first and this walk gains a stage the others do not have. The other books against the application's own reference and needs nothing beforehand.
And in both, booking twice with the same reference returns the account already booked. There is no second loan, no duplicate to reconcile. That is worth knowing before anyone designs a retry.
3.9 Read the loan account back
The account number just minted is read back, and out comes the loan as the credit union's staff will see it: the principal, the rate, the term, the balances, when the next payment falls due.
Same proof as reading the application back, now on the other side of the fork. Something was written into a second system, and a different call found it there.
3.10 Write the account number back onto the application
Two calls close the loop. The origination system is told the money moved, and the account number the lending system just minted is written onto the application.
This is the one call that ties the two systems together, and it is worth pausing on, because in most credit unions today it is a person. Someone reads the account number off one screen and types it into another. Here the platform does it, and the reason it can is that both systems were talked to through the same journey — the account number never left the machine.
3.11 Read it funded
The application is read one final time.
It carries the account number. It reads funded. Its status has moved to closed-and-booked. One application, decided once by a named officer, now pointing at one real loan account in another system — and nothing between the two was rekeyed by anybody.
That is the journey. Chapters 4, 5 and 6 are this same journey three times over, with real values in it.
Chapter 4 — Walk one · Greylock FCU
Greylock originates on Temenos Originations and books on Fiserv DNA — the only one of the three that crosses vendors, and the reason the fork exists at all. Twenty-one calls, in the order they happen. Two values make them Greylock's and nothing else does: the Originations
ApiKeymss-greylock, and the FiservEFXHeader.OrganizationId999950001. Because DNA books an account against a party rather than against an application, this walk has one stage the other two do not: the member is added on DNA first.
4.1 Authenticating as Greylock
Getting there. 1 · A member applies → 01 the key that names the credit union.
An API key and a secret go in. A session token comes back, and every later call carries it.
Look closely at the token that came back: mss.bXNzLWdyZXlsb2Nr.833bee50…. The middle section is Greylock's own key, mss-greylock, encoded. The token is the credit union. There is no other field, anywhere in the rest of this walk, that says which lender is meant — and no address contains one.
Three milliseconds.
4.2 Create the application
Getting there. 1 · A member applies → 02 a member applies for a car loan.
Marisol Vega asks for $24,500 over 60 months at 6.75%, assigned to a named officer. One request carries all of it.
Back comes the identifier: GL-2026-4473.
That identifier is worth a moment. In the same run, the same call at United Teletech returned APP-2026-004473, and at Credit Union of New Jersey APP-2026-007217. Three credit unions, three independent numbering sequences. No shared counter, no collision, and no credit union able to guess at another's numbering.
4.3 Read it back
Getting there. 1 · A member applies → 03 the application is on file.
A different request, on a different connection, asking only for the identifier just minted.
Everything comes back as it went in — the amount, the term, Marisol Vega's name — and the status reads 1, submitted. Not decided, because nothing has decided it.
This is the read that separates a stateful mock from a conventional one. A mock that only knew the shape would answer here with a plausible application. This one answers with this application.
4.4 Find it on the feed
Getting there. 2 · An officer reviews it → 01 it reaches the officer's queue.
A date range goes in; a list comes back, and GL-2026-4473 is in it.
This is the call that matters most to anyone planning the integration, because it is how work arrives. Nothing is pushed. The platform asks what has changed and finds the new application waiting — exactly as it will against the real system.
4.5 Note it, and read the note back
Getting there. 2 · An officer reviews it → 02 the officer leaves a note, then 03 the note is on the application.
The officer writes the sort of line written a hundred times a day — "Title and insurance received. Ready for decision." — and it comes back with an identifier of its own, 88201.
The second call reads the notes on the application, and the one just written is among them. Two calls, because one proves the note was accepted and only the second proves it was kept.
4.6 Write the verdict
Getting there. 3 · The officer decides → 01 the officer approves it.
Approve, $24,500, 60 months, and R. Nakamura — the officer's name, which is what makes this a record rather than a state change. A lending decision belongs to a person.
Nothing on the application moves. Read it now and it still says submitted. The verdict has been written down; it has not been acted on.
4.7 Commit the decision
Getting there. 3 · The officer decides → 02 the approval is committed.
Look at what is being sent, on the left of the screen. There is no verdict in it. No decision, no amount, no officer — a single field about whether to push past warnings, and nothing else.
The outcome comes from the row written a moment ago, and the response says APPROVE.
Read the application again and it has moved: status 3, approved, $24,500, with an expiry date on it. Send this call without a verdict recorded first and it is refused.
Deciding takes two calls because the vendor takes two calls. A mock that folded them into one would be easier to use and would break the integration on the day it met the real system.
4.8 Add the member on DNA
Getting there. 4 · The loan account opens → 02 the member is created in the core.
This is where Greylock leaves the path the other two follow. Everything up to here has been the same system, the same calls, for all three credit unions. From this point Greylock is talking to Fiserv.
The stage opens with a credential — 01 the core accepts the credential — and it is worth naming the difference. Fiserv's credential says nothing about who is calling. It is shared, and the credit union travels separately, in a header on every single call. Temenos's credential was the credit union. Same journey, two different ideas of what a credential is.
Then Marisol Vega is created at Fiserv, and comes back with a PersonNum of 40001.
Fiserv opens an account against a member, so the member has to exist there first. That is the only reason this stage exists, and it is the one thing Greylock's walk has that the other two do not.
4.9 Book the loan account on Fiserv DNA — the fork
Getting there. 4 · The loan account opens → 04 the loan account is opened.
$24,500 at 6.75% over 60 months, owned by the member just created, and carrying GL-2026-4473 so the loan account can always be traced back to the application it came from.
Back comes the account number: 700160941.
That number did not exist a moment ago. It is the thing the credit union's staff will quote to Marisol Vega for the next five years.
4.10 Read the loan account back
Getting there. 4 · The loan account opens → 05 the loan account reads back.
The account number just minted, read back: principal $24,500, rate 6.75%, term 60 months, and the full set of sixteen balances Fiserv returns on a loan.
Same proof as reading the application back, now on the other side of the fork. Something was written into a second system, and a different call found it there.
4.11 Who is on the account
Getting there. 4 · The loan account opens → 06 the member owns the account.
One relationship comes back: Marisol Vega, as owner.
Nothing created that relationship except the booking call. It was not written separately and it was not loaded in advance — booking an account at Fiserv writes the ownership at the same time, and this read is how you know it did.
4.12 Note the loan account, and read the note back
Getting there. 4 · The loan account opens → 07 a note goes on the account, then 08 the note is on the account.
A note on a loan account at Fiserv is a different object from a note on an application at Temenos — Fiserv calls it a memo tickler. Same idea for the member, two systems, two records.
Worth knowing when someone asks where a note lives: it depends entirely on what it was written against.
4.13 Write the account number back onto the application
Getting there. 5 · The member has a loan → 01 the money moves, then 02 the account number goes back.
Two calls close the loop. The origination system is told the money moved, and then the Fiserv account number — 700160941 — is written onto the application.
This is the one call that ties the two vendors together, and it is worth pausing on, because in most credit unions today it is a person: someone reads an account number off one screen and types it into another. Here nothing is retyped, and the reason it can be is that both systems were reached through the same journey.
4.14 Read it funded
Getting there. 5 · The member has a loan → 03 one application, one account.
The application, read one final time.
Status 5, funded. Account number 700160941. Approved amount $24,500, and the decision history still naming R. Nakamura as the officer who approved it.
One application, decided once by a named person, now pointing at one real loan account in a different vendor's system — and nothing between the two was rekeyed by anybody. Twenty-one calls, none of them slower than six milliseconds.
Chapter 5 — Walk two · United Teletech Financial FCU
United Teletech originates and books on Temenos — Originations then Transact Lending — so its fork stays inside one vendor. Eighteen calls. Its Originations
ApiKeyismss-united-teletechand its TransactcompanyIdisUT0010001, and those two travel very differently: Transact issues no session at all, so thecompanyIdheader names the credit union on every single call, the way Fiserv'sOrganizationIddoes.
5.1 Authenticating as United Teletech
Getting there. 1 · A member applies → 01 the key that names the credit union.
The same call as Greylock's, sent to the same address, with the same two fields in it. Only the key differs.
And the token that comes back carries it: mss.bXNzLXVuaXRlZC10ZWxldGVjaA==.776810f9…, whose middle section is mss-united-teletech. Greylock's said mss-greylock. That one value is the entire difference between two credit unions' data, and there is nothing else in the request to change.
5.2 Create the application
Getting there. 1 · A member applies → 02 a member applies for a car loan.
Priya Raman asks for $24,500 over 60 months at 6.75% — the same loan as Greylock's, deliberately, so that anything that differs later is the credit union and not the loan.
Back comes APP-2026-004473, from United Teletech's own sequence.
5.3 Read it back
Getting there. 1 · A member applies → 03 the application is on file.
Amount, term and Priya Raman's name come back as sent, and the status reads 1, submitted.
Nothing of Greylock's is visible here, and nothing could be. The token decides which lender's book this read is against, and there is no parameter that would let it reach across.
5.4 Find it on the feed
Getting there. 2 · An officer reviews it → 01 it reaches the officer's queue.
The same date range that found Greylock's application finds this one — and returns United Teletech's work, not Greylock's.
This is the separation, demonstrated rather than asserted. Two credit unions, one address, one request, and each sees only its own.
5.5 Note it, and read the note back
Getting there. 2 · An officer reviews it → 02 the officer leaves a note, then 03 the note is on the application.
The note is accepted and comes back with the identifier 88601 — United Teletech's own comment numbering, running independently of Greylock's, which was 88201.
The second call reads it back off the application.
5.6 Write the verdict
Getting there. 3 · The officer decides → 01 the officer approves it.
Approve, $24,500, 60 months, and the officer's name.
As before, the application does not move. The verdict is a record; acting on it is the next call.
5.7 Commit the decision
Getting there. 3 · The officer decides → 02 the approval is committed.
The same shape as Greylock's: a request carrying no verdict at all, and a response of APPROVE.
The application moves to status 3, approved, $24,500, with an expiry date.
5.8 Book the loan account on Temenos Transact — the fork
Getting there. 4 · The loan account opens → 01 the loan account is opened, then 02 opening it again opens nothing new.
This is the fork, and United Teletech takes the other branch. Where Greylock crossed to a second vendor and had to create the member there first, United Teletech stays inside Temenos and books against the application's own reference. There is no member to create. The stage is shorter by three calls, and that difference is the whole of what changes between these two credit unions.
The account reference comes back: AATWDVA9L8DIMG5.
Then the same request is deliberately sent a second time — and the screenshot below is that second send. The same reference comes back. No second loan, nothing to reconcile, no duplicate for someone to find at month end. Worth knowing before anyone designs a retry.
5.9 Read the loan account back
Getting there. 4 · The loan account opens → 03 the loan account reads back.
The reference just minted, read back: currency USD, term 60M, and $24,500 disbursed.
Same proof as everywhere else — written by one call, found by another.
5.10 The balances
Getting there. 4 · The loan account opens → 04 what the member owes.
Principal outstanding $24,500.00. Overdue: nothing.
This is the call the loan screen reads. On the day this matters it will be answering with a number that has been paid down; here it is answering with the number the loan was booked at, because the loan was booked ninety seconds ago.
5.11 The payment schedule
Getting there. 4 · The loan account opens → 05 when the payments fall due.
The installments, and when the next one is due.
Nothing was told to build this. The schedule follows from the amount, the rate and the term that were sent at booking, which is the same thing the real system does with them.
5.12 Write the account number back onto the application
Getting there. 5 · The member has a loan → 01 the money moves, then 02 the account number goes back.
The origination system is told the money moved, and the Transact reference AATWDVA9L8DIMG5 is written onto the application.
Identical to Greylock's closing pair, and worth noticing precisely because it is identical. The two credit unions booked in different systems and got different kinds of account number — a nine-digit number at Fiserv, a fifteen-character reference at Temenos — and the call that carries it home is the same call.
5.13 Read it funded
Getting there. 5 · The member has a loan → 03 one application, one account.
Status 5, funded. Account number AATWDVA9L8DIMG5.
Eighteen calls against a system that had never heard of Priya Raman when the run started.
Chapter 6 — Walk three · Credit Union of New Jersey
The same eighteen calls as chapter 5 — same paths, same bodies, same headers — against a different credit union. Its
ApiKeyismss-cu-of-new-jerseyand itscompanyIdisNJ0010001, and those two fields are the entire difference. Read this chapter beside chapter 5 and what shows is that nothing in a request carries a credit union except the field the vendor already had, which is the property the whole mock exists to keep.
6.1 Authenticating as Credit Union of New Jersey
Getting there. 1 · A member applies → 01 the key that names the credit union.
Third credit union, same call. The token comes back as mss.bXNzLWN1LW9mLW5ldy1qZXJzZXk=.808b29db… — mss-cu-of-new-jersey in the middle of it.
Three credit unions have now presented three keys to the same address and been given three separate books of business. Nothing was configured between them. Each is a row of data saying which identifiers belong to which lender.
6.2 Create the application
Getting there. 1 · A member applies → 02 a member applies for a car loan.
Andre Whitfield asks for the same $24,500 over 60 months at 6.75%.
Back comes APP-2026-007217 — the third independent sequence, running alongside Greylock's GL-2026-4473 and United Teletech's APP-2026-004473 without either being aware of it.
6.3 Read it back
Getting there. 1 · A member applies → 03 the application is on file.
Read back by its identifier: the amount, the term, Andre Whitfield's name, status 1, submitted.
6.4 Find it on the feed
Getting there. 2 · An officer reviews it → 01 it reaches the officer's queue.
The same date range, for the third time, against the same address — and it returns Credit Union of New Jersey's application and nobody else's.
By now the point is made three times over: the address does not know about credit unions, and it does not need to.
6.5 Note it, and read the note back
Getting there. 2 · An officer reviews it → 02 the officer leaves a note, then 03 the note is on the application.
Comment 91401, written and read back. A third sequence, again independent.
6.6 Write the verdict
Getting there. 3 · The officer decides → 01 the officer approves it.
Approve, $24,500, 60 months, the officer named.
Nothing on the application moves yet, for the same reason as the other two.
6.7 Commit the decision
Getting there. 3 · The officer decides → 02 the approval is committed.
A request with no verdict in it, a response of APPROVE, and an application that moves to status 3, approved, $24,500 with an expiry date.
Three credit unions, three approvals, one behaviour. The two-call shape is not a quirk of one lender's setup; it is what the vendor does, and every integration against it will have to.
6.8 Book the loan account on Temenos Transact — the fork
Getting there. 4 · The loan account opens → 01 the loan account is opened, then 02 opening it again opens nothing new.
Credit Union of New Jersey takes the same branch as United Teletech: Temenos to Temenos, booked against the application's own reference, no member to create first.
The reference comes back as AANO0KMRXGWR5GC, and sending the same request again returns that same reference rather than opening a second loan.
So of the three credit unions, two share a path and one does not — and the one that differs, Greylock, differs only inside this stage. That is what the cost of a new credit union turns on: a lender running a system already built has nothing to build.
6.9 Read the loan account back
Getting there. 4 · The loan account opens → 03 the loan account reads back.
Currency USD, term 60M, $24,500 disbursed, read back off the reference just minted.
6.10 The balances
Getting there. 4 · The loan account opens → 04 what the member owes.
Principal outstanding $24,500.00, nothing overdue — the same answer United Teletech gave, from a separate loan account belonging to a separate credit union.
6.11 The payment schedule
Getting there. 4 · The loan account opens → 05 when the payments fall due.
The installments and the next date due, derived from what was sent at booking.
6.12 Write the account number back onto the application
Getting there. 5 · The member has a loan → 01 the money moves, then 02 the account number goes back.
The money moves, and AANO0KMRXGWR5GC is written onto the application.
The third time this guide has shown these two calls, and the third time they are the same two calls.
6.13 Read it funded
Getting there. 5 · The member has a loan → 03 one application, one account.
Status 5, funded. Account number AANO0KMRXGWR5GC.
That is three members, three credit unions, two different lending systems and fifty-seven calls, all against one address holding a database that was created empty a few minutes earlier. Every value on these three chapters' screenshots was put there by a call you can see on an earlier one.
Chapter 7 — What the run leaves behind
Three tables hold everything the three walks just created, and only three, whatever call gets added next. Knowing what is in them is how you check a claim this guide makes rather than take it: which credit union an identifier resolved to, what a read will return, and every call that arrived, in order, whatever the outcome.
7.1 config — which credit union an identifier resolves to
Nine rows. Three credit unions, and for each one, the identifier it is known by at each of the three systems.
| Credit union | Fiserv DNA | Temenos Originations | Temenos Transact |
|---|---|---|---|
| Greylock Federal Credit Union | 999950001 | mss-greylock | GL0010001 |
| United Teletech Financial | 999950002 | mss-united-teletech | UT0010001 |
| Credit Union of New Jersey | 999950003 | mss-cu-of-new-jersey | NJ0010001 |
This is the whole of what makes a credit union exist here, and it is worth being blunt about what that means. Every request in this guide was resolved to a lender by looking up one of those nine values. Nothing else in the system knows there is more than one credit union.
So a fourth credit union is three more rows — one per system it runs on — applied the way any other data change is applied. No code is written, no request changes, nothing is redeployed and nothing is rebuilt.
That is the line the whole document exists to draw. A lender running systems already built is a data change. A lender running a system nobody has built yet is development, and it is development whether it is the fourth credit union or the fortieth.
7.2 object_store — the response is the record
Twenty-eight records after the run: Greylock sixteen, the other two six each. Greylock's includes the ten that were already there — the small set Fiserv's own collection expects to find, and the only thing anywhere in this system that was not created by a request.
Six records per journey, then. An application, a note, a decision, and on the other side of the fork the member, the loan account and the ownership between them.
What is kept is the answer, not an object. A record here is exactly what its read returns — there is no separate shape held inside and translated on the way out.
That sounds like a detail and it is the reason the mock cannot quietly drift away from the vendor. A system that stores its own idea of a loan and converts it into the vendor's envelope on the way out has somewhere to be wrong. This one has nowhere to be wrong, because the envelope is what is stored.
7.3 request_log — every call, in order, with its status
Fifty-seven calls. All of them succeeded. Between two and six milliseconds each, averaging 3.4.
Every call that arrives is recorded whatever happens to it — the refused ones too, which is what makes this useful when something is wrong rather than only when everything is right.
And it is where this guide's own numbers came from. Not one value in chapters 4, 5 or 6 was typed by hand. They were read out of this record, from the same run the screenshots were taken during, so a picture and the number written beside it cannot disagree.
Run the collections again and you get a different loan with different identifiers, and the guide regenerates around it. That is what makes it something you can check rather than something you have to trust.
Chapter 8 — Supported, but not on this loan's path
A loan needs a small number of calls and this guide walks them. The mock answers a good many more, and an integrator planning the work needs to know what is already there before deciding what to build. That is all this chapter is: a list, so nothing here is a surprise later.
8.1 Everything else the mock answers
Funding the loan is on the journey and does not have a section of its own, because on its own it is one call with one word in the answer. It runs between approving the loan and writing the account number back — the money moves request in stage 5 — and it is refused outright if the application was never approved. It is listed here so it is written down somewhere precise.
The rest are calls a lending team uses constantly, none of which this particular loan needed:
| What it does | Where |
|---|---|
| Find a member by tax id, partial name or member number | Fiserv DNA |
| Change a member's details after they are created | Fiserv DNA |
| Relate one member to another | Fiserv DNA |
| Change a loan account after it is booked | Fiserv DNA |
| Change who is on an account, or remove them | Fiserv DNA |
| A member's addresses | Fiserv DNA |
| Beneficiaries on an account — add, and list | Fiserv DNA |
| Remove a note from an account | Fiserv DNA |
| Transaction history on an account | Fiserv DNA |
| The applicants on an application, with income and scores — read and add | Temenos Originations |
| Fund an application | Temenos Originations |
None of these needs anything built. They answer today, they hold state the same way, and they are in the same collections — they simply are not part of the journey from asking to having, which is what this guide follows.
Chapter 9 — Glossary
The vendors' own words, in the order the walks meet them. Before you start holds this guide's vocabulary; this chapter holds theirs, and several of these mean something other than they look like they mean.
9.1 The vendors' words
In the order the walks meet them. Several of these mean something other than they look like they mean, which is the reason for the chapter.
| Word | What it means |
|---|---|
| Party | Fiserv's word for a person or business the credit union deals with. What everyone else calls a member |
| PersonNum | The number Fiserv mints when a member is created. Marisol Vega's was 40001 |
A path ending /secured | A read, not a write — even though it is sent the same way a write is. This trips people up constantly: at Fiserv, asking a question and making a change can look identical from the outside, and the difference is the last word of the address |
| Memo tickler | Fiserv's word for a note left on a member or an account |
AcctId | Fiserv's loan account number. Nine digits |
| Decision history | Temenos's record of a verdict — who decided, what they approved, when. Several can exist; only the newest is in force |
ByPassWarnings | The only field in the request that commits a decision. It does not carry the decision |
| Application identifier | The reference staff say out loud — GL-2026-4473. Distinct from the internal number the system counts with, which nobody quotes |
accountReference | Temenos Transact's loan account number. Fifteen characters, beginning AA |
quotationReference | What a Temenos loan account was booked against — the application it came from. Booking twice with the same one returns the account already booked, rather than opening a second |
companyId | The header naming the credit union on every Temenos Transact call |
| Status 1, 3, 5 | Submitted, approved, funded. The three the walks pass through |
| Disburse | The call that says the money moved. Refused if the application was never approved |
9.2 The same thing, spelled three ways
The same six ideas, as each system names them. This table is the translation cost of running three vendors, and it is why the platform holds one record of a member and one record of a loan rather than asking anyone to keep three in their head.
| The thing | Fiserv DNA | Temenos Originations | Temenos Transact |
|---|---|---|---|
| Which credit union | EFXHeader.OrganizationId, on every call | the key presented at the start, then the token | companyId, on every call |
| The member | a party, with a PersonNum | an applicant, with a person number | a party id on the loan |
| The loan account number | AcctId — nine digits | AccountNumber, once written back | accountReference — fifteen characters |
| A note | a memo tickler, on the account | a comment, on the application | — |
| How much | InitialAmount | RequestedAmount, then ApprovedAmount | loanAmount |
| How long | 60, counted in months | 60 | "60M" |
Read the bottom two rows again. The same sixty months is written three different ways by three systems, and every one of them is correct in its own house. Somewhere between them, something has to know that. In this demonstrator, that something is the mock; in the product, it is the platform — and in most credit unions today, it is a person with two screens open.