Skip to content

ADR-008: Validacion de Identidad Post-Aprobacion

Estado: Aceptada
Fecha: 2026-05-18
Autor: Equipo de Arquitectura

Contexto

La validacion de identidad (biometria facial, liveness detection, OCR de documentos) es un paso costoso en el proceso de originacion. Los proveedores cobran por transaccion:

  • Validacion biometrica: ~$0.50 - $2.00 USD por transaccion
  • Liveness detection: ~$0.30 - $1.00 USD por transaccion
  • OCR de documento: ~$0.20 - $0.50 USD por transaccion

En un flujo tipico, un porcentaje significativo de solicitudes son rechazadas antes de llegar a la validacion de identidad:

  • ~30% rechazadas por score crediticio insuficiente
  • ~10% rechazadas por listas de AML/PEP
  • ~5% rechazadas por politicas internas del tenant

Si la validacion de identidad ocurre antes de la decision crediticia, se paga el costo de validacion para solicitudes que seran rechazadas de todas formas. En un volumen de 10,000 solicitudes/mes con 45% de rechazo, esto representa un desperdicio de ~$4,500 - $13,500 USD mensuales.

Decision

La validacion de identidad ocurre despues de la aprobacion crediticia por defecto. En el pipeline configurable (ADR-006), el paso identity_validation tiene la configuracion trigger: "after_approval".

Configuracion del Paso

json
{
  "type": "identity_validation",
  "order": 8,
  "required": true,
  "config": {
    "trigger": "after_approval",
    "provider": "imagflow_identity",
    "checks": ["biometric", "liveness", "document_ocr"],
    "skip_if_validated_within_days": 90,
    "on_failure": "cancel_approval",
    "max_attempts": 3
  }
}

Flujo por Defecto (Post-Aprobacion)

Flujo Alternativo (Pre-Aprobacion)

Para tenants que prefieren validar identidad antes de la decision crediticia, pueden reordenar el paso en la configuracion del pipeline:

json
{
  "type": "identity_validation",
  "order": 3,
  "required": true,
  "config": {
    "trigger": "before_approval",
    "provider": "imagflow_identity",
    "checks": ["biometric", "liveness", "document_ocr"]
  }
}

Logica de Skip

Si el solicitante ya fue validado dentro de los ultimos N dias (configurable), el paso se omite automaticamente:

typescript
async canSkip(context: PipelineContext, config: StepConfig): Promise<boolean> {
  const lastValidation = await this.getLastValidation(context.userId);
  if (!lastValidation) return false;

  const daysSinceValidation = differenceInDays(new Date(), lastValidation.date);
  return daysSinceValidation <= config.skip_if_validated_within_days;
}

Alternativas Consideradas

AlternativaProsContras
Siempre validar antes de aprobacionMaxima seguridad, no hay cancelaciones post-aprobacionCosto elevado por validaciones desperdiciadas en rechazos
Validar solo para perfiles de alto riesgoReduce costos parcialmenteReglas complejas para determinar riesgo, posibles falsos negativos
Nunca validar identidadCero costo de validacionRiesgo de fraude inaceptable, no cumple regulacion
Validar post-aprobacion por defecto (elegida)Ahorro significativo, configurable por productoRiesgo de cancelacion post-aprobacion si identidad falla

Consecuencias

Positivas

  • Ahorro significativo en costos de proveedores de identidad (solo se validan creditos aprobados)
  • Configurable por producto: cada tenant decide segun su apetito de riesgo
  • La logica de skip evita validaciones redundantes para usuarios recurrentes
  • Compatible con el pipeline configurable (ADR-006): es solo un cambio de orden

Negativas

  • Un credito aprobado puede ser cancelado si la validacion de identidad falla post-aprobacion
  • Experiencia de usuario potencialmente confusa: "tu credito fue aprobado" seguido de "necesitamos validar tu identidad"
  • Requiere comunicacion clara al usuario sobre el estado condicional de la aprobacion

Riesgos

  • Fraude: un solicitante podria usar datos de otra persona para obtener aprobacion y luego fallar la validacion (mitigacion: la aprobacion es condicional, no se desembolsa sin validacion)
  • Regulatorio: algunos reguladores podrian exigir validacion previa (mitigacion: configurable por tenant/producto)
  • UX: el usuario podria percibir la cancelacion post-aprobacion como injusta (mitigacion: comunicacion clara de "aprobacion condicional")

Referencias

Reimagine Tech LLC — Documentacion Interna