BCRA

BCRA — Suspensiones y levantamientos para operar en cambios

Eventos de habilitación e inhabilitación para operar en cambios, por entidad.

RegulatorioCambiario (sanciones)

Qué incluye

18 columnas documentadas
Formato Parquet y CSV
Cobertura desde 21 de mar de 2003
Actualización diaria
Acceso por descarga, API y MCP
Schema versionado y trazable a la fuente

Casos de uso

¿El CUIT 20-XXXXXXXX-X está actualmente suspendido para operar en cambios?
Lista de todas las personas (físicas y jurídicas) suspendidas hoy (estado vigente).
Historial de suspensiones y levantamientos de una razón social o CUIT.
¿Cuántas suspensiones cambiarias publicó el BCRA en los últimos 12 meses?
¿Qué suspensiones se levantaron (rehabilitaciones) este año?

Columnas18

Columna	Tipo	Descripción	Unidad
numero_comunicacion	Int64	Número de la Comunicación C del BCRA que dispuso el evento. Con fuente_url permite ir al PDF original.	—
fecha	Date	Fecha de la Comunicación que dispone la suspensión o el levantamiento.	ISO 8601 YYYY-MM-DD
razon_social	String	Nombre / razón social de la persona física o jurídica afectada. NULL en el 61% de las filas (ver gotcha de razón social ausente): la Comunicación del BCRA listó a la persona solo por CUIT/DNI, sin nombre — muy concentrado 2019-2021 y en 2025.	—
cuit	String	CUIT (11 dígitos sin separadores). Null si la Com. solo informó DNI.	—
dni	String	Número del documento de identidad de la persona física (el tipo está en tipo_documento: DNI/LE/LC/CI/PAS). Sin separadores. En 29 filas con tipo_documento='DNI' no coincide con el DNI que embebe el propio CUIT — ver gotcha. Cuando tipo_documento es CI/PAS/LE (extranjeros), el CUIT NO embebe ese documento y una discrepancia ahí es esperada, no un error.	—
tipo_documento	String	Tipo del documento cuyo número está en `dni`: DNI / LE (Libreta de Enrolamiento) / LC (Libreta Cívica) / CI (Cédula de Identidad) / PAS (Pasaporte). Null si no se informó documento. La C.D.I. (clave fiscal de 11 díg) va en `cuit`, no acá.	—
tipo_persona	String	Clasificación del sujeto: 'Persona Física' / 'Persona Jurídica' / 'Sin determinar'. Usar este término — no 'entidad'.	—
accion	String	Tipo de evento: 'Suspensión' (primera sanción), 'Levantamiento' (rehabilitación) o 'Revocación de levantamiento' (el BCRA deja sin efecto un levantamiento previo — PESE AL NOMBRE, el resultado deja a la entidad de nuevo con estado_resultante='Suspendida', no 'Habilitada'). Los tres valores están en producción desde el backfill de cobertura del 2026-07-30 (verificado en el CHECK de la tabla); único caso de 'Revocación de levantamiento' hoy: Com. C 102038 (Recaudar S.R.L.) — ver gotcha 'Fix de cobertura aplicado' para el detalle.	—
estado_actual	String	Estado VIGENTE neto por identidad (última acción gana): 'Suspendida' / 'Habilitada'. Para el estado de hoy, usar esta columna — pero ver la gotcha 'Levantamientos faltantes': puede estar desactualizado si falta en el dataset el evento más reciente de la identidad.	—
rol	String	Rol de la persona física dentro de la persona jurídica/empresa: titular, presidente, socio, director, apoderado, etc.	—
ref_numero_susp	Int64	Para un levantamiento, número de la Comunicación de suspensión original referenciada (cuando el texto la cita).	—
calidad_flag	String	Marca de calidad. Errores de verificación cruzada: 'cuit_digito_invalido' (CUIT no pasa el dígito verificador), 'cuit_no_verbatim' (el CUIT extraído no aparece textual en la fuente — 0 filas hoy), 'doc_no_verbatim' (el número de documento no aparece textual en la fuente — 0 filas hoy), 'dni_no_coincide_cuit' (el documento no concuerda con un CUIT válido), 'doc_truncado_fuente' (el número aparece truncado vs otra Comunicación), 'doc_removido_juridica' (una empresa traía un documento personal mal atribuido por la fuente). Sobre IDENTIDAD FALTANTE — de quién es la culpa (ver gotcha dedicado): 'sin_cuit_ni_documento' (la fuente no publicó NINGÚN identificador para esa entidad — no hay nada más que buscar), 'identidad_posiblemente_truncada_por_parser' (la fuente SÍ traía el identificador y el PARSER no lo capturó — este SÍ es nuestro fallo, en principio recuperable), 'entidad_sin_identificador' (la entidad no tiene ni CUIT/documento ni razón social — 0 filas hoy). Null = fila verbatim-cierta y válida. Se publica con la marca (no se oculta) por compliance. De las inconsistencias DNI-CUIT genuinas (tipo_documento='DNI'), 'dni_no_coincide_cuit' cubre el 83% (24/29); el resto ya trae 'cuit_digito_invalido' — ver gotcha.	—
documento_corregido	String	El valor que Almanac identificó como CORRECTO cuando la fuente trae el documento mal (truncado por OCR, o inconsistente con un CUIT válido). El campo `dni` conserva el valor verbatim del PDF; esta columna expone nuestra corrección con trazabilidad (ver calidad_flag). Solo se completa en alta confianza (truncación clara o ≤2 dígitos de diferencia respecto del cuerpo de un CUIT válido); ante ambigüedad queda null y la fila va a revisión. Null = no hubo corrección.	—
motivo	String	Motivo de la suspensión cuando el texto lo especifica (suele ser null).	—
plazo	String	Plazo de la suspensión cuando figura (null = sin plazo declarado).	—
entidad_orden	Int64	Orden del sujeto dentro de la Comunicación (una Com. puede listar varios).	—
fuente_url	String	URL del PDF original de la Comunicación C en el sitio del BCRA.	—
identidad	String	Clave interna que unifica al mismo sujeto entre eventos: 'CUIT:<cuit>' cuando hay CUIT, 'DNI:<dni>' cuando solo hay DNI, o 'RS:<razón_social>' como último recurso cuando no hay ningún identificador numérico. Es la columna sobre la que se calcula estado_actual (DISTINCT ON / última fecha por identidad — ver example_queries). Excluida del explorer (no se muestra ni se filtra en la UI) pero disponible para SQL avanzado.	—

Pueden invalidar un análisis ingenuo. Documentadas como parte del control de calidad.

Las filas son EVENTOS, no el estado actual

Una persona o empresa puede tener varias filas (suspensión y luego levantamiento). Para saber si está suspendida HOY hay que tomar la última acción por identidad (CUIT/DNI) — ver la query "estado neto".

Fix de cobertura aplicado en dos rondas (2026-07-30/31): 55 de 65 Comunicaciones recuperadas, 10 siguen sin poder derivarse

Contexto (histórico): de las Comunicaciones "C" que matchean el filtro del parser, 65 derivaban CERO filas — el dataset tenía 3.042 números de Comunicación distintos sobre 3.107 que deberían haber estado. El fix de cobertura corrió en DOS backfills de producción. Verificado con count(*) sobre el dato vivo en cada corte (no una simulación):

	original	backfill 1 (2026-07-30)	backfill 2 (2026-07-31)
filas	62.084	62.676	62.709
Comunicaciones distintas	3.042	3.078	3.099
identidades distintas	48.630	48.649	48.665
identidades Suspendida	36.847	36.296	36.308
identidades Habilitada	11.783	12.353	12.357
cola de revisión	—	32	13

Ojo cómo leer los saltos entre columnas: Suspendida/Habilitada NO cierran 1 a 1 entre sí en ningún corte, porque las identidades totales también suben (backfills que agregan identidades enteramente nuevas, como Recaudar S.R.L., que no tenía NINGUNA fila antes). No es correcto leer los deltas como "tantas personas se rehabilitaron": es el cambio neto de TODA la población, mezclando identidades preexistentes que cambiaron de estado con identidades nuevas — no se pudo separar limpio uno de otro sin el estado por-identidad de antes de cada backfill.

Recuperación del backlog original de 65 Comunicaciones (verificado 2026-07-31 comparando la lista de la cola de revisión en cada corte, y por separado con comunicaciones distintas de fecha ≤2026-07-20: 3.042 → 3.076 → 3.097): tras el backfill 1, 34 tenían ya alguna fila y 31 seguían en cero; tras el backfill 2, 21 más se recuperaron. Total: 55 recuperadas, 10 siguen sin ninguna fila.

Casos testigo (sin cambios desde el backfill 1):

CUIT 20-25664766-5 (MAGNOTTA Rodolfo Diego): estado_actual = 'Habilitada' — la Com. C 102062 (2026-07-15) que la levantó está en el dataset.
Recaudar S.R.L. (Com. C 102038): accion = 'Revocación de levantamiento', estado_resultante = 'Suspendida' — antes no tenía NINGUNA fila. Los tres valores de accion están en el CHECK de producción (pg_get_constraintdef lo confirma).

CONTRATO NUEVO desde el backfill 2 (2026-07-31): cuando el CUERPO de una Comunicación usa una forma VERBAL de levantar la suspensión (ej. "se ha resuelto levantar las medidas...") pero la clasificación automática había resuelto accion = 'Suspensión', el parser YA NO ELIGE por su cuenta: manda el documento a la cola de revisión en vez de publicar (o mantener publicado en silencio) un estado de compliance que podría estar invertido. Hoy hay 4 Comunicaciones en esta situación: C 52077, C 57287, C 62482 y C 72821.

Matiz importante, verificado fila por fila (no asumido): C 52077, C 57287 y C 62482 YA ESTABAN PUBLICADAS con la acción invertida (accion = 'Suspensión', estado_resultante = 'Suspendida') ANTES de esta detección, y sus filas NO se tocaron — este fix no retracta dato ya publicado. En la tabla TODAVÍA figuran como 'Suspensión'. Lo que cambió es que ahora además están registradas en la cola de revisión (antes era un defecto silencioso, invisible). Dato tranquilizador, verificado en las tres: el estado_actual NETO es 'Habilitada' — existe un levantamiento posterior genuino en cada caso, así que la respuesta a "¿puede operar hoy?" es correcta. Lo que está MAL es el historial de eventos de esas tres, no el estado vigente. C 72821 (que sí forma parte de las 10 sin ninguna fila) es distinto: nunca se publicó, y sigue en cero — la corrección para publicarla salió a un PR aparte, todavía no aplicado.

Lo que SIGUE pendiente: 10 Comunicaciones del backlog original de 65 sin ninguna fila (incluye C 72821); más C 52077/57287/62482 publicadas con un evento histórico bajo revisión (su estado_actual es correcto igual). Todas quedan registradas en una cola de revisión interna (data_bcra_suspensiones_cambios_review, tabla NO expuesta en el catálogo/MCP — solo la usa el pipeline), que hoy tiene 13 entradas (10 sin fila + 3 con fila pero acción bajo revisión). Ante una decisión de compliance importante, sobre todo si el último evento registrado para una identidad es antiguo o si la identidad tiene pocos eventos, seguir contrastando contra el listado de Comunicaciones C del BCRA (o bcra.regulacion.comunicaciones) antes de darla por buena — el hueco masivo original ya no está, pero no hay garantía al 100%.

ACTUALIZAR ESTE GOTCHA si la cola de revisión cambia de 13, si C 72821 se publica, o si se corrigen los 3 casos de acción invertida (confirmar siempre con count(*) sobre el dato vivo, no asumir).

Nota: el total de filas del dataset siguió subiendo después de este fix por trabajo NO relacionado con cobertura (recuperación de identidades truncadas por el parser, 2026-08-01) — ver la gotcha de identidad faltante para esas cifras; esta tabla queda congelada en el estado de la cobertura al 2026-07-31.

Personas solo con DNI (sin CUIT)

282 filas identifican a la persona solo por DNI; el matching por CUIT solo las pierde — caer a DNI. 36 filas no traen ningún identificador numérico (solo razón social) — verificado 2026-08-01, todas casas/ agencias de cambio que la fuente publicó sin CUIT (calidad_flag = 'sin_cuit_ni_documento', patrón real, no error nuestro). Los 2 casos vigentes de calidad_flag = 'identidad_posiblemente_truncada_por_parser' tienen HOY algún identificador parcial (no entran en este conteo de "sin ningún identificador") — ver gotcha dedicado.

Identidad faltante: hoy no queda ninguna atribuible al parser — pero el flag puede volver a encenderse

Verificado 2026-08-01 contra el código (susp_quality.py) y el dato vivo (recuento real, no una simulación). Dos motivos existen en el vocabulario para decir "falta identidad", pero significan cosas MUY distintas para compliance:

calidad_flag = 'sin_cuit_ni_documento' (36 filas): el BCRA NO publicó ningún identificador para esa entidad — patrón real (casas/agencias de cambio identificadas solo por razón social, ej. C 97456/C 98376). No hay nada más que buscar.
calidad_flag = 'identidad_posiblemente_truncada_por_parser': hoy, 0 filas. Cuando este flag SÍ tiene filas, significa que la fuente traía un identificador recuperable y el PARSER no lo capturó — es nuestro fallo, no de la fuente. Que hoy esté en cero es una mejora real, pero NO es un estado permanente: el flag sigue existiendo en el código y puede volver a encenderse si aparece un patrón de truncamiento todavía no cubierto — no leer "0 filas hoy" como "el problema está resuelto para siempre".

Últimos dos casos recuperados (2026-08-01, verificado fila por fila): en ambos el número estaba en el texto, pero un CALIFICADOR intercalado lo dejaba fuera del alcance del extractor:

Com. C 54462: "RETAMOZO HORACIO CARLOS C.U.I.L. Electoral N° 20-23691431-4" → CUIT 20236914314 recuperado.
Com. C 93018: "GEORGE AL NAOUM (D.N.I. extranjero N° 1.458.670" → documento 1458670 recuperado, tipificado tipo_documento = 'CI' (Cédula de Identidad), NO 'DNI' — pese a que la fuente dice literalmente "D.N.I.", queda correctamente reconocido como documento EXTRANJERO, no un DNI argentino. Importa para cualquier cruce por número de documento: un extranjero mal etiquetado como DNI argentino podría hacer matchear a dos personas distintas (numeraciones de países distintos pueden coincidir en el mismo número).

Antes, el PR #1527 había recuperado otras 5 filas del mismo flag (verificado fila por fila, 2026-08-01):

Com. C 53995: pasó de 1 fila (bloque con 19 personas fusionadas) a 19 filas, una por persona.
Com. C 70360 (Lin Juan / Lin Wei / Lin Yun): los fragmentos "DNI N° 27" desaparecieron — CUIT recuperado (27940314947, 27942430545, 27946219202).
Com. C 79965: de 3 filas (con un fragmento huérfano) a 2 filas limpias.

C 70360 lista a 13 personas DOS VECES — no es un bug nuestro, pero sumá por identidad, no por fila

Verificado 2026-08-01: la Com. C 70360 (listado masivo, 703 filas, 690 identidades distintas) repite exactamente 13 personas dos veces cada una — mismo razon_social, cuit y dni (26 de las 703 filas), ej. "Lin Juan" con cuit = 27940275089 aparece en entidad_orden 300 y 696 (muy separados entre sí: una mención en el cuerpo principal del listado y otra en una corrección al pie del mismo documento). No es un error de nuestro parser duplicando filas — es el propio BCRA repitiendo a esas personas dentro del mismo documento; de hecho esa repetición fue justamente la que permitió recuperar el CUIT completo de varios casos (ver gotcha de identidad faltante).

Importa para no contar doble: un count(*) crudo sobre esta Comunicación sobreestima en 13 la cantidad de personas afectadas. identidad ya deduplica esto correctamente (13 valores repetidos colapsan a 1 cada uno con COUNT(DISTINCT identidad)), así que cualquier agregación por identidad (como la de "estado neto") no se ve afectada — el riesgo es solo para quien cuente filas crudas dentro de esta Comunicación puntual.

Alcance verificado: esto se chequeó específicamente sobre C 70360, NO se hizo un barrido de todo el corpus buscando el mismo patrón en otras Comunicaciones masivas — no asumir que es exclusivo de C 70360 ni que está descartado en otras.

El pipeline puede RETIRAR filas ya publicadas si un documento deja de ser reproducible

Verificado 2026-08-01 contra el código (derive_susp_parser.py): desde un cambio reciente del pipeline, si una corrida posterior reclasifica una Comunicación que HOY tiene filas publicadas como no-parseable (falla a la cola de revisión), esas filas se BORRAN (antes quedaban para siempre, aunque el documento cayera a la cola de revisión — comportamiento previo de este mismo dataset). Tiene un tope de seguridad por FILAS, no por documentos (TOPE_FILAS_RETRACTADAS = 8.000 — muy por encima de cualquier caso de negocio legítimo: la Comunicación más grande de todo el corpus, C 85918, tiene 5.974 filas). Si una corrida intentara retirar más de 8.000 filas de una sola vez, el borrado NO se ejecuta y el pipeline NO publica un snapshot nuevo — sospecha de regresión, no un default silencioso.

Por qué importa para quien consume el dataset: si comparás dos cortes/snapshots y una fila que existía antes ya no está, puede ser este mecanismo — no asumir que es un error de carga.

Estado real verificado 2026-08-01 (no asumido): el mecanismo existe en el código, pero TODAVÍA no retiró ninguna fila en producción — las 3 Comunicaciones que hoy tienen filas con la acción invertida (C 52077/57287/62482, ver gotcha de cobertura) siguen publicadas sin cambios; son las candidatas más directas a una futura retracción si una corrida las vuelve a evaluar. ACTUALIZAR esta nota si alguna de esas filas desaparece.

61% de las filas no traen razón social (solo CUIT/DNI)

Verificado 2026-08-01 (tras los tres backfills): 38.443 de 62.723 filas (61%) tienen razon_social NULL — la Comunicación del BCRA listó esa persona solo por su documento, sin nombre. Está muy concentrado en 2019-2021 (más del 90% de las filas de esos tres años) y reaparece en 2025 (69%) y en 2026 (78,6%, 561 de 714 — antes del fix de cobertura ese año tenía sólo 12,7% de NULL): las Comunicaciones masivas recuperadas por el fix listan CUIT/DNI sin nombre. Para búsquedas por nombre, filtrar explícitamente razon_social IS NOT NULL; para identificar/cruzar personas no asumir que el nombre está poblado — usar CUIT y caer a DNI (ver gotcha anterior).

Comparar dni vs. CUIT da 114 discrepancias, pero solo 29 son inconsistencias reales

Verificado 2026-08-01: comparar dni contra los dígitos 3 a 10 del cuit (el tramo que en un CUIT argentino embebe el DNI) da 114 discrepancias sobre 61.068 filas con ambos campos. Pero 85 de esas 114 NO son un error: son personas con tipo_documento distinto de DNI —63 Cédula de Identidad, 20 Pasaporte, 2 Libreta de Enrolamiento—, es decir extranjeros a quienes AFIP les asignó un CUIT con un cuerpo numérico propio que NO deriva de su documento extranjero (incluye el caso GEORGE AL NAOUM/C 93018 recién recuperado, tipo_documento = 'CI' — ver gotcha de identidad faltante). Que no coincidan ahí es lo ESPERADO por la estructura del CUIT, no un defecto de la fuente ni del parser. Un chequeo que compare dni vs. cuit sin filtrar tipo_documento = 'DNI' va a reportar 114 "errores" falsos.

Las inconsistencias genuinas son 29 (todas con tipo_documento = 'DNI'; no hay ningún caso con tipo_documento NULL en este universo). De esas 29, calidad_flag marca 24 con 'dni_no_coincide_cuit' (83%) y las 5 restantes ya están marcadas con 'cuit_digito_invalido' (el CUIT tenía además un dígito verificador inválido, lo que también explica el desvío) — es decir, el 100% de las 29 ya trae ALGÚN calidad_flag, aunque el flag específico 'dni_no_coincide_cuit' cubre el 83%. Para encontrar las 29, filtrar tipo_documento = 'DNI' antes de comparar dni contra el cuerpo del cuit; no usar la comparación cruda sobre toda la tabla.

Datos personales (personas físicas)

Incluye nombres y DNI/CUIT de personas físicas sancionadas bajo el Régimen Penal Cambiario. Son actos administrativos públicos del BCRA, pero su uso debe respetar la Ley 25.326 de Protección de Datos Personales. Ver content_advisory.