Inactivity Tracking API Architecture: How to Build a Quiet-Period Clock for a Fintech
Entrustt is an API for the quiet-period clock: you send activity signals, receive signed webhooks and have a person review disclosure. This page shows how any inactivity clock is built, so engineers can decide whether to build or integrate.
Entrustt takes activity signals from your systems, runs the quiet-period clock and sends signed, replayable webhooks when a state changes. A person reviews any disclosure. Here is what such a system involves.
Signals
Keep the payload small: who, what, when, and an id so the event is processed once.
POST /v1/signals
{
"event_id": "evt_7f3a91",
"customer_ref": "cus_20931",
"type": "session.authenticated",
"occurred_at": "2026-10-22T09:14:03Z"
}- Send your own customer reference, not a name or phone number.
- Send the time the activity happened, not the time you sent the event.
- Treat the event id as an idempotency key, so a retry cannot reset a clock twice.
- Decide which signals count. A login, a transfer and a card payment are strong. An automatic debit usually is not.
Store and policy
Store last_activity_at, state and next_due_at per customer and product. Only move last_activity_at forward, and index next_due_at. Keep quiet periods in per-product configuration with a version number, so you can say later which rule applied on a given day.
State machine
| State | What it means | Moves on when |
|---|---|---|
| active | Recent activity | The quiet period passes with no signal |
| quiet | No activity for the first threshold | A check-in is sent |
| checked_in | Customer was asked to confirm they are fine | They reply, or the grace period ends |
| grace | Waiting for a reply | Reply, new activity, or the grace period ends |
| in_review | A person decides what happens next | The reviewer approves or declines |
| disclosed or closed | Information shared, or case closed | End of the case |
New activity or a reply returns the customer to active from quiet, checked_in or grace. Once a case is in_review, activity should not silently cancel it. Raise it to the reviewer.
Sweeper and outputs
Run one job on a short interval. It selects rows where next_due_at has passed, moves each to its next state in a transaction, writes an audit entry and queues the output. Make each transition safe to run twice. Do not create a timer per customer.
Outputs are customer messages in your name on more than one channel, a review queue for staff, and webhooks to your systems. See the guide to signed webhooks with HMAC-SHA256.
What an in-house build involves
- Per-product policies you can change without a deploy.
- Late, duplicate and out-of-order events.
- Retries for messages and webhooks, with limits and alerts.
- A consented next-of-kin register and a way for customers to update it.
- A review desk with roles, an audit log and compliance exports.
- Monitoring, because a silent failure means nobody is contacted.
A good team can build all of it. Count the maintenance as well as the first version.
Related reading
- On Entrustt: solutions for banks and fintechs, pricing and request sandbox keys
- Inactivity monitoring software for banks and fintechs, for the buyer’s view
- CBN dormant account compliance checklist, for the rules this clock supports
- Next-of-kin API providers compared
Common questions
What is an inactivity tracking API?
A service that takes the activity events you already record, such as logins and transactions, keeps a last-activity time for each customer and starts a countdown when activity stops. When the countdown ends it triggers the next step, usually a message to the customer or a named contact.
Should I use cron jobs for each customer?
No. Store a due time for each customer and run one sweeper that picks up everything that is due. One job per customer does not scale and is hard to reset when new activity arrives.
How do I handle events that arrive late or twice?
Give every event a unique id and ignore ids you have seen. Compare the event’s own time with the stored last-activity time and only move the clock forward.
Is it better to build or integrate?
Building is possible. The cost sits in the details: per-product rules, resets, retries, audit logs and the review desk. Integrate if inactivity handling is not your product.