A request arrives on a Tuesday
Your partner bank's oversight team sends an email. They want the full history for a list of customers: how each was onboarded, what checks ran, any reviews or restrictions, contact with support and a list of transactions, for a set period. They would like it by the end of next week.
Your ops lead starts a folder. Onboarding results come from one provider's dashboard as PDFs. Account changes are in your database, which means an engineer. Manual review notes are in a spreadsheet and in Slack threads. Support conversations are in your helpdesk. Transactions are in the provider's portal and your ledger, with slightly different references. By Thursday there is a folder of screenshots and exports that tell the story, if you read them in the right order.
Why history is so hard to reassemble
Each system keeps its own records well enough. None of them was built to tell one customer's story in time order.
- Different systems use different IDs for the same customer, such as a provider applicant ID, your user ID and a helpdesk contact ID.
- Some actions leave no record at all, like an engineer changing a value directly in the database.
- Notes about decisions sit in chat, where they are hard to search and easy to lose.
- Exports come in different formats and time zones.
The first request of this kind is usually handled by heroics. By the third, it is clear it will keep coming.
The time it takes and what it signals
Each request pulls senior ops people and an engineer away for days. Gaps in the trail need explaining, and an explanation after the fact is weaker than a record made at the time. Your partner forms a view of your operational maturity partly from how quickly and cleanly you answer. What your partner expects, and what counts as enough, is for your compliance lead and the partner to agree; our part is making the record complete and quick to retrieve.
A customer event record and a request screen
What we build captures events as they happen, in one place, so the trail is already assembled when someone asks.
- A single customer key is linked to every external ID: onboarding provider, payment provider, card processor and helpdesk.
- Events are written to an append-only store as they happen: check results, decisions, account changes, restrictions, reviews, support contacts and payments.
- Changes made by staff through admin tools are recorded with who, when and what changed. Direct database edits are routed through a logged admin action instead.
- Decision notes are captured in the review tools where decisions are made, not in chat.
- A request screen takes a list of customers and a date range and produces a readable timeline for each, with source references.
- The output exports to PDF and CSV in a consistent format, with a record that the request was produced and by whom.
| Part of the trail | Captured from | How it appears |
|---|---|---|
| Onboarding checks and results | Provider webhooks | Each check, result and time |
| Onboarding decision | Your review tool | Decision, reviewer, reason |
| Account changes | Admin actions and app events | Old value, new value, who, when |
| Reviews and restrictions | Your review queue | Trigger, outcome, notes |
| Support contacts | Helpdesk API such as Zendesk or Intercom | Date, channel, summary link |
| Transactions | Your ledger, linked to provider references | Line per transaction |
When the next request lands
The ops lead pastes the customer IDs into the request screen, picks the period and reviews the timelines. Anything odd is visible straight away because it is in order. The export goes back with a short covering note, and the request itself is logged, so you can show later what was sent and when.
Engineers are not involved unless something needs explaining. Over time the gaps close, because the event record makes it obvious which actions still happen outside a logged tool.
Is this how audit requests feel for you?
- Each request becomes a folder of screenshots.
- An engineer has to query the database for account history.
- Decision notes live in Slack threads.
- The same customer has different IDs across your tools.
- You would struggle to show what you sent for a past request.