REDEC

Esta página es la referencia de REDEC por concepto. Para el recorrido de punta a punta, ve al flujo REDEC.

El boundary

Es permanente y conviene tenerlo presente en cada decisión de diseño:

otorgamiento → Evidence constitutiva + internalConsentCode (artifact pending | ready)
Consensa autoriza → authorized | denied (no depende del artifact)
authorized → el banco/reportante consulta la CMF directamente
banco/reportante → Consensa confirma accessed | failed | cancelled

Consensa no consulta /consultarDeudas, no recibe ni almacena deuda CMF y no custodia credenciales CMF del reportante.

REDEC es un producto que Consensa habilita por tenant. Mientras no lo esté, las operaciones REDEC responden 403 con REDEC_NOT_ENABLED; si el producto está habilitado pero el tenant no completó su configuración REDEC, 422 REDEC_NOT_CONFIGURED. Revocar, terminar una extensión por crédito y confirmar un acceso ya autorizado siguen disponibles siempre, para que las obligaciones vigentes y los derechos del titular puedan honrarse.

Cómo se captura el consentimiento

La forma soportada en estas guías es el Embed de Consensa: creas una Embed Session sobre un Flow que contiene REDEC y el titular decide en tu página. La captura es síncrona y el reloj regulatorio es la recepción de Consensa (grantedAt = recordedAt). Todo el detalle está en el flujo REDEC.

Finalidad, objetivos y sistema origen de la obligación se congelan al publicar el Flow. Tu backend no los envía: vienen de redecConfiguration en la metadata del Flow.

Existe además una captura diferida para consentimientos obtenidos fuera de Consensa (teléfono, presencial, respaldo físico), con POST /v1/redec/consent-interactions y su otorgamiento. Tiene reglas propias de occurredAt, provenance y evidencia de canal; su contrato completo está en la API Reference. Si vas a usarla, conversa antes el Regulatory Profile que aplica a tu canal.

El código interno del consentimiento

internalConsentCode es el código interno regulatorio (NCG 540 §7.3). Lo genera Consensa al registrar el otorgamiento, es único en tu tenant y no cambia. Nunca se acepta como entrada: un otorgamiento que lo traiga responde 400 VALIDATION_ERROR con internal_consent_code_is_server_generated.

Identifica el consentimiento en el aviso al titular, en el RDC30 y en la búsqueda por código.

Lectura regulatoria

GET /v1/redec/consents/{redecConsentId} entrega la representación regulatoria vigente: los valores congelados al otorgar (código interno, canal, clase de captura, finalidad, medio, objetivos) y el estado derivado de los hechos posteriores (revocación, corrección de revocación, extensiones por crédito).

{
  "redecConsentId": "redec-consent-9c2",
  "internalConsentCode": "R0K7Q2M9X4V8B1N6C3Z",
  "customerId": "customer-tenant-4f1",
  "status": "extended",
  "revocable": false,
  "channel": "digital",
  "captureTiming": "synchronous",
  "grantedAt": 1787702400000,
  "initialAccessValidUntil": 1789430400000,
  "retentionUntil": null,
  "retentionBasis": null,
  "finalityCode": "2",
  "mediumCode": "1",
  "objectiveCodes": ["01"],
  "revocation": { "revokedAt": 1787788800000, "channel": "digital", "effective": false, "correctedAt": 1787875200000 },
  "creditExtensions": [
    { "creditExtensionId": "credit-extension-77a", "objectiveCode": "01", "creditOperationReference": "OP-2026-000981",
      "creditGrantedAt": 1787702460000, "extendedAt": 1787875200000, "status": "active", "endReason": null, "endedAt": null }
  ],
  "artifactStatus": "ready",
  "artifactDeliveryReady": true
}

• status: granted (ventana inicial), extended (hay una extensión sin término; no es revocable), revoked (revocación efectiva) o expired (ya no habilita accesos y no fue revocado efectivamente).
• revocable anticipa si una revocación sería aceptada ahora. La operación de revocación sigue siendo la autoridad.
• retentionUntil / retentionBasis: piso mínimo de conservación de 5 años desde la revocación efectiva, la pérdida de vigencia o la extinción de la obligación. Es null mientras el consentimiento sigue vigente o extendido. No es una fecha de borrado automático.
• Si el titular revocó pero el crédito ya se había otorgado antes, la revocación queda en revocation con effective: false: Consensa la conserva como hecho y no la presenta como revocación efectiva.

Para ubicar un consentimiento sin su id usa GET /v1/redec/consents?internalConsentCode=... o GET /v1/redec/consents?creditOperationReference=... (exactamente uno). Responde { "consents": [...] }; un valor desconocido o de otro tenant devuelve una lista vacía.

Evidence y Artifact

Evidence ≠ Artifact. Un consentimiento REDEC tiene superficies separadas:

Consentimiento REDEC
├── estado
├── evidence
└── artifact, cuando corresponde

GET /v1/redec/consents/{redecConsentId}/evidence muestra la vista auditable del hecho regulatorio: decisión, timestamps, template, autenticación/provenance, profile, canal, finalidad, objetivos y timing canónico. No contiene deuda CMF ni bytes documentales.

GET /v1/redec/consents/{redecConsentId}/artifact muestra metadata pública como estado, tipo de medio, origen, MIME y hash de contenido. Un Artifact puede ser un PDF generado, un PDF externo o un audio/original capturado cuando el profile y canal lo permiten; no se promete un PDF universal.

GET /v1/redec/consents/{redecConsentId}/artifact/download descarga únicamente los bytes exactos de un Artifact listo y custodiado por Consensa. Los recursos externos no se proxifican y un Artifact pending no es descargable.

Readiness: para descargarlo, no para autorizar

El consentimiento vale desde el otorgamiento: su Evidence constitutiva, alcance y vigencia son lo que evalúa POST /v1/redec/accesses/authorize, aunque el respaldo siga en artifactStatus: "pending". NCG 576 no exige hash para autorizar.

Si necesitas el respaldo —por ejemplo, para responder a la CMF por tus canales— y el otorgamiento respondió artifactStatus: "pending", consulta GET /v1/redec/consents/{redecConsentId} con polling acotado y backoff hasta observar artifactStatus: "ready", o suscríbete al evento redec.consent_artifact.ready en Webhooks. No uses polling agresivo ni asumas un SLA que no haya sido acordado para tu ambiente.

artifactStatus: "ready" no es una autorización: sólo indica que el artifact está custodiado y es descargable.

Custodia completa

GET /v1/redec/custody?internalConsentCode=... resuelve en una sola llamada el comprobante generado, el artifact de origen (si existe) y los compromisos append-only que ligan cada uno a la Evidence de la que deriva. Es útil para preparar una respuesta a la CMF.

Es un formato interno de producto de Consensa: no es un payload API2/API3 de la CMF y no implica que Consensa implemente ningún transporte hacia la CMF.

Autorizar el acceso externo

Antes de cada consulta a la CMF, el backend llama POST /v1/redec/accesses/authorize. Hay tres bases:

{
  "authorizationBasis": "consent",
  "consentAuthorizationMode": "initial_window",
  "redecConsentId": "redec-consent-9c2",
  "dataCategoryCode": "redec.consolidated_debt_record",
  "scopeId": "scope-credit-information",
  "objectiveCode": "01",
  "reportingObligation": {
    "status": "none",
    "sourceSystem": "core-banking",
    "sourceReference": "obligation-check-4821",
    "assertedAt": 1787702460000
  },
  "sourceSystem": "bank-channel",
  "sourceReference": "access-request-882"
}

Sólo una decisión explícita "status": "authorized" habilita al reportante para continuar. "denied" (con denyReasonCode) es una decisión de negocio durable; un timeout o error nunca equivale a una autorización. La respuesta es { "decision": { … }, "replayed": false }.

Confirmar el resultado

El reportante consulta la CMF directamente con sus propias credenciales. Luego ejecuta POST /v1/redec/accesses/{redecAccessId}/confirm con exactamente uno de estos outcomes:

{ "outcome": { "kind": "accessed", "accessedAt": 1787702475000 } }

{ "outcome": { "kind": "failed" } }

{ "outcome": { "kind": "cancelled" } }

No envíes a Consensa el payload de deuda ni las credenciales usadas para acceder a la CMF.

Ciclo de vida del crédito

Si otorgas un crédito bajo el consentimiento, tu core bancario lo informa con POST /v1/redec/consents/{redecConsentId}/credit-extensions. El consentimiento sigue vigente más allá de la ventana inicial mientras exista la obligación. Si el titular ya había revocado, Consensa registra la corrección de la revocación.

{
  "customerTenantId": "customer-tenant-4f1",
  "objectiveCode": "01",
  "creditOperationReference": "OP-2026-000981",
  "creditGrantedAt": 1787702460000,
  "sourceSystem": "core-banking",
  "sourceReference": "ledger-9"
}

Si la extensión se registra después de que Consensa ya había aceptado una revocación (creditGrantedAt anterior a revokedAt), la corrección append-only que deja esa revocación sin efecto exige sourceReference no vacío en el body — una referencia checkeable del sistema fuente al otorgamiento del crédito. Sin ella, el registro se rechaza con redec_revocation_correction_requires_source_reference.

Cuando la obligación se extingue o se ejecuta la aceleración, informa el término una sola vez con POST /v1/redec/consents/{redecConsentId}/credit-extensions/{creditExtensionId}/end y endReason obligation_extinguished, acceleration_executed o superseded_by_new_obligation (refinanciamiento: la obligación fue reemplazada por una nueva). Este último exige supersededByObligationReference con la creditOperationReference de la obligación nueva — la nueva obligación no hereda este consentimiento; necesita su propio tratamiento. Ambas operaciones requieren Idempotency-Key.

POST /v1/redec/accesses/authorize con consentAuthorizationMode: "credit_lifecycle_extension" exige además accessPurpose: "manage_existing_obligation" (la única forma de obtener authorized) o "evaluate_new_credit" — este último es un "denied" auditable (redec_credit_extension_purpose_not_obligation_management), nunca un error de validación: la extensión sólo gestiona la EXACTA obligación de la que nació, nunca una evaluación de crédito nueva para el mismo cliente.

Cartera anterior a REDEC

POST /v1/redec/legacy-credit-relationships registra, una vez por cliente y operación, que mantienes un crédito originado antes del 1 de abril de 2026 (00:00 hora de Chile). No es un consentimiento: no crea ConsentAction, permisos ni un consentimiento REDEC. El redecLegacyCreditRelationshipId que devuelve es la base de un authorize con authorizationBasis: legacy_pre_redec_credit. Un crédito originado en la fecha de corte o después se rechaza con redec_legacy_cutoff_not_met.

Código de consentimiento para RDC01/RDC02

Cuando el banco confirma que una obligación fue efectivamente otorgada, registra la relación exacta con POST /v1/redec/reportable-obligations/bindings (consent:runtime, Idempotency-Key). Este hecho no se crea al evaluar un otorgamiento: la evaluación puede terminar sin crédito.

El lookup GET /v1/redec/reportable-obligations/consent-code?sourceSystem=...&obligationReference=... (consent:read) usa ambos componentes de la identidad de la obligación y nunca busca por cliente, por consentimiento más reciente ni por una operación parecida. Devuelve una semántica explícita en resolution, y el valor exacto del campo X(20) en serializedValue:

Los 9 y los 0 son sólo serialización en la frontera MSI; no se persisten como códigos internos ficticios. Registrar una extensión de ciclo de vida produce naturalmente el mismo binding exacto, pero la extensión no es requisito para obligaciones sin ese lifecycle.

Notificación al titular

La obligación de entrega nace del evento redec.notification.required, que Consensa emite apenas registra un otorgamiento o una revocación. Ver Webhooks para el envelope, la firma y los reintentos.

Quién notifica se elige por Flow con la opción "Consensa notifica al titular por email" (activa por defecto en Flows nuevos del Portal) y queda congelado al publicar cada versión. No existe una política a nivel tenant.

• Consensa notifica (consensa + email). Al crear la sesión (POST /v1/embed/sessions) debes enviar en identifiers exactamente un email del cliente junto a su RUT, por ejemplo { "system": "email", "type": "email", "value": "cliente@ejemplo.cl" }; sin él la sesión se rechaza con redec_notification_email_required. En el Embed, el titular ve ese email enmascarado y lo confirma, o indica otro que se usa solo para esa notificación (no se guarda en el cliente). Consensa envía el aviso en nombre de tu organización (nombre de branding), con fecha y hora de Chile, canal y código interno.
• Tu organización notifica (tenant + tenant_determined). Consensa emite redec.notification.required y tu organización registra después la evidencia del envío.

Consensa conserva cada destino como una designación cifrada e inmutable y envía de forma asincrónica. Outbox, Queue y logs solo transportan IDs opacos, nunca el email en claro. Un destino que envía el backend de tu organización (por ejemplo, al revocar por API un consentimiento que Consensa notifica) queda registrado como afirmado por tu organización, no como confirmación del titular.

sent significa aceptación del proveedor, no entrega. Sin un evento autenticado del proveedor no se infiere delivered ni bounced. Si el worker pierde la respuesta o cae después de iniciar el request, el intento queda outcome_unknown y no se reenvía automáticamente. Ese estado, igual que failed o bounced, es operacional y no resuelve por sí mismo el efecto jurídico sobre la autorización REDEC. Consensa no promete exactly-once end-to-end.

Registrar la evidencia del envío

Después de enviar el aviso, regístralo con POST /v1/redec/consents/{redecConsentId}/notification-evidence (consent:runtime, Idempotency-Key).

Para hechos ocurridos desde el 14 de octubre de 2026 (hora de Chile) y estados sent o delivered, son obligatorios destination, contentType y contentBase64: el destino real y la copia exacta del mensaje. Consensa calcula el SHA-256 en el servidor, guarda la copia en almacenamiento privado y protege el destino con cifrado por tenant e índice ciego. Si faltan, la respuesta es 400 notification_copy_and_destination_required.

{
  "notificationReason": "grant",
  "notificationChannel": "email",
  "deliveryAttemptId": "attempt-5521",
  "destination": "titular@ejemplo.cl",
  "status": "sent",
  "sentAt": 1787702520000,
  "provider": "bank-mailer",
  "providerMessageId": "msg-5521",
  "sourceSystem": "bank-notifications",
  "sourceReference": "notice-grant-5521",
  "contentType": "text/plain; charset=utf-8",
  "contentBase64": "Q29uc3RhbmNpYSBkZSBjb25zZW50aW1pZW50bw=="
}

Para estados que no exigen copia (requested, failed, bounced), puedes registrar el hecho con recipientHash y contentSha256 en lugar del destino y la copia. Uno de los dos caminos es obligatorio: sin destination ni recipientHash la respuesta es destination_or_recipient_hash_required, y sin copia ni contentSha256, content_sha256_required.

Reglas que conviene tener a mano:

• Consensa ancla la evidencia al otorgamiento o a la revocación del consentimiento; no envíes consentActionId, internalConsentCode ni identificadores del cliente (la respuesta los devuelve). Una evidencia revoke antes de la revocación responde redec_consent_not_revoked.
• La evidencia es append-only: registra cada estado de entrega que conozcas (requested, sent, luego delivered o bounced) como una llamada nueva con su propia Idempotency-Key. Todos los estados del mismo intento comparten deliveryAttemptId; un retry usa otro ID.
• sent y delivered exigen sentAt; delivered exige además deliveredAt. Las fechas no pueden ser anteriores al hecho notificado ni posteriores a la recepción de Consensa.
• No existe una notificación de corrección: si una revocación se corrige por un crédito ya otorgado, la lectura regulatoria refleja el estado correcto.

Para auditar o reconciliar: GET /v1/redec/notification-requirements lista las obligaciones con su estado conocido, GET /v1/redec/notification-evidence/{notificationId} devuelve la metadata de un registro y GET /v1/redec/notification-evidence/{notificationId}/copy descarga la copia custodiada, reverificando su SHA-256 antes de entregarla.

Revocar un consentimiento REDEC

Cuando el titular revoca, llama a POST /v1/redec/consents/{redecConsentId}/revoke con una Idempotency-Key estable para esa operación. Un retry exacto devuelve el mismo resultado; reutilizar la clave con un request distinto produce conflicto.

curl --request POST "$CONSENSA_API_URL/v1/redec/consents/$REDEC_CONSENT_ID/revoke" \
  --header "Authorization: Bearer $CONSENSA_API_KEY" \
  --header "Content-Type: application/json" \
  --header "Idempotency-Key: redec-revoke-$REDEC_CONSENT_ID-01" \
  --data '{
    "channel": "digital",
    "occurredAt": 1787702460000,
    "sourceType": "direct",
    "identityAssurance": "client_authenticated"
  }'

La revocación queda registrada por el flujo canónico y los permisos REDEC dejan de habilitar nuevos accesos según las reglas de dominio existentes. El valor de assurance debe corresponder a la evidencia real aceptada para el canal y profile.