Four parts. One platform. All of it on the same five screens.
Each part is named for the duty it carries rather than for a box in a diagram. A firm can buy the first part on its own and add the others later. The first three keep the record. The fourth gets it back out.
The daily record of whose money is whose.
A payment firm holds money that belongs to its customers. At the end of every day it has to know exactly how much of that money belongs to each of them. That ledger is what the regulations ask for by name. Checking it against the account the money actually sits in is how a firm knows the ledger is true, and how a gap gets found on the day it appears rather than in March.
Safeguard is the first thing a firm buys, because it is the easiest thing to buy. It answers one question on a normal morning, and on a bad morning it answers it before anybody else notices there is a question.
A dated record of the day, and the evidence behind it
- The day's comparison. What the firm holds for customers, set against what the account holds.
- The gap, named and listed. Every unexplained item appears in its own right rather than only as part of a total.
- A shortfall. It stands on its own in the record, so it is never visible only as a net figure.
- A named signature. A person reads the result and signs it. The software carries the work, the person carries the authority.
- The legal view on the account, held on file with the date it falls due for review.
Everything else the same statute asks for.
The daily count is one duty among several. The same law asks for a written risk and incident framework, a way of testing that framework and a record of every test, a notice inside forty eight hours when something goes wrong, notice before a significant change, and a report through the regulator's portal every 31 March on a form that changes each year.
Most firms carry a money laundering framework under a second statute at the same time. Comply is sold into a login that is already open, because the person doing this work is the person already doing the daily count.
The paper, the notices, and the return
- The written framework, with an owner and the date it was last read over.
- The test plan and every test result, kept as they were run rather than summarised afterwards.
- The incident notice, drafted against the clock that starts when the incident is identified.
- The change notice, raised before the change rather than reported after it.
- The 31 March return, filled from the record of the year rather than rebuilt from memory in three weeks.
- The file an independent reviewer opens, and the reply that goes back with it.
The same platform, pointed at a second regulator.
A property brokerage holds deposits and rent that belong to owners and tenants. It owes a monthly reconciliation on those accounts, signed by the broker inside thirty days of the statement, plus a running record for each client inside one pooled account.
Different regulator, different clock, different vocabulary. The same five screens, and the same question underneath all of it: whose money is this, is it all here, and can you show me.
The monthly reconciliation the broker signs
- The month's comparison, client records against the trust account.
- A running record for each client held inside one pooled bank account.
- The broker's signature, against the thirty day clock rather than against a reminder.
- The pack a practice review asks for, cut by date range in exactly the same way.
A regulator asks about a week three years ago.
This is the request every firm quietly dreads. It arrives as an ordinary email, it names a date range nobody remembers, and it carries a deadline set by somebody else. The usual answer is three weeks of one person pulling folders, chasing a former employee's spreadsheet, and rebuilding a year out of memory.
Recall answers it from what was already written down. The question goes in as it arrived. What comes back is the records that answer it, each one linked to the day it was made. Nothing is composed, nothing is inferred, and nothing leaves until a named person has read it and signed it.
Records stay reachable for as long as the firm's statute requires them, which in several of these regimes is ten years.
The answer, and the means to check it
- The records that answer the question, each one linked back to the day it was made and the person who signed it.
- A list of what was looked for and what came back, so the answer can be checked rather than trusted.
- The same pack an examiner already expects, cut to the range that was asked for.
- A named signature on the response, before any of it goes back.
- Nothing else. Recall never writes a record, never edits one, and never fills a gap with something that reads like a record.
The hard part was never finding the answer. It was proving the answer was already there before anyone asked.
A payment firm's daily duty and a brokerage's monthly one land on the same five screens.
The words on them change. The shape of the work does not. Below is the same screen carrying two entirely different regulators, which is a claim about what a user sees and not a description of anything underneath it.
| Screen | Payment firm, daily, to the Bank of Canada | Property brokerage, monthly, to a provincial council |
|---|---|---|
| Today | The daily money check, beside the other duties on the same statute. | The monthly trust check, beside the other duties for the brokerage. |
| Money | Customer balances against the safeguarding account, with any shortfall standing on its own. | Client records against the trust account, with what is held for each client listed. |
| Proof | Framework, test results, the legal view on the account, and incident files. | Signed reconciliations, a note on each client record, and the broker sign off on each. |
| Filings | The 31 March return, filled from the record of the year. | What the provincial council asks for on an inspection, built the same way. |
| Exam pack | The pack an examiner asks for, cut by date range and by duty. | The pack a practice review asks for, cut in exactly the same way. |
The table above is a claim about what a user sees. Nothing underneath it is described on this site.
Three things we will not build. Stated before anyone has to ask.
These are refusals, not a roadmap. They are the answers a security reviewer asks for in the second meeting, so we would rather give them in the first.
The software never decides
It gathers, it checks and it drafts. Then a person decides and a person signs. The moment software decides something an examiner will question, the proof stops being a record and becomes an opinion.
A person carries the authorityNo customer data is mixed
Each customer's records sit apart from every other customer's. We will not build a view across customers, and a customer would refuse it in the security review anyway.
Kept apart by designNo custom forms
A customer gets settings, never a bespoke build. It is the discipline most easily sold away in a large deal, so we are naming it here before the large deal arrives. The first one will test it.
Settings, not forks