Creditcrest Decisioning and Creditcrest Record
An approval you can explain a year later.
The question that arrives by letter, eighteen months after a loan was written, is not “would you lend to this person today”. It is “what was your policy in March, and does this file show you followed it”. A credit policy that lives in a manual and an implementation that lives in an origination system are two artefacts that drift apart quietly, and the drift is invisible until somebody asks.
These two products answer that one question between them, which is why they are one surface. Creditcrest Decisioning holds the policy as dated, content-hashed rules and replays an application against the version that was in force on a given day. Creditcrest Record is the sealed file the answer lives in: hashed, amendable only by appending, and provably unedited since.
The demonstration
Take an application. Run it against the credit policy in force today. Run the same application — the same reading, the same assessment, the same proposed loan — against the version that was in force on an earlier day. Then read, side by side, which conditions came to a different answer and which clause in the policy changed it.
Every figure in this example is invented. There is no borrower, no bank statement and no lender: the transactions below were generated from the numbers in the form so that the policy engine has a statement to read, which is what it reads.
The credit policy replayed here is the one that says this at the top of itself. models/policies/example-au.txt is an example. Its thresholds are round numbers chosen to make the mechanism visible. They are not advice, not a market standard and not anybody’s policy. A real policy is written by a lender's credit risk function against their own book and signed off by people whose names go on it.
What each one does
Creditcrest Decisioning
A lender’s own credit policy written as rules that can be read, versioned, replayed and defended. The policy is an editable text file a credit risk officer can diff and approve, not code; each version is dated and content-hashed, so a decision made last March can be re-run against the policy as it stood last March and shown to be the same rules. Every rule outcome carries its reason and the figures behind it. It reports which conditions were met and which could not be evaluated. It does not approve and it does not decline.
The policy shipped with it is a worked example and not advice. The product is the format, the parser, the replay and the evidence — not the thresholds.
Creditcrest Record
The file a lender keeps. Canonical serialisation, SHA-256, the hash travelling with the content, amendments that append rather than overwrite. It proves the content has not changed since it was sealed. It does not prove the content was true when written, and says so.
Instead of: A database row, which proves what the database says now.
Two example policies, and neither is anybody's
Pick the one that answers your question. They hold the same shape of thing — dated versions, hashed rules, a replay against the version in force on the day — and they are written for different readers.
Round numbers
models/policies/example-au.txt
Written to make the mechanism visible: a $300 surplus floor, a 45 per cent debt service ceiling, thresholds a reader can do in their head while watching the replay work.
models/policies/example-au.txt is an example. Its thresholds are round numbers chosen to make the mechanism visible. They are not advice, not a market standard and not anybody’s policy.
Replay an application against it · Read it, version by version
2 versions, 1 March 2026 onwards.
In the shape of a published guideline
models/policies/example-guideline-au.txt
Written in the shape those documents have — a servicing buffer, a floor rate, a debt-to-income ceiling with a referral band under it, a minimum servicing surplus and the condition that waives it, and a separate line for each kind of income — so that somebody who reads credit guidelines for a living can see in one glance what a replay would do with theirs.
models/policies/example-guideline-au.txt is an example. It is a set of figures OF THE KIND Australian lenders publish, written to show the mechanism. It is not any lender’s policy, it names no lender, it reproduces nobody’s wording, and no lender has seen it, endorsed it, licensed it or is associated with it in any way.
Replay an application against it · Read it, version by version
3 versions, 2 February 2026 onwards.
The policy the links above open by default
Example unsecured personal lending policy (illustrative only), 2 versions, of which 2026.06 is in force on 26 September 2026. It is models/policies/example-au.txt.
| Version | In force | Rules | Hash of the rules |
|---|---|---|---|
| 2026.03 | 1 March 2026 to 1 June 2026 | 13 | 8400e4ccd45d6d4696e20f87… |
| 2026.06 | 1 June 2026 onwards | 13 | 083754ea2ff07e44c7b5d232… |
What is kept
Nothing. No account, no cookie, no session, no database. An application under assessment lives in the query string and in the memory that serves one request. The policy replay and the sealed record below are computed to answer a request and do not outlive it — including the sealed record, which is sealed and immediately thrown away, because this surface exists so the mechanism can be watched rather than to keep anybody's file.
Except the policy artefact, which is committed to the repository and has to be: the whole product is that the rules which ran in March are still exactly the bytes that were hashed in March.
What it will not do
Creditcrest Technologies is not a credit provider, is not a credit assistance provider, and does not hold an Australian credit licence. Its software produces evidence; the licensee makes the decision.
It does not approve and it does not decline. approve, decline, score and recommend are not words the policy format has, and writing one is a parse error whose message says the decision and the responsibility for it stay with the licensee.
No rule passes on missing data. Where an input is absent the rule reports that it could not be evaluated: not false, which would be a finding, and not true, which would be a lie. One unresolved rule makes the whole run unresolved, because nobody has established either way.
No benchmark table. The Household Expenditure Measure is licensed from the Melbourne Institute and this repository has no licence; the benchmark is an input a lender supplies. Inventing plausible benchmark figures would be the most damaging thing this software could do, because they would look right.
The same thing as data
/v1/decisioning lists every endpoint. Each of the three pages above has a JSON twin carrying the same figures and the same evidence, because a lender's own system has to be able to read this and an HTML page is not an interface.