Ingeniería de CRM: Máquinas de Estados Finitos para Flujos de Trabajo Hipotecarios

En el panorama actual del desarrollo de software para el sector fintech, la robustez del código no es un lujo, sino un requisito de cumplimiento. Al diseñar un CRM destinado a la gestión de expedientes de crédito, el error más común es confiar el ciclo de vida del expediente a una serie desordenada de condiciones booleanas. En este contexto, la Máquina de Estados Finitos (FSM – Finite State Machine) emerge como la entidad arquitectónica fundamental para garantizar que procesos complejos, como la concesión de una hipoteca, sigan caminos deterministas y seguros. Este artículo explora cómo aplicar los principios de la ingeniería de sistemas para transformar la lógica de negocio en un motor de flujo de trabajo inatacable, reflejando la experiencia adquirida en el desarrollo de plataformas de alta criticidad como el CRM BOMA.

El Problema de la “Spaghetti Logic” en los CRM Financieros

Imaginad tener que gestionar un expediente hipotecario. En un enfoque ingenuo, el desarrollador podría añadir columnas a la base de datos como is_approved, docs_uploaded, contract_signed. El código resultante para verificar si una hipoteca puede ser concedida se parecería a esto:

if (loan.is_approved && loan.docs_uploaded && !loan.is_rejected) {
  // Desembolsa fondos
}

Este enfoque escala desastrosamente. ¿Qué sucede si el expediente se suspende? ¿Añadimos un flag is_suspended? ¿Y si se reabre? La combinación de N flags booleanos crea 2^N estados posibles, la mayoría de los cuales son estados inconsistentes (ej. un expediente simultáneamente “rechazado” y “pendiente de firma”). Las máquinas de estados finitos resuelven este problema reduciendo el universo de posibilidades a un grafo dirigido de estados válidos y transiciones explícitas.

¿Qué es una Máquina de Estados Finitos (FSM)?

Una FSM es un modelo matemático de cálculo. Es un sistema abstracto que puede encontrarse exactamente en uno de un número finito de estados en un momento dado. La FSM cambia de estado en respuesta a inputs externos; el paso de un estado a otro se llama transición.

Para un CRM de hipotecas, una FSM se define por:

• Estados (S): {BORRADOR, ANÁLISIS, APROBACIÓN, FIRMA, DESEMBOLSADO, RECHAZADO, CANCELADO}
• Eventos/Input (E): {ENVIAR_DOCUMENTOS, APROBAR_CRÉDITO, FIRMA_CLIENTE, REALIZAR_TRANSFERENCIA}
• Función de Transición (δ): Una regla que define: Si estoy en el estado X y ocurre el evento Y, paso al estado Z.

Modelado del Flujo de Trabajo de la Hipoteca

En lugar de preguntarse “¿qué flags están activos?”, nos preguntamos “¿en qué estado se encuentra el expediente?”. Así es como se modela un flujo hipotecario estándar:

1. BORRADOR: El bróker está introduciendo los datos. El único evento posible es ENVIAR_A_ANÁLISIS.
2. ANÁLISIS: El banco analiza los documentos. Eventos posibles: APROBAR (lleva a APROBACIÓN) o RECHAZAR (lleva a RECHAZADO). No es posible ir directamente a DESEMBOLSADO.
3. APROBACIÓN: El crédito está aprobado. Evento: EMITIR_OFERTA.
4. FIRMA: El cliente debe firmar. Evento: REGISTRAR_FIRMA.
5. DESEMBOLSADO: Estado final positivo.

Diagrama de Transiciones (Representación Lógica)

La potencia de las máquinas de estados finitos reside en la prohibición implícita. Si el sistema recibe el evento REALIZAR_TRANSFERENCIA mientras el expediente está en el estado ANÁLISIS, la FSM no debe limitarse a fallar silenciosamente: debe lanzar una excepción de Transición Ilegal. Esto hace que el sistema sea determinista.

Implementación Técnica: Patrones y Código

Para implementar una FSM en un stack backend moderno (ej. Node.js/TypeScript o Python), desaconsejamos el uso de switch/case gigantes. Es preferible utilizar el State Pattern o librerías dedicadas como XState. Aquí un ejemplo de implementación conceptual en TypeScript:

type LoanState = 'DRAFT' | 'UNDERWRITING' | 'APPROVED' | 'DISBURSED' | 'REJECTED';

class MortgageFSM {
  private state: LoanState;

  private transitions = {
    DRAFT: { SUBMIT: 'UNDERWRITING' },
    UNDERWRITING: { APPROVE: 'APPROVED', REJECT: 'REJECTED' },
    APPROVED: { DISBURSE: 'DISBURSED', CANCEL: 'REJECTED' },
    DISBURSED: {}, // Estado terminal
    REJECTED: {}   // Estado terminal
  };

  constructor(initialState: LoanState) {
    this.state = initialState;
  }

  public transition(event: string): void {
    const nextState = this.transitions[this.state][event];
    
    if (!nextState) {
      throw new Error(`Transición inválida: Imposible ejecutar ${event} desde el estado ${this.state}`);
    }

    console.log(`Transición: ${this.state} -> ${nextState}`);
    this.state = nextState;
    this.onStateChange(nextState);
  }

  private onStateChange(newState: LoanState) {
    // Hook para efectos secundarios (ej. envío email, webhooks)
  }
}

Persistencia y Base de Datos

A nivel de base de datos (SQL), la representación más eficiente no es una serie de booleanos, sino una única columna status indexada, a menudo respaldada por un tipo ENUM para garantizar la integridad referencial.

Sin embargo, para pistas de auditoría complejas (requeridas por la normativa bancaria), es aconsejable una tabla separada loan_state_history:

• loan_id (FK)
• previous_state
• new_state
• trigger_event
• timestamp
• user_id (quién desencadenó la transición)

Arquitectura Orientada a Eventos y Efectos Secundarios

La integración de las máquinas de estados finitos con una arquitectura de eventos es donde el CRM se vuelve proactivo. Cada transición de estado válida debe emitir un Domain Event.

El Flujo Reactivo

1. El usuario hace clic en “Aprobar Expediente” en el panel de control.
2. La API invoca la FSM: fsm.transition('APPROVE').
3. La FSM valida la lógica, actualiza la BD y, si tiene éxito, emite el evento LoanApprovedEvent en un message broker (ej. RabbitMQ o Kafka).
4. Consumers desacoplados reaccionan:
   • El Notification Service envía un email al bróker.
   • El Document Service genera el PDF de la resolución.
   • El Audit Service registra la operación para compliance.

Este desacoplamiento impide que la lógica de envío de emails “ensucie” la lógica pura de aprobación del crédito.

Prevención de Estados Inconsistentes (Safety)

En la experiencia de desarrollo de sistemas como BOMA, hemos identificado tres reglas de oro para la seguridad de las FSM:

1. Atomicidad: La transición de estado y el guardado en BD deben ocurrir en la misma transacción de base de datos. Si el guardado falla, el estado en memoria debe ser restaurado.
2. Idempotencia: Si un sistema externo envía dos veces el evento APPROVE, la FSM debe gestionar el segundo intento con gracia (ignorándolo o devolviendo el estado actual), sin crear duplicados o errores.
3. Guardas (Guards): Además de la validez de la transición (A -> B), es posible implementar “guardas”. Ejemplo: “Puedes pasar de ANÁLISIS a APROBACIÓN solo si la suma de los documentos cargados > 5”. Las guardas añaden un nivel de lógica condicional controlada dentro de la estructura rígida de la FSM.

Conclusión

La adopción de las máquinas de estados finitos en el desarrollo de CRM para hipotecas no es solo una elección estilística de código, sino una decisión arquitectónica estratégica. Desplaza la complejidad de la gestión de errores a la fase de diseño, obligando a ingenieros y product managers a definir el proceso de negocio con precisión quirúrgica antes de escribir una sola línea de código. El resultado es un sistema predecible, auditable y, sobre todo, seguro para la gestión de activos financieros.

Preguntas frecuentes