In a bank, an insurer or a payments firm, a decision is rarely questioned on the day it is made. It is questioned eighteen months later, by internal audit, a risk committee or a supervisor, and the question is plain: who approved this, what did they know, and what did they turn down?
I founded Traceway. This page is a vendor's description of how our product records that answer. It is not regulatory advice, and using a tool does not make a firm compliant with anything.
Why the record matters more here
Accountability in financial services is increasingly personal. The UK Financial Conduct Authority describes its Senior Managers and Certification Regime as "making individuals more accountable for their conduct and competence". Whatever regime applies to you, the practical effect is similar. A named person needs to be able to show what they approved and on what basis, without rebuilding it from email.
That is hard when the reasoning is spread across a committee pack, a change ticket, a model document and a chat thread. Each holds part of it. None holds the decision.
A worked example
A fictional retail bank is moving its core platform. During the migration the team proposes calculating interest accruals in real time, and not in the overnight batch. It is a technical change with consequences well outside engineering: finance reporting cut-offs move, an operational risk is accepted for the transition, and a date promised to the board depends on it.
In Traceway the decision is one record. It holds the call, the reason for making it now, the alternatives that were set aside (keep the batch, run both for a quarter) and the people in each role. The approver's sign-off is a separate act, with their name on it. The record is connected to the migration goal and the initiative delivering it.
Six months later the cut-over slips. The question for the risk committee is whether the accepted risk still holds for a longer transition. With the record in front of them they can see what was approved and on what basis, and treat the extension as a new decision with its own approval.
What a reviewer can be shown
| The reviewer asks | Where the answer is |
|---|---|
| Who approved it? | The named approver and their sign-off on the decision record. |
| What did they consider? | The rationale and the alternatives that were set aside, kept with the decision. |
| What did it lead to? | The goal, the initiative and the work linked to it through Strategy Alignment. |
| What changed afterwards? | The later decisions connected to it, and what was approved again. |
Our guide to preparing decision evidence for an audit covers what reviewers ask in more detail.
Questions your security team will ask
- Where is the data held? You choose the region when the workspace is set up: the United States or the European Union. Our security and data page says which things stay in the United States for every workspace, and marks each statement as confirmed, in progress, to confirm or not yet.
- How do people sign in? SAML single sign-on and SCIM provisioning with Okta or Microsoft Entra are built, with role-based access. Whether they are switched on depends on how your workspace is set up, so confirm that with us before you rely on it.
- Does AI approve anything? No. Trace AI helps draft and refine a record. Approval is a human act.
- What is not there yet? The security page lists it. Read that page before you rely on anything here.
How to test it
Choose one decision a committee approved last year that has since been questioned. In a demo, rebuild the record from the pack, then ask us to show how an extension or a reversal appears against the original approval. Bring your second line or internal audit to the same session. Request the demo here.