Clase 04 · Clasificación, calidad y gobierno de datos financieros

← 03 · El Sistema de Finanzas Abiertas de Chile · Índice de la parte · 05 · Consentimiento: creación, vigencia, renovación y revocación →

Parte 17 — Finanzas abiertas, APIs y economía de datos · Nivel: Profesional — perfil bancario · Duración: 90 minutos

🎯 Propósito

Aprender a clasificar un dato financiero antes de exponerlo, y a medir su calidad con números. Una API de finanzas abiertas expone datos que otra empresa usará para decidir; si el dato es de mala calidad, el error se propaga con la firma de quien lo publicó.

Con el régimen y las figuras ya situados, esta clase entra en lo que se comparte. Y establece la distinción que decide qué cubre un consentimiento: no es lo mismo un dato que el cliente entregó que uno que el sistema dedujo de él.

📚 Objetivos

Al finalizar podrás:

1. Clasificar un dato por sensibilidad, titularidad y finalidad admisible.
2. Medir la calidad de un conjunto de datos con seis dimensiones y umbrales.
3. Diseñar el diccionario de datos que acompaña a una API pública.
4. Detectar inferencias sensibles que un dato aparentemente inocuo permite.
5. Decidir qué dato no se expone, y justificarlo por escrito.

Agenda de 90 minutos

La clase dura noventa minutos y se recorre en cinco tramos. No es un horario rígido: es el orden en que los bloques de esta página se sostienen unos a otros, y por eso conviene respetarlo aunque cambien los tiempos.

Los diez primeros minutos se dedican a recuperar la clase anterior, porque casi todo lo que aquí se explica supone algo que ya se vio. Los veinticinco siguientes desarrollan los conceptos con la fuente oficial a la vista: las referencias del final de la página no son un adorno bibliográfico, se consultan mientras se estudia. Del minuto 35 al 55 se resuelve el ejemplo guiado paso a paso, sin saltarse ninguno, porque el error típico vive precisamente en el paso que parece obvio. Los veinticinco minutos siguientes son de práctica con datos propios o sintéticos —nunca reales de terceros—, que es cuando se comprueba si se entendió. Los diez últimos cierran con las preguntas de comprobación y el registro del entregable.

Si el tiempo aprieta, lo que se recorta es la práctica y se traslada al laboratorio de la parte; lo que no se recorta nunca es el ejemplo guiado.

🧩 Conceptos centrales

Los cuatro primeros términos clasifican el dato por su origen; los cuatro siguientes, su calidad y sus límites de uso. La distinción entre dato derivado e inferido es la que más consecuencias tiene: un dato inferido puede revelar información sensible que el titular nunca entregó.

🧠 Modelo mental

El modelo mental es una cadena de transformación con un límite: cada transformación produce un dato nuevo, y el consentimiento del dato original no cubre automáticamente lo que se deduce de él.

TRES PREGUNTAS ANTES DE EXPONER UN CAMPO

  1. ¿DE QUIÉN ES?
       del cliente        → consentimiento
       de la entidad      → decisión comercial
       de un tercero      → no es tuyo para compartirlo

  2. ¿QUÉ PERMITE INFERIR?
       el campo «comercio» de un movimiento
       permite inferir salud, religión, afiliación y domicilio
       → la sensibilidad del dato NO es la del campo:
         es la de lo que el campo permite deducir

  3. ¿PARA QUÉ SE VA A USAR?
       si la finalidad no está declarada, el dato no se expone
       «por si sirve después» no es una finalidad

📖 Desarrollo

1. Clasificación por sensibilidad efectiva

De los cinco niveles, el cuarto es el que más se subestima, porque sus campos no llevan el nombre de lo que revelan.

LA CATEGORÍA QUE MÁS SE SUBESTIMA ES LA CUARTA

  «pago en Clínica Oncológica»          → estado de salud
  «transferencia mensual a Fundación X» → convicción
  «pago recurrente en guardería»        → estructura familiar
  «compra semanal, misma calle, 07:45»  → domicilio y rutina

  ninguno de esos campos se llama «salud», «religión» ni «domicilio».
  Todos los revelan.

2. Dato declarado, derivado e inferido

No todo dato tiene el mismo origen, y el origen determina cómo se corrige cuando está mal. El bloque separa los tres casos y termina en el que más problemas causa: el dato inferido, que el cliente no puede corregir porque ni siquiera sabe que existe.

DECLARADO   el cliente lo dio:      renta declarada, teléfono
DERIVADO    se calculó:             gasto medio mensual, deuda total
INFERIDO    se dedujo:              probablemente tiene hijos,
                                    probablemente cambiará de trabajo

EL RÉGIMEN NO ES EL MISMO
  el declarado se corrige pidiéndoselo al cliente
  el derivado se corrige recalculando
  el inferido NO SE PUEDE CORREGIR: el cliente ni siquiera
  sabe que existe, y el error se propaga sin señal

  → todo dato inferido que afecte a una decisión sobre la persona
    debe ser explicable y contestable (Parte 14, clase 11)

3. Seis dimensiones de calidad, con umbral

Las seis dimensiones admiten umbrales negociables salvo una, y conviene explicar por que esa no.

LA CONSISTENCIA ES LA ÚNICA QUE ADMITE UMBRAL CERO
  si el saldo no es la suma de los movimientos,
  no es un problema de calidad: es un descuadre contable

4. El diccionario de datos

Cada campo expuesto necesita, como mínimo:

nombre técnico        booking_date
nombre funcional      fecha de contabilización
tipo                  string, ISO 8601 con zona horaria
obligatorio           sí
dominio               fechas entre la apertura de la cuenta y hoy
significado           instante en que el movimiento afecta al saldo contable
NO significa          la fecha en que el cliente hizo la operación
origen                sistema central, tabla de movimientos
frecuencia            tiempo real
nulo permitido        no
ejemplo               2026-06-30T03:14:00Z

La línea «NO significa» es la que evita la mitad de los incidentes de integración. Un tercero que confunde fecha de operación con fecha de contabilización produce categorizaciones desplazadas un día, y el cliente ve un gasto en el mes equivocado.

5. Gobierno: quién responde de qué

Gobernar un dato es, sobre todo, poder nombrar a quien responde de él. El bloque reparte cinco papeles y cierra con la regla que los hace operativos: sin un propietario con nombre y apellido, el dato no sale al exterior.

PROPIETARIO DEL DATO      área de negocio; decide finalidad y acceso
CUSTODIO                  tecnología; garantiza integridad y disponibilidad
ADMINISTRADOR DE CALIDAD  mide, publica y escala los incumplimientos
OFICIAL DE PRIVACIDAD     valida finalidad, base de licitud y retención
AUDITORÍA                 verifica que lo anterior ocurre

REGLA PRÁCTICA
  un dato sin propietario nombrado no se expone.
  «es del banco» no es un propietario.

🧮 Ejemplo guiado

El ejemplo clasifica un conjunto de datos y determina qué consentimiento cubre cada uno. Conviene detenerse en los inferidos: son los que exigen una base propia.

Situación. Antes de publicar la API de movimientos, calidad audita una muestra de 50 000 movimientos de 2 400 cuentas.

RESULTADOS DE LA AUDITORÍA

  movimientos totales                      50 000
  con campo «glosa» vacío                   1 340
  con «comercio» sin normalizar             8 900
  con importe positivo en cargos                17
  identificadores duplicados                     6
  saldo de la cuenta ≠ suma de movimientos      31 cuentas de 2 400
  retardo p95 desde el hecho económico       42 s
  fechas fuera del rango de la cuenta          104

Paso 1 — calcula cada dimensión.

COMPLETITUD (campos obligatorios)
  «glosa» NO es obligatorio → no computa aquí
  campos obligatorios sin valor: 0 → 0,00 %      ✓

VALIDEZ
  importe positivo en cargo:  17 / 50 000 = 0,034 %   ✗ (umbral 0 %)
  fecha fuera de rango:      104 / 50 000 = 0,208 %   ✗

UNICIDAD
  6 / 50 000 = 0,012 %                                ✗ (umbral 0 %)

CONSISTENCIA
  31 / 2 400 cuentas = 1,29 %                         ✗✗ (umbral 0 %)

PUNTUALIDAD
  p95 = 42 s < 60 s                                   ✓

EXACTITUD
  no medida en esta auditoría                         ⚠ sin dato

Paso 2 — ordena por gravedad, no por magnitud.

1,29 % de descuadre parece pequeño al lado de
17,8 % de comercios sin normalizar.
No lo es.

DESCUADRE (31 cuentas)
  el saldo que publicaremos no cuadra con los movimientos
  que publicaremos, en la misma respuesta
  → un tercero que sume verá el error inmediatamente
  → es un defecto de INTEGRIDAD, no de presentación

COMERCIO SIN NORMALIZAR (8 900)
  la categorización del tercero será peor
  → es un defecto de UTILIDAD
  → degrada el producto, no lo invalida

Paso 3 — cuantifica el impacto del descuadre.

2 400 cuentas en la muestra, 31 con descuadre = 1,29 %

SI LA CARTERA TIENE 1 850 000 CUENTAS
  1 850 000 × 1,29 % ≈ 23 900 cuentas con descuadre

SI EL 12 % DE LOS CLIENTES OTORGA CONSENTIMIENTO
  23 900 × 12 % ≈ 2 870 clientes verían el error

CON 158 LLAMADAS POR CLIENTE Y TRIMESTRE
  ≈ 453 000 respuestas incoherentes por trimestre

Paso 4 — investiga la causa del descuadre.

HIPÓTESIS A · movimientos en curso no contabilizados
  → si es esto, NO es un descuadre: es que se están
    mezclando saldo disponible y saldo contable

HIPÓTESIS B · movimientos anteriores a la ventana de 24 meses
  → el saldo incluye historia que los movimientos no muestran

HIPÓTESIS C · error real de contabilización

VERIFICACIÓN
  se recalcula el saldo contable a partir de los movimientos
  de los últimos 24 meses MÁS el saldo inicial de la ventana

  resultado: 29 de las 31 cuentas cuadran con esa fórmula
             2 no cuadran por ningún camino

Paso 5 — reformula el problema.

NO HABÍA 31 CUENTAS DESCUADRADAS
HABÍA UN CAMPO QUE FALTA EN LA API

  «saldo al inicio de la ventana consultada»

  sin ese campo, el tercero no puede reconstruir el saldo
  y concluye que el proveedor publica datos incoherentes

  29 de 31 casos eran un defecto de DISEÑO DEL CONTRATO,
  no de calidad del dato

  2 de 31 sí son error contable → escalado al área responsable

Paso 6 — decide.

BLOQUEAR LA PUBLICACIÓN hasta corregir:
  · validez: 17 signos invertidos y 104 fechas fuera de rango
  · unicidad: 6 duplicados
  · contrato: añadir «saldo al inicio de la ventana»
  · los 2 casos de error contable real

NO BLOQUEAR por:
  · comercios sin normalizar (8 900)
    → se publica con el campo tal cual, se DECLARA en el
      diccionario que no está normalizado, y se abre un plan
    → publicar un dato imperfecto y declararlo
      es mejor que retenerlo o que maquillarlo

MEDIR LO QUE NO SE MIDIÓ
  la exactitud quedó sin dato: se programa auditoría
  contra el sistema central antes del siguiente hito

Interpreta: la auditoría encontró un problema de calidad y, al investigarlo, apareció un defecto de contrato. Es lo habitual: la mayoría de los «datos malos» de una API son datos correctos expuestos sin el campo que los hace interpretables.

🧭 Perspectivas

La clasificación del dato afecta a lo que cada actor puede hacer con él. La tabla lo recoge.

🏦 Del cliente al banco

El cliente comparte movimientos y el banco maneja datos derivados e inferidos con reglas distintas. La tabla enfrenta las dos lecturas.

⚖️ Riesgos y controles

Los riesgos de esta clase están en la inferencia y en la calidad. La tabla los recoge con su control.

🧪 Práctica

El laboratorio pide clasificar datos y determinar el consentimiento de cada uno. Los datos inferidos son los que deciden el ejercicio.

En labs/lab-03.md:

1. Clasifica quince campos por sensibilidad efectiva, no por su nombre.
2. Calcula las seis dimensiones sobre el dataset sintético del repositorio.
3. Escribe el diccionario de tres campos, con la línea «NO significa».
4. Identifica un campo que decidas no exponer, y justifícalo por escrito.

⚠️ Errores frecuentes

Los síntomas de la tabla describen problemas con datos. Las causas son inferencias sin base propia y calidad no medida.

❓ Preguntas de comprobación

1. ¿Por qué la sensibilidad de un campo no es la del campo, sino la de lo que permite inferir? Da dos ejemplos.
2. ¿Qué distingue un dato derivado de uno inferido, y por qué el segundo es más difícil de corregir?
3. ¿Cuál de las seis dimensiones admite umbral cero y por qué?
4. En el ejemplo guiado, ¿por qué 29 de los 31 descuadres no eran un problema de calidad?
5. ¿Por qué publicar un dato imperfecto declarándolo es mejor que retenerlo?

📥 Entregable

Guarda en portfolio/parte-17/clase-04/:

• la clasificación de quince campos por sensibilidad efectiva;
• las seis dimensiones calculadas sobre un conjunto sintético;
• el diccionario de tres campos con su línea «NO significa»;
• la justificación escrita de un campo que decidiste no exponer.

🔗 Referencias cruzadas

• Viene de: Parte 14, clase 4 (datos en un banco); Parte 14, clase 11 (ética algorítmica); clase 1 de esta parte.
• Continúa en: clase 9 (APIs de información), clase 12 (privacidad y portabilidad).
• Se aplica en: Parte 18, clase 6 (datos estructurados en ISO 20022); Parte 23, clase 7.

🔐 Seguridad, ética y límites

Trabaja siempre con datos sintéticos o propios: nunca uses datos reales de terceros, números de cuenta, documentos de identidad ni antecedentes crediticios ajenos. Este material es formativo y no constituye asesoría financiera, tributaria ni legal; las tasas, comisiones, límites y normas citados cambian y deben verificarse en la fuente oficial vigente del país donde se aplique. Cuando un cálculo alimente una decisión que afecte a otra persona, registra los supuestos y quién los aprobó.

📗 Fuentes y verificación

• ISO/IEC 25012. Data quality model. International Organization for Standardization. Dimensiones de calidad del dato que la clase mide. https://www.iso.org/standard/35736.html
• Basel Committee on Banking Supervision (2013). Principles for effective risk data aggregation and risk reporting (BCBS 239). BIS. Principios de agregación y trazabilidad aplicados a la API. https://www.bis.org/publ/bcbs239.htm
• Comisión para el Mercado Financiero. Anexo técnico del Sistema de Finanzas Abiertas: definiciones y esquemas de datos. CMF. Esquemas de datos que fijan el contrato de publicación. https://www.cmfchile.cl/
• OECD (2021). Recommendation of the Council on Enhancing Access to and Sharing of Data. OECD. Criterios de acceso y compartición de datos entre organizaciones. https://legalinstruments.oecd.org/en/instruments/OECD-LEGAL-0463
• NIST (2020). NIST Privacy Framework 1.0. National Institute of Standards and Technology. Funciones de gobierno de privacidad aplicadas al dato expuesto. https://www.nist.gov/privacy-framework
• Verificación local: comprueba qué esquema de datos exige el anexo técnico vigente en tu jurisdicción y qué categorías de dato personal recibe tratamiento reforzado. Fecha de verificación de esta clase: 2026-08-06.