Registro de Cambios

​

Política por código de advertencia KYC

​

Idioma configurable de validación

​

Reactivación segura de onboarding

​

Compartir matrices, listas y webhooks con canales

​

Reportes manuales de riesgo transaccional

​

Demografía CUIT en accounts-count

​

CNAE principal en fichas de empresas brasileñas

​

GET de enrichment normalizado y datos actuales

• Obtener enrichment normalizado — GET /entities/{id}/normalized-enrichment. Dossier Gu1 NormalizeType (RootData + consolidadores + summaries). 404 NOT_FOUND si la entidad aún no tiene fila normalizada.
• Obtener datos actuales de enrichment — GET /entities/{id}/enrichment-data. Últimos payloads mapped / raw por código de integración. Si la entidad existe pero no hay snapshot, HTTP 200 con hasEnrichmentData: false.

​

statusIds en los in-list de CPF

• CUIT in-list: statusIds, asRecipientStatusIds, asInitiatorStatusIds.
• Account in-list: statusIds.

{
  "field": "services.cpf.in_list",
  "operator": "eq",
  "value": true,
  "serviceCuitFieldPath": "destinationTaxId",
  "serviceCpfMode": "both",
  "serviceCpfStatusIds": ["2"]
}

​

Mensajes error para integradores

​

Rutas de cuentas por external ID y tax ID

• /entities/by-external-id/{externalId}/accounts
• /entities/by-tax-id/{taxId}/accounts

​

Identificación fiscal KYB en España (autónomos)

​

Cuentas de entidades

​

Espera de rate limit en el body del 429

​

Filas automáticas vs manuales

​

Concurrencia de importaciones masivas y tope de filas de entidades

​

Retención por archivo en el historial

​

Cierre de cargas relacionadas

​

Dispositivos de una entidad y sus relaciones directas

​

jobFailure.code: ARTIFACT_UPLOAD_FAILED y QUEUE_ERROR

• ARTIFACT_UPLOAD_FAILED — no se pudo almacenar el payload o el archivo fuente; el worker no tenía nada que retomar.
• QUEUE_ERROR — la cola rechazó el encolado y el job nunca arrancó.

​

validate-csv: avisos por fila en mapeos de transacción

• Nuevo totalRows a nivel raíz, junto al sampledRows que ya existía.
• Cada entrada de warnings puede traer field, value, allowedValues y occurrences. Los code, message, row y column existentes no cambian.
• Nuevo código de aviso INVALID_ENUM_VALUE. Ante un código desconocido, usá message como respaldo.
• Los avisos se agrupan por problema en vez de emitirse por fila: una entrada informa la primera fila afectada más occurrences. Si contabas warnings.length como “filas con problemas”, leé occurrences.

​

Nuevo estado de entidad: awaiting_information

• Podés enviar status: "awaiting_information" en create o PATCH como cualquier otro valor de ciclo de vida.
• El analista de onboarding setea este estado cuando envía el correo de pedido de documentos y guarda el estado anterior en el pedido. Cuando el merchant carga los documentos (o el operador acepta/descarta el intake), Gu1 restaura ese estado — salvo que un operador lo haya cambiado o bloqueado mientras esperaba.
• awaiting_information no bloquea operaciones como blocked / suspended / rejected.

​

Servicio marketplace: Central de Prevención de Fraude (CPF)

• Base: /api/integration-services/ar_gueno_cpf_service
• Reglas: services.cpf.*
• In-list (availableCount=true): también devuelve importes acumulados (totalAmount, importes por rol)
• Distinto de BCRA Central de Deudores

​

Reporte de entidad: riesgo vigente y screening AML explícitos

• riskSummary (nuevo): riesgo vigente del reporte. mode es manual, automatic o not_evaluated. Con override manual activo, effective trae el score manual, manual incluye justificación, usuario, fecha y score anterior, y automatic.supersededByManual marca el score de matriz como histórico. Antes el reporte mostraba el score de matriz aunque el operador hubiera fijado el riesgo a mano.
• amlScreening (nuevo): una fila por proveedor de listas con matchStatus, totalHits / relevantHits, listNames, reportedRiskLevel (valor crudo del proveedor, incluido unknown cuando así lo envían) y effectiveRiskLevel + riskLevelSource (nivel derivado de las coincidencias cuando hace falta internamente). El PDF muestra el reportedRiskLevel cuando existe.
• checks[]: se suman screeningType, executionStatus (completed / failed), matchStatus y effectiveRiskLevel opcional. matchStatus puede ser undetermined: un check sin screening normalizado ya no se presenta como “No Match”.
• Impacto para integradores: los campos son aditivos y no cambian los ya existentes. Si tu integración inferías “sin coincidencias” desde checks[], leé amlScreening o checks[].matchStatus y tratá undetermined como “no concluyente”.

​

Transacciones: largo de MCC más flexible

​

AML Crypto: paridad del flujo cliente

• Los endpoints de ejecución responden { success, data } con checkId opcional cuando se guarda un snapshot.
• GET /aml-crypto/checks soporta filtros + paginación (total, limit, offset).
• GET /aml-crypto/checks/:id devuelve un check por org.
• Permisos: aml_crypto:read (historial) y aml_crypto:execute (consultas).

​

POST /automations/from-template crea siempre deshabilitada

• Impacto para integradores: después de from-template, activar explícitamente con POST /automations/:id/toggle.
• No cambian campos de request ni de response.

​

Plantilla de automation: monitoreo de entidades (programada)

• Nueva plantilla entity_monitoring_scheduled: cron → fetch_entities (filtros preconfigurables) → run_risk_matrix (matriz elegida). Se crea deshabilitada.
• Knobs de preconfig: frecuencia/hora/zona, builder de filtros, límite de listado, riskMatrixId.

​

Plantillas de automation: preconfig + alerta → email

• GET /automations/templates puede incluir parameterDefinitions (path + mirrorPaths opcionales).
• POST /automations/from-template acepta paramValues opcional. Params requeridos faltantes → 400.
• Nueva plantilla alert_created_email_notify: ante alert_created, envía email con send_push_notification (reglas, severidades, destinatarios, plantilla). Se crea deshabilitada.

​

Presets editables + preview + CSV/PDF

​

Generar reporte → async S3 + Descargables

• alerts_by_rules ya no devuelve un XLSX sincrónico ni contentBase64 en la respuesta del run.
• La automation send_report / Generar reporte prioriza reportPresetId; con sendEmail opcional (+ recipientEmails) también envía el archivo por correo.
• Investigaciones, ficha de entidad (PDF) y Metrics Hub con delivery: "download" ya no responden skipped por falta de destinatarios: encolan el job y el archivo queda en Descargables. Los reportes de ficha y métricas se listan con kind: "documents".

​

API de presets de reportes

​

API de plantillas de reportes

​

Automatizaciones por cambio de estado de investigación

• Nuevos orígenes que disparan automatizaciones: avanzar o retroceder de etapa (En progreso ↔ Pendiente de revisión y cierre por etapa), reapertura de un caso cerrado, acciones de agente, la acción change_status / start_investigation de otra automatización y el pipeline automático de resolución. Antes ninguno de estos emitía el evento, por lo que las automatizaciones sobre PENDING_REVIEW nunca corrían.
• Ya no se emite cuando el estado no cambia: reenviar el estado actual (por ejemplo CLOSED sobre un caso cerrado) deja de generar notificaciones duplicadas.
• Estado anterior en el contexto: nueva condición investigation.previousStatus y nueva variable de plantilla {{investigation.previousStatus}}, más investigation.transitionSource para saber de dónde vino el cambio.
• Nuevas plantillas de email de sistema por estado: investigation_in_progress_email_*, investigation_pending_review_email_*, investigation_closed_email_* e investigation_reopened_email_* (es / en / pt).
• El selector de estado en las condiciones ahora ofrece los cuatro estados reales del flujo, incluido Pendiente de revisión.

​

Nuevo estado de entidad: not_started

• El default al crear sigue siendo under_review para no romper integraciones existentes.
• Enviá status: "not_started" en create (manual, automática o bulk) para usarlo.
• Las etiquetas de matriz y las reglas updateEntityStatus pueden pasar de not_started a under_review, active, rejected, blocked, etc. — no hay paso intermedio obligatorio.
• Tabla completa y flujos de ejemplo: Descripción general — Estados.

​

Delta y % de cambio totales (CBU+CVU) en metrics

• totalDelta — cbuDelta + cvuDelta
• totalPctChange — % sobre el stock total al inicio (null si start = 0)
• totalAccountsStart / totalAccountsEnd — stock CBU+CVU en los extremos de la ventana

​

autoExecuteIntegrations.enrichments se filtra por país y tipo de entidad

• Aplica a enrichments, enrichmentGroupRefs y executeAllActiveEnrichments, tanto en la entidad principal como en las relacionadas (autoExecuteIntegrationsShareholders).
• No cambia la habilitación por organización, los bloqueos de integración ni las cadenas de fallback: acá solo se valida cobertura de país / tipo de entidad.
• Impacto: los requests que mezclaban códigos de otro país dejan de devolver esos proveedores en los errores de enrichment. Todo proveedor válido para el país de la entidad se comporta igual que antes.

​

Crear notas en el dossier de entidad

• POST /entities/{id}/notes — body: content (obligatorio, máx. 8000), noteType opcional (general | analysis | finding | recommendation), isImportant opcional (boolean). Requiere entities:edit (legacy entities:write).
• Cada nota guarda source: manual (UI) o agent (HITL / agente contextual).
• Evento de auditoría note_added con source, noteType, noteId y contenido.
• GET /entities/{id}/notes sin cambios (listado, más recientes primero).

​

Nuevo código de fallo por fila: SCIENTIFIC_NOTATION_ID

• Campos verificados: externalId, originExternalId, destinationExternalId, originTaxId, destinationTaxId.
• La fila falla con el código SCIENTIFIC_NOTATION_ID en failures.csv / JSON failures[]; identifier_type lista los campos afectados.
• El comportamiento sigue batchErrorHandling como cualquier otro fallo de fila (rollback_all aborta el archivo, continue_collect_errors crea las válidas).
• Impacto: archivos que antes importaban con ids corruptos ahora reportan esas filas como fallidas. Volvé a exportar el CSV manteniendo las columnas de id como texto.

​

Política de errores y artefactos S3 en batch de transacciones

• batchErrorHandling=rollback_all es el default (UI + upload multipart si se omite): aborta el archivo ante refs/amounts inválidos o fallos de insert; el detalle va a failures.csv (S3), sin arrays gigantes en jsonb.
• El cliente puede elegir continue_collect_errors (omitir filas inválidas y crear las válidas) o stop_keep_success.
• El selector de política también está en imports sin mapper (TX y entidades).
• CSV de fallos: columnas external_id,code,error,role,identifier_type,value.
• Nuevo GET /batch-import/jobs/{jobId}/payload: descarga el payload.json procesado cuando está guardado (adjunto autenticado).
• Alineación: jobs de user-events y entidades siguen el mismo modelo S3-first que transacciones. El kind en respuestas es entity_batch; entity_automatic sigue como alias de entrada.

​

Filtro por última evaluación de reglas

​

Campos adicionales en webhooks legacy planos de entidades

​

Reporte de filas omitidas en batch de transacciones

• Disponible para jobs corridos con el default skipDuplicates=true; con skipDuplicates=false los duplicados los resuelve la base de datos y solo se cuentan, así que el endpoint devuelve SKIPS_NOT_AVAILABLE.
• Los jobs terminados antes de este release no tienen reporte guardado (SKIPS_NOT_AVAILABLE).
• También disponible como botón de descarga en el historial de importaciones.

​

Relaciones declarativas con tax_id duplicado (bulk)

​

Vínculos a entidades existentes en create e importación masiva

• POST /entities y POST /entities/automatic: body opcional relationships[] (máx. 10).
• Bulk CSV plataforma: columnas related_tax_id / related_external_id / related_entity_id, relationship_type, relationship_role, relationship_as_source (una relación por fila).
• Si la contraparte no existe → RELATED_ENTITY_NOT_FOUND y la entidad no se crea.

​

security.member.environment_changed

• Evento: security.member.environment_changed
• context.fromAccess / context.toAccess: "both" | "production" | "sandbox" | "none"
• changes.environmentAccess: { previous, current } con los mismos valores

​

Link de entidades: soft-link siempre, default estricto de batch sin cambio

• Default batch (BC): omitir flags sigue estricto — validateExistingEntity default true. Refs sin resolver → 400 (igual que antes).
• linkEntityStrict=true: fuerza hard-fail (body o query).
• linkEntityStrict=false: fuerza soft-link (no falla si falta), aunque validateExistingEntity diga otra cosa.
• validateExistingEntity=false: soft-link (y ahora sí vincula si encuentra — antes el soft de batch salteaba el link).

​

Código de error: CREATION_CONTRACT_QUOTA_EXCEEDED

• Mismo status HTTP y shape del payload (module, remainingTotal, periodKey, requested).
• Los fallos de fila en bulk import emiten CREATION_CONTRACT_QUOTA_EXCEEDED; el código viejo queda como alias deprecado para failures.csv históricos.

​

Unicidad de tax ID (por organización)

• Mismo tipo ya existe → la creación automática reutiliza esa entidad (alreadyExisted).
• Otro tipo ya tiene el tax ID → 409 con código DUPLICATE_TAX_ID (sin fila nueva).
• Aplica a create manual, create automatic, PATCH de tax ID y restore de soft-delete.
• Los duplicados históricos no se borran; los writes conflictivos nuevos se bloquean en app y con un trigger en base de datos.

​

Nueva acción de regla: addFieldToCustomList

{
  "type": "addFieldToCustomList",
  "addFieldToCustomList": {
    "mappings": [
      { "fieldPath": "originTaxId", "listId": "uuid-lista-123" },
      { "fieldPath": "metadata.phone", "listId": "uuid-lista-456" }
    ],
    "reason": "Opcional — motivo en el ítem"
  }
}

​

Bloqueo en creación (configuración de análisis de riesgo)

​

Endpoint dedicado para atributos

• mode: merge (default) — las claves enviadas pisan o crean; las omitidas se conservan
• mode: replace — attributes del body reemplaza el mapa completo ({} borra todo)
• Buckets anidados por categoría en escritura
• Dispara webhook entity.updated y matrices con trigger entity_updated cuando aplica

​

Atributos personalizados almacenados tal cual (API)

• Sin categoría: valores escalares/array en la raíz (p. ej. { "phone": "..." }) — sin cambios.
• Categorizado: un objeto de primer nivel agrupa sus claves internas bajo esa categoría (p. ej. { "contact": { "phone": "..." } }). La clave del objeto es la categoría; en el dashboard se muestra como card de categoría.
• Lectura: GET devuelve la misma forma que se escribió (sin aplanar).
• Reglas / webhooks: leen la forma almacenada — attributes.phone para plano, attributes.contact.phone para anidado. Usá claves de categoría identificador-seguras.

​

Activación operativa por país (merchant)

• GET /entities/{id}/country-activations — lista AR, BR, CL, CO, MX, US; filas ausentes = deactivated (opt-in).
• PATCH /entities/{id}/country-activations/{countryCode} — body { "status": "deactivated" | "activation_requested" | "activation_in_progress" | "activated" }; requiere entities:edit. Transiciones libres. Idempotente si el estado no cambia (sin webhook).
• Webhook entity.country_activation_changed — se emite en cada cambio real; incluye activeCountryCodes, snapshot countries y timeline por país; suscribirse en la config de webhooks existente.

​

Import batch de eventos de usuario — política de errores por fila

• POST /batch-import/import/user-events acepta batchErrorHandling: continue_collect_errors (default), rollback_all o stop_keep_success.
• Respuestas 202 incluyen preflightFailures cuando filas inválidas se omiten con política continue.
• POST /batch-import/validate-csv valida cada fila si el target es user_event (rowErrors, validRowCount, invalidRowCount).

​

POST /rules — revisión IA síncrona en toda alta

• Las reglas nuevas quedan siempre en in_progress con enabled: false; status / enabled del body se ignoran en create.
• La respuesta incluye aiReview y puede tardar varios segundos.
• Body opcional creationProvenance: origen (user, agent, import_json, template, bundle, api) e ids de chat del agente.
• La revisión se audita pero no debita tokens de IA.

​

security.member.invited / security.member.created — payload.context ampliado

• invitationId — correlacionar invited → created
• granularRoleIds, granularRoleIdsSandbox
• includeProduction, includeSandbox
• teamId, teamIdSandbox
• hasEnvironmentAccess — flag de acceso para la org del sobre
• environment — "production" o "sandbox" según la org del sobre
• invitedByUserId, acceptedVia (en created)
• syncPartialFailure, syncErrorMessage (en created cuando la configuración secundaria no se completó)

​

Polling de jobs batch import

​

Endpoints HTTP

• GET /batch-import/jobs/{jobId} — lookup directo por job id (entidades, transacciones y user events). Devuelve status, contadores (totalItems, succeeded, failed, skipped), timestamps y jobFailure opcional si abortó el job completo. Query opcional include=failures devuelve el mismo JSON que los endpoints de failures por tipo.
• GET /batch-import/unified-history — nuevo query param jobId (coincidencia exacta; 0 o 1 fila). El histórico unificado sigue siendo para listados; usar GET /batch-import/jobs/{jobId} para polling post-upload.

​

Flujo recomendado para integradores

​

Inteligencia de Titulares CBU/CVU (ar_gueno_holder_intelligence_service)

​

Endpoints HTTP

• GET /api/integration-services/ar_gueno_holder_intelligence_service/health — disponibilidad y frescura del corpus (status, corpusFreshnessDate). Sin cobro.
• GET /api/integration-services/ar_gueno_holder_intelligence_service/cuits/:cuit/exists — pertenencia al corpus. Devuelve found y snapshotDate (null si no existe). Siempre HTTP 200 en éxito (incluso found: false). Sin cobro.
• GET /api/integration-services/ar_gueno_holder_intelligence_service/cuits/:cuit/accounts-count — totales CBU/CVU + isNew y snapshotDate. Cobro por request cuando el producto tiene precio.
• GET /api/integration-services/ar_gueno_holder_intelligence_service/cuits/:cuit/metrics — lookback densificado (lookback 1–180 o preset window w_1d…w_180d). Query opcional date (YYYY-MM-DD, fin inclusive). Devuelve aliases de stock, deltas, %, varianza y aceleración. Cobro por request cuando el producto tiene precio. Errores: 400 LOOKBACK_REQUIRED / INVALID_LOOKBACK / INVALID_WINDOW / INVALID_DATE, 404 CUIT_NOT_FOUND, 422 INCOMPLETE_WINDOW / NO_INCREMENTAL_STATE.

​

Motor de reglas

​

Documentación Servicios (en / es / pt)

​

Identificadores de entidad además de entityId

​

Creación (POST)

• POST /api/kyc/validations — body acepta entityId, entityExternalId o entityTaxId (exactamente uno).
• POST /api/kyc/biometric/sessions — mismas opciones.

​

Lectura (GET)

• GET /api/kyc/validations?entityTaxId=... o ?entityExternalId=...
• GET /api/kyc/biometric/sessions?entityTaxId=... o ?entityExternalId=...
• KYC: GET /api/kyc/entities/by-tax-id/:taxId/current|validations|status y rutas by-external-id
• Biométrico: GET /api/kyc/biometric/entities/by-tax-id/:taxId/current y by-external-id

​

Vista previa sandbox (solo GET)

• GET /api/entities/by-tax-id/{taxId} y GET /api/entities?taxId=... pueden devolver datos sintéticos sandboxMock: true (id: null) para números del catálogo sin fila real. No habilita POST sin crear entidad real.

​

Respuestas 409 aditivas para sesiones / validaciones abiertas

​

Biometría embebida — POST /api/kyc/biometric/sessions

• Con la última sesión en pending o in_progress, el create siempre devuelve 409 ACTIVE_SESSION_EXISTS (nunca 201 con la misma sesión pending).
• El body incluye activeSessionId para cancelar: POST .../sessions/{activeSessionId}/cancel.

​

Validación KYC — POST /api/kyc/validations

• Con una validación abierta (pending, in_progress, in_review), el create devuelve 409 VALIDATION_IN_PROGRESS.
• El body ahora también incluye activeValidationId para cancelar: DELETE .../validations/{activeValidationId}/cancel.

​

includeRulesSummary en GET de una transacción

• includeRulesSummary=full — Agrega persisted.rulesExecutionSummary desde la fila más reciente de risk_analysis_audits de esa transacción. No se re-ejecutan reglas en la lectura.

​

Campos opcionales en rulesExecutionSummary

• rulesHit[].actions.originEntityStatus / destinationEntityStatus — configurados en la regla que hizo match.
• actionsExecuted.originEntityStatus / destinationEntityStatus — estados finales de entidad aplicados en esa corrida (junto con actionsExecuted.status para la transacción).

​

Eventos security.member.* (nomenclatura unificada)

• Perfil / contraseña: security.member.profile_updated, .password_reset, .password_generated
• Equipos: security.member.team_added, .team_removed, .team_role_changed
• Canales (org hija): security.member.channel_granted, .channel_revoked
• Acceso a entornos (production / sandbox): security.member.environment_granted, .environment_revoked — distinguidos por context.environment ("production" | "sandbox")

​

GET /api/kyc/biometric/entities/:entityId/current

• Devuelve la última sesión biométrica de la entidad (por createdAt), cualquier estado (pending, in_progress, approved, rejected, …).
• 200 con null si la entidad no tiene sesiones biométricas (ya no 404).
• En el listado, currentSessionId sigue siendo solo la última sesión approved.

​

Eventos webhook de seguridad (security.*)

• Auth: security.auth.login_succeeded, security.auth.logout, security.auth.login_failed
• Miembros: security.member.invited, .created, .removed, .activated, .deactivated
• Roles: security.role.created, .updated, .deleted, .assigned, .revoked
• RBAC: security.rbac.granular_toggled
• Contraseña (admin): security.member.password_reset, security.member.password_generated (antes security.user.password_*)
• Settings: security.settings.updated (sandbox, parámetros de seguridad auditados)

​

Triggers granulares de matriz (watchFields)

​

Actualización de entidad — entity_updated cableado

​

Import bulk automático — enrichments en hijos y alcance de monitoreo

• childEnrichmentPolicy: all_active (default), by_root_type o basic_only.
  • by_root_type: filas empresa → accionistas con todos los enrichments activos excepto global_gueno_sanctions_enrichment; filas persona → relacionadas solo con datos básicos del proveedor de la raíz.
• monitoringApplyToRelationships: con false, monitoring solo en entidades principales. Default true con depth > 0 si se omite.

​

Eventos — campos de sesión del SDK y pre-login

​

Eventos — nuevos tipos

​

Nuevo endpoint — GET /sdk/config

​

Enrichment marketplace — errores estructurados

​

Creación automática / bulk — tax ID estricto

​

Transacciones — exchangeRate opcional (fallback)

​

POST /entities/{entityId}/refresh — scope unificado y sync seguro

• refreshScope: basic_data | all_active | selected (+ providerCodes si selected).
• preserveName: true conserva el nombre; omitido = sync legacy desde fullName normalizado.
• preserveEntityData: solo con refreshScope: "basic_data" — true completa vacíos en entityData, false reemplaza; omitido = no tocar ficha.

​

Warning GUENO_CROSS_ENTITY_DUPLICATED

• Añade GUENO_CROSS_ENTITY_DUPLICATED a warnings de la validación por sesión.
• Si el proveedor mapeó approved, Gu1 deja el estado en in_review (metadata.guenoCrossEntityDuplicateEscalation).
• No omitible: no puede ir en omitWarnings (400) y bloquea auto-aprobación por omit.

​

Gu1 Biometría (POST /api/kyc/biometric y /api/kyc/biometric/sessions)

​

decision siempre incluye pares array + objeto por feature

• id_verification ↔ id_verifications[0]
• liveness ↔ liveness_checks[0]
• face_match ↔ face_matches[0]
• aml_screening ↔ aml_screenings[0]
• ip_analysis ↔ ip_analyses[0]

​

Config del motor en POST /entities/{entityId}/analyze

​

ejemplar en extractedData

​

Doble chequeo RENAPER en validaciones KYC

​

Producto marketplace *_check eliminado

• Eliminado: códigos *_check, POST /integration-execution/marketplace/check, triggers/acciones de reglas check_completed / execute_check, y permisos RBAC checks:read / checks:execute.
• Usar en su lugar: el *_enrichment equivalente con Ejecutar enrichment.
• Compat legacy: payloads de create/import con checks, executeAllActiveChecks o *_check en autoExecuteIntegrations.enrichments se ignoran al parsear.

​

Códigos estables y endpoints JSON de fallos batch

• Fallos por fila con code + message — Catálogo. CSV incluye columna code.
• JSON: GET /batch-import/transaction-jobs/{jobId}/failures, GET /batch-import/user-event-jobs/{jobId}/failures, GET /batch-import/entity-jobs/{jobId}/failures — incluyen failures[], jobFailure opcional, skips[] en entidades, truncated / failuresTotal (máx. 500).
• CSV: mismas rutas con sufijo .csv para descarga directa.

​

Asignar matrices de riesgo al actualizar entidad

• PATCH /entities/{id} (y PATCH /entities/by-external-id/{externalId}, PATCH /entities/by-tax-id/{taxId}): documentados riskMatrixIds (string[]) y riskMatrixId (string | string[] | null) — misma normalización que en create. Solo asigna matrices; no ejecuta el motor de reglas (usar Analizar entidad o triggers del ciclo de vida).
• Mintlify actualizado en /en/, /es/, /pt/ en Actualizar entidad y Actualizar por ID externo.

​

configRulesExecution en alta de transacción

• POST /transactions: objeto opcional en el body configRulesExecution con notifications (boolean). Con false, gu1 omite notificaciones in-app de la evaluación de reglas (matriz / estado). Acciones createAlert e investigaciones no cambian.
• Default: si se omite el objeto, el resto de organizaciones mantiene el comportamiento anterior (notifications efectivamente true). Paytime prod (3bc1f621-27d4-423e-9d64-86680bec2388) usa notifications: false por defecto.
• Legacy KYT POST /legacy/kyt/verifyTransaction: mismo campo en el body Gu2; Paytime prod notifications: false por defecto si se omite.
• Aplica en reglas sync y async (asyncRules).

​

POST /transactions y lote — campos de contraparte vinculados

• originTaxId / destinationTaxId ← entities.tax_id
• originExternalId / destinationExternalId ← entities.external_id

​

POST /events/user — isNewDevice respeta el valor del integrador

• Si envías isNewDevice: true o false, gu1 persiste exactamente ese valor (sin sobrescritura en servidor).
• Si omitís el campo, gu1 lo infiere cuando hay deviceId + deviceDetails (registro de dispositivos; true si el device es nuevo o firstSeenAt está dentro de los últimos 5 minutos); si no, false.

​

CSV plataforma: attributes.* y entityData.*

• Cabeceras con punto (misma idea que transacciones nativas): attributes.segment_tag, attributes.tags.tier, entityData.income, entityData.tradeName.
• entityData.<campo> sin person/company → bucket según type de la fila.
• Columnas sin prefijo (segment_tag) siguen yendo a attributes (retrocompat).
• Plantillas hub actualizadas; ver Importar entidades (CSV).

​

Límites documentados (en / es / pt)

• Importaciones masivas — overview: matriz de archivos por request, filas por plan e manual vs automático en entidades.
• Páginas por endpoint con límites: Importar entidades (CSV), transacciones, eventos de usuario.
• Consulta límites en runtime: GET /individual-organization/batch-upload-enabled.

​

Países en import bulk (manual vs automático)

• Manual (manual): cualquier ISO2 válido de plataforma (lote o country_code / country por fila). Sin pipeline Nosis/CPF.
• Automático (automatic): AR, BR y CL (datos básicos por tax ID, incl. enrichments Chile: ruts.info / BaseAPI).
• Aplica a POST /batch-import/import/entities (CSV plataforma y CSV custom con mappingId).

​

POST /batch-import/import/entities — enrichments en manual

• El modo manual multipart coincide con el hub Manual: autoExecuteIntegrations, monitoring y matrices opcionales — sin pipeline Nosis/CPF.
• Solo CSV (sin enrichments explícitos) → entidad mínima, sin enrichments.
• Columnas CSV de enrichment por fila aplican en manual; depth solo en automático.

​

POST /batch-import/import/entities — default manual

• Sin entityImportMode, el modo efectivo es manual (entidad mínima; enrichments solo si los pedís).
• Automático con entityImportMode=automatic (+ autoExecuteIntegrations, depth, etc.).
• Modo manual exige suggested_name en cada fila (400 si falta).
• Respuesta 202 incluye importMode aplicado.

​

POST /batch-import/import/entities — formato plataforma

• mappingId opcional con CSV formato plataforma (tax_id, type, …). Default de import: manual (ver entrada siguiente en este changelog).

​

asyncRules al crear transacción

• POST /transactions: flag opcional asyncRules en query o body (default false). Con true y executeRules distinto de false, la transacción se crea en la misma request pero las reglas corren en background vía cola de jobs. La respuesta HTTP vuelve al instante con rulesHit / rulesNoHit vacíos, más asyncRules: true y rulesEvaluationStatus: "queued".
• Sin cambio por defecto: omitir asyncRules mantiene ejecución síncrona y un rulesExecutionSummary completo — clientes existentes siguen igual.
• Legacy KYT POST /legacy/kyt/verifyTransaction: mismo flag por query o campo en body Gu2. Paytime prod (3bc1f621-27d4-423e-9d64-86680bec2388) usa async por defecto si no envían el flag; asyncRules=false fuerza sync en una request.
• No aplica a batch. Si Redis/cola no está disponible, puede responder 503 ASYNC_RULES_QUEUE_UNAVAILABLE (la transacción puede existir — revisar el body antes de reintentar).

​

Doble chequeo RENAPER en endpoints KYC standalone

• POST /api/kyc/face-match: doubleCheckRenaper opcional (body o query). Tras aprobar face match: RENAPER biométrico + datos. Requiere documentNumber, gender, personalNumber (fallback de entidad para DNI/género). Respuesta con responseDoubleChecks.
• POST /api/kyc/id-verification: mismo flag; tras OCR approved solo chequeo datos RENAPER. Fallo → declined + códigos en warnings.
• Credenciales RENAPER de org (igual que KYC por sesión). Timeout HTTP ≥ 60 s en face-match con double-check.

​

KYT — triggers separados: cambio de estado vs actualización de campos

• PATCH …/changeStatus ejecuta reglas/matrices con trigger status_changed (trigger_transaction_status_changed), no updated.
• PATCH /transactions/{id} con executeRules=true sigue usando updated (trigger_transaction_updated) para cambios de metadata, deviceDetails, channel o reason.
• Migración: reconfigurar reglas que debían correr al cambiar estado al nuevo trigger (Rule Builder: Al cambiar estado; matrices: transaction_status_changed).

​

Actualización parcial de transacción

• PATCH /transactions/{id} y PATCH /transactions/external/{externalId}: actualizar metadata (merge superficial), deviceDetails (merge superficial en device_details), channel (nullable) y/o reason (enum). Requiere transactions:edit.
• Query executeRules=true re-ejecuta reglas KYT con trigger updated — no reglas de cambio de estado.
• Auditoría transaction_updated y webhook transaction.updated con mapa changes (incluye deviceDetails si aplica).

​

Eventos de usuario — has-events por external ID o tax ID

• GET /events/user/entity/has-events (nuevo): comprobación sí/no sin UUID interno. Query params: entity_id, entity_external_id o tax_id (al menos uno obligatorio). Prioridad: entity_id → entity_external_id → tax_id; comparación de tax ID con normalización (sin caracteres no alfanuméricos).
• La respuesta incluye entityId resuelto para poder llamar a Listar por entidad cuando hasEvents es true.
• GET /events/user/entity/{entityId}/has-events sigue soportado (contrato sin cambios).

​

KYC por sesión — advertencias de análisis de dispositivo e IP

• GET /api/kyc/validations/:id (y rutas de sync/webhook): el array warnings ahora fusiona códigos risk de decision.ip_analyses[].warnings[] (y legacy decision.ip_analysis.warnings), además de verificación de documento, liveness, face match y AML.
• Ocho códigos del proveedor (p. ej. PRIVATE_NETWORK_DETECTED, DUPLICATED_DEVICE_FINGERPRINT, IP_ADDRESS_IN_BLOCKLIST). Ver Códigos de advertencia KYC — Análisis de dispositivo e IP.
• Los mismos códigos son válidos en omitWarnings de POST /api/kyc/validations al auto-aprobar sesiones en in_review.

​

ID Verification — extractedData más completo

• POST /api/kyc/id-verification y auditoría list/get persisten y devuelven un extractedData más amplio: identidad (personalNumber, taxNumber, placeOfBirth, …), providerStatus, warningMeta (p. ej. sesión duplicada), scores de calidad, extraFields, mrz, parsedAddress, barcodes cuando los devuelve el servicio ID Verification de Gu1.
• warnings sigue siendo un array de códigos de riesgo para i18n; la metadata estructurada de duplicados va en warningMeta dentro de extractedData.
• No se devuelven URLs externas de imagen ni base64; las imágenes subidas están en imágenes ID Verification.
• debugProviderResponse solo en entornos no productivos de la API Gu1 (payload de verificación sanitizado, sin imágenes).

​

Horario operativo por entidad (global)

• Entidades: campo opcional en raíz operationalHours (timezone enum + weekly). Aplica a person y company, manual y POST /entities/automatic. Columna entities.operational_hours. Ver Crear entidad, person/create y create-automatic.
• Transacciones: enum transaction_time_zone ampliado (zonas Brasil). timeZone independiente de operationalHours. transactedAt: UTC en DB; ISO con Z sin cambios para clientes actuales; datetime local + timeZone opcional convierte a UTC.
• Reglas: operadores outside_entity_operational_hours e inside_entity_operational_hours sobre transactedAt (value: origin | destination).

​

timeZone en transacciones

• Base de datos: Nueva columna nullable time_zone en transactions con enum transaction_time_zone (valores IANA como America/Argentina/Buenos_Aires, UTC, etc.). Las filas existentes siguen en null.
• API: timeZone opcional en POST /transactions y creación en lote; se devuelve en GET /transactions/{id} y GET /transactions/external/{externalId} como string | null.

​

validateExistingEntity (creación de transacciones)

• POST /transactions: nuevo campo opcional validateExistingEntity (default false). Con true, cada identificador de origen/destino que envíes debe existir en la org; si no, 400 INVALID_ENTITY_REFERENCES y no se crea la fila.
• Batch (POST /transactions/batch, upload, JSON): el default sigue siendo true (validación estricta si enviás identificadores). Para import histórico permisivo: validateExistingEntity: false.
• Legacy KYT POST /legacy/kyt/verifyTransaction: acepta el mismo campo en el body Gu2 (validateExistingEntity).

​

excludeEnrichments en creación de entidades

​

Nuevo: Documentación de Página de Onboarding Alojada

​

Novedades

• ✅ Guía completa de parámetros de personalización (branding, colores, diseño)
• ✅ Configuración de reglas de validación (verificación de edad, métodos de captura, detección de duplicados)
• ✅ Reglas de validación de documentos (QR/código de barras, MRZ, fechas de vencimiento, vivacidad)
• ✅ Guía de integración paso a paso con ejemplos de código
• ✅ Diagrama de flujo visual mostrando el proceso completo
• ✅ Mejores prácticas de seguridad para gestión de sesiones
• ✅ Confirmación de diseño mobile-responsive

• 📱 Diseño mobile-responsive para todos los dispositivos
• 🎨 Personalización completa de colores, branding y diseño
• 🔒 Directrices de seguridad completas
• 📊 Diagramas de secuencia visuales para mayor claridad
• 🌐 Información de canal de soporte para cambios de configuración

​

Idiomas

• 🇺🇸 English
• 🇪🇸 Español
• 🇧🇷 Português

​

Impacto

• Implementación más rápida para soluciones sin código
• Guía clara sobre opciones de personalización
• Mayor conciencia de seguridad
• Mejor comprensión del flujo de la página alojada

​

Refinamiento de Páginas KYC Basado en Feedback del Cliente

​

Novedades

• ✅ Tabla comparativa completa: Creación Automática vs Manual
• ✅ Guía completa de configuración de Matriz de Riesgo con instrucciones del dashboard
• ✅ Aclaración sobre función de accionistas (solo KYB, no KYC)
• ✅ Referencia de códigos de proveedores con ejemplos de uso
• ✅ Sección detallada de gestión de créditos con costos y flujos de trabajo

• ✅ Explicación Webhooks vs polling manual
• ✅ Tabla comparativa KYC Completo vs Verificaciones Individuales
• ✅ Advertencia completa sobre seguridad de face matching para bancos/fintech
• ✅ Tabla mejorada de endpoints API con casos de uso

• ✅ Diagrama de secuencia completo mostrando el flujo completo
• ✅ Aclaración Sandbox vs Producción
• ✅ Manejo de entidades duplicadas con ejemplos de código
• ✅ Documentación expandida de integrationCode

• ✅ Campos opcionales marcados con ejemplos (attributes, entityData)
• ✅ Ejemplos de creación de entidad mínima vs completa

​

Idiomas

• 🇺🇸 English
• 🇪🇸 Español
• 🇧🇷 Português

​

Impacto

• 14 preguntas de cliente respondidas inline
• 12 archivos de documentación actualizados
• 0 enlaces rotos
• Experiencia de onboarding de desarrolladores mejorada

​

Documentación Multi-idioma Mejorada

​

Cambios

• Cobertura completa de traducción para KYC, KYB y Monitoreo de Transacciones
• Terminología consistente en todos los idiomas
• Ejemplos específicos del idioma (DNI para España, CPF para Brasil, etc.)

​

Idiomas Disponibles

• Inglés (EN) - Principal
• Español (ES) - Completo
• Portugués (PT) - Completo

​

Lanzamiento de Documentación gu1

​

Funcionalidades Principales

• Referencia API completa para todos los endpoints
• Guías de casos de uso (KYC, KYB, Monitoreo de Transacciones)
• Guías de integración de webhooks
• Tutoriales interactivos
• Soporte multi-idioma

​

Componentes

• API de entidades persona
• API de entidades empresa
• Flujos de validación KYC
• Monitoreo de transacciones
• Motor de reglas
• Matrices de riesgo
• Alertas e investigaciones