ADR-006: Pipeline Configurable de Originacion de Credito
Estado: Aceptada
Fecha: 2026-05-18
Autor: Equipo de Arquitectura
Contexto
La originacion de credito requiere flexibilidad: diferentes productos financieros necesitan diferentes pasos, en diferente orden y con diferentes requisitos. Un wizard rigido de 6 pasos no funciona para todos los casos. Por ejemplo:
- Un credito de nomina puede omitir la validacion de identidad si el empleador ya la hizo.
- Un microcredito puede requerir solo consentimiento legal y desembolso.
- Un credito hipotecario necesita revision manual, documentos adicionales y firma notarial.
Cada tenant puede tener multiples productos, cada uno con su propio flujo de originacion.
Decision
Implementar un pipeline configurable por producto. Cada producto define en su configuracion cuales pasos incluir, su orden, cuales son obligatorios y la configuracion especifica de cada paso.
Tipos de Pasos Disponibles
| Tipo | Descripcion |
|---|---|
landing | Pagina de entrada con informacion del producto |
user_registration | Registro del solicitante en el sistema |
legal_consent | Aceptacion de terminos y condiciones |
contact_verification | Verificacion de email/telefono (OTP) |
form | Formulario dinamico de captura de datos |
compliance_check | Validacion automatica (bureau, AML, scoring) |
manual_review | Revision humana del caso |
identity_validation | Validacion biometrica y documental |
document_signature | Firma electronica de contratos |
disbursement | Desembolso del credito |
Configuracion por Producto
json
{
"product_id": "microcredito-express",
"pipeline": {
"steps": [
{
"type": "landing",
"order": 1,
"required": true,
"config": { "template": "express" }
},
{
"type": "user_registration",
"order": 2,
"required": true,
"config": { "fields": ["email", "phone", "full_name"] }
},
{
"type": "legal_consent",
"order": 3,
"required": true,
"config": { "documents": ["terms_v2", "privacy_policy"] }
},
{
"type": "contact_verification",
"order": 4,
"required": true,
"config": { "method": "sms_otp", "max_attempts": 3 }
},
{
"type": "form",
"order": 5,
"required": true,
"config": { "schema_id": "microcredito_datos_basicos" }
},
{
"type": "compliance_check",
"order": 6,
"required": true,
"config": { "checks": ["bureau", "aml_basic"] }
},
{
"type": "document_signature",
"order": 7,
"required": true,
"config": { "provider": "imagsign", "type": "simple" }
},
{
"type": "disbursement",
"order": 8,
"required": true,
"config": { "method": "bank_transfer" }
}
]
}
}Arquitectura del Pipeline
Cada paso es un modulo independiente que implementa una interfaz comun:
typescript
interface PipelineStep {
type: StepType;
execute(context: PipelineContext, config: StepConfig): Promise<StepResult>;
validate(context: PipelineContext, config: StepConfig): Promise<ValidationResult>;
canSkip(context: PipelineContext, config: StepConfig): boolean;
}Alternativas Consideradas
| Alternativa | Pros | Contras |
|---|---|---|
| Wizard rigido de 6 pasos (diseno original) | Simple de implementar, predecible | No escala a multiples productos, cambios requieren codigo |
| ImagFlow como motor del pipeline | Reutiliza infraestructura existente | Demasiado generico para logica financiera, overhead innecesario |
| Codigo custom por producto | Maxima flexibilidad | No escala, duplicacion masiva, imposible de mantener |
| Pipeline configurable por producto (elegida) | Flexible, escalable, configurable sin codigo | Mayor complejidad inicial de implementacion y testing |
Consecuencias
Positivas
- Maxima flexibilidad por tenant y producto sin cambios de codigo
- Cada paso es un modulo independiente que se puede habilitar/deshabilitar
- Nuevos productos se crean con configuracion, no con desarrollo
- Testing aislado por modulo: cada step tiene sus propios tests
- Soporte nativo para persistencia multi-sesion (el usuario puede abandonar y retomar)
Negativas
- Mayor complejidad de implementacion inicial vs un wizard simple
- Requiere un framework robusto de validacion de configuraciones
- Testing de integracion mas complejo (combinaciones de pasos)
- Curva de aprendizaje para el equipo de producto al configurar pipelines
Riesgos
- Configuraciones invalidas podrian generar pipelines rotos (mitigacion: validacion en tiempo de configuracion)
- Demasiados tipos de pasos podrian fragmentar el esfuerzo de desarrollo
- La interfaz comun de steps podria ser demasiado restrictiva para casos edge