> For the complete documentation index, see [llms.txt](https://yutax.gitbook.io/developer/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yutax.gitbook.io/developer/caracteristicas/reporte-de-informacion.md). # Reporte de información Las empresas que trabajan con Yutax también actúan como **proveedores de datos**, aportando información estructurada que permite construir perfiles de riesgo más precisos y activar mecanismos de prevención de fraude de forma anticipada. El reporte de información es un componente esencial del funcionamiento de Yutax. Para que el sistema pueda identificar usuarios compartidos, generar métricas agregadas y emitir alertas relevantes, **Yutax debe conocer previamente las cuentas de los usuarios que operan en cada empresa**. Si una empresa no reporta las cuentas de sus usuarios, Yutax no puede: * Identificar coincidencias entre plataformas * Asociar eventos de riesgo a un perfil válido * Generar alertas preventivas de fraude * Calcular métricas de antigüedad y consistencia * Notificar eventos ocurridos en otros servicios Por este motivo, el **reporte de cuentas es un requisito previo** antes de poder reportar información negativa, recibir alertas de riesgo o participar en la prevención de fraude. Yutax opera bajo un modelo de **privacidad por diseño**. Las empresas no tienen acceso a los detalles individuales de las cuentas reportadas por otros proveedores participantes. Toda la información compartida se transforma en **métricas agregadas, señales y alertas**, sin exponer datos sensibles ni identificar a la empresa reportante. *** ### 1- Reporte de cuentas El reporte de cuentas consiste en registrar en Yutax las cuentas activas de los usuarios que operan dentro de una empresa. Este proceso establece la base del sistema de riesgo y permite que las evaluaciones, alertas y métricas se construyan de forma consistente. Una cuenta debe existir en Yutax **antes** de que pueda asociarse cualquier evento negativo o alerta. *** ### ¿Por qué es obligatorio reportar las cuentas? La obligatoriedad del reporte de cuentas no es solo un requisito técnico, sino un **principio fundamental del ecosistema Yutax**. #### Trazabilidad del riesgo Reportar las cuentas permite mantener una **trazabilidad clara de los eventos de riesgo** a lo largo del tiempo. Cada señal o evento se asocia a una cuenta previamente registrada, evitando reportes aislados, inconexos o sin contexto histórico. Sin cuentas registradas: * No existe historial verificable * No se puede asociar correctamente un evento * El análisis de riesgo pierde consistencia *** #### Equidad para el usuario El reporte previo de cuentas protege al usuario legítimo y garantiza un sistema **justo y equilibrado**. Ninguna cuenta puede verse afectada por información negativa si no existe previamente un registro que respalde su relación con una empresa. Esto evita: * Señalamientos arbitrarios * Reportes tardíos sin relación demostrable * Impactos desproporcionados sobre perfiles legítimos Cada evaluación de riesgo se basa en **hechos verificables**, no en reportes aislados. *** #### Prevención de abusos Exigir que una cuenta exista antes de aceptar reportes negativos reduce de forma significativa el riesgo de **uso indebido del sistema**. Este enfoque previene: * Reportes masivos sin fundamento * Intentos de afectar perfiles inexistentes * Uso del sistema como mecanismo de represalia Esto protege tanto a las empresas como al ecosistema completo. *** #### Identificación de usuarios compartidos Solo mediante el reporte previo de cuentas, Yutax puede **identificar usuarios que operan en múltiples plataformas** y activar alertas cuando se detectan eventos relevantes en otros servicios. Si las cuentas no han sido reportadas: * No existen coincidencias * No se generan alertas cruzadas * No hay prevención anticipada de fraude *** #### Métricas agregadas y consistencia El reporte de cuentas permite a Yutax generar métricas agregadas confiables, como: * número total de cuentas reportadas * antigüedad de la cuenta más antigua Estas métricas fortalecen el perfil de confianza sin exponer datos sensibles ni detalles individuales. ```json { "reported_accounts": 7, "oldest_account_age_months": 64 } ``` *** #### Principio operativo > En Yutax, ningún evento negativo puede existir sin una cuenta previamente registrada. Este principio garantiza que el sistema funcione con **integridad, equilibrio y responsabilidad**, manteniendo la privacidad de los usuarios y la trazabilidad de las empresas participantes.\ Cada evento de riesgo está respaldado por una relación previa y verificable entre una cuenta y una empresa, evitando reportes aislados, arbitrarios o sin contexto. *** ### Principios de integridad y protección del ecosistema Además del principio operativo, Yutax se rige por un conjunto de **principios de integridad y protección** diseñados para preservar la neutralidad del sistema, la privacidad de las empresas y la seguridad de los usuarios. #### Neutralidad entre empresas Yutax no revela la identidad de la empresa que reporta una cuenta o un evento.\ Este enfoque evita que la información de riesgo sea utilizada con fines comerciales indebidos, como: * Identificar clientes activos de otras empresas * Intentar captar usuarios que no pertenecen a la propia plataforma * Usar el sistema como una herramienta de competencia desleal Yutax opera como una capa neutral de riesgo, no como un directorio comercial. *** #### Protección contra apropiación de clientes y billeteras No se comparten nombres, correos, teléfonos, identificadores internos ni ningún dato que permita reconstruir o transferir una relación comercial existente. Este diseño evita: * Robo o redirección de clientes * Apropiación de billeteras digitales * Interferencia en relaciones comerciales legítimas Las empresas reciben **señales y métricas**, no oportunidades de captación. *** #### Privacidad de las empresas reportantes La identidad de las empresas que reportan información está protegida en todo momento.\ Esto garantiza que: * Las empresas puedan reportar eventos sin represalias * No exista presión entre participantes * El sistema fomente reportes responsables y consistentes La confidencialidad es esencial para la estabilidad del ecosistema. *** #### Protección del usuario legítimo Yutax minimiza la exposición del usuario final asegurando que: * Los datos no se replican entre empresas * No se construyen perfiles públicos ni accesibles * Solo se utilizan métricas agregadas y señales no identificables Esto reduce el riesgo de estigmatización y uso indebido de la información. *** #### Prevención de abusos sistémicos Al no revelar fuentes ni detalles , Yutax reduce de forma significativa: * Reportes malintencionados * Uso del sistema para bloqueo injustificado * Manipulación de señales con fines externos Cada evento pasa por validaciones internas antes de afectar un perfil. *** #### Principio de minimización de datos Yutax solo expone la información estrictamente necesaria para la toma de decisiones de riesgo.\ Cualquier dato que no aporte valor directo a la evaluación es omitido por diseño. *** #### Principio de confianza acumulativa Las evaluaciones de riesgo en Yutax se basan en **comportamientos acumulados y consistentes**, no en incidentes aislados.\ Esto permite decisiones más justas y reduce falsos positivos. *** #### En resumen > Yutax prioriza la prevención de fraude y la protección del ecosistema sin interferir en las relaciones comerciales ni exponer información sensible de usuarios o empresas. *** ### Condiciones para reportar una nueva cuenta Para registrar una cuenta en Yutax, la empresa debe proporcionar un conjunto mínimo de datos verificados. Estos campos son obligatorios para garantizar la integridad del sistema y evitar registros incompletos o abusivos. #### Campos obligatorios * **Nombre de la cuenta**\ Identificador visible de la cuenta dentro de la empresa (persona o negocio). * **Identificador interno de la cuenta**\ ID único y estable utilizado por la empresa en sus sistemas. * **Teléfono verificado**\ Número telefónico previamente validado por la empresa. * **Correo electrónico verificado**\ Dirección de correo previamente validada por la empresa. * **Fecha de creación de la cuenta**\ Fecha en la que fue abierta o verificada esa cuenta. Estos datos permiten crear una representación confiable de la cuenta sin exponer información sensible a terceros. {% hint style="info" %} Los detalles de las cuentas reportadas son visibles para el propietario verificado de todas ellas y solo es accesible solicitando su archivo en Yutax Membership. {% endhint %} {% hint style="warning" %} Las empresas no tienen acceso a los detalles que componen una cuenta reportada, como el nombre de la empresa reportante, nombre o ID de la cuenta, teléfono, correo electrónico u otros datos que permitan identificar a la persona o la empresa. {% endhint %} {% hint style="info" %} Las empresas solo reciben valores de conteo sobre la cantidad de cuentas reportadas en el archivo de cada usuario. No se comparten detalles individuales como nombre de la empesa que reporta, nombre, correo, telefono y otros. Además, se informa la edad de la cuenta más antigua, utilizada para determinar la antigüedad del perfil de confianza. Ejemplo de información que reciben las empresas acerca de las cuentas reportadas: `{ "reported_accounts": 7, "oldest_account_age_months": 64 }` {% endhint %} *** ### Flujo general del reporte de cuentas 1. La empresa reporta las cuentas existentes (backfill). 2. Cada nuevo usuario registrado se reporta automáticamente. 3. Yutax consolida las cuentas de forma segura. 4. El perfil del usuario comienza a acumular antigüedad y señales. 5. El sistema queda habilitado para alertas y reportes futuros. *** ### Endpoint para reportar cuentas Todos las cuentas se reportan mediante un único endpoint: ``` POST /v1/accounts/report ``` *** ### Siguiente paso: Reporte de información negativa Una vez que las cuentas han sido registradas, las empresas pueden **reportar información negativa asociada a esas cuentas**, como fraude, impagos, chargebacks o incidentes de seguridad. En la siguiente sección se describen: * Tipos de eventos negativos admitidos * Reglas y validaciones * Impacto en alertas y señales * Efectos sobre el perfil de riesgo *** ### Reporte de información negativa El reporte de información negativa permite a las empresas notificar a Yutax sobre **eventos que representan un riesgo real y verificable**, asociados a **cuentas previamente registradas**. Para reportar información negativa, **la cuenta del usuario debe haber sido reportada con anterioridad**.\ Yutax no acepta reportes negativos sobre cuentas inexistentes o no registradas, como parte de su compromiso con la **trazabilidad**, la **equidad del sistema** y la **prevención de abusos**. *** ### Requisitos previos Antes de reportar información negativa, se deben cumplir las siguientes condiciones: * La cuenta del usuario **ya debe existir en Yutax** * La cuenta debe estar asociada a la empresa que reporta * El evento debe corresponder a una **relación real y verificable** * El reporte debe reflejar un **hecho concreto**, no una suposición {% hint style="warning" %} Los reportes que no cumplan estas condiciones serán rechazados. {% endhint %} *** ### Tipos de información negativa admitidos Yutax clasifica la información negativa en categorías claras, cada una con efectos distintos sobre el perfil del usuario. *** #### Chargebacks (Contracargos) Los **chargebacks** representan disputas de pagos iniciadas por el usuario a través de su entidad financiera y constituyen una señal crítica de riesgo. **Efectos del reporte** * Afectan el **archivo del consumidor** * Generan **señales de fraude y comportamiento** * Pueden activar **alertas** para otras empresas con el mismo usuario * Influyen en el **YUTAX SCORE** y el nivel de riesgo **Requisitos del reporte** * La transacción debe haber ocurrido realmente * El chargeback debe estar confirmado o en proceso válido * El evento debe estar vinculado a la cuenta reportada *** #### Chargeoffs (Deudas impagas) Los **chargeoffs** representan obligaciones económicas no saldadas y reflejan un riesgo financiero relevante. **Efectos del reporte** * Afectan el **archivo del consumidor** * Contribuyen al análisis de **riesgo** * Impactan el **score** y las métricas de confianza * Pueden generar alertas preventivas **Requisitos del reporte** * La deuda debe estar vencida o declarada como impaga * El monto y la relación deben ser verificables * El evento debe estar asociado a una cuenta registrada *** #### Reporte de robo de identidad El **reporte de robo de identidad** indica que una persona o negocio ha sido víctima de suplantación o uso indebido de identidad. **Efectos del reporte** * **No afecta el archivo del consumidor** * **No penaliza el score** * Genera **alertas adicionales** para las empresas asociadas * Activa recomendaciones de verificación reforzada Este tipo de reporte está diseñado para **proteger al usuario legítimo** y prevenir fraudes secundarios, no para penalizar. *** ### Endpoint de reporte Todos los eventos negativos se reportan mediante un único endpoint: ``` POST /v1/events/report ``` Este endpoint es **idempotente** y valida que la cuenta exista antes de aceptar el evento. *** ### Estructura base del payload Todos los tipos de eventos utilizan una estructura común: ```json { "external_account_id": "u_1848392", "event_type": "chargeback", "occurred_at": "2026-01-25T13:40:00Z", "severity": "high", "reference_id": "cb_889212", "metadata": {} } ``` #### Campos * `external_account_id`: identificador interno de la cuenta * `event_type`: tipo de evento reportado * `occurred_at`: fecha y hora del evento * `severity`: nivel de impacto del evento * `reference_id`: identificador único para evitar duplicados * `metadata`: información adicional no sensible *** ### Ejemplos de payload por tipo de evento #### Ejemplo: Chargeback ```json { "external_account_id": "u_1848392", "event_type": "chargeback", "occurred_at": "2026-01-20T10:15:00Z", "severity": "high", "reference_id": "cb_20260120_001", "metadata": { "amount": 320.00, "currency": "USD", "reason_code": "fraud", "status": "confirmed" } } ``` *** #### Ejemplo: Chargeoff ```json { "external_account_id": "u_991203", "event_type": "chargeoff", "occurred_at": "2026-01-10T00:00:00Z", "severity": "medium", "reference_id": "co_771299", "metadata": { "amount": 1500.00, "currency": "USD", "days_past_due": 120 } } ``` *** #### Ejemplo: Robo de identidad ```json { "external_account_id": "u_558811", "event_type": "identity_theft", "occurred_at": "2026-01-22T09:30:00Z", "severity": "informational", "reference_id": "it_002190", "metadata": { "reported_by_user": true } } ``` *** ### Severidades de los reportes Las severidades indican el **impacto del evento**, no la culpabilidad del usuario. | Severidad | Descripción | | --------------- | -------------------------------------- | | `informational` | Evento protector, sin impacto negativo | | `low` | Riesgo menor o aislado | | `medium` | Riesgo relevante | | `high` | Riesgo crítico o fraude confirmado | Yutax puede **recalcular internamente** la severidad final según el contexto. *** ### Estados de los reportes Cada evento reportado tiene un estado interno para garantizar trazabilidad. | Estado | Descripción | | -------------- | ------------------------------- | | `reported` | Evento recibido | | `under_review` | Validación en proceso | | `confirmed` | Evento validado y aplicado | | `rejected` | Evento inválido o inconsistente | | `resolved` | Evento cerrado o mitigado | El estado puede reflejarse en alertas y señales, aunque no siempre se expone directamente. *** ### Validación y procesamiento de reportes Todos los reportes pasan por validaciones internas para garantizar: * Consistencia con la cuenta registrada * Coherencia temporal del evento * Prevención de duplicados o abusos * Integridad del sistema Yutax puede rechazar, limitar o reclasificar reportes que no cumplan los criterios establecidos. *** ### Privacidad y visibilidad de los reportes Los reportes de información negativa: * **No revelan** la identidad de la empresa reportante * **No exponen** datos personales del usuario * **No comparten** detalles transaccionales sensibles Las empresas solo reciben: * Alertas de riesgo * Señales agregadas * Cambios en métricas y score *** ### Principio de impacto proporcional Los efectos de un reporte negativo se aplican de forma **proporcional y contextual**.\ Un evento aislado no define por sí solo el perfil del usuario; el análisis considera el historial completo, la antigüedad y la consistencia del comportamiento. *** ### Resumen operativo * Las cuentas deben reportarse **antes** de cualquier evento negativo * Chargebacks y chargeoffs **afectan el archivo del consumidor** * El robo de identidad **no penaliza**, solo genera alertas * Todos los eventos usan un **endpoint único y validado** * No se comparten fuentes ni datos identificables * Todas las acciones se basan en trazabilidad, equidad y privacidad ***