When a decision returns Review or BlockAndReview the transaction is held and a case is opened. This page covers how long that case may wait, and who is allowed to close it.

​
Answer time

Each queue (inbox) carries its own: Settings → Inboxes → Answer within (hours). The deadline is stamped when the case opens, not computed on read. Two consequences, both deliberate:
  • Moving a case to another queue does not rewrite a deadline it has already been measured against.
  • Changing a queue’s policy does not retroactively make yesterday’s work late — or on time.
Leaving it empty means no promise. Zero counts the same way: a setting that makes every case late the moment it opens produces an escalation list identical to the case list, and both stop being read.
Per queue, because the promise differs per queue. A card-present review is answered in minutes and a merchant onboarding review in days; one number for both is a number nobody can act on.

​
Escalation

A sweep marks cases whose deadline has passed. A marked case:
  • shows a late badge in the list,
  • is handed to the next analyst ahead of everything else in its queue,
  • gets an entry in the case’s own history,
  • increments fraud.cases.sla_breach.
The breach is recorded, not derived. Extending the deadline afterwards, or closing the case, does not erase that it was once late — which is the only version an audit can use.
Escalation does not reassign, reroute or notify. Which team picks up a missed review at 2am is your operating policy; Krino makes the breach visible rather than guessing at it.
The counter is the earliest signal that review capacity no longer matches what the rules produce — it rises before the complaints do.

​
Putting a case aside until a date

An analyst waiting on a document from the customer has nothing to do with that case. Leave it in the queue and it gets opened again, read again, and put down again by whoever gets it next — the same file read three times by three people, and nobody learns anything from any of it. Put aside for later on the case screen takes it out of the queue until a date. Saying what is being waited for is required: a parked case with no note is indistinguishable from a forgotten one, and the next person starts from the beginning to work out whether the wait is still live. A parked case is not listed in the queue and is never handed to anybody as the next case. The queue filter’s Also show cases put aside brings them back: a supervisor asking what their queue is really carrying has to be able to see the parked work too.
Putting a case aside does not stop the clock. The answer time is a promise to the customer whose transaction is held, and their wait does not get shorter because we are waiting on somebody else. A case whose deadline passes while it is aside is brought back by escalation, and a case that is already late cannot be parked at all. Otherwise parking would be a way of making the breach figures say whatever somebody wanted.
A case comes back by the clock rather than by the sweep: the moment its wake time passes it is in the queue again. The sweep only writes the event and tidies the field.

​
Batch actions

Opening forty cases that reach the same conclusion one at a time is not making the same decision forty times — it is approving thirty-nine of them without reading. Tick rows in the case list and Close, Assign and Tag appear. A batch action is the fast version of doing it one at a time, not a relaxed version of it: Partial success is the expected outcome, not an error. Where three of forty are waiting on a second approver, the other thirty-seven are applied and the untouched ones come back grouped by reason. “34 closed, 3 waiting on a second approver” says what to do next; “34 cases updated” hides the other six.
Tagging adds or removes; it does not replace. The tag field on a single case changes the selection, but “tag these forty as card-testing” does not mean wiping whatever they already carry.

​
Second approval (four eyes)

Enabled per queue with Settings → Inboxes → Closing a case needs a second person. With it on, closing splits into two steps:
1

The first analyst proposes the outcome

They pick the outcome and try to close. The case stays open, the proposed outcome is visible, and the queue marks it as awaiting a second approval.
2

Somebody else approves

Any user in the queue — except the one who asked — can close it. Both steps are written into the case history with who performed them.
The requester trying again is refused. That holds for a deliberate re-submission and for a double click alike.
The only property enforced is that two different people looked. Seniority, assignment and role are not checked — who may approve whom is your own structure. A caller with no identity does not count as the second pair of eyes.
Turning the policy off releases cases already waiting: work should not sit behind a step nobody is going to be asked to take.

​
Why these two controls

What a review actually decides is whether to release a held transaction. Without a deadline that decision can be deferred indefinitely and no report can say so, because there is no threshold to breach. Without a second approval it rests on one person: open the case, mark it a false positive, close it, and the money moves. Neither gap produces an error. The platform decides correctly, the case opens correctly, and the file waits.