Lapachos Lending : Lend2b - Producto base - Goodyear Chile

Introducción:

En este documento voy a detallar un primer modelo de producto Lend2b.

La idea es plantear un producto muy simplificado, detallando similitudes y diferencias con lo que hemos construido en la DEMO de B2FI. El objetivo es intentar reciclar todo lo que se pueda de lo que ya tenemos desarrollado.

Luego tambien voy a resaltar las mejoras que deberemos ir agregando a este primer MVP, para englobar todas las necesidades del producto, para el caso Goodyear Chile.

Algunas definiciones principales:

• Únicamente operamos con un modelo de extensión de cuentas por pagar. Una cuenta ancla emite facturas para su red de clientes. Se podrá extender el plazo de pago de esas facturas.

• No existirá la posibilidad de ejecutar pagos directos sin financiamiento. Siempre habrá intermediación del Lender.

• Los ecosistemas tienen total independencia entre uno y otro. No hay cruce de información ni conciliación mixta entre ecosistemas.

Definición del modelo financiero:

La vida de una factura o cuenta por pagar/cobrar se dividirá en dos periodos distintos:

1. Financiación directa Goodyear (Cuenta Ancla): periodo entre el momento de la emisión de la factura y el momento de vencimiento original de la misma. Es un periodo único y fijo.

2. Extensión automática: periodo entre el primer vencimiento original y una nueva fecha de cancelación extendida. La distancia (en dias) tambien es única y fija.

Este plan de financiación es UNICO. Esto quiere decir que todo cliente y toda factura (al menos dentro de un mismo ecosistema) tendrá la misma estructura, los mismos plazos (para ambos periodos) y el mismo costo financiero (asumido siempre por la Cuenta Ancla en un 100%).

Las variables que definen el plan de financiación son:

1. Distancia periodo 1: marca los dias que hay entre la emisión y el primer vencimiento de factura.

2. Distancia periodo 2: marca los dias que hay entre el vencimiento original y la fecha única de extensión de la factura.

3. Costo financiero: es la TNA que asume en un 100% la Cuenta Ancla.

Operatoria general:

1. En primer lugar deberán estar definidas esas variables recien detalladas para todo el ecosistema. Debemos crear un flujo de configuración del plan único o que directamente se configure desde el backend sin una interfaz.

2. La carga de la factura la ejecuta la Cuenta Ancla. En esta etapa deberá definir:

• Fecha de emisión

• Monto total

• Cliente

3. El Cliente es quien aprueba la factura. Al momento de hacer la aprobación se esta comprometiendo al plan de financiación que es fijo y esta preestablecido.

4. Llegado el vencimiento del primer periodo el Lender deberá cancelar la deuda que tiene con la Cuenta Ancla, considerando cierto descuento por el costo financiero de la operación. El costo financiero lo asume al 100% la Cuenta Ancla y se calcula considerando el monto, el plazo y la tasa financiera.

5. Luego del vencimiento del segundo periodo el Cliente deberá cancelar su deuda con el Lender. El importe es siempre igual al valor original de la factura, no hay descuento ni tasas extras.

Simplificaciones del modelo - Mejoras a futuro:

1. Plan de financiación único y fijo:

Todo el ecosistema tendrá un único plan de financiación (primario) con variable fijas e inalterables. Por poner un ejemplo, siempre se trabajara con 30 dias iniciales mas 60 dias extras de extensión y con una tasa (TNA) del 1,5% asumida al 100% por la Cuenta Ancla.

Como posible mejora se podrá definir mas de un plan de financiación (primario) por ecosistema o por cliente. El cliente, en el momento de la aprobación de la factura, podrá definir cual de los planes activos le es mas conveniente.

2. Sistema de comisiones básico o nulo:

El modelo teórico tiene un proceso comisional del cual participa Lender - Lend2B - Amex. Podríamos optar por evitar la construcción de un sistema que concilie las distintas comisiones que se van generando durante el procesamiento de facturas. Tambien podríamos definir un sistema comisional mas simplificado y menos desglosado.

3. Morosidad:

Podemos evitar la construcción de los incrementales por morosidad que se dan por la deuda entre Cliente el Lender. En ese caso una deuda no saldada y vencida mantiene su valor original sin sufrir alteraciones hasta el pago final.

4. Proceso de refinanciamiento:

El modelo teórico completo tiene un tercer periodo que no estaríamos contemplando para la primer salida productiva. El distribuidor podrá optar por refinanciar su deuda para re extender el plazo de cancelación.

A diferencia de los dos periodos anteriores, en este caso el costo financiero lo asume el mismo distribuidor con una tasa definida para ese cliente en cuestion.

Hasta no tener construido el flujo de refinanciación quedara por fuera de la plataforma la gestión de esta etapa del proceso.

5. Linea de crédito

Si no es de primera necesidad podemos optar por no construir las lógicas de configuración y alteración de las líneas de crédito para cada cliente del ecosistema.

Si no automatizamos la aprobacion de la solicitud de extension podemos mantener las logicas detras de las lineas y los disponibles por cliente.

6. Rieles de pago automatizados:

En el modelo teórico se definieron dos métodos de pago y cobranza independientes:

• Pay-out: automatización de transferencias salientes para el pago del Lender a la Cuenta Ancla luego del fin del primer periodo.

Podemos, en primera instancia, resolver este movimiento de dinero con transferencias manuales ejecutadas por el Lender. Con estados de transacciones y confirmaciones dobles de movimientos podríamos obtener una solución confiable, que no requiera de servicios externos integrados.

• Pay-in: solicitudes de transferencias pull para el cobro de la deuda de los clientes.

De la misma manera que para la etapa de pago anterior podríamos salir a producción con un proceso de cancelación voluntaria efectuada por cada uno de los clientes del ecosistema. Con estados de transacciones y confirmaciones dobles de movimientos podríamos obtener una solución confiable, que no requiera de servicios externos integrados.

Análisis de MVP B2FI

En este aparto quiero relevar algunas flujos y funcionalidades de la DEMO B2FI que podrán ser total o parcialmente recicladas para la construcción de la primer plataforma productiva.

1. Carga de Factura:

De este proceso hay 3 datos claves que deben mantenerse en los nuevos flujos:

• Fecha de emisión: define el momento exacto de comienzo del primer periodo y marca tambien la referencia para las otras dos etapas.

• Cliente: define a que distribuidor se le asigna la nueva cuenta por pagar

• Monto: valor base para los cálculos de intereses, comisiones, transacciones, etc.

Respecto a la fecha de pago podríamos dejarla como un campo libre a completarse o que se defina automáticamente a partir de la variable que define la distancia del periodo 1.

Los demas campos podrán seguir estando pero no tienen un impacto directo en las lógicas y cálculos.

2. Declinar o Rechazar una nueva factura:

Esos procesos deberían reutilizarse en su totalidad.

3. Aprobación de una Factura:

La aprobación de una factura abre dos posibilidades de ejecución, para el cliente. El pago sin financiamiento y la solicitud de extensión. Para el modelo Goodyear Chile solamente existirá el pago con todo el plan de financiamiento ya fijado.

En este mismo proceso de aprobación se deberá detallar plazo y monto de pago de caras al cliente, ya que al aprobar la factura se esta directamente activando el plan de pago extension.

4. Proceso de pago o de solicitud de extensión:

Estos dos procesos dejaran de existir. La misma acción de aprobación de factura generara la extensión automática con sus respectivas lógicas.

No estará permitido cancelar la deuda sin intervención del Lender. Es por eso que la acción de Pagar se elimina, y secundariamente la transacción asociada de Pago.

5. Proceso de aprobación de la solicitud de extensión

¿Necesitamos de un proceso manual de aceptación por parte del Lender?

¿Tendrá que existir una linea de crédito que defina automáticamente la decision?

Estas respuestas definirán como avanzar respecto a esta etapa del flujo.

6. Transaccionalidad asociada - “Cancelación” y “Extensión”

Creo que vamos a poder usar la misma estructura de transacciones asociadas a la entidad base, que es la factura original.

En lo que respecta al pago Lender → Cuenta Ancla tenemos la transacción de “Cancelación” en representación.

Luego, respecto al pago Cliente → Lender, tenemos la transacción de “Extensión”.

Lo que si deberemos retrabajar es en la parte del calculo y desglose de esas transacciones.

Por ejemplo:

• la comisión es un valor independiente al interés (en la DEMO). No asi en el modelo Goodyear.

• la extensión tiene calculo de mora luego de vencido el plazo.

7. Comisiones

• Comisión de extensión: porcentaje del total de la factura a pagar por Cuenta Ancla y por el Cliente en la proporción definida por el % trasladado. Se ejecuta al momento de pagar la transacción de Cancelación.

Esta comisión puede ser reciclada para usarla en la comisión del día 30. La gran diferencia es que es asumida siempre en un 100% por la Cuenta Ancla, que es variable respecto al tiempo y que es distribuida en una proporción especifica a Lendb2 y a AMEX.

• Comisión de extensión: es la comisión que paga el Lender al momento de efectuarse la transacción de extensión. Es un % sobre el total de esa transacción (incluyendo el extra por mora).

Creo que tambien podemos reciclar esta comisión para usarla en la del día 90. La paga Lender a Lend2b, eso es igual. La diferencia esta en que es una variable dependiente del tiempo (tipo tasa). No debe tener en consideración la mora.

Considero que no es vital tener esta solución construida para el MVP. Podríamos conciliar la parte comisión por fuera de la plataforma, sin mayor esfuerzo.

8. Linea de Crédito

En principio podemos reciclarla al 100%, ya que mantenemos el proceso de aprobación de la solicitud de extensión de manera manual.

9. Onboarding de Cliente