Fundamentos de los sistemas de pago: libros contables, compensación y liquidación

La mayoría de los ingenieros de software conocen los pagos a través de una API: envías una petición, recibes un estado y esperas que diga ACCEPTED. Esa visión aguanta hasta el primer incidente en producción —un cargo duplicado, un pago atascado dos días en PENDING, un archivo de conciliación que no cuadra— y entonces toca abrir la abstracción. Debajo de la API hay una cadena de entidades, libros contables, horas de corte y obligaciones legales, y casi cada comportamiento incómodo de una API de pagos es el reflejo fiel de algo real en esa cadena.

Esta guía construye el modelo desde abajo. Deja fuera a propósito las tarjetas, que tienen su propia coreografía a cuatro partes y se tratan en pagos con tarjeta, y también el acceso regulado de terceros que introdujo la legislación europea, tratado en PSD2 y open banking. Lo que sigue es la base sobre la que se apoya todo eso.

Un pago es una transferencia de obligaciones

El saldo que muestra una app bancaria no es una caja de dinero con tu nombre. Es un pasivo: una cantidad que la entidad te debe, reembolsable a la vista. Cuando pagas a alguien de otra entidad, no se teletransporta ningún valor. Tu banco reduce lo que te debe y, a la vez, asume una obligación con el banco del beneficiario; el banco del beneficiario aumenta lo que debe a su cliente. Ahora los dos bancos están descuadrados entre sí, y ese desequilibrio hay que saldarlo por separado.

Ese reequilibrio se hace en dinero de banco central: los saldos que los bancos comerciales mantienen en su banco central, el único derecho de cobro del sistema que no conlleva riesgo de contraparte. Todo lo que experimenta un cliente minorista es dinero de banco comercial, un derecho de cobro frente a una entidad privada. Esta distinción explica mucho: por qué la quiebra de un banco es contagiosa, por qué los sistemas de liquidación los gestionan instituciones públicas y por qué «el pago se ha enviado» y «el pago es firme» son afirmaciones distintas.

En todos los esquemas se repiten tres papeles: el ordenante (cuya cuenta se carga), el beneficiario (cuya cuenta se abona) y uno o varios proveedores de servicios de pago que actúan por cuenta de ellos. Un esquema es el reglamento que los proveedores aceptan: formatos de mensaje, plazos, responsabilidades y qué ocurre cuando algo sale mal.

Cuentas, libros contables y partida doble

La estructura de datos central de todo sistema de pagos es un libro contable (ledger), y la disciplina que lo mantiene honesto es la contabilidad por partida doble. Cada hecho económico se registra como dos o más apuntes cuyos importes con signo suman cero. Nunca se actualiza nada in situ; las correcciones son apuntes nuevos. Un saldo no es una columna que se sobrescribe, sino la suma de los apuntes de una cuenta.

Transaction T-8841 — customer pays 250.00 EUR to a supplier

  account                       debit     credit
  --------------------------------------------- 
  customer:4711                250.00
  clearing:sepa-outbound                  250.00
                               ------    ------
                               250.00    250.00     -> balanced

Las convenciones confunden a los recién llegados porque están escritas desde el punto de vista de la entidad: el depósito de un cliente es un pasivo del banco, así que abonar la cuenta del cliente aumenta lo que el banco debe. En lugar de discutir sobre signos, la mayoría de los equipos de ingeniería guardan un entero con signo en unidades menores (céntimos, no floats) y un indicador de sentido, y derivan la presentación contable después.

Un esquema de libro contable que sobrevive a una auditoría suele tener este aspecto:

CREATE TABLE ledger_entry (
  id             BIGSERIAL PRIMARY KEY,
  transaction_id UUID        NOT NULL,
  account_id     BIGINT      NOT NULL,
  amount_minor   BIGINT      NOT NULL,   -- signed, in minor units
  currency       CHAR(3)     NOT NULL,
  booked_at      TIMESTAMPTZ NOT NULL DEFAULT now(),
  value_date     DATE        NOT NULL
);
CREATE INDEX ON ledger_entry (account_id, booked_at);
-- invariant, enforced in the write path and re-checked by a nightly job:
--   SELECT transaction_id FROM ledger_entry
--   GROUP BY transaction_id, currency HAVING SUM(amount_minor) <> 0;

Hay dos detalles que importan más de lo que parece. Nunca mezcles divisas dentro de una misma transacción cuadrada sin una cuenta de cambio explícita; de lo contrario, el invariante de suma cero deja de tener sentido. Y distingue booked_at (cuándo registró el apunte tu sistema) de value_date (cuándo el dinero surte efecto económico): intereses, horas de corte y disputas dependen de la segunda, no de la primera. Las retenciones y autorizaciones se modelan como apuntes contra una cuenta dedicada a fondos reservados, de modo que el saldo disponible es una consulta sobre el libro contable y no un campo mutable que puede desviarse. Estas consideraciones se solapan mucho con el diseño y la normalización de bases de datos; lo habitual son tablas append-only con agregados derivados.

Las familias de instrumentos

Los instrumentos se diferencian sobre todo en quién inicia el pago, quién asume el riesgo de retrocesión y cuánto tarda en ser firme.

La distinción push frente a pull es la que hay que interiorizar. Un instrumento push no puede dejar en descubierto una cuenta que el ordenante no controla, así que el fraude suele ser de ingeniería social. Un instrumento pull permite a un comercio meter la mano en una cuenta, y los esquemas lo compensan con mandatos, notificación previa y derechos de devolución generosos; por eso el cobro de un adeudo directo no es un ingreso que puedas reconocer con tranquilidad el primer día. Un monedero no es un rail aparte: es una experiencia de usuario montada sobre tarjetas, transferencias o un saldo almacenado, y su perfil de riesgo es el de lo que tenga debajo.

Compensación frente a liquidación

La compensación (clearing) es el intercambio y la validación de órdenes entre entidades, incluido el cálculo de quién debe qué. La liquidación (settlement) es la extinción definitiva de esas obligaciones. Los sistemas se diferencian en cómo combinan ambas.

Un sistema de liquidación bruta en tiempo real (RTGS) liquida cada orden por separado y de inmediato en dinero de banco central. No hay neteo ni exposición crediticia entre participantes, pero cada pago debe tener fondos en el momento en que se emite, así que los participantes necesitan mucha liquidez intradía. Los pagos de alto importe y los urgentes funcionan así.

Un sistema de liquidación neta diferida acumula órdenes durante un ciclo y solo liquida las posiciones netas.

Gross obligations during one clearing cycle (millions)

  A -> B  40      B -> A  25      A -> C  30
  C -> A  15      B -> C  20      C -> B  35

Multilateral net positions
  A:  pays 70, receives 40  ->  -30   (must fund 30)
  B:  pays 60, receives 75  ->  +15
  C:  pays 50, receives 65  ->  +15
                                ----
  sum of net positions            0   (always true)

Gross value exchanged 165, actual settlement 30 -> ~82% liquidity saving

El neteo es enormemente eficiente y, en la misma medida, arriesgado: entre el momento en que se compensa una orden y el momento en que se liquida el ciclo, los participantes están expuestos entre sí. Los sistemas modernos lo mitigan con prefinanciación, garantías, reglas de reparto de pérdidas y ciclos más cortos. Siempre que veas una restricción extraña en un esquema de pagos —horas de corte, límites de importe, prefinanciación obligatoria—, lo normal es que tenga su origen en la gestión de esa ventana.

Identificar la cuenta: IBAN y BIC

Un IBAN identifica una cuenta a nivel internacional: un código de país de dos letras, dos dígitos de control y luego el identificador nacional de la cuenta (el BBAN), hasta 34 caracteres. Su mejor virtud es que una errata puede detectarse en el cliente, antes de que se mueva dinero, con una comprobación módulo 97 definida en la norma ISO.

IBAN:  GB11 ABCD 1234 5678 9012 34

1. Move the first four characters to the end:
   ABCD12345678901234 GB11
2. Replace each letter by its position in the alphabet + 9 (A=10 ... Z=35):
   1011121312345678901234161111
3. Take that (very large) integer modulo 97:
   1011121312345678901234161111 mod 97 = 1
4. A remainder of exactly 1 means the check digits are consistent.

Para generar los dígitos de control en lugar de verificarlos, pon 00 en su posición, calcula el resto de la cadena reordenada y usa 98 - remainder. Como el número supera cualquier tipo entero nativo, las implementaciones lo procesan por trozos:

static int mod97(String rearranged) {
    int remainder = 0;
    for (int i = 0; i < rearranged.length(); i++) {
        char c = rearranged.charAt(i);
        int value = Character.isDigit(c) ? c - '0' : c - 'A' + 10;
        remainder = (remainder * (value > 9 ? 100 : 10) + value) % 97;
    }
    return remainder;
}
// valid when mod97(iban.substring(4) + iban.substring(0, 4)) == 1

Unos dígitos de control válidos solo demuestran que la cadena es coherente consigo misma, no que la cuenta exista, esté abierta o pertenezca a la persona indicada. Un BIC (a veces aún llamado código SWIFT) identifica la entidad y no la cuenta: cuatro letras para la entidad, dos para el país, dos para la ubicación y un sufijo opcional de sucursal de tres caracteres. En muchos flujos nacionales y europeos, el BIC ya se deduce en lugar de indicarse.

SEPA, banca corresponsal e ISO 20022

Dentro de la zona euro, la Zona Única de Pagos en Euros (SEPA) armonizó los pagos en euros en un pequeño conjunto de esquemas regidos por reglamentos públicos: un esquema de transferencias, un esquema de adeudos directos en sus variantes básica (core) y entre empresas (B2B), y un esquema de transferencias inmediatas que entrega los fondos en segundos, a cualquier hora, hasta un límite fijado por el esquema. Las consecuencias técnicas de los esquemas inmediatos son serias: ya no existe una ventana de proceso nocturno para ejecutar los controles antifraude, el filtrado de sanciones y la gestión de liquidez, así que todo debe ocurrir en línea, en unos cientos de milisegundos, sin opción de decir «ya lo arreglaremos mañana».

Los pagos transfronterizos fuera de un esquema común usan la banca corresponsal (correspondent banking). Un banco que no tiene cuenta en el banco de destino enruta a través de un intermediario en el que sí tiene cuentas: una cuenta nostro (nuestro dinero en su banco) reflejada en su cuenta vostro. Cada salto añade una comisión, una hora de corte y un paso de filtrado, y por eso los pagos transfronterizos tradicionales son lentos y su seguimiento es un producto en sí mismo.

La mensajería de todos estos sistemas converge en ISO 20022, un diccionario de datos junto con definiciones de mensajes XML (y cada vez más JSON) con nombres como pain.001 (iniciación de transferencia del cliente), pacs.008 (transferencia interbancaria) y camt.053 (extracto del banco al cliente). Frente a los antiguos formatos de líneas fijas heredados de la época del télex, transporta partes estructuradas, información de remesa y códigos de finalidad detallados, lo que hace mucho más precisos la conciliación automática y el filtrado.

<CdtTrfTxInf>
  <PmtId><EndToEndId>INV-2026-000871</EndToEndId></PmtId>
  <Amt><InstdAmt Ccy="EUR">1250.00</InstdAmt></Amt>
  <Cdtr><Nm>Beneficiary Company Ltd</Nm></Cdtr>
  <CdtrAcct><Id><IBAN>GB11ABCD12345678901234</IBAN></Id></CdtrAcct>
  <RmtInf><Ustrd>Invoice 2026-000871</Ustrd></RmtInf>
</CdtTrfTxInf>

Fíjate en EndToEndId: una referencia elegida por el ordenante que cada entidad debe transmitir sin cambios hasta el beneficiario. Es el gancho que hace posible la conciliación de extremo a extremo, y poner ahí un UUID aleatorio en lugar de tu propia referencia de negocio es un error del que te arrepentirás en el cierre de mes.

Escribir software de pagos que aguante

Un servicio de pagos es un sistema distribuido en el que uno de los participantes —el mundo exterior— nunca hace rollback. Cuatro hábitos hacen la mayor parte del trabajo.

Sé idempotente en la frontera. Cada orden lleva una clave proporcionada por el cliente; el servidor la guarda junto con el pago resultante y devuelve la respuesta original ante cualquier reintento. Sin esto, un timeout de socket se convierte en un doble cargo.

POST /v1/payments HTTP/1.1
Content-Type: application/json
Idempotency-Key: 4f0a2c1e-9d3b-4a77-8c0e-6a1f7b2d5c93

{"debtorAccount":"GB11ABCD12345678901234",
 "amount":{"currency":"EUR","value":"1250.00"},
 "endToEndId":"INV-2026-000871"}

Modela el pago como una máquina de estados explícita. RECEIVED → VALIDATED → SUBMITTED → SETTLED, con REJECTED y RETURNED como ramas terminales, y cada transición escrita en el libro contable y en un registro de auditoría. Resiste la tentación de fusionar estados: «enviado al esquema» y «confirmado por el esquema» implican responsabilidades distintas.

Nunca confíes en un único sistema de registro. Concilia tu libro contable con los extractos de cuenta que envía el esquema o el corresponsal, cada día, de forma automática, y alerta ante cualquier descuadre partida a partida, no ante una simple diferencia de totales: dos errores de signo contrario pueden sumar cero y seguir siendo dos errores. Aquí es donde un EndToEndId estructurado demuestra su valor.

Prefiere una semántica de mensajería que puedas defender. Los rails de pago entregan at-least-once y a veces fuera de orden; la deduplicación y el orden son problema tuyo, exactamente como se describe en patrones y garantías de mensajería. Cuando una operación de negocio abarca varios servicios, usa transacciones de compensación en lugar de un commit en dos fases que cruce fronteras entre entidades, como se explica en transacciones distribuidas y consistencia.

Dos advertencias para terminar. El dinero nunca es un número en coma flotante: guarda las unidades menores como enteros y lleva la divisa al lado, porque las reglas de redondeo cambian según la divisa y el esquema. Y trata la cancelación como una petición, no como una orden: una vez que una instrucción ha pasado a un esquema, la única API honesta es «recall solicitado», cuyo resultado depende de la buena voluntad de otra entidad.

Ideas clave

• Un pago transfiere una obligación entre entidades; lo que realmente viaja entre ellas es un mensaje, y el desequilibrio se salda más tarde en dinero de banco central.
• Los libros contables por partida doble, con apuntes append-only en unidades menores enteras, te dan saldos, retenciones, retrocesiones y una pista de auditoría que concilia.
• Los instrumentos push protegen al ordenante; los pull protegen al beneficiario con mandatos y plazos de devolución. Elige teniendo en cuenta el riesgo de retrocesión.
• La compensación acuerda quién debe qué; la liquidación lo extingue. La liquidación bruta elimina el riesgo de crédito a costa de liquidez; el neteo hace lo contrario.
• Los dígitos de control del IBAN detectan erratas en el cliente, y los mensajes ISO 20022 transportan las referencias estructuradas que hacen automática la conciliación.
• Claves de idempotencia, máquinas de estados explícitas, conciliación diaria y transacciones de compensación son los cuatro hábitos que mantienen honesto un servicio de pagos.