Audit

Platform → Audit is the record of what staff did, and it is the reason the console can be trusted with the powers it has.

Needs audit.read. The expiring-grants tab also needs user.read, because it names people and their roles — enforced on that tab alone, so an auditor with audit.read and nothing else can read everything else here.

Six tabs, because one log answers six questions badly

Everything here except the sign-in attempts could be got out of the general log by somebody who already knows the right filter. That is precisely the problem: a review that depends on knowing which filter to type is a review nobody performs.

Tab	The question somebody arrives with
Log	What happened, with the before and after.
One record	Everything ever done to a single resource.
Sign-ins	Who tried to get in, and how often one account or address has been tried.
Refused	Privileged actions that were declined.
Impersonation	Every time staff acted inside a merchant’s account.
Grants	Access about to lapse, and access that already has.

Each tab reads when you first open it.

The log

Filterable, with the before and after values of what changed. Timestamps are precise to the second and the zone — an audit entry is correlated against application logs by request id and against a partner’s own records by the clock, and a minute’s resolution cannot order two actions taken in the same minute by the same person. Which is exactly the case somebody is looking at when they open this page.

The most useful filter here is “refused only”

A refused privileged attempt is where an investigation starts. The filter is offered by that name rather than as a checkbox labelled “succeeded”, which reads as “show me the ones that worked”.

One record

Everything ever done to a single resource, over a long default window — 400 days, because “a record’s history is usually wanted in full.”

Field	Notes
Kind of record	“As recorded by the handler that wrote the entry.” Not a table name of your choosing — if a kind returns nothing, the entry was written under another one.
Record id	“Paste it from the record’s own page rather than typing it.”
it is the same entries filtered to one record: two tables with drifting columns
would make the same entry look like two different kinds of thing depending on how
it was reached.

This is the tab for “who changed this merchant’s fee settings, and when”.

Sign-ins

The default is staff only

An operator who opens this page looking for a merchant’s failed logins sees nothing and concludes there were none.

The population being looked at is therefore a visible choice with staff pre-selected — never an empty “any” that quietly means something narrower. Switch it to merchant users when that is who you are investigating.

The window is seven days by default, because attempts are high-volume and the question this tab answers is a recent one.

The most informative field on the row

Whether the attempt matched a real account.

The identifier	What it means
Matched no account	Somebody is guessing addresses.
Matched an account	Somebody has a real address and is working on the password.

Those are different incidents, and they look identical in a count. The table says which.

Two counters answer is this an attack: how often one account has been tried, and how often one address has. A single account under attack is one conversation; one address against forty accounts is another.

Refused

Privileged actions that were declined.

Pattern	What it usually is
One refusal	A stale bookmark.
A cluster against one permission from one account	Either a role missing a grant it genuinely needs, or an account probing what it can reach.

Both want looking at, and they look identical in a count. The difference is usually obvious from which permissions were tried: somebody who needs ledger.read tries ledger.read, and somebody probing tries six unrelated things.

Impersonation

Every time staff acted inside a merchant’s account.

This is the register a merchant is entitled to ask about

The only honest answer to “has anyone at PaySigna been in my account” comes from here.

The reason is the field that matters, and it is the one most likely to be thin. When you act inside a merchant’s account, write the reason for the merchant who may one day read it back, not for yourself.

Expiring grants

Access about to lapse, and access that already has — and the two halves mean different things.

A lapsed grant confers nothing already; the row is waiting to be swept, so it is bookkeeping rather than exposure. An expiring one is still live until its date.

A screen that treated them alike would have somebody chasing an urgent revocation that had already taken effect — or, worse, assuming an expiry had been applied when it was still days away.

Work the expiring half: renew what is still needed, and let the rest lapse.

How an oversight review goes

1. Refused — any clusters? Who, and against what?
2. Impersonation — every entry in the period, and does each reason actually explain itself?
3. Sign-ins, staff population — repeated failures against real accounts?
4. Sign-ins, merchant population — the same question for merchants, which is the half that gets forgotten.
5. Grants — anything expiring that should not be renewed, and anybody holding access they no longer need? Cross-check against Staff.
6. Log, filtered to the money permissions — settlement releases, withdrawal completions, limit changes, pricing writes — and read the reasons.

If a reason field anywhere in that review does not explain the action to somebody with no other context, that is the finding.