Casos de uso de TED Lerian

Cada caso de uso muestra quién actúa en cada paso, la llamada a la API o el evento involucrado, y qué pasa cuando el recorrido no sale como se espera.

​

Pagos a proveedores

---

Un ERP paga facturas de proveedores a cuentas en otros bancos. Cada pago sale como una TED con un código de finalidad oficial y una referencia que vincula la transferencia con la factura.

1. El ERP aprueba el lote de facturas por pagar.
2. Para cada pago, llama a POST /v1/transfers/fee-quotes para mostrar la comisión, el total y si la ventana del STR está abierta.
3. Envía cada TED con POST /v1/transfers, el número de factura en clientReference y su propia clave X-Idempotency.
4. TED Lerian retiene el monto más la comisión en Midaz.
5. TED Lerian envía la TED a Lerian SPB, que la envía al STR.
6. Lerian SPB informa que el STR liquidó la TED.
7. TED Lerian publica transfer.settled.
8. El ERP cierra la factura que encuentra a través de clientReference.

Si la red se cae durante el lote, reenviar una solicitud con la misma clave X-Idempotency no crea una segunda transferencia. Si el STR rechaza la TED, TED Lerian libera la retención y transfer.rejected lleva el motivo.

​

Retiro a la cuenta del cliente en otro banco

---

Un cliente mueve el saldo de tu plataforma a su propia cuenta en otro banco. La app muestra el costo, evita que el saldo se gaste dos veces y avisa al cliente cuando el dinero salió.

1. El cliente solicita el retiro e ingresa los datos bancarios.
2. La app llama a POST /v1/transfers/fee-quotes y muestra la comisión.
3. El cliente confirma.
4. La app envía la TED con POST /v1/transfers.
5. TED Lerian retiene el monto más la comisión en Midaz, así que el saldo no puede gastarse dos veces.
6. TED Lerian envía la TED a Lerian SPB, que la envía al STR.
7. Lerian SPB informa que el STR liquidó la TED.
8. TED Lerian publica transfer.settled.
9. La app avisa al cliente que el retiro está completo.

Si la ventana está cerrada, la cotización devuelve windowOpen como false y la app muestra nextWindowOpensAt antes de que el cliente confirme. Si la TED se rechaza, la retención se libera y el saldo vuelve al cliente.

​

Transferencia entre clientes de la misma institución

---

Cuando el banco del destinatario es tu propia institución, la misma solicitud se convierte en una transferencia interna. Se liquida en una sola transacción de Midaz, también fuera del horario del STR. Los límites de uso y, cuando está configurada, la comisión siguen aplicando.

1. El cliente paga a otro cliente de la misma institución.
2. La app envía POST /v1/transfers con el ISPB propio de la institución como banco del destinatario.
3. TED Lerian encuentra la cuenta del destinatario en el CRM de Midaz.
4. Midaz debita y acredita en la misma transacción.
5. La respuesta vuelve de inmediato con type=INTERNAL y status=SETTLED.

Con saldo insuficiente, la respuesta es 201 con status=REJECTED y TED-0031. Si TED Lerian no encuentra al destinatario, rechaza la solicitud con 422 TED-1021 y no crea nada.

​

Recibir una TED y acreditar al cliente en 60 minutos

---

Un cliente recibe una TED de otro banco. La regla da 60 minutos desde la liquidación interbancaria para acreditarla o devolverla. TED Lerian lo hace sin ningún paso humano en el caso normal.

1. Lerian SPB informa una TED que el STR liquidó. Empieza el plazo de 60 minutos.
2. TED Lerian registra la TED entrante y publica incoming_transfer.received.
3. TED Lerian busca la cuenta y su titular en el CRM de Midaz por agencia, cuenta y documento.
4. TED Lerian verifica que el titular y el tipo de cuenta coincidan.
5. Midaz acredita al cliente.
6. TED Lerian publica incoming_transfer.credited.
7. El sistema de la institución avisa al cliente sobre la TED.

Si la cuenta no existe o pertenece a otro titular, TED Lerian devuelve la TED con el motivo oficial (incoming_return.*). Si no puede decidir, la TED pasa a revisión manual y aparece en la cola del operador.

​

Devolver una TED entrante por sospecha de fraude

---

Una TED se acreditó, pero la institución emisora pide que se devuelva o el equipo de fraude encuentra un problema. El operador ordena una devolución total con el motivo oficial y una justificación que queda en el registro de auditoría.

1. El operador marca la sospecha.
2. El operador lee la línea de tiempo con GET /v1/incoming-transfers/{incomingTransferId}/timeline.
3. El operador ordena la devolución con POST /v1/incoming-transfers/{incomingTransferId}/return, el motivo oficial y una justificación.
4. Midaz revierte el crédito del cliente.
5. TED Lerian envía la devolución a Lerian SPB, que la envía al STR.
6. Lerian SPB informa que el STR liquidó la devolución.
7. TED Lerian publica incoming_return.returned.

Si el STR rechaza la devolución, llega incoming_return.failed y la TED vuelve a revisión manual.

​

Trabajo de back-office en una transferencia sin respuesta

---

Enviaste una TED y no llegó ninguna respuesta a tiempo. TED Lerian mantiene la retención y pide el resultado real a Lerian SPB. Cuando la respuesta automática no es concluyente, un operador decide con evidencia.

1. La transferencia pasa a AWAITING_RECONCILIATION y mantiene la retención.
2. TED Lerian pide el resultado a Lerian SPB.
3. La respuesta no es concluyente.
4. El operador ve el ítem en la cola con GET /v1/reconciliation/queue, con su antigüedad y su plazo.
5. El operador lo desbloquea con POST /v1/transfers/{transferId}/unblock, el resultado y la evidencia del STR.
6. Midaz liquida o libera la retención, según indique el resultado.
7. TED Lerian publica transfer.settled o transfer.rejected.

Cuando la respuesta es concluyente, TED Lerian aplica el resultado por su cuenta y el operador no actúa.