Working the queues

The queues are most of the job. They are work that arrives rather than work you go looking for, and each one loses something different when it is left.

The order to work them in

Not by size. By what a delay costs:

Disputes near a deadline. A missed deadline is an automatic loss, and the deadline belongs to the customer’s institution, not to us. This is the only queue where doing nothing decides the outcome.
Risk review. Real transactions are held, which means real merchants are waiting and real customers are looking at a payment that has not completed.
Approvals. Somebody else’s work is blocked on a second pair of eyes.
KYC review. A merchant cannot go live until it clears.
Risk alerts. Important, but they describe something that already happened.

Approvals

Queues → Approvals holds every action that needs a second person.

The rule is absolute: the approver may not be the requester. It is enforced in the platform, not left to discipline.

Before approving anything, you are answering three questions, and “a colleague asked me to” is not an answer to any of them:

What exactly does this change, and what is the effect if it is wrong?
Is the stated reason consistent with what you can see — the merchant’s history, the amounts, the timing?
Is this reversible? Some of these are not.

Reject with a reason rather than letting a request sit. A rejected request with an explanation lets the requester fix it; an ignored one leaves them guessing and usually produces a second identical request.

KYC review

Queues → KYC review is merchants waiting to be verified. Until it clears, their live requests are refused with kyc_required, so this queue is somebody’s business not starting.

You are checking that the business is real, that the person presenting it is entitled to, and that what they say they sell is what they are going to sell:

Identity documents that are legible, unexpired and match the named person.
A business that exists and matches the registration given.
A settlement destination in the business’s name — not a director’s personal wallet, not a third party’s.
A stated business model that is consistent with everything else in the file.

The last one is the one that matters most and is easiest to wave through. The description of the business drives their limits, their pricing and their risk profile. A merchant described as a retailer who is in fact running a remittance operation is not a paperwork problem; it is the wrong limits, the wrong rules and the wrong partner routing, all of which only surface later.

Decline with a reason, and ask for one specific thing. A rejection that says “documents insufficient” produces another insufficient set. One that says “the utility bill is dated more than three months ago; send one from the last 90 days” produces the right document on the first try.

Approve, decline or request more — and record what you saw. The next person to look at this merchant will be reading your note, possibly during an incident.

Disputes

Queues → Disputes is every dispute across all merchants, which is a different view from the one a merchant sees of their own.

The deadline is the whole thing. A dispute that expires is lost on silence rather than on merits, and the merchant usually has no idea it was happening unless somebody told them.

Your job here is mostly to make sure the merchant knows, their evidence is complete before submission, and the submission goes before the deadline rather than on it. Submissions are reviewed by people who go home.

The platform shares one definition of “a complete submission” between the merchant portal and this console, deliberately — so the two cannot disagree about whether a merchant has finished. If the portal says complete and you think it is not, that is a finding worth raising rather than working around.

A rising dispute rate for one merchant is a risk signal, not just a workload. It belongs in their risk profile and eventually in their pricing. See Risk.