GH GambleHub

Parcing de registros y automatización

TL; DR

La robusta automatización de «soldadura» se construye sobre tres ballenas: ingestión determinista (entrega segura, idempotencia, control de integridad), capa normalizada de datos (esquema único, llaves de yuxtaposición, unidades de tiempo/monedas/signos estandarizados) y disciplina de calidad rígida (validación, tolerancias, DLQ, alertas, correcciones automáticas). El objetivo es convertir los archivos/webhooks de varios lados en tablas estables para conciliar, reportar y BI con SLA sobre disponibilidad.


1) Paisaje de fuentes y formatos

1. 1 Fuentes

PSP/equipadores/agregadores: transacciones, conjuntos, comisiones, dispouts.
Bancos: extractos de MT940, ISO 20022 CAMT. 052/053/054, pagos PAIN. 001/002.
ARMH/monederos/pagos (OCT/RTP/SEPA): registros de payouts, devoluciones.
Crypto-castody/exchange: transacciones on-chain, informes de conversión/comisiones.
Impuestos/Estado. portales: CSV/XLSX/PDF, a veces a través de un navegador de secuencias de comandos.

1. 2 Formatos

CSV/TSV (separadores variativos, locals, codificaciones).
XLSX (multi-costura, celdas combinadas).
XML (ISO 20022 CAMT/PAIN, esquema personalizado XSD).
SWIFT MT940/942 (campos de posición).
JSON-API/NDJSON (descargas incrementales, cursores).
PDF (tabular - parser; escaneos - OCR).
ZIP/TAR. GZ (batches con varios archivos).


2) Arquitectura de ingestión-paipline

Contornos:

1. Landing: la aceptación segura de archivos (SFTP/FTPS/WebAMB/API/webhooks) → inmediatamente contar checksum, mantenemos la materia prima invariablemente.

2. Raw: distribución por fechas/proveedores/batches, almacenamiento con versiones.

3. Normalize: parsing → unificación de tipos/unidades → tablas normalizadas.

4. Validado: post-validación (reglas de calidad) → banderas, DLQ.

5. Matched: correlación con eventos internos/banco.

6. Serving/BI: escaparates para la conciliación/finanzas/operaciones.

Requisitos clave:
  • Idempotencia ingestion: '(proveedor, file_name, file_size, checksum, statement_date)' → una clave única.
  • Repeticiones/retrés: volver a ejecutar el archivo no crea tomas.
  • DLQ (dead-letter queue): todas las reglas no reconocidas/violadas están en una cola aislada.
  • Versioning: nuevo archivo para el mismo día → nueva versión con referencia a la anterior.

3) Seguridad de envío y secretos

Canales: SFTP con claves limitadas; FTPS - sólo con TLS estricto; API - OAuth2/tokens con TTL corto.
Cifrado de contenido: PGP/GPG al cargar archivos; S/MIME para inbox de correo electrónico (si se utilizan).
Control de integridad: SHA-256/512 checksum, comparación con el hash en el manifiesto.
Secretos: almacenado en Vault/KMS, rotación, prohibido en archivos de configuración/logs.
Accesos: RBAC + principio de «menos privilegios», cuentas de servicio individuales.


4) Normalización y esquema de datos

4. 1 Normas universales

Tiempo: siempre UTC en ISO-8601; para fechas settlement es 'DATE' sin TZ.
Sumas: 'DECIMAL (p, s)' en unidades menores + 'scale' separada; signo: parroquia/consumo estrictamente según el diccionario.
Monedas: ISO-4217, tabla de tipos fijos con 'fx _ src'.
Locali: la prohibición de autocartera es una configuración explícita de separadores/punto decimal/milésima.
Codificaciones: iniciar sesión en UTF-8; otros - conversión con el logotipo.

4. 2 Capa «plana» normalizada (ejemplo)

json
{
"provider": "Acquirer_A",
"source_kind": "PSP_TX    PSP_SETTLEMENT    BANK    WALLET    CRYPTO",
"kind": "AUTH    CAPTURE    REFUND    PAYOUT    FEE    SETTLEMENT    CHARGEBACK",
"payment_id": "pay_123",        // ваше
"provider_txid": "psp_abc_789",    // внешнее
"merchant_ref": "mr_456",
"sequence": 0,             // partial/refund line index
"amount_minor": 100000,        // 1000.00
"currency": "EUR",
"fee_minor": 120,           // 1.20
"fx_rate": 1.0000,
"fx_src": "PSP    ECB    BANK",
"event_ts": "2025-11-03T12:00:00Z",
"value_date": "2025-11-05",
"account": "PSP_MERCHANT_CARD_A",
"bin": "425000",
"last4": "1234",
"status": "APPROVED    CAPTURED    SUCCESS    FAILED    SETTLED",
"file_id": "ing_20251103_001",
"row_hash": "sha256(raw_row)"
}

5) Parsers por formatos: recepciones y rastrillos

5. 1 CSV/TSV

Especifique explícitamente 'delimiter', 'quotechar', 'escapechar', 'encoding'.

Detalle de las filas vacías/cambios de título; soporte para header aliases (por ejemplo, 'AmountAMTTxnAmount`).
Transformación de signo (menos/paréntesis), normalización de milésimas (', '/' ./espacios).

5. 2 XLSX

Leer por sheet whitelist; prohibición de autoliquidaciones - aplanamiento de células unidas.
Convertir fórmulas en valores; fechas de Excel → UTC con TZ explícito.

5. 3 XML (ISO 20022 CAMT/PAIN)

Validación por XSD; XPath-mapping (<Ntry>, <TxDtls>, <Amt>, <CdtDbtAmb>).
Normalización de credit/debit → signo; soporte para múltiples '<Chrgs', '<RmtAmb'.

5. 4 MT940

Análisis de etiquetas ': 61:', ': 86:'; Apoyo a las ampliaciones nacionales; campos de posición → reglas de slicing.
Consolidación de varios ': 61:' en un solo batch.

5. 5 JSON/NDJSON/API

Cursores 'since _ idcreated_atpage_token`; rate-limit aware retraie (429 → backoff + jitter).
Semántica parcial (varias líneas de referencia a una sola 'provider _ txid').

5. 6 PDF/OCR

Primero se intenta el parsing tabular (aprox-detector), sólo después el OCR (Tesseract) con caracteres whitelist.
Post-validación: sumas, resultados de control, conciliar el número de líneas.

5. 7 Archivos/batches

Desempaquetar manteniendo la estructura; cada archivo es un 'file _ id' independiente; manifiesto, control de todas las partes.


6) Validaciones y normas de calidad de los datos

Comprobaciones obligatorias:
  • Esquema: todos los campos requeridos están presentes.
  • Tipos: sumas - numéricas, fechas - pares.
  • Sumas de comprobación/totales: suma de filas = total en el archivo (si lo hay).
  • Rangos: fecha en una ventana razonable; suma> 0 (o por diccionario de negativos permitidos).
  • Singularidad: '(provider, provider_txid, sequence)' no se duplica en normalizado.
  • Tolerances: discrepancias permitidas 'amount/fx/time'.

Resultado: 'VALID', 'VALID _ WITH _ WARNINGS', 'INVALID → DLQ (reason_code)'.


7) Idempotencia y deduplicación

Ingestion key: '(proveedor, file_name, filesize, checksum, statement_date)' → el único 'file _ id'.
Row-level idem: `row_hash = sha256(normalized_row_compact)`; volver a cargar no crea nuevos registros.
Webhooks/API: 'idempotency _ key' proveedor + sus etiquetas ('exec _ id'), almacenar TTL.
Dobles del proveedor: dedoup por 'provider _ txid' + 'sequence', en caso de discrepancia, en DLQ_DUPLICATE.


8) Orquestación y horarios

Оркестратор: Airflow/Dagster (DAG: `fetch → decrypt → parse → normalize → validate → publish → match`).
SLA/SLO: 'Time-to-Availability (TtA)' desde la aparición del archivo hasta 'normalizado = READY'.
Retrai: retroceso exponencial + jitter; límites de intento; estados claros.
Paralelismo y aislamiento: XLSX heavy OCR/parsing - en un pool/worker separado con límite CPU/RAM.
DLQ-replay: repetición periódica cuando se actualizan las reglas/mappings.


9) Observabilidad y alertas

Métricas:
  • Éxito de la ingeniería%, Éxito de Parse% según las fuentes.
  • TtA p50/p95, Throughput (líneas/min).
  • DLQ Rate и Aging DLQ p50/p95.
  • Schema Drift Incidents (cambio de título/formato).
  • Duplicate Rate по `provider_txid`.
Alertas (ejemplo):
  • `TtA p95 > SLA` → P1.
  • 'DLQ Rate> 2%' por hora por proveedor de → P1.
  • 'Schema Drift detected' → P0 (parada de auto-match según la fuente).
  • 'Duplicate spike' → P2 (comprobar proveedor/webhooks).

Dashbord: el embudo ' files → rows_raw → rows_norm → rows_valid → rows_matched ', la tarjeta DLQ por las causas, TtA-kvantili.


10) Autocorrección y Mappings

Header aliases: diccionario con versiones (e. g., `Amount`→`amt`, `AMOUNT`→`amt`).

Mapas de código: los estados del proveedor → su referencia ('APPROVEDCAPTUREDSETTLED`).
Política de señalización: 'CR/DR', 'C/D', paréntesis - en un único modelo «icónico».
Amount repair: eliminación de milésimas separadores, normalización de menos.
Reparación de Timezone: tiempo local del proveedor → UTC con DST en mente.
💡 Cualquier autocorrección: se lógica y marca en 'repair _ flags'.

11) Relación con «Conciliación de pagos e informes PSP»

La capa normalizada terminada es la entrada para el match (provider_txid/merchant_ref/fuzzy), cálculo de taxonomia diff, registros automáticos y settlement↔bank de costura. Los campos clave son: 'provider _ txid', 'sequence', 'kind',' amount _ minor ',' value _ date ',' account '.


12) Modelo de almacenamiento y tabla

Tabla de archivos landed:
sql
CREATE TABLE landed_files (
file_id TEXT PRIMARY KEY,
provider TEXT,
source_kind TEXT,
file_name TEXT,
file_size BIGINT,
checksum TEXT,
statement_date DATE,
received_at TIMESTAMP WITH TIME ZONE,
version INT,
status TEXT, -- RECEIVED    PARSED    FAILED error TEXT
);
Cadenas normalizadas:
sql
CREATE TABLE psp_norm (
row_id BIGSERIAL PRIMARY KEY,
file_id TEXT REFERENCES landed_files(file_id),
provider TEXT,
source_kind TEXT,
kind TEXT,
payment_id TEXT,
provider_txid TEXT,
merchant_ref TEXT,
sequence INT,
amount_minor BIGINT,
currency CHAR(3),
fee_minor BIGINT,
fx_rate NUMERIC(18,8),
fx_src TEXT,
event_ts TIMESTAMPTZ,
value_date DATE,
account TEXT,
status TEXT,
row_hash TEXT UNIQUE,
repair_flags TEXT[]
);
CREATE INDEX idx_psp_norm_txid ON psp_norm(provider, provider_txid, sequence);

13) Pseudocódigo de los parsers

CSV/XLSX:
python def parse_table(file, spec):
df = load_csv_or_xlsx(file, delimiter=spec.delim, encoding=spec.enc, sheet=spec.sheet)
df = rename_headers(df, spec.header_aliases)
df = clean_amounts(df, thousand=spec.thousand, decimal=spec.decimal, sign_policy=spec.sign)
rows = []
for r in df.itertuples():
rows.append(normalize_row(r, spec))
return rows
XML CAMT:
python def parse_camt(xml):
root = parse_xml(xml, xsd="camt053.xsd")
for ntry in root.findall('.//Ntry'):
sign = 1 if ntry.findtext('CdtDbtInd') == 'CRDT' else -1 amt = Decimal(ntry.findtext('Amt')) sign
... map to normalized fields
OCR PDF (fallback):
python def parse_pdf_ocr(pdf):
text = tesseract(pdf, lang="eng", psm=6, whitelist="0123456789.,-;:/A-Za-z")
table = detect_table(text)
return normalize_table(table)

14) GDPR/PII y edición de registros

Enmascaramiento/hashing: PAN/email/teléfono → 'sha256 + salt', registros - sin valores primarios.
Política de retención: 'retention' por tipo de origen (AML/contabilidad).
Accesos PII - sólo por función; auditoría de lecturas/exportaciones.


15) KPI y objetivos (para parsing/ingestion)

Ingestion Success % ≥ 99. 5 %/día por fuente.
Parse Success % ≥ 99%, DLQ ≤ 1%.
TtA p95 (fayl→normalized) ≤ 15 minutos (CSV/XML), ≤ 60 minutos (PDF/OCR).
Schema Drift Incidents: 0/mes sin alerta/fix.
Duplicate Rate по `provider_txid` ≤ 0. 05%.


16) Playbucks de incidentes

Schema drift: stop auto-match, encienda el parser «suave» con altavoces ML-baby, prepare el parche de alias, ahuyente el DLQ-replay.
Ráfaga DLQ: depurar los archivos más recientes, verificar la codificación/locali/signo, rebajar temporalmente el rigor de los tolerantes (con bandera).
Retrasos de SFTP: cambio a API-polling/webhooks, aumento de retraídas, comunicación con el proveedor.
Spikes duplicates: habilita el control previo de 'row _ hash', un bloque de repeticiones hasta que se aclare.


17) Paquete de prueba de casos (UAT/Prod-preparación)

1. Idempotencia: repetir la misma carga → 1 'file _ id', 0 nuevas filas.
2. Locali: archivos con ', '/' ./espacios → cantidades correctas.
3. Parte/refund: varias 'sequence' a una 'provider _ txid'.
4. XML XSD: CAMT invisible → 'INVALID' + DLQ.
5. Variaciones MT940: ampliaciones nacionales → análisis correcto.
6. PDF→OCR: escaneo con ruido → extracción y aprobación de las reglas básicas.
7. Schema drift: nuevo hader → parche alias y volver a procesar archivos históricos.
8. Throughput: prueba de carga de archivos N/hora → cumplimiento de TtA SLA.
9. Edición PII: registros sin PAN/e-mail, sólo hashes.


18) Lista de verificación de implementación

  • Registro de fuentes: protocolo, horario, SLA, formato, contacto.
  • Canales seguros (SFTP/PGP/API), Vault para secretos.
  • Idempotent ingestion + checksum + versiones.
  • Parsers por formatos, alias-diccionario, sign/locale-policy.
  • Capa normalizada e índices de claves.
  • Reglas de validación, toleranzas, DLQ y replay.
  • Orquestador (DAG), retrai/backoff, grupos de recursos.
  • Observabilidad: métricas, dashboards, alertas.
  • Enmascaramiento GDPR/PII, auditorías de acceso.
  • Casos de prueba y drills regulares de schema-drift.

Resumen

La automatización del parsing no es «escribir parser», sino construir un circuito industrial: entrega y encriptación confiables, paipelines idempotentes, normalización estricta, reglas de calidad y alertas transparentes. Este esquema convierte cualquier registro en tablas predecibles con un SLA garantizado para la disponibilidad de datos - una base para la verificación, tesorería e informes de gestión.

Contact

Póngase en contacto

Escríbanos ante cualquier duda o necesidad de soporte.¡Siempre estamos listos para ayudarle!

Iniciar integración

El Email es obligatorio. Telegram o WhatsApp — opcionales.

Su nombre opcional
Email opcional
Asunto opcional
Mensaje opcional
Telegram opcional
@
Si indica Telegram, también le responderemos allí además del Email.
WhatsApp opcional
Formato: +código de país y número (por ejemplo, +34XXXXXXXXX).

Al hacer clic en el botón, usted acepta el tratamiento de sus datos.