Como desenhar uma fila de revisão KYC que escala

Uma fila de revisão KYC é o fluxo de trabalho de back-office em que as verificações de identidade que uma máquina não conseguiu resolver sozinha são colocadas à frente de um humano. A maioria dos pedidos deve passar automaticamente; a fila existe para os que não passam. O seu objetivo de design é permanecer pequena — conter ambiguidade genuína e nada mais — porque uma fila que se enche de casos que uma máquina devia ter decidido não é um controlo, é um gargalo que cresce linearmente com os registos. Acerte na fila e o back-office escala com as exceções, não com o volume.

Essa propriedade única — pequena de propósito — condiciona todas as decisões seguintes. Comece pela separação que a mantém assim.

O objetivo é o straight-through; a fila é a exceção

O straight-through processing (STP) significa que um pedido é resolvido de ponta a ponta sem intervenção humana: documentos lidos, identidade validada, rastreio de sanções e PEP limpo, prova de vida aprovada, decisão registada. Este deve ser o caminho comum, e a percentagem de pedidos que o seguem — a taxa de STP — é o número que diz se a fila vai escalar. Se noventa e tal por cento se resolvem automaticamente, a fila humana recebe um fluxo gerível; se metade cai para revisão, estará a contratar revisores ao ritmo do crescimento. A fila não é onde o KYC acontece. É onde o KYC automatizado admite que não tem certeza. Aumente a taxa de STP e todos os outros números melhoram de borla: menos casos em fila, esperas mais curtas, menos revisores a contratar. Vale a pena atacá-la diretamente — melhor captura de documentos no cliente, instruções mais claras antes de tirar a fotografia, limiares de correspondência afinados para que clientes legítimos não sejam recusados por uma regra demasiado cautelosa — porque cada ponto percentual recuperado é um caso que nunca se torna a tarde de alguém.

O que cai na fila, e porquê

Os casos caem para revisão por razões específicas e identificáveis, e a razão é o atributo mais importante que um caso transporta. A fotografia do documento está demasiado desfocada para ser lida. O nome no documento de identificação não coincide com o nome no pedido. Um rastreio de sanções ou PEP devolveu uma possível correspondência que exige que um humano a confirme ou descarte. Não é possível verificar uma morada em nenhuma fonte. Uma prova de vida falhou, ou o mesmo rosto ou documento já existe noutra conta. Cada uma destas situações é um tipo diferente de trabalho que exige um tipo diferente de julgamento — e juntá-las numa pilha indiferenciada é o primeiro erro de uma fila de revisão. E a mesma razão pode ter pesos muito diferentes: uma divergência de nome pode ser uma banal diferença de nome de casada ou o primeiro sinal de uma identidade roubada, e a função da fila é encaminhá-la para quem sabe distinguir, em vez de forçar um veredicto apressado num caso que merece um cuidadoso.

Uma só fila não chega: segmente por motivo

Uma fila única obriga cada revisor a ser generalista e cada caso a esperar atrás de outros que nada têm a ver com ele. Segmentar por motivo resolve ambos os problemas. Uma fila de possíveis correspondências de sanções é trabalhada por pessoas treinadas em rastreio e decisão; uma fila de qualidade documental é uma verificação visual rápida que um revisor júnior resolve em segundos; uma fila de contas duplicadas é uma investigação de fraude. Cada segmento tem o seu próprio encaminhamento, a sua competência exigida e o seu próprio objetivo de nível de serviço, porque uma fotografia desfocada deve ser resolvida em minutos, enquanto uma correspondência genuína de sanções merece uma decisão cuidadosa e sem pressa. A segmentação é o que permite que débito e rigor coexistam, em vez de se sacrificarem um ao outro.

Uma fila de revisão não escala com a contratação de revisores. Escala ao decidir, corretamente, que casos nunca precisaram de revisão — e ao garantir que os que precisam chegam já ordenados pelo motivo.

Ações auditadas, com motivo obrigatório

Cada decisão de um revisor — aprovar, rejeitar, escalar, pedir mais documentos — tem de exigir um motivo e ficar registada. Não como nota livre de última hora, mas como uma seleção estruturada que diz porque é que a ação foi tomada, captada no momento em que é tomada. Isto não é burocracia: é o que torna a fila defensável. Quando um regulador, um auditor ou um revisor posterior pergunta porque é que uma conta foi aprovada apesar de um alerta, a resposta é um revisor identificado, uma data e hora e um motivo declarado — não um encolher de ombros. O registo de auditoria é só de acrescento (append-only), pelo que uma decisão não pode ser reescrita em silêncio depois de tomada; as correções são novas entradas, não edições sobre as antigas. Na nossa stack, esta fila e o seu modelo de auditoria vivem no Protocore Center (/products/center), a consola de operador onde cada ação privilegiada exige um motivo e fica num registo que não pode ser alterado em silêncio.

Os casos de quatro olhos

Algumas decisões são demasiado importantes para uma só pessoa. Dar como falso um alerta real de sanções, aprovar um perfil de risco elevado ou anular uma rejeição automática deve exigir a confirmação de um segundo revisor — maker-checker, ou quatro olhos. O primeiro revisor propõe e indica o motivo; um segundo, com autoridade para tal, confirma ou rejeita e indica o seu. Ambas as ações ficam registadas. Não é desconfiança em relação aos revisores: é reconhecer que as aprovações de maior risco são precisamente aquelas em que um único erro sai mais caro, e que um segundo par de olhos é o seguro mais barato contra isso. O desenho da fila deve encaminhar estes casos automaticamente, por motivo, para uma decisão em duas etapas, em vez de depender de os revisores se lembrarem. Reserve, contudo, as duas etapas para os casos relevantes; aplicá-las a tudo duplica o custo da fila inteira e habitua os revisores a carimbar a segunda assinatura sem olhar, o que anula em silêncio o propósito de ela existir.

Desenhar para o volume: antiguidade, priorização, SLAs

Uma fila que só cresce é uma fila que falhou. Incorpore no desenho a pressão que a mantém em movimento. Os casos envelhecem à vista, para que nada fique esquecido; cada segmento tem um objetivo de nível de serviço, de modo que um caso de foto desfocada a falhar um SLA de poucos minutos se destaca de forma diferente de um caso de sanções dentro do seu prazo mais longo. A priorização é uma escolha real: o mais antigo primeiro é justo e simples, mas o risco primeiro — a pior exposição potencial no topo — é muitas vezes a decisão certa, com a antiguidade como critério de desempate, para que os casos de baixo risco continuem a ser resolvidos em vez de ficarem à fome. O ecrã do revisor deve apresentar o próximo caso, já encaminhado e priorizado, e não uma lista para escolher — porque uma fila onde as pessoas escolhem é uma fila onde os casos incómodos nunca são escolhidos. Uma fila sem antiguidade visível apodrece em silêncio: os casos difíceis afundam-se no fundo enquanto os fáceis giram no topo, e a única métrica que o teria revelado — a idade do caso aberto mais antigo — é exatamente o número que ninguém vigia até um cliente se queixar.

Medir a fila

Quatro números dizem se o desenho funciona. A taxa de STP indica quanto nunca precisou de um humano; a profundidade da fila e a sua tendência dizem se está a acompanhar o ritmo ou a ficar para trás; o tempo até à decisão, acompanhado por segmento face ao respetivo SLA, diz se os clientes esperam demasiado para serem integrados; e a taxa de reabertura — decisões revertidas mais tarde — diz se os revisores decidem bem ou apenas depressa. Observe-os em conjunto, porque compensam-se entre si: reduzir o tempo até à decisão enquanto a taxa de reabertura sobe significa que comprou velocidade com erros. Uma fila saudável é pequena, está em movimento, decide corretamente e é honesta quanto aos casos que ainda tem abertos.

O back office que as pessoas imaginam — salas de funcionários a introduzir candidaturas à mão — é o que se obtém quando a automação resolve pouco e a fila é um monte indiferenciado. O back office que escala é o inverso: a maioria das candidaturas nunca chega a um humano, as que chegam vêm ordenadas por motivo e prioridade, cada ação leva um motivo para um registo append-only, e os quatro olhos protegem as decisões que o justificam. Construa a fila para as exceções e ela mantém-se pequena à medida que cresce. Construa-a como o sítio onde o KYC acontece e ela cresce a cada registo que aceitar.