Casos de uso do TED Lerian

Cada caso de uso mostra quem age em cada etapa, a chamada de API ou o evento envolvido e o que acontece quando a jornada não segue o caminho esperado.

​

Pagamento a fornecedores

---

Um ERP paga faturas de fornecedores em contas de outros bancos. Cada pagamento sai como uma TED com um código de finalidade oficial e uma referência que liga a transferência à fatura.

1. O ERP aprova o lote de faturas a pagar.
2. Para cada pagamento, ele chama POST /v1/transfers/fee-quotes para mostrar a tarifa, o total e se a janela do STR está aberta.
3. Ele envia cada TED com POST /v1/transfers, o número da fatura em clientReference e a sua própria chave X-Idempotency.
4. O TED Lerian reserva o valor mais a tarifa no Midaz.
5. O TED Lerian envia a TED ao Lerian SPB, que a envia ao STR.
6. O Lerian SPB informa que o STR liquidou a TED.
7. O TED Lerian publica transfer.settled.
8. O ERP baixa a fatura que encontra por clientReference.

Se a rede cair durante o lote, reenviar uma requisição com a mesma chave X-Idempotency não cria uma segunda transferência. Se o STR rejeitar a TED, o TED Lerian libera a reserva e transfer.rejected traz o motivo.

​

Saque para a conta do cliente em outro banco

---

Um cliente move o saldo da sua plataforma para a própria conta em outro banco. O app mostra o custo, impede que o saldo seja gasto duas vezes e avisa o cliente quando o dinheiro saiu.

1. O cliente pede o saque e informa os dados bancários.
2. O app chama POST /v1/transfers/fee-quotes e mostra a tarifa.
3. O cliente confirma.
4. O app envia a TED com POST /v1/transfers.
5. O TED Lerian reserva o valor mais a tarifa no Midaz, para que o saldo não possa ser gasto duas vezes.
6. O TED Lerian envia a TED ao Lerian SPB, que a envia ao STR.
7. O Lerian SPB informa que o STR liquidou a TED.
8. O TED Lerian publica transfer.settled.
9. O app avisa o cliente que o saque foi concluído.

Se a janela estiver fechada, a cotação retorna windowOpen como false e o app mostra nextWindowOpensAt antes de o cliente confirmar. Se a TED for rejeitada, a reserva é liberada e o saldo volta para o cliente.

​

Transferência entre clientes da mesma instituição

---

Quando o banco do recebedor é a sua própria instituição, a mesma requisição vira uma transferência interna. Ela liquida em uma única transação no Midaz, também fora do horário do STR. Os limites de uso e, quando configurada, a tarifa continuam valendo.

1. O cliente paga outro cliente da mesma instituição.
2. O app envia POST /v1/transfers com o ISPB da própria instituição como banco do recebedor.
3. O TED Lerian encontra a conta do recebedor no CRM do Midaz.
4. O Midaz debita e credita na mesma transação.
5. A resposta volta na hora com type=INTERNAL e status=SETTLED.

Com saldo insuficiente, a resposta é 201 com status=REJECTED e TED-0031. Se o TED Lerian não encontrar o recebedor, ele recusa a requisição com 422 TED-1021 e não cria nada.

​

Receber uma TED e creditar o cliente em até 60 minutos

---

Um cliente recebe uma TED de outro banco. A regra dá 60 minutos, a partir da liquidação interbancária, para creditar ou devolver. O TED Lerian faz isso sem nenhuma etapa humana no caso normal.

1. O Lerian SPB informa uma TED que o STR liquidou. O prazo de 60 minutos começa.
2. O TED Lerian registra a TED recebida e publica incoming_transfer.received.
3. O TED Lerian busca a conta e o titular no CRM do Midaz por agência, conta e documento.
4. O TED Lerian confere se o titular e o tipo de conta correspondem.
5. O Midaz credita o cliente.
6. O TED Lerian publica incoming_transfer.credited.
7. O sistema da instituição avisa o cliente sobre a TED.

Se a conta não existir ou pertencer a outro titular, o TED Lerian devolve a TED com o motivo oficial (incoming_return.*). Se não conseguir decidir, a TED vai para revisão manual e aparece na fila do operador.

​

Devolver uma TED recebida por suspeita de fraude

---

Uma TED foi creditada, mas a instituição remetente pede o valor de volta ou o time de fraude encontra um problema. O operador ordena uma devolução integral com o motivo oficial e uma justificativa que fica na trilha de auditoria.

1. O operador sinaliza a suspeita.
2. O operador lê a linha do tempo com GET /v1/incoming-transfers/{incomingTransferId}/timeline.
3. O operador ordena a devolução com POST /v1/incoming-transfers/{incomingTransferId}/return, o motivo oficial e uma justificativa.
4. O Midaz estorna o crédito do cliente.
5. O TED Lerian envia a devolução ao Lerian SPB, que a envia ao STR.
6. O Lerian SPB informa que o STR liquidou a devolução.
7. O TED Lerian publica incoming_return.returned.

Se o STR recusar a devolução, chega incoming_return.failed e a TED volta para revisão manual.

​

Trabalho de back-office em uma transferência sem resposta

---

Você enviou uma TED e nenhuma resposta chegou a tempo. O TED Lerian mantém a reserva e pede o resultado real ao Lerian SPB. Quando a resposta automática não é conclusiva, um operador decide com evidência.

1. A transferência passa para AWAITING_RECONCILIATION e mantém a reserva.
2. O TED Lerian pede o resultado ao Lerian SPB.
3. A resposta não é conclusiva.
4. O operador vê o item na fila com GET /v1/reconciliation/queue, com a idade e o prazo.
5. O operador destrava o item com POST /v1/transfers/{transferId}/unblock, o resultado e a evidência do STR.
6. O Midaz liquida ou libera a reserva, conforme o resultado.
7. O TED Lerian publica transfer.settled ou transfer.rejected.

Quando a resposta é conclusiva, o TED Lerian aplica o resultado sozinho e o operador não age.