Manual técnico - Simulación del Ecosistema Financiero Virtual

1Qué es esto

Un gemelo digital del ecosistema financiero: contrapartes simuladas de cada institución con la que una aplicación de pagos o financiera debe comunicarse en la República Dominicana, organizadas exactamente como el Banco Central organiza el sistema real.

Cada contraparte habla el formato de mensaje propio de su clase, mantiene estado - cuentas, saldos, órdenes, casos -, obedece las reglas que fija el Reglamento y puede ponerse en modos de falla. Su equipo conecta su aplicación y ejecuta un proceso completo de extremo a extremo, desde la vinculación hasta la liquidación en el LBTR simulado, sin tocar una institución real, una persona real ni dinero real. Cada mensaje queda registrado y la corrida produce un informe instrumentado.

El valor no está en ningún simulador aislado. Está en que todos existen juntos, de forma consistente, en un mismo lugar, con una única población sintética que los atraviesa, de manera que un proceso que cruza seis organizaciones pueda ejercitarse como un solo proceso y bajo las reglas que regirán cuando sea real.

Todo lo que hay aquí es simulado. Cada institución lleva un nombre del Lab, ninguna es la entidad que modela y ninguna reclama su respaldo. No existen en el ecosistema credenciales, llaves, BIN, identificadores de enrutamiento, alias ni certificados reales, y no interviene ninguna persona, institución ni dinero real.

Esto NO es un «ambiente de prueba» conforme al Art. 83 del Reglamento de Sistemas de Pago. El ecosistema no involucra proveedores reales ni usuarios externos reales, de modo que no queda bajo el régimen de no objeción. Una corrida nunca sustituye la no objeción del Banco Central. Si su siguiente paso es una solicitud al amparo del Art. 83, el informe de una corrida es evidencia para esa solicitud y nada más.

«Hoy esto es una simulación, no un gemelo digital en sentido estricto: todavía no existe un sistema terminado del cual ser gemelo, porque el sistema de pagos instantáneos se está construyendo ahora. Nuestra meta es convertirnos en el verdadero gemelo digital del ecosistema financiero dominicano a medida que toma forma, siguiendo el trabajo y los lineamientos del Banco Central, la Superintendencia y la industria.»

Qué está en operación hoy

Esta instancia ejecuta la totalidad de la Fase 1 y los contratos tipados de la Fase 2. Contiene 76 reglas catalogadas, 12 escenarios que comprenden 32 corridas con sus variantes, y 46 endpoints documentados.

Fase	Qué comprende	Estado
Fase 0	Catálogo de actores, contratos de mensajes, formatos de escenario y de reglas, población sintética, nomenclatura y advertencias. Tres de los cuatro instructivos del BCRD leídos página por página e incorporados al catálogo.	completa
Fase 1	Banco Central con cuentas corrientes, LBTR con su cola, prioridad y prelación; SGPI con fidelidad de estado; Pagos al Instante; tres bancos con tres personalidades; una entidad de pago electrónico; el administrador DD/DC; identidad y buró de crédito; la red de cajeros y el carril de máquinas; el nivel de comportamiento; una detección adversarial puntuada; la consola; mundos por equipo.	en operación
Fase 2	Adquirente y subadquirente con estado, el códec de cable ISO 8583 empaquetado, compensación de tarjetas y contracargos, proveedores de billetera e iniciación, agentes con estado, el supervisor y la UAF simulados, inyectores de caos.	solo contratos tipados
Fase 3	Cheques y el SCC, aseguradoras y corredores, agentes de remesas y de cambio, SIPA, telcos y la administración tributaria, el resto del catálogo adversarial.	no iniciada
Fase 4	Catálogo público y llaves autogestionadas, nodos patrocinados, acceso de reguladores y de la academia.	este manual es su primera parte

Un stub es honesto respecto de ser un stub. Los actores de la Fase 2 responden con respuestas enlatadas detrás de un contrato tipado, de modo que una integración escrita hoy contra ellos sigue funcionando cuando adquieran estado; ese es el sentido de publicarlos temprano. Una respuesta enlatada no prueba nada, y la referencia de endpoints indica en qué nivel está cada actor.

2Inicio rápido

Cinco minutos: obtener una llave, preguntar si la instancia responde, leer su mundo, enviar un pago y abrir la corrida que produjo.

1. Obtener una llave de equipo

La llave se emite a un equipo, no a una persona. Solicítela mediante el formulario de solicitud o escriba a partners@cemi.ai. El Lab le entrega una cadena que comienza con lab-. Colóquela en una variable de entorno y manténgala fuera de su repositorio, de sus comandos de despliegue y del historial de su consola.

2. Todo lo demás

# 1. the key never appears in a command, a file or a shell history
export FINLAB_API_KEY="<the key the Lab gave your team>"
export FINLAB="https://ecosystem.financial"

# 2. is it up, and what is it running?
curl -s "$FINLAB/v1/health" | jq

# 3. what is in your world?
curl -s -H "x-lab-api-key: $FINLAB_API_KEY" "$FINLAB/v1/directory" | jq '{
  institutions: [.institutions[] | select(.role=="bank") | .id],
  aliases: [.aliases[0:3][] | .alias],
  firstPerson: .people[0]
}'

# 4. send an instant payment, addressed by alias, in ISO 20022 shape
curl -s -X POST "$FINLAB/v1/payments/instant" \
  -H "x-lab-api-key: $FINLAB_API_KEY" -H 'content-type: application/json' \
  -d '{
    "GrpHdr": { "MsgId": "MSG-0001" },
    "CdtTrfTxInf": [{
      "PmtId": { "EndToEndId": "E2E-0001" },
      "Amt": { "InstdAmt": { "Ccy": "DOP", "value": 1500.00 } },
      "DbtrAgt": { "FinInstnId": { "Othr": { "Id": "banco-norte" } } },
      "DbtrAcct": { "Id": { "Othr": { "Id": "<an account number from the directory>" } } },
      "CdtrAlias": "<an alias from the directory>"
    }]
  }' | jq

# 5. run a scenario end to end, and open its report
curl -s -X POST "$FINLAB/v1/runs" \
  -H "x-lab-api-key: $FINLAB_API_KEY" -H 'content-type: application/json' \
  -d '{ "scenario": "sgpi-instant-alias" }' | jq
curl -s -H "x-lab-api-key: $FINLAB_API_KEY" "$FINLAB/v1/runs" | jq '.[0]'

// Node 18+ or any modern browser runtime. No SDK: it is plain HTTP.
const BASE = process.env.FINLAB ?? 'https://ecosystem.financial';
const KEY = process.env.FINLAB_API_KEY;            // never hard-code the key
const headers = { 'x-lab-api-key': KEY, 'content-type': 'application/json' };

async function call(path, init = {}) {
  const res = await fetch(BASE + path, { ...init, headers: { ...headers, ...(init.headers ?? {}) } });
  const body = await res.json();
  if (!res.ok) throw Object.assign(new Error(body.message ?? res.statusText), { status: res.status, body });
  return body;
}

const health = await call('/v1/health');
console.log(health.status, 'rule catalogue', health.ruleCatalogue);

// everything your team's world holds
const directory = await call('/v1/directory');
const payer = directory.people.find((p) => p.accounts.some((a) => a.kind === 'sight'));
const payee = directory.aliases.find((a) => a.holder !== payer.fullName);

// an instant payment, addressed by alias
const result = await call('/v1/payments/instant', {
  method: 'POST',
  body: JSON.stringify({
    GrpHdr: { MsgId: 'MSG-0001' },
    CdtTrfTxInf: [{
      PmtId: { EndToEndId: 'E2E-' + Date.now() },
      Amt: { InstdAmt: { Ccy: 'DOP', value: 1500.0 } },
      DbtrAgt: { FinInstnId: { Othr: { Id: payer.accounts[0].institution } } },
      DbtrAcct: { Id: { Othr: { Id: payer.accounts[0].accountNumber } } },
      CdtrAlias: payee.alias,
    }],
  }),
});

// the findings are the point: every rule the payment touched, with its article
for (const finding of result.findings) {
  console.log(finding.status.toUpperCase(), finding.ruleId, '-', finding.article, '-', finding.detail);
}

# Python 3.9+, standard library only. No SDK: it is plain HTTP.
import json, os, urllib.request

BASE = os.environ.get("FINLAB", "https://ecosystem.financial")
KEY = os.environ["FINLAB_API_KEY"]          # never hard-code the key


def call(path, body=None):
    data = json.dumps(body).encode() if body is not None else None
    req = urllib.request.Request(
        BASE + path,
        data=data,
        headers={"x-lab-api-key": KEY, "content-type": "application/json"},
        method="POST" if data else "GET",
    )
    try:
        with urllib.request.urlopen(req) as res:
            return json.load(res)
    except urllib.error.HTTPError as err:            # a refusal is an answer, so read it
        raise SystemExit(json.load(err)) from None


health = call("/v1/health")
print(health["status"], "rule catalogue", health["ruleCatalogue"])

directory = call("/v1/directory")
payer = next(p for p in directory["people"] if p["accounts"])
payee = next(a for a in directory["aliases"] if a["holder"] != payer["fullName"])

result = call("/v1/payments/instant", {
    "GrpHdr": {"MsgId": "MSG-0001"},
    "CdtTrfTxInf": [{
        "PmtId": {"EndToEndId": "E2E-0001"},
        "Amt": {"InstdAmt": {"Ccy": "DOP", "value": 1500.00}},
        "DbtrAgt": {"FinInstnId": {"Othr": {"Id": payer["accounts"][0]["institution"]}}},
        "DbtrAcct": {"Id": {"Othr": {"Id": payer["accounts"][0]["accountNumber"]}}},
        "CdtrAlias": payee["alias"],
    }],
})

for finding in result["findings"]:
    print(finding["status"].upper(), finding["ruleId"], "-", finding["article"], "-", finding["detail"])

Qué acaba de ocurrir

/v1/health no requiere credencial alguna, porque una sonda que necesita credencial no es una sonda. Informa la versión del catálogo de reglas que ejecuta la instancia, que es la versión contra la cual se juzga cada hallazgo que usted reciba.
/v1/directory es el mundo de su equipo: instituciones, máquinas, alias y personas de muestra con sus documentos sintéticos y sus cuentas. Otro equipo que haga la misma consulta recibe personas enteramente distintas.
El pago se instruyó con forma ISO 20022 - una proyección fiel en JSON de pain.001 - y regresó con sus hallazgos: cada regla que tocó, con el artículo que la respalda.
El informe de la corrida es el registro. Lleva la semilla, de modo que cualquiera que lo tenga puede reproducir la corrida exactamente.

3Autenticación

Dos credenciales, y cada una identifica algo distinto. Una llave de equipo identifica a un equipo. Un principal autenticado identifica a una persona.

La llave de equipo

Se envía en el encabezado x-lab-api-key en cada llamada. Lleva consigo el equipo al que pertenece, y el equipo determina a qué mundo llega la petición: una llave abre exactamente un ecosistema y jamás puede observar, mover ni alcanzar nada perteneciente a otro equipo.

La llave abre la totalidad de /v1, incluido el carril de máquinas en /v1/atm/**, donde es la única credencial posible: un cajero automático no puede mantener una sesión. También puede iniciar corridas, porque la corrida ocurre en el mundo propio del equipo y su informe se escribe bajo ese equipo y no es visible para ningún otro.

x-lab-api-key: lab-3f9a...

Iniciar sesión en la consola

La consola, en ecosystem.financial, inicia sesión con Firebase Auth - Google, o correo y contraseña - y envía el token de identidad recibido en un encabezado Authorization: Bearer. La pasarela lo verifica en cada llamada. A qué equipo pertenece una persona se configura en la instancia; a quien la instancia no mapee se le asigna el equipo por omisión.

Qué puede hacer cada una

	Llave de equipo	Persona autenticada	Principal administrador
Leer el directorio, los actores, las reglas	su propio mundo	su propio mundo	el de cualquier equipo, con `x-lab-team`
Operar pagos y el carril de máquinas	sí	sí	sí
Adelantar el reloj	solo su propio mundo	solo su propio mundo	el de cualquier equipo
Iniciar una corrida	sí	si figura en la lista de permitidos	sí
Listar y abrir informes de corridas	los de su equipo	los de su equipo	los de todos los equipos
Reiniciar un mundo	el suyo	el suyo, si figura en la lista	el de cualquier equipo

Dos listas, con funciones distintas. ALLOWED_PRINCIPALS decide qué personas autenticadas pueden consumir cómputo del Lab iniciando una corrida. ADMIN_PRINCIPALS decide quién ve a todos los equipos. Ninguna gobierna las llaves, porque una llave ya está confinada a un solo mundo.

Rotación y revocación

Las llaves residen en Secret Manager y nunca en este repositorio, en un comando de despliegue ni en el historial de una consola. Rotar la llave de su equipo significa que el Lab escribe una nueva versión del secreto con su llave anterior sustituida; la nueva llave opera desde la siguiente revisión y la anterior deja de operar. Revocar significa una versión sin su par. Ninguna de las dos afecta sus informes de corridas, que son el registro.

Solicite una rotación mediante el formulario de retroalimentación o en security@cemi.ai. Si sospecha que una llave se filtró, dígalo de inmediato y no espere a estar seguro: una rotación le cuesta un minuto al Lab.

4Referencia de endpoints

Generada a partir del propio documento OpenAPI de la instancia, de modo que no puede desviarse de lo que la pasarela realmente responde. El contrato en vivo está en /openapi.json y es el mismo documento.

Formas de error

Tres cosas pueden salir mal, y son deliberadamente respuestas distintas.

Estado	Forma	Qué significa
`401`	`{ error, message }`	Sin credencial, o con una que no verificó. El mensaje indica qué credencial espera el carril.
`403`	`{ error, message }`	Una credencial válida que no puede hacer esto: una persona fuera de la lista de permitidos iniciando una corrida, o un equipo pidiendo actuar como otro.
`404`	`{ error, message }`	No existe el endpoint, o no existe la corrida que usted pueda ver. El informe de otro equipo responde 404, igual que uno inexistente, de modo que un listado no es enumerable desde fuera.
`422`	`{ error, message, findings[] }`	Un rechazo. El ecosistema le entendió y dijo que no: un tope excedido, un beneficiario al que se le pretendió cobrar, una orden fuera de su ventana. `error` es el código propio del actor y `findings` lleva cada regla que el intento tocó, con su artículo.

Un rechazo es la respuesta interesante, no el caso de falla. Un 422 con CHARGE_TO_BENEFICIARY_REFUSED y un hallazgo fallido de TRANSFER.NO_CHARGE_TO_BENEFICIARY que cita el Art. 81 es el ecosistema haciendo su trabajo. En el carril de máquinas la regla es distinta: un rechazo del emisor regresa con 200, approved: false y su código DE039 de ISO 8583, porque eso es lo que una máquina espera, y porque los rechazos son precisamente lo que hace detectable un patrón de prueba de tarjetas.

Hallazgos: lo que acompaña a cada llamada

Cada operación devuelve, junto a su resultado, las reglas que tocó. Un hallazgo nombra la regla, el artículo, el instrumento y la fecha de la resolución, lo observado y lo esperado, y el momento. Los hallazgos con needsRecheck provienen de un instructivo que cita un Reglamento derogado: la regla está vigente en el catálogo, simplemente no se presenta como asunto zanjado.

{
  "result": { "...": "la respuesta propia de la operación" },
  "findings": [
    {
      "ruleId": "SGPI.FINAL_CREDIT",
      "article": "Art. 62",
      "instrument": "Reglamento de Sistemas de Pago",
      "resolution": "Segunda Resolucion de la Junta Monetaria",
      "resolutionDate": "2025-08-28",
      "status": "pass",
      "severity": "critical",
      "actor": "central-bank",
      "observed": 1700,
      "expected": "<= 10s",
      "detail": "elapsed 1.7s against a limit of 10s (Art. 62)",
      "at": "2026-09-08T13:00:01.700Z",
      "local": "2026-09-08 09:00"
    }
  ]
}

ATM and ITM

GET /v1/atm/terminals The machines registered on the simulated ATM network

Each terminal names the participant that operates it and holds its notes, the currency it dispenses, and the notes left in its cassettes.

Credencial: x-lab-api-key (clave de equipo)

Cuerpo de la petición

Sin cuerpo de petición.

Respuestas

200 the terminals

POST /v1/atm/withdrawals Cardholder withdrawal at a machine

The switch routes the transaction to the issuer, which verifies the holder by PIN or by biometric through the simulated identity entity, authorizes, and lets the machine's operator pay out the notes. The position between issuer and operator settles net in the simulated LBTR at the end of the cycle (Art. 79). An issuer decline comes back as a 200 with approved: false and its ISO 8583 DE039 response code - a decline is a response, not an error, which is what a machine expects.

Credencial: x-lab-api-key (clave de equipo)

Cuerpo de la petición

{
  "$ref": "#/components/schemas/AtmWithdrawalRequest"
}

Respuestas

`200`	the machine transaction, approved or declined
`422`	the transaction could not be attempted; the body names the rule and its article

POST /v1/atm/cardless/orders Start a cardless (phygital) withdrawal on the phone

The holder's own institution checks the account and asks the ATM-network administrator to mint a one-time code and the QR that carries the data needed to initiate the order (Art. 78 numeral IV). The order is single-use and expires; both controls are the Lab's and are catalogued as such.

Credencial: x-lab-api-key (clave de equipo)

Cuerpo de la petición

{
  "$ref": "#/components/schemas/CardlessOrderRequest"
}

Respuestas

`200`	the order, its code and its QR payload
`422`	refused

POST /v1/atm/cardless/redemptions Finish a cardless withdrawal at the machine

The machine sends the code the holder keyed in, or the QR it read. The order is spent exactly once.

Credencial: x-lab-api-key (clave de equipo)

Cuerpo de la petición

{
  "type": "object",
  "properties": {
    "terminalId": {
      "type": "string"
    },
    "code": {
      "type": "string"
    },
    "qr": {
      "type": "string"
    }
  },
  "required": [
    "terminalId"
  ]
}

Respuestas

`200`	the machine transaction
`422`	the order is unknown, expired or already redeemed

POST /v1/atm/deposits Deposit at the machine, with note recognition

What the machine recognizes is what is credited. A difference between the declared and the recognized amount is recorded as an adjustment, which Art. 41 requires of the ten-year record.

Credencial: x-lab-api-key (clave de equipo)

Cuerpo de la petición

{
  "$ref": "#/components/schemas/AtmDepositRequest"
}

Respuestas

`200`	the machine transaction
`422`	refused

POST /v1/atm/remittance-payouts Pay out a remittance in cash at the machine

Against a balance the beneficiary's institution already holds. The beneficiary is never charged for it (Art. 81).

Credencial: x-lab-api-key (clave de equipo)

Cuerpo de la petición

{
  "type": "object",
  "properties": {
    "terminalId": {
      "type": "string"
    },
    "issuerId": {
      "type": "string"
    },
    "accountNumber": {
      "type": "string"
    },
    "amountMinor": {
      "type": "integer"
    },
    "remittanceRef": {
      "type": "string"
    },
    "biometric": {
      "type": "boolean"
    }
  },
  "required": [
    "terminalId",
    "issuerId",
    "accountNumber",
    "amountMinor"
  ]
}

Respuestas

`200`	the machine transaction
`422`	refused

POST /v1/atm/balance-inquiries Balance inquiry at a machine

Credencial: x-lab-api-key (clave de equipo)

Cuerpo de la petición

{
  "type": "object",
  "properties": {
    "terminalId": {
      "type": "string"
    },
    "issuerId": {
      "type": "string"
    },
    "accountNumber": {
      "type": "string"
    }
  },
  "required": [
    "terminalId",
    "issuerId",
    "accountNumber"
  ]
}

Respuestas

200 the balance

POST /v1/atm/echo Network management echo (ISO 8583 0800/0810)

What a machine sends to prove the switch is alive.

Credencial: x-lab-api-key (clave de equipo)

Cuerpo de la petición

Sin cuerpo de petición.

Respuestas

200 the echo response

POST /v1/atm/cycles Settle the network cycle

Art. 79: the net result of the cycle settles in the simulated LBTR. Issuers pay the operators of the machines their cardholders used.

Credencial: x-lab-api-key (clave de equipo)

Cuerpo de la petición

{
  "type": "object",
  "properties": {
    "cycleId": {
      "type": "string"
    }
  }
}

Respuestas

200 the cycle, its net positions and the LBTR legs that settled it

La Poblacion del Lab

GET /v1/directory La Poblacion del Lab: your team's world, in one call

The starting point. Every institution standing in your world with its Lab name and its personality, the machines on the floor, the aliases registered in the simulated SGPI directory, sample people with their synthetic documents and their accounts (in full and masked), the businesses, the population counts and how many people the Lab has flagged as adversaries. It also carries the identifier scheme, so nobody has to look up why a document begins with LAB- before deciding whether it is safe to put in a slide.

Scoped to your own team. Two teams on the same instance are handed two different populations, because their worlds are seeded from their team ids and share nothing.

Credencial: x-lab-api-key (clave de equipo) o Authorization: Bearer (principal autenticado)

Cuerpo de la petición

Sin cuerpo de petición.

Respuestas

200 the team's world: institutions, terminals, aliases, people, businesses

POST /v1/worlds/reset Throw your team's world away and stand a fresh one up

Everything the team did is gone: accounts, balances, aliases, the LBTR queue, the clock. What comes back is a new world with the same starter population, built from the same seed, so the people and their documents are the ones the directory listed before.

The run reports the team already produced are NOT gone. A report is the record, and a reset is not a way to unsay one.

Resets your own team's world. An admin principal may reset another team's by sending x-lab-team; nobody else can.

Credencial: x-lab-api-key (clave de equipo) o Authorization: Bearer (principal autenticado)

Cuerpo de la petición

Sin cuerpo de petición.

Respuestas

`200`	the fresh world: its seed, its instant, its actors and its population
`403`	this principal may not reset a world on this instance

GET /v1/worlds Which worlds are standing on this instance

A team is told its own. An admin principal is told every world that has been stood up, and when.

Credencial: x-lab-api-key (clave de equipo) o Authorization: Bearer (principal autenticado)

Cuerpo de la petición

Sin cuerpo de petición.

Respuestas

200 the worlds this principal may see

Other

GET /v1/health Liveness, the simulated clock, the reports backend and whether sign-in is required

Exempt from the team key and from sign-in: a probe that needs a credential is not a probe. Also answers on /health and, locally, on /healthz - Google's front end intercepts that last path before it reaches a Cloud Run container, which is why there are three.

Credencial: ninguna: abierto, para que una sonda nunca necesite credencial

Cuerpo de la petición

Sin cuerpo de petición.

Respuestas

200 the gateway is up

GET /health Liveness (alias of /v1/health)

Credencial: ninguna: abierto, para que una sonda nunca necesite credencial

Cuerpo de la petición

Sin cuerpo de petición.

Respuestas

200 the gateway is up

GET /healthz Liveness (alias of /v1/health; intercepted by Google's front end on Cloud Run)

Credencial: ninguna: abierto, para que una sonda nunca necesite credencial

Cuerpo de la petición

Sin cuerpo de petición.

Respuestas

200 the gateway is up

GET /v1/actors The simulated counterparts on the bus, with their fidelity tier and the ops each answers

Credencial: x-lab-api-key (clave de equipo)

Cuerpo de la petición

Sin cuerpo de petición.

Respuestas

200 the actor catalogue

GET /v1/rules The rule catalogue: every executable rule with its article and the resolution that fixed its value

Credencial: x-lab-api-key (clave de equipo)

Cuerpo de la petición

Sin cuerpo de petición.

Respuestas

200 the rule catalogue

GET /v1/findings Rule findings raised so far in this session

Credencial: x-lab-api-key (clave de equipo)

Cuerpo de la petición

Sin cuerpo de petición.

Respuestas

200 findings

GET /v1/trace The message trace of this session

Credencial: x-lab-api-key (clave de equipo)

Cuerpo de la petición

Sin cuerpo de petición.

Respuestas

200 trace entries

POST /v1/clock/advance Advance the simulated clock (stepped and accelerated modes)

Credencial: x-lab-api-key (clave de equipo)

Cuerpo de la petición

{
  "type": "object",
  "properties": {
    "by": {
      "type": "string",
      "example": "8m"
    }
  },
  "required": [
    "by"
  ]
}

Respuestas

200 the new simulated instant

POST /v1/payments/instant SGPI instant payment, ISO 20022 pacs.008 projection in, pacs.002 out

Final credit within ten seconds (Art. 60-61), 24/7/365, alias addressing. A charge bearer of CRED is refused: the beneficiary of a transfer is never charged (Art. 81; Art. 56 numeral II).

Credencial: x-lab-api-key (clave de equipo)

Cuerpo de la petición

{
  "$ref": "#/components/schemas/CreditTransferInstruction"
}

Respuestas

`200`	pacs.002 payment status report
`422`	the instruction was refused; the body names the rule and its article

POST /v1/payments/pai Pagos al Instante BCRD transfer

Final credit within eight minutes, 07:00-23:00 local with a weekday pause 16:00-18:30. An order given OUTSIDE that schedule is not refused: it becomes effective at 08:00 on the NEXT BUSINESS DAY, so a Friday-night order lands on Monday morning. A dollar transfer needs no correspondent - it settles in the LBTR, which settles in Dominican pesos, US dollars and euros (Art. 56) - and where the beneficiary account is in another currency, named on CdtrAcct.Ccy, the originating institution converts and the conversion is recorded with the transaction (Arts. 41-42). The rates are Lab indicative figures, never quotations.

Credencial: x-lab-api-key (clave de equipo)

Cuerpo de la petición

{
  "$ref": "#/components/schemas/CreditTransferInstruction"
}

Respuestas

`200`	pacs.002 payment status report
`422`	refused

POST /v1/transfers/lbtr High-value transfer through the LBTR

Gross settlement in DOP, USD or EUR. An order that the ordering participant cannot cover queues and is revocable while queued (Art. 66); the third-party credit follows within four minutes (Art. 57).

Credencial: x-lab-api-key (clave de equipo)

Cuerpo de la petición

{
  "$ref": "#/components/schemas/CreditTransferInstruction"
}

Respuestas

200 the LBTR order and its status

POST /v1/webhooks Register a webhook for bus notifications

Credencial: x-lab-api-key (clave de equipo)

Cuerpo de la petición

{
  "type": "object",
  "properties": {
    "url": {
      "type": "string"
    },
    "events": {
      "type": "array",
      "items": {
        "type": "string"
      }
    }
  },
  "required": [
    "url"
  ]
}

Respuestas

201 the subscription

POST /v1/actors/central-bank/ops/{op} Invoke an operation on Banco Central del Lab

Simulated counterpart operated by the CEMI Financial Innovation Lab. Not a real institution, not endorsed by the entity it is modelled after, and not an ambiente de prueba under Art. 83.

Operations: registerParticipant, openCurrentAccount, creditCurrentAccount, currentAccountBalance, issueAccountNumber, validateAccountNumber, lbtr.submit, lbtr.revoke, lbtr.status, lbtr.queue, lbtr.endOfDayFlush, sgpi.registerAlias, sgpi.resolveAlias, sgpi.pay, pai.submit, pai.raiseClaim, pai.answerClaim, pai.claims, net.settle, vigilancia.report

Credencial: x-lab-api-key (clave de equipo)

Cuerpo de la petición

{
  "type": "object",
  "additionalProperties": true
}

Respuestas

`200`	the operation result
`422`	the operation was refused

POST /v1/actors/bank/ops/{op} Invoke an operation on Banco del Lab

Simulated counterpart operated by the CEMI Financial Innovation Lab. Not a real institution, not endorsed by the entity it is modelled after, and not an ambiente de prueba under Art. 83.

Operations: onboardCustomer, openAccount, deposit, balance, accountInfo, internalTransfer, transfer, registerAlias, postIncomingCredit, ddc.debitOriginator, ddc.reverse, lbtr.creditNotice, lbtr.revocationNotice, lbtr.revoked, sgpi.notification, cb.currentAccountCredited, atm.withdraw, records.query, records.attest, customer, issueCard, card, cards, atm.authorizeWithdrawal, atm.postDeposit, atm.terminalCashOut, atm.terminalCashIn, cardless.request, monitoring.feed, monitoring.resolveCard

Credencial: x-lab-api-key (clave de equipo)

Cuerpo de la petición

{
  "type": "object",
  "additionalProperties": true
}

Respuestas

`200`	the operation result
`422`	the operation was refused

POST /v1/actors/epe/ops/{op} Invoke an operation on EPE del Lab

Simulated counterpart operated by the CEMI Financial Innovation Lab. Not a real institution, not endorsed by the entity it is modelled after, and not an ambiente de prueba under Art. 83.

Operations: openEPaymentAccount, agentOperation, balance, accountInfo, addCredential, inboundRemittance, socialSubsidy, chequeFunding, registerAlias, postIncomingCredit, reconcileFloat, dailyReport, headroom, raiseClaim, answerClaim, claims, sgpi.notification, cb.currentAccountCredited, agents, atm.authorizeWithdrawal, atm.postDeposit, monitoring.feed

Credencial: x-lab-api-key (clave de equipo)

Cuerpo de la petición

{
  "type": "object",
  "additionalProperties": true
}

Respuestas

`200`	the operation result
`422`	the operation was refused

POST /v1/actors/ddc-administrator/ops/{op} Invoke an operation on Administrador de Debito y Credito Directo del Lab

Simulated counterpart operated by the CEMI Financial Innovation Lab. Not a real institution, not endorsed by the entity it is modelled after, and not an ambiente de prueba under Art. 83.

Operations: submitBatch, runCycle, batch, cycles, reasonCodes

Credencial: x-lab-api-key (clave de equipo)

Cuerpo de la petición

{
  "type": "object",
  "additionalProperties": true
}

Respuestas

`200`	the operation result
`422`	the operation was refused

POST /v1/actors/identity/ops/{op} Invoke an operation on Registro e Identidad del Lab

Simulated counterpart operated by the CEMI Financial Innovation Lab. Not a real institution, not endorsed by the entity it is modelled after, and not an ambiente de prueba under Art. 83.

Operations: lookup, verify

Credencial: x-lab-api-key (clave de equipo)

Cuerpo de la petición

{
  "type": "object",
  "additionalProperties": true
}

Respuestas

`200`	the operation result
`422`	the operation was refused

POST /v1/actors/credit-bureau/ops/{op} Invoke an operation on Buro de Credito del Lab

Simulated counterpart operated by the CEMI Financial Innovation Lab. Not a real institution, not endorsed by the entity it is modelled after, and not an ambiente de prueba under Art. 83.

Operations: inquiry, history

Credencial: x-lab-api-key (clave de equipo)

Cuerpo de la petición

{
  "type": "object",
  "additionalProperties": true
}

Respuestas

`200`	the operation result
`422`	the operation was refused

POST /v1/actors/monitoring/ops/{op} Invoke an operation on Unidad de Monitoreo del Lab

Simulated counterpart operated by the CEMI Financial Innovation Lab. Not a real institution, not endorsed by the entity it is modelled after, and not an ambiente de prueba under Art. 83.

Operations: run, alerts, score, movements, thresholds

Credencial: x-lab-api-key (clave de equipo)

Cuerpo de la petición

{
  "type": "object",
  "additionalProperties": true
}

Respuestas

`200`	the operation result
`422`	the operation was refused

POST /v1/actors/acquirer/ops/{op} Invoke an operation on Adquirente del Lab

Simulated counterpart operated by the CEMI Financial Innovation Lab. Not a real institution, not endorsed by the entity it is modelled after, and not an ambiente de prueba under Art. 83. Stub tier: canned responses, no state.

Operations: affiliateMerchant, authorize, capture, refund, chargeback, settlementReport

Credencial: x-lab-api-key (clave de equipo)

Cuerpo de la petición

{
  "type": "object",
  "additionalProperties": true
}

Respuestas

`200`	the operation result
`422`	the operation was refused

POST /v1/actors/sub-acquirer/ops/{op} Invoke an operation on Subadquirente del Lab

Operations: onboardSubMerchant, authorize, payout

Credencial: x-lab-api-key (clave de equipo)

Cuerpo de la petición

{
  "type": "object",
  "additionalProperties": true
}

Respuestas

`200`	the operation result
`422`	the operation was refused

POST /v1/actors/card-processor/ops/{op} Invoke an operation on Procesador card-processor del Lab

Operations: authorize, clearing, settlement, tokenize, threeDSecure, iso8583

Credencial: x-lab-api-key (clave de equipo)

Cuerpo de la petición

{
  "type": "object",
  "additionalProperties": true
}

Respuestas

`200`	the operation result
`422`	the operation was refused

POST /v1/actors/atm-network-administrator/ops/{op} Invoke an operation on Administrador de Red de Cajeros del Lab

Simulated counterpart operated by the CEMI Financial Innovation Lab. Not a real institution, not endorsed by the entity it is modelled after, and not an ambiente de prueba under Art. 83.

Operations: registerTerminal, terminals, terminal, withdraw, cardless.order, cardless.redeem, cardless.status, cardless.cancel, deposit, remittancePayout, balanceInquiry, networkEcho, settleCycle, transactions, positions

Credencial: x-lab-api-key (clave de equipo)

Cuerpo de la petición

{
  "type": "object",
  "additionalProperties": true
}

Respuestas

`200`	the operation result
`422`	the operation was refused

POST /v1/actors/wallet-provider/ops/{op} Invoke an operation on Billetera del Lab

Operations: enrolInstrument, presentQr, readQr

Credencial: x-lab-api-key (clave de equipo)

Cuerpo de la petición

{
  "type": "object",
  "additionalProperties": true
}

Respuestas

`200`	the operation result
`422`	the operation was refused

POST /v1/actors/initiation-provider/ops/{op} Invoke an operation on Iniciador de Pagos del Lab

Operations: requestConsent, initiate

Credencial: x-lab-api-key (clave de equipo)

Cuerpo de la petición

{
  "type": "object",
  "additionalProperties": true
}

Respuestas

`200`	the operation result
`422`	the operation was refused

POST /v1/actors/gateway-provider/ops/{op} Invoke an operation on Pasarela del Lab

Operations: createCheckout, webhook

Credencial: x-lab-api-key (clave de equipo)

Cuerpo de la petición

{
  "type": "object",
  "additionalProperties": true
}

Respuestas

`200`	the operation result
`422`	the operation was refused

POST /v1/actors/supervisor/ops/{op} Invoke an operation on Superintendencia del Lab

Operations: submitReport, requestRecords

Credencial: x-lab-api-key (clave de equipo)

Cuerpo de la petición

{
  "type": "object",
  "additionalProperties": true
}

Respuestas

`200`	the operation result
`422`	the operation was refused

POST /v1/actors/uaf/ops/{op} Invoke an operation on Unidad de Analisis Financiero del Lab

Operations: suspiciousTransactionReport, cashTransactionReport

Credencial: x-lab-api-key (clave de equipo)

Cuerpo de la petición

{
  "type": "object",
  "additionalProperties": true
}

Respuestas

`200`	the operation result
`422`	the operation was refused

Runs and reports

GET /v1/principal Who this gateway thinks you are, which team you are, and what you may do

A team key answers as kind: key and carries the team the key belongs to; a console sign-in answers as kind: user with the verified email and the team TEAM_PRINCIPALS maps it to. mayStartRuns reflects this instance's ALLOWED_PRINCIPALS list for a person, and is always true for a team key, because a key can only ever write into its own world. admin is true for a principal on ADMIN_PRINCIPALS, who sees every team's runs and may act on any team's world with the x-lab-team header.

Credencial: x-lab-api-key (clave de equipo) o Authorization: Bearer (principal autenticado)

Cuerpo de la petición

Sin cuerpo de petición.

Respuestas

200 the principal

GET /v1/scenarios The scenarios in this instance, with their variants

Credencial: x-lab-api-key (clave de equipo) o Authorization: Bearer (principal autenticado)

Cuerpo de la petición

Sin cuerpo de petición.

Respuestas

200 the scenario catalogue

GET /v1/runs The run reports YOUR TEAM holds, newest first

Scoped to the caller: a team sees its own runs and nobody else's, and an admin principal sees every team's. A report id carries its team in front of the run id, so asking for another team's report by id answers 404 - the same answer as for a report that does not exist, which is what stops the listing being enumerable from outside.

Backed by REPORTS_BACKEND: reports on disk, which is what makes a run reproducible by anybody holding the file, or in the project's Firestore, which is what a Cloud Run instance needs because it loses its filesystem on restart. The answer is the same either way.

Credencial: x-lab-api-key (clave de equipo) o Authorization: Bearer (principal autenticado)

Cuerpo de la petición

Sin cuerpo de petición.

Respuestas

200 one summary row per run

POST /v1/runs Run a scenario and keep the report

Requires a signed-in principal on the instance's allow-list when AUTH_REQUIRED is on.

Credencial: x-lab-api-key (clave de equipo) o Authorization: Bearer (principal autenticado)

Cuerpo de la petición

{
  "type": "object",
  "properties": {
    "scenario": {
      "type": "string"
    },
    "variant": {
      "type": "string"
    },
    "seed": {
      "type": "string"
    }
  },
  "required": [
    "scenario"
  ]
}

Respuestas

`201`	the run started, finished and was kept
`403`	the principal may not start runs on this instance
`422`	the run could not be started

GET /v1/runs/{id} One run report in full, with its trace, ledgers and reconciliation

Credencial: x-lab-api-key (clave de equipo) o Authorization: Bearer (principal autenticado)

Cuerpo de la petición

Sin cuerpo de petición.

Respuestas

`200`	the report
`404`	no report with that id

GET /v1/runs/{id}/report.md The same run report as rendered Markdown

The document a team attaches to an Art. 83 request as evidence, and nothing more.

Credencial: x-lab-api-key (clave de equipo) o Authorization: Bearer (principal autenticado)

Cuerpo de la petición

Sin cuerpo de petición.

Respuestas

`200`	the report
`404`	no report with that id

5Servicios web y el carril de máquinas

Cuatro interfaces, elegidas para que un equipo integre como integraría de verdad.

Interfaz	Dónde	Qué la habla
REST + OpenAPI	todo bajo `/v1`	una aplicación, una batería de pruebas, un job de integración continua
ISO 20022, proyección JSON	`/v1/payments/*`, `/v1/transfers/lbtr`	una aplicación de pagos que instruye pain.001 y lee pacs.002
ISO 8583, proyección JSON	`/v1/atm/**`	una integración de cajero o ITM; cada respuesta lleva el par 0200/0210 que construyó el conmutador
Webhooks	`POST /v1/webhooks`	cualquier cosa que prefiera que le avisen a estar consultando

La proyección, con precisión. Lo que lleva el carril de máquinas son los mismos elementos de datos identificados por su número de campo ISO 8583, en JSON, registrados junto a cada transacción. La codificación empaquetada - los mapas de bits, los encabezados de red - es de la Fase 2 y todavía no existe. Si su integración necesita el formato de cable y no la semántica de los campos, dígalo en el formulario de retroalimentación: es lo más útil que un procesador de tarjetas podría pedirnos priorizar.

Integrar una máquina, paso a paso

Este es el recorrido para poner un cajero o un ITM real - o un simulador de uno - en el carril.

Cargue una llave de equipo en el dispositivo. El carril de máquinas es el único donde la llave no es una comodidad: el hardware no puede mantener una sesión, así que la llave es la credencial. Aprovisiónela como aprovisionaría cualquier secreto de dispositivo.
Primero el eco. POST /v1/atm/echo es lo que envía un conmutador antes de confiar en un enlace. No cuesta nada y confirma que la red responde y que la llave sirve.
Lea los terminales. GET /v1/atm/terminals lista las máquinas que están de pie en su mundo, sus casetes, la institución que las opera y si aceptan depósitos. Una de las cuatro está deliberadamente sin efectivo, para que su ruta de fuera de servicio tenga contra qué ejercitarse.
Registre su propio terminal si conduce hardware real: POST /v1/actors/atm-network/ops/registerTerminal con el identificador del terminal, su operador, su casete y si acepta depósitos.
Ejecute un retiro con tarjeta. El PAN y el PIN se devuelven una sola vez en la emisión y no salen jamás del emisor: el conmutador ve un PAN enmascarado y el veredicto del emisor. Lea approved y, ante un rechazo, lea el código de respuesta DE039 en lugar de tratarlo como un error.
Ejecute el flujo sin tarjeta si lo soporta. La orden se levanta en el teléfono, en la institución del propio titular, y se completa en la máquina, exactamente una vez y dentro de su vigencia. La carga útil del QR es la cadena del Lab LAB-QR:v1:<red>:<ordenId>:<código>: el instructivo de QR del Banco Central no está publicado, y el Lab no inventa uno.
Cierre el ciclo. La red no retiene dinero ni lleva libro: es un participante indirecto. POST /v1/atm/cycles liquida la posición neta del día en el LBTR simulado conforme al Art. 79, y el informe muestra las patas brutas que hicieron falta para llegar allí.

# The machine lane is what an ATM or ITM integration drives. It is the one lane where a
# team key is not a convenience but the only possible credential: hardware cannot hold a
# session, so it presents a key and nothing else.
export FINLAB="https://ecosystem.financial"
K="x-lab-api-key: $FINLAB_API_KEY"

# 0. the machines standing in your world, with their cassettes and their operator
curl -s -H "$K" "$FINLAB/v1/atm/terminals" | jq

# 1. a network echo, which is what a switch sends before it trusts a link
curl -s -X POST -H "$K" -H 'content-type: application/json' "$FINLAB/v1/atm/echo" -d '{}' | jq

# 2. a cardholder withdrawal. The PAN and the PIN come from the issuer at issuance and
#    never leave it: the switch sees a masked PAN and the issuer's verdict, nothing more.
curl -s -X POST -H "$K" -H 'content-type: application/json' "$FINLAB/v1/atm/withdrawals" -d '{
  "terminalId": "TERM-LAB-0001",
  "labPan": "<the PAN issued to the card>",
  "pin": "<the PIN returned once at issuance>",
  "amountMinor": 200000,
  "currency": "DOP"
}' | jq '{approved, responseCode, iso8583: .result.iso8583.DE039}'

# A DECLINE IS A RESPONSE, NOT AN ERROR. An issuer refusal comes back 200 with
# approved:false and its ISO 8583 DE039 code, because that is what a machine expects -
# and because the declines are what makes a card-testing pattern detectable at all.

# 3. the cardless flow: the order is raised on the phone, at the holder's own institution
ORDER=$(curl -s -X POST -H "$K" -H 'content-type: application/json' "$FINLAB/v1/atm/cardless/orders" -d '{
  "issuerId": "banco-norte",
  "accountNumber": "<an account number from the directory>",
  "amountMinor": 300000
}')
echo "$ORDER" | jq '{orderId: .result.orderId, code: .result.code, qr: .result.qr}'

# 4. and finished at the machine, exactly once and inside its validity
curl -s -X POST -H "$K" -H 'content-type: application/json' "$FINLAB/v1/atm/cardless/redemptions" -d '{
  "terminalId": "TERM-LAB-0002",
  "code": "<the one-time code from step 3>"
}' | jq

# 5. a deposit the machine counted and recognized
curl -s -X POST -H "$K" -H 'content-type: application/json' "$FINLAB/v1/atm/deposits" -d '{
  "terminalId": "TERM-LAB-0002",
  "labPan": "<the PAN>",
  "pin": "<the PIN>",
  "amountMinor": 500000
}' | jq

# 6. close the cycle: the network holds no money and keeps no book, so the day's net
#    position settles in the simulated LBTR (Art. 79)
curl -s -X POST -H "$K" -H 'content-type: application/json' "$FINLAB/v1/atm/cycles" -d '{}' | jq

// A minimal ATM/ITM driver. The shape a real integration takes: one function that
// posts a machine message and reads back the ISO 8583 projection of the 0200/0210 pair.
const BASE = process.env.FINLAB ?? 'https://ecosystem.financial';
const headers = { 'x-lab-api-key': process.env.FINLAB_API_KEY, 'content-type': 'application/json' };

async function machine(path, message) {
  const res = await fetch(BASE + path, { method: 'POST', headers, body: JSON.stringify(message) });
  const body = await res.json();
  // 422 is a structural refusal - a malformed message, an unknown terminal. A DECLINE is
  // not one of those: it arrives 200 with approved:false and a DE039 response code.
  if (res.status === 422) throw new Error(body.error + ': ' + body.message);
  return body;
}

const [terminal] = (await (await fetch(BASE + '/v1/atm/terminals', { headers })).json()).result;

const withdrawal = await machine('/v1/atm/withdrawals', {
  terminalId: terminal.terminalId,
  labPan: process.env.LAB_PAN,
  pin: process.env.LAB_PIN,
  amountMinor: 200_00,
  currency: 'DOP',
});

if (withdrawal.result.approved) {
  console.log('dispense', withdrawal.result.amountMinor, 'authorization', withdrawal.result.authorizationCode);
} else {
  // DE039: 51 insufficient funds, 55 wrong PIN, 75 attempt limit reached, and so on
  console.log('decline', withdrawal.result.responseCode, withdrawal.result.reason);
}

// every rule the transaction touched, with the article behind it
for (const finding of withdrawal.findings) console.log(finding.status, finding.ruleId, finding.article);

import json, os, urllib.request

BASE = os.environ.get("FINLAB", "https://ecosystem.financial")
H = {"x-lab-api-key": os.environ["FINLAB_API_KEY"], "content-type": "application/json"}


def machine(path, message):
    req = urllib.request.Request(BASE + path, data=json.dumps(message).encode(), headers=H, method="POST")
    with urllib.request.urlopen(req) as res:
        return json.load(res)


withdrawal = machine("/v1/atm/withdrawals", {
    "terminalId": "TERM-LAB-0001",
    "labPan": os.environ["LAB_PAN"],
    "pin": os.environ["LAB_PIN"],
    "amountMinor": 200_00,
    "currency": "DOP",
})

result = withdrawal["result"]
if result["approved"]:
    print("dispense", result["amountMinor"], "authorization", result["authorizationCode"])
else:
    # a decline is a response: 200, approved false, and the ISO 8583 DE039 code
    print("decline", result["responseCode"])

for finding in withdrawal["findings"]:
    print(finding["status"], finding["ruleId"], finding["article"])

6La Población del Lab

Cada mundo de equipo nace con el mismo conjunto de datos inicial documentado, de modo que quien recibe una llave nueva no tenga que inventar un ecosistema antes de hacer una llamada real.

Las instituciones

Actor	Nombre del Lab	Qué es
`banco-norte`	Banco Norte del Lab	`strict-legacy` - branch-first, conservative at the door, batch-shaped posting habits
`banco-del-sur`	Banco del Sur del Lab	`permissive-digital` - app-first, onboards remotely in seconds, leans on monitoring rather than on the door
`coop-del-lab`	Cooperativa del Lab	`cooperative` - member-owned, accepts a thin file because membership is the relationship
`epe-lab`	EPE del Lab	Entidad de pago electrónico: cuentas de pago electrónico, tres agentes, los topes del Art. 78 numeral II
`ddc-administrator`	Administrador DD/DC del Lab	Administrador de débito y crédito directo: lotes, ciclos sobre calendario hábil, devoluciones, liquidación neta
`atm-network`	Red de Cajeros del Lab	Administrador de red de cajeros: cuatro máquinas, una de ellas deliberadamente sin efectivo
`central-bank`	Banco Central del Lab	LBTR, SGPI, Pagos al Instante, las cuentas corrientes de los participantes, el estándar de cuenta

La cooperativa no es adorno. El plan sostiene que la personalidad de un banco es dato, y que una cooperativa, una asociación de ahorros y préstamos o un banco patrocinado entran sin tocar la clase del banco. La tercera personalidad es esa afirmación, puesta a prueba.

Las personas, y lo que tienen

Qué	Cuántos
personas sintéticas	200
empresas	40
personas incorporadas en un banco, rotando entre los tres	90
de ellas, con tarjeta de débito	30
cuentas de pago electrónico en la EPE	30
alias registrados en el directorio del SGPI simulado	45
empresas con cuenta	20
personas marcadas por el Lab como adversarias	12

Las cifras son techos, no garantías, y deliberadamente: el sembrador entra por la puerta principal de cada institución, invocando la misma vinculación que invoca un equipo. Banco Norte es una institución estricta y debe rechazar personas. Un conjunto de datos inicial que esquivara en silencio su propia puerta estaría enseñando lo contrario de lo debido en el primer minuto del primer día.

Saldos de apertura

Cuenta	Saldo de apertura
cuenta corriente de cada banco en el Banco Central simulado	RD$50,000,000.00
flotante de la EPE, que debe cubrir cada saldo administrado	RD$5,000,000.00
cuenta de ahorro o corriente de una persona	RD$25,000.00
cuenta de una empresa	RD$400,000.00
cuenta de pago electrónico	RD$8,000.00

Por qué ningún identificador de aquí puede confundirse con uno real

Identificador	Esquema y por qué no puede ser real
`person`	LAB-###-#######-# - the 3-7-1 shape of a cedula de identidad y electoral, so field widths, input masks and validators exercise correctly, behind a LAB- prefix a real cedula can never carry, because a real cedula is eleven digits and separators and never a letter. The prefix is what makes it unmistakably synthetic; the Lab makes no claim about which digit blocks have or have not been issued.
`business`	LAB-RNC-######### - the nine digits of a Registro Nacional de Contribuyente behind the same LAB- prefix.
`account`	LB + two check digits + a four-character institution code + sixteen digits, the shape of the regional standardized account number with the country prefix deliberately LB and never DO (assumption A-02).
`card`	A PAN whose issuer identification number begins with 9 - the range ISO/IEC 7812 reserves for national assignment - so it can never collide with a card-scheme BIN. The check digit is a real Luhn digit, so a validator behaves correctly.
`phone`	+1-809-555-#### - the 555 exchange, which is not routed to subscribers. NANP formally reserves only 555-0100 to 555-0199 for fictional use; the Lab uses the whole exchange because two hundred people do not fit in a hundred numbers, and that widening is a Lab decision (assumption A-24).
`email`	name@lab.invalid - .invalid is reserved by RFC 2606 and can never be delegated.
`alias`	@name#### - the SGPI alias, unique inside one world and meaningless outside it.

Ese mismo bloque viaja con cada respuesta de GET /v1/directory, de modo que nadie tenga que volver aquí antes de decidir si un número puede ir en una lámina.

Los adversarios

Doce de las doscientas personas están marcadas: dos anillos de mulas con un controlador y tres mulas cada uno, y cuatro probadores de tarjetas. Se toman del final de la población para que nadie que un escenario necesitara se convierta calladamente en mula, y sus rasgos de cara a la vinculación se fuerzan limpios, porque a una mula se la recluta precisamente para eso: papeles que pasan. El patrón tiene que encontrarse en los movimientos, nunca en la puerta.

Lo que el Lab sabe sobre quiénes son es el oráculo contra el cual una corrida puntúa una detección. Nada que realice detección puede leerlo, y la unidad de monitoreo lo lee solo después de que sus alertas ya existen.

Reiniciar su mundo

POST /v1/worlds/reset descarta el mundo de su equipo y levanta uno nuevo desde la misma semilla. Las personas regresan con los mismos documentos y las mismas cuentas; todo lo que hicieron, no. Sus informes de corridas sobreviven al reinicio, porque un informe es el registro y un reinicio no es una manera de desdecirlo.

7Escenarios

Un escenario es un proceso completo, escrito: un elenco, un reloj, una población, una secuencia de pasos con sus expectativas y una declaración de las reglas que afirma ejercitar.

Cada escenario declara lo que cita, y el informe enumera lo citado que no se alcanzó. Un escenario que reclama una regla y nunca la toca es un escenario fallido. No es una cortesía: es lo que impide que un catálogo de reglas se convierta en un catálogo de intenciones.

Una variante recorre el mismo escenario por otro camino: el solicitante menor de edad, la máquina que se queda sin billetes, la orden que llega después de cerrada la ventana, la institución mal configurada que pretende cobrarle al beneficiario. Inicie una con { "scenario": "...", "variant": "..." } y pase su propia seed para que la corrida sea reproducible por quien reciba esa semilla.

adversarial-detectionA mule ring, a card-testing run, and a monitoring unit that is scored on both

The first adversarial run. The synthetic population is asked for a mule ring - three accounts that collect from elsewhere and pass almost everything straight on to a controller - and for a card tester, who tries a card at a machine again and again with a PIN they do not have. The institutions behave normally throughout: nobody is refused for being an adversary, because nothing in the ecosystem knows who is one. Then the simulated monitoring unit consumes what Arts. 43-44 make available - the institutions' own movement records and the network's machine transactions, refusals included - looks for two patterns, and raises alerts. Only afterwards does it read the Lab's own ground truth, which is the one place that knows who was made an adversary, and score itself against it. Neither pattern nor any threshold in it comes from the Reglamento. Art. 43 makes the Ley 155-17 obligation apply and Art. 44 puts the records at the supervisors' disposal; what to look for in them is the Lab's decision, recorded as assumption A-23. A score is a score on this run, this seed and these thresholds. The banks run at the BEHAVIOURAL fidelity tier: the legacy core under a busy-branch-day profile, with jitter, a queue and a long tail; the digital bank on a cautious fraud desk that refuses one machine withdrawal in twenty on its own suspicion, whatever the balance says. The patterns have to be found through that, not in spite of it.

Proceso: 6.14 Fraud and adversarial - mule networks and card testing in the synthetic population, with a run that scores the detection · Semilla: finlab-adversarial-2026

Variantes

no-pattern-nothing-to-find - The same institutions, the same monitoring, and nobody doing anything. The other half of a detection claim, and the half that is usually missing: a run with no pattern in it must raise no alert. A monitoring unit that finds a mule ring in an ordinary day is not a detection, it is a noise generator.

Reglas que declara ejercitar

AML.TRANSACTION_MONITORING ATM.CARDHOLDER_VERIFICATION RECORDS.INCLUDES_REJECTED RECORDS.RETENTION_YEARS TRANSFER.NO_CHARGE_TO_BENEFICIARY ACCOUNT.STANDARD_NUMBER SIPARD.INTEROPERABILITY

atm-cardholder-withdrawalCardholder withdrawal and deposit at a machine of another institution

A customer of the permissive digital bank takes cash out of a machine that the strict legacy bank operates, and then puts notes back into it. The card is one the issuer issued, the PIN is verified at the issuer, and the switch between the machine and the host is the simulated ATM-network administrator at stateful fidelity. Neither institution moves money to the other at the moment of the withdrawal: the position between them joins the network's cycle, and the cycle's net result settles in the simulated LBTR, which is what Art. 79 requires of every clearing cycle of the electronic-instrument systems. The variants are the two things a machine on the Lab floor will do most often by accident: a wrong PIN until the card blocks, and a machine that has run out of notes.

Proceso: 6.3 Cards / 6.4 ATM-ITM - withdrawal at a machine through the simulated network administrator, deposit with recognition, and settlement of the network's net result in the LBTR (Art. 79) · Semilla: finlab-atm-2026

Variantes

wrong-pin-blocks-the-card - Three wrong PINs and the card is blocked. A machine on a Lab floor sees a wrong PIN more often than anything else. The issuer counts the attempts, blocks the card on the third, and every refusal is retained in the ten-year record with its response code (Art. 41).
machine-out-of-notes - The machine has no notes left. The switch refuses before it ever troubles the issuer, and says so with DE039 51.

Reglas que declara ejercitar

ATM.CARDHOLDER_VERIFICATION ATM.DEPOSIT_DISCREPANCY_RECORDED NET.SETTLES_IN_LBTR NET.DEFERRED_FINALITY LBTR.SETTLEMENT_CURRENCY SIPARD.INTEROPERABILITY SIPARD.DIRECT_PARTICIPANT_HAS_CB_ACCOUNT CAPITAL.EPE_SUBACQUIRER_ATM_WALLET ACCOUNT.STANDARD_NUMBER RECORDS.RETENTION_YEARS RECORDS.INCLUDES_REJECTED

atm-cardless-withdrawalCardless withdrawal started on the phone and finished at the machine

The phygital flow the Lab floor is built for. A customer opens the bank's app, asks for cash without a card, and the simulated ATM-network administrator mints a one-time code and the QR that carries the data needed to initiate the order - which is what Art. 78 numeral IV requires every provider to be able to present and read. Minutes later the customer walks up to a machine of another institution, keys the code, and takes the notes. Nothing authenticates at the machine: the order was authenticated on the phone, and the order is spent exactly once. The second half is the other thing these machines are for in this country: a remittance that arrived at an electronic-payment entity is paid out in cash at the machine, in full, because the beneficiary of a payment is never charged for receiving it (Art. 81).

Proceso: 6.4 ATM-ITM phygital - cardless withdrawal started on the phone and finished on the machine, and a remittance paid out in cash at the machine · Semilla: finlab-atm-cardless-2026

Variantes

order-redeemed-twice - The same code presented at the machine a second time. An order is spent once. A replay is refused, and the rule that refuses it says so by name.
order-expired-before-the-machine - The holder took too long to reach the machine. The order is minted with a five-minute validity and the holder arrives after six. The machine refuses, and the account is never touched.

Reglas que declara ejercitar

ATM.CARDLESS_ORDER_SINGLE_USE ATM.CARDHOLDER_VERIFICATION QR.PRESENT_AND_READ TRANSFER.NO_CHARGE_TO_BENEFICIARY EPA.PERMITTED_OPERATION EPA.BALANCE_CAP NET.SETTLES_IN_LBTR SIPARD.INTEROPERABILITY ACCOUNT.STANDARD_NUMBER

charge-to-beneficiary-must-failA bank that charges the beneficiary must fail

A misconfigured institution is put on the bus on purpose. Its personality carries chargesBeneficiary, so it builds its instructions with an ISO 20022 charge bearer of CRED - the charge borne by the creditor. The Reglamento does not allow it: Art. 81 and Art. 56 numeral II say the beneficiary of a transfer or payment is never charged. The run proves that the rule bites on the institution's own internal transfer, and again at the simulated Central Bank when the instruction reaches the SGPI. This scenario is expected to raise failed findings: that is the point of it.

Proceso: 6.2 Electronic funds transfers - variant: beneficiary charged (must fail, Art. 81) · Semilla: finlab-art81-2026

Variantes

Sin variantes.

Reglas que declara ejercitar

TRANSFER.NO_CHARGE_TO_BENEFICIARY SGPI.MANDATORY_PARTICIPATION RECORDS.INCLUDES_REJECTED

direct-credit-with-returnPayroll by direct credit, with one item returned

An employer hands a payroll file to the simulated direct-debit and direct-credit administrator. The originator's account is debited when the file is accepted. At the clearing cycle each item is applied at the receiving institution; one of them names an account that does not exist, so it comes back with a reason code and the originator is made whole. The net position of the cycle then settles in the simulated LBTR, which is what Art. 79 requires of the results of a clearing cycle.

Proceso: 6.2 Electronic funds transfers - direct credit through the simulated administrator with returns; 6.12 Business - payroll · Semilla: finlab-ddc-2026

Variantes

weekend-cycle - A clearing cycle attempted on a Sunday

Reglas que declara ejercitar

DDC.CYCLE_ON_BUSINESS_DAY DDC.RETURN_CARRIES_REASON_CODE NET.SETTLES_IN_LBTR NET.DEFERRED_FINALITY SIPARD.INTEROPERABILITY RECORDS.INCLUDES_REJECTED

internal-transferInternal transfer between two accounts at one bank

The simplest movement in the ecosystem, and the one every integration starts with: two customers of the same institution, one transfer, no system in between. The run checks that the beneficiary is not charged (Art. 81), that the ordering party bears the fixed fee, that the bank's book balances, and that the movement is in the ten-year record. The variant asks for more than the account holds.

Proceso: 6.2 Electronic funds transfers - internal · Semilla: finlab-internal-2026

Variantes

insufficient-funds - The ordering account does not hold the amount

Reglas que declara ejercitar

TRANSFER.NO_CHARGE_TO_BENEFICIARY ACCOUNT.STANDARD_NUMBER RECORDS.RETENTION_YEARS RECORDS.INCLUDES_REJECTED

lbtr-foreign-currencyHigh-value settlement in dollars and in euros

The LBTR settles continuously in Dominican pesos, US dollars and euros, and Art. 56 puts national and foreign currency on the same footing. Until now every scenario moved pesos, and the currency rule was checked against a single member of its own list. This one moves a hundred thousand dollars between two participants that hold dollar current accounts at the simulated Central Bank, credits the beneficiary within the four minutes Art. 57 allows, and does the same in euros in its variant. Each currency has its own current account and its own queue: a participant with pesos to spare and no dollars cannot settle a dollar order, which is the point of the third variant.

Proceso: 6.2 Electronic funds transfers - high-value through the LBTR in foreign currency (Art. 56: national and foreign currency) · Semilla: finlab-fx-lbtr-2026

Variantes

euros - The same settlement in euros. The third of the LBTR's currencies, exercised the same way. Nothing in the flow changes but the current account the order is drawn on, which is the property worth proving.
no-liquidity-in-that-currency - Pesos in the vault, no dollars in the account. Each currency has its own current account at the simulated Central Bank and its own queue. A participant seeded only in pesos cannot settle a dollar order: the order queues, and it queues in dollars.

Reglas que declara ejercitar

LBTR.SETTLEMENT_CURRENCY LBTR.THIRD_PARTY_CREDIT LBTR.IRREVOCABLE_ONCE_SETTLED SIPARD.DIRECT_PARTICIPANT_HAS_CB_ACCOUNT ACCOUNT.STANDARD_NUMBER RECORDS.RETENTION_YEARS

lbtr-high-valueHigh-value transfer through the LBTR, with a queue and a revocation

A high-value order arrives at the simulated LBTR while the ordering bank's current account at the Central Bank does not cover it, so the order queues. Queued, it is revocable, and the run revokes it and watches the debit come back. The Central Bank then credits the bank's current account, a second order settles gross, the receiving bank posts the third-party credit inside the four minutes of Art. 57, and a revocation of the settled order is refused: once settled, an order is irrevocable (Art. 66).

Proceso: 6.2 Electronic funds transfers - high value through the LBTR with the four-minute third-party credit and irrevocability once settled · Semilla: finlab-lbtr-2026

Variantes

Sin variantes.

Reglas que declara ejercitar

LBTR.SETTLEMENT_CURRENCY LBTR.REVOCABLE_WHILE_QUEUED LBTR.IRREVOCABLE_ONCE_SETTLED LBTR.THIRD_PARTY_CREDIT SIPARD.DIRECT_PARTICIPANT_HAS_CB_ACCOUNT

onboarding-account-openingOnboarding and account opening at two banks with different appetites

The same applicant walks into the strict legacy bank and the permissive digital bank. Identity is verified against the simulated civil registry with document and, where the institution requires it, liveness; the bureau is queried; the institution's own policy decides. The run then opens an electronic payment account and funds it, and the RD$79,000 cap of Art. 78 numeral II is enforced on the way in. The variants are the cases a real onboarding desk actually meets: a politically exposed person, a minor, a thin file, a poor document capture, and a funding that would breach the cap.

Proceso: 6.1 Onboarding and account opening - identity, bureau, risk scoring, account or e-payment account creation (Art. 19), first funding · Semilla: finlab-onboarding-2026

Variantes

pep-hit - The applicant is a politically exposed person
minor-applicant - The applicant is a minor
thin-file - A thin credit file, refused by one bank and accepted by the other
document-mismatch - The document capture is too poor to verify
cap-reached - Funding that would breach the RD$79,000 cap

Reglas que declara ejercitar

ACCOUNT.STANDARD_NUMBER AML.SCREENING_REQUIRED EPA.NO_INTEREST EPA.BALANCE_CAP EPA.FUNDING_CAP_30D EPA.PERMITTED_OPERATION EPA.ADDITIONAL_CREDENTIALS RECORDS.RETENTION_YEARS RECORDS.INCLUDES_REJECTED AGENT.PERMITTED_ACTIVITY SIPARD.DIRECT_PARTICIPANT_HAS_CB_ACCOUNT

pagos-al-instante-dollarsA dollar transfer through Pagos al Instante, converted by the originating bank

Two things the Central Bank says about Pagos al Instante that no scenario had exercised yet: a transfer in dollars needs no correspondent bank, and where the beneficiary's account is held in another currency the originating institution may convert, so that the beneficiary is credited in the currency of their own account. A customer of the strict legacy bank holds dollars and pays a customer of the permissive digital bank who holds pesos. The originating bank converts, records the conversion with the transaction as Arts. 41-42 require of the ten-year record, and instructs a peso order that settles in the LBTR - which settles in national and foreign currency alike (Art. 56), which is exactly why no correspondent is needed. The rates are Lab indicative figures, deliberately round and deliberately fictitious (assumption A-21). Nothing in this repository uses a published rate.

Proceso: 6.2 Electronic funds transfers - Pagos al Instante BCRD in dollars: no correspondent, and conversion by the originating institution when the beneficiary account is in another currency · Semilla: finlab-pai-fx-2026

Variantes

dollars-to-dollars - Dollars into a dollar account, with nothing to convert. The other half of the same statement. When the beneficiary already holds dollars there is nothing to convert, and still no correspondent: the order settles gross in the LBTR's dollar leg.
correspondent-must-fail - A bank that insists on a correspondent for dollars. The misconfiguration switch, in the shape the repository already uses for Art. 81: a bank configured to route dollar transfers through a correspondent is refused, the rule fails by name, and the refusal is retained in the record.

Reglas que declara ejercitar

PAI.USD_NO_CORRESPONDENT PAI.ORIGINATOR_CONVERTS FX.CONVERSION_RECORDED PAI.FINAL_CREDIT PAI.OPERATING_WINDOW PAI.FIXED_FEE_ONLY PAI.NO_DEDUCTION_BY_RECEIVING_BANK LBTR.SETTLEMENT_CURRENCY TRANSFER.NO_CHARGE_TO_BENEFICIARY RECORDS.RETENTION_YEARS RECORDS.INCLUDES_REJECTED

pagos-al-instantePagos al Instante BCRD - eight minutes, and the window that closes at four

Pagos al Instante BCRD runs on the LBTR and credits the beneficiary finally within eight minutes. It is available seven days a week from 07:00 to 23:00 local time, with a pause on weekdays between 16:00 and 18:30, and an order given outside that schedule becomes effective at 08:00 on the NEXT BUSINESS DAY - «se hacen efectivos a las 8:00 a.m. del siguiente dia laborable», BCRD Pagos al Instante page. The base run sends one transfer inside the window on a Tuesday morning and measures the credit. The variants send one into the weekday pause, one after 23:00, and one on a Friday night that has to wait the whole weekend - and watch the simulated Central Bank hold each of them, raising a finding on the window rule as it does, because the instruction did arrive outside it.

Proceso: 6.2 Electronic funds transfers - Pagos al Instante BCRD with the eight-minute credit, the 07:00-23:00 window, and the deferral to 08:00 on the next business day · Semilla: finlab-pai-2026

Variantes

weekday-pause - An order given during the weekday pause waits for the next business morning
after-hours - An order given after 23:00 becomes effective at 08:00 the next business day
friday-night-waits-for-monday - A Friday-night order waits the whole weekend, because the page says business day. The correction that made this variant worth writing. A generic "next instant the window opens" would have executed this on Saturday at 07:00; the BCRD page says «el siguiente dia laborable», so it executes on MONDAY at 08:00. Friday 13 March 2026 at 23:30 local becomes Monday 16 March at 08:00 local, which is 12:00Z.

Reglas que declara ejercitar

PAI.FINAL_CREDIT PAI.OPERATING_WINDOW PAI.FIXED_FEE_ONLY PAI.NO_DEDUCTION_BY_RECEIVING_BANK LBTR.THIRD_PARTY_CREDIT TRANSFER.NO_CHARGE_TO_BENEFICIARY

sgpi-instant-aliasSGPI instant payment addressed by alias

A customer of the strict legacy bank pays a customer of the permissive digital bank through the simulated Sistema de Gestion de Pagos Instantaneos, addressing the beneficiary by alias. The run checks that the payment is final inside ten seconds, that both parties are notified, that the alias resolved through the Central Bank's directory, and that both institutions are registered participants as Art. 61 numeral I requires. It is run at 03:00 on a Sunday on purpose: the SGPI has no operating window.

Proceso: 6.2 Electronic funds transfers - SGPI with the ten-second credit, alias resolution and 24/7/365 · Semilla: finlab-sgpi-2026

Variantes

unregistered-beneficiary-alias - The alias is not in the directory. An instant payment addressed to an alias nobody registered must fail cleanly.

Reglas que declara ejercitar

SGPI.FINAL_CREDIT SGPI.AVAILABILITY SGPI.MANDATORY_PARTICIPATION SGPI.NOTIFY_BOTH_PARTIES SGPI.ALIAS_ADDRESSING SIPARD.SGPI_MANAGED_BY_CENTRAL_BANK SIPARD.DIRECT_PARTICIPANT_HAS_CB_ACCOUNT TRANSFER.NO_CHARGE_TO_BENEFICIARY ACCOUNT.STANDARD_NUMBER

Ejecutar un escenario completo

# A whole process, end to end, from one call: onboarding at a strict institution,
# with the five variants that make it interesting.
export FINLAB="https://ecosystem.financial"

# what is on offer, and what each one claims to exercise
curl -s -H "x-lab-api-key: $FINLAB_API_KEY" "$FINLAB/v1/scenarios" | jq '.[] | {id, title, variants: [.variants[].id]}'

# the base run
curl -s -X POST "$FINLAB/v1/runs" \
  -H "x-lab-api-key: $FINLAB_API_KEY" -H 'content-type: application/json' \
  -d '{ "scenario": "onboarding-account-opening" }' | jq '{id, passed, summary}'

# the same scenario with the applicant who breaches the funding cap, on your own seed,
# so the run is reproducible by anybody you hand the seed to
curl -s -X POST "$FINLAB/v1/runs" \
  -H "x-lab-api-key: $FINLAB_API_KEY" -H 'content-type: application/json' \
  -d '{ "scenario": "onboarding-account-opening", "variant": "cap-reached", "seed": "our-team-2026-09-08" }' \
  | jq '{id, passed}'

# the report, in JSON and rendered as Markdown
RUN=$(curl -s -H "x-lab-api-key: $FINLAB_API_KEY" "$FINLAB/v1/runs" | jq -r '.[0].id')
curl -s -H "x-lab-api-key: $FINLAB_API_KEY" "$FINLAB/v1/runs/$RUN" | jq '.findings[] | select(.status=="fail")'
curl -s -H "x-lab-api-key: $FINLAB_API_KEY" "$FINLAB/v1/runs/$RUN/report.md" > report.md

const BASE = process.env.FINLAB ?? 'https://ecosystem.financial';
const headers = { 'x-lab-api-key': process.env.FINLAB_API_KEY, 'content-type': 'application/json' };
const call = async (path, init) => (await fetch(BASE + path, { headers, ...init })).json();

// run every variant of one scenario and see which rules each of them reached
const [scenario] = (await call('/v1/scenarios')).filter((s) => s.id === 'onboarding-account-opening');
const variants = ['base', ...scenario.variants.map((v) => v.id)];

for (const variant of variants) {
  const started = await call('/v1/runs', {
    method: 'POST',
    body: JSON.stringify({ scenario: scenario.id, variant, seed: 'our-team-2026-09-08' }),
  });
  const report = await call('/v1/runs/' + encodeURIComponent(started.id));
  const failed = report.findings.filter((f) => f.status === 'fail');
  console.log(
    variant.padEnd(22),
    started.passed ? 'PASS' : 'FAIL',
    report.rulesExercised.length + ' rules',
    failed.map((f) => f.ruleId + ' (' + f.article + ')').join(', '),
  );
}

import json, os, urllib.request

BASE = os.environ.get("FINLAB", "https://ecosystem.financial")
H = {"x-lab-api-key": os.environ["FINLAB_API_KEY"], "content-type": "application/json"}


def call(path, body=None):
    data = json.dumps(body).encode() if body is not None else None
    req = urllib.request.Request(BASE + path, data=data, headers=H, method="POST" if data else "GET")
    with urllib.request.urlopen(req) as res:
        return json.load(res)


scenario = next(s for s in call("/v1/scenarios") if s["id"] == "onboarding-account-opening")
for variant in ["base"] + [v["id"] for v in scenario["variants"]]:
    started = call("/v1/runs", {"scenario": scenario["id"], "variant": variant, "seed": "our-team-2026-09-08"})
    report = call("/v1/runs/" + started["id"])
    failed = [f for f in report["findings"] if f["status"] == "fail"]
    print(
        variant.ljust(22),
        "PASS" if started["passed"] else "FAIL",
        f"{len(report['rulesExercised'])} rules",
        ", ".join(f"{f['ruleId']} ({f['article']})" for f in failed),
    )

8Catálogo de reglas

76 reglas, versión del catálogo 2026.09.05. Cada una cita el artículo que ejecuta, el instrumento al que pertenece el artículo, la resolución que fijó su valor y la fecha de esa resolución. Una regla que no lleve los cuatro campos no carga: está impuesto en el cargador, no meramente solicitado.

Dos reglas no citan artículo alguno del Reglamento, y lo declaran en el propio campo article: un control del Lab y una regla de gobernanza. Varias más precisan en su source qué mitad es del Reglamento y qué mitad es nuestra. Un umbral con un artículo al lado que ese artículo no contiene es un hecho regulatorio fabricado, y este catálogo está construido para que no pueda escribirse uno por descuido.

13 reglas están marcadas como «pendientes de reverificación». Provienen de IN-36-023 e IN-36-024, ambos en versión 01 del 30 de julio de 2021, que remiten al Reglamento del 29 de enero de 2021 derogado por la Segunda Resolución del 28 de agosto de 2025. Las reglas están vigentes en el catálogo: cargan, se evalúan y producen hallazgos. La marca impide que el Lab las presente como asunto zanjado, y viaja con cada hallazgo que producen. El IN-36-005 es versión 03 del 9 de abril de 2026 y cita el mismo Reglamento que el resto del catálogo, de modo que nada tomado de él lleva la marca.

Cuando un valor cambia - la Junta Monetaria ajusta un tope cada enero, y el umbral de alto valor se ajusta anualmente por el IPC - cambia en un solo lugar, y con él cambia la versión del catálogo.

Numeración de cuentas 1

ACCOUNT.STANDARD_NUMBERNovena Resolucion, 18 November 2010major

Accounts are numbered to the regional standardized account number adopted in 2010. The Lab uses an account number of the same shape with an LB prefix and ISO 7064 mod 97-10 check digits so it can never be mistaken for a real account.

Artículo: Novena Resolucion, 18 November 2010
Instrumento: Novena Resolucion de la Junta Monetaria
Resolución: Novena Resolucion de la Junta Monetaria
Fecha: 2010-11-18
Comprobación: must_be_true
Parámetro: account_number_valid
Valor: true
Fuente: Novena Resolucion, 18 November 2010; field layout is Lab assumption A-02

Agentes 1

AGENT.PERMITTED_ACTIVITYArt. 26-27major

Enrol users, fund accounts, pay out cash, show balances and deliver cards.

Artículo: Art. 26-27
Instrumento: Reglamento de Sistemas de Pago
Resolución: Segunda Resolucion de la Junta Monetaria
Fecha: 2025-08-28
Comprobación: must_be_member
Parámetro: agent_activity
Valor: ["enrol","fund","cash-out","balance","card-delivery"]
Fuente: Reglamento Arts. 26-27

Prevención de lavado de activos 2

AML.SCREENING_REQUIREDArt. 43-44major

Obligations under Ley 155-17 apply to payment-service providers and participants; records must be available to supervisors.

Artículo: Art. 43-44
Instrumento: Reglamento de Sistemas de Pago
Resolución: Segunda Resolucion de la Junta Monetaria
Fecha: 2025-08-28
Comprobación: must_be_true
Parámetro: screening_performed
Valor: true
Fuente: Reglamento Art. 43-44; Ley 155-17

AML.TRANSACTION_MONITORINGArt. 43-44critical

Anti-money-laundering obligations under Ley 155-17 apply to payment-service providers and participants, and their records must be available to the supervisors. A run that claims monitoring must show what was reviewed: the movements of the institutions and the machine transactions of the networks, refusals included.

Artículo: Art. 43-44
Instrumento: Reglamento de Sistemas de Pago
Resolución: Segunda Resolucion de la Junta Monetaria
Fecha: 2025-08-28
Comprobación: must_be_true
Parámetro: monitoring_reviewed_the_movements
Valor: true
Fuente: Reglamento Arts. 43-44 (Ley 155-17 obligations, and records at the supervisors' disposal). The article requires the obligation and the availability of the records; it prescribes no detection pattern and no threshold. The patterns the Lab looks for, and every number in them, are Lab decisions recorded as assumption A-23.

Cajeros 3

ATM.CARDHOLDER_VERIFICATIONLab controlcritical

No withdrawal at a machine is authorized until the issuer has verified the holder: a PIN on the card, a biometric check through the identity entity, or an order the holder already authenticated on the phone. This is a Lab control, not an article of the Reglamento; the Reglamento's own requirement on this flow is that every transaction, including the refused ones, is recorded (Art. 41).

Artículo: Lab control
Instrumento: CEMI Financial Innovation Lab governance
Resolución: Plan approved by Carlos Miranda Levy
Fecha: 2026-09-04
Comprobación: must_be_true
Parámetro: cardholder_verified
Valor: true
Fuente: Lab control, not a regulatory statement. The number of PIN attempts before a card is blocked is assumption A-19.
Notas: Catalogued so a run reports it next to the articles it does execute. Nothing in the sources read for the plan states a cardholder-verification obligation for ATM transactions; if the instructivo for administrators of payment systems does, this rule is rewritten with its citation.

ATM.CARDLESS_ORDER_SINGLE_USEArt. 78 SIVcritical

An order started on the phone and finished at the machine may be redeemed exactly once and only inside its validity. Art. 78 numeral IV requires the QR that carries it to hold the data needed to initiate a payment order; that the order is single-use and time-limited is a Lab control.

Artículo: Art. 78 SIV
Instrumento: Reglamento de Sistemas de Pago
Resolución: Segunda Resolucion de la Junta Monetaria
Fecha: 2025-08-28
Comprobación: must_be_true
Parámetro: order_redeemable_once_within_validity
Valor: true
Fuente: Reglamento Art. 78 numeral IV for the QR; the single-use and time-limit controls are Lab decisions (assumption A-20).

ATM.DEPOSIT_DISCREPANCY_RECORDEDArt. 41-42major

A deposit at a machine credits what the machine recognized. Where that differs from what was declared, the difference is recorded as an adjustment, because the record of every transaction must include adjustments and be retained for ten years.

Artículo: Art. 41-42
Instrumento: Reglamento de Sistemas de Pago
Resolución: Segunda Resolucion de la Junta Monetaria
Fecha: 2025-08-28
Comprobación: must_be_true
Parámetro: recognition_discrepancy_recorded
Valor: true
Fuente: Reglamento Arts. 41-42; the recognition model itself is assumption A-20.

Capital mínimo 3

CAPITAL.SYSTEM_ADMINISTRATOR_AND_ACQUIRERTitulos II-Vinformational

RD$78,866,000 minimum paid-in capital, the 2026 value.

Artículo: Titulos II-V
Instrumento: Reglamento de Sistemas de Pago
Resolución: Quinta Resolucion de la Junta Monetaria
Fecha: 2026-01-29
Comprobación: manual
Parámetro: minimum_paid_in_capital
Valor: 78866000 DOP
Fuente: Quinta Resolucion of 29 January 2026, adjusting the Reglamento's values by CPI

CAPITAL.EPE_SUBACQUIRER_ATM_WALLETTitulos II-Vinformational

RD$19,720,000 minimum paid-in capital, the 2026 value.

Artículo: Titulos II-V
Instrumento: Reglamento de Sistemas de Pago
Resolución: Quinta Resolucion de la Junta Monetaria
Fecha: 2026-01-29
Comprobación: manual
Parámetro: minimum_paid_in_capital
Valor: 19720000 DOP
Fuente: Quinta Resolucion of 29 January 2026

CAPITAL.INITIATION_PROVIDERTitulos II-Vinformational

RD$9,445,500 minimum paid-in capital, the 2026 value.

Artículo: Titulos II-V
Instrumento: Reglamento de Sistemas de Pago
Resolución: Quinta Resolucion de la Junta Monetaria
Fecha: 2026-01-29
Comprobación: manual
Parámetro: minimum_paid_in_capital
Valor: 9445500 DOP
Fuente: Quinta Resolucion of 29 January 2026

Tarjetas 1

CARD.PREPAID_CAPArt. 78 SIIcritical

The same RD$79,000 cap applies to prepaid cards.

Artículo: Art. 78 SII
Instrumento: Reglamento de Sistemas de Pago
Resolución: Quinta Resolucion de la Junta Monetaria
Fecha: 2026-01-29
Comprobación: max_amount
Parámetro: prepaid_cap
Valor: 79000 DOP
Fuente: Reglamento Art. 78 numeral II

Reclamaciones 1

CLAIM.TYPIFICATIONIN-36-023 numeral 10 f) ivmajor Pendiente de reverificación: 2025 Reglamento

The normas de funcionamiento must provide an auditable register for the control of claims and their answers, typified as attributable to operational or technological errors of the system administrator, its participants, the acquirer or its affiliated establishments; or derived from claims made by clients to participants or to users of the payment instruments processed.

Artículo: IN-36-023 numeral 10 f) iv
Instrumento: Instructivo para los Administradores de Sistemas de Pago o de Liquidacion de Valores
Resolución: IN-36-023 version 01, aprobado por el Gobernador del Banco Central
Fecha: 2021-07-30
Comprobación: must_be_member
Parámetro: claim_class
Valor: ["operational-or-technological","client-originated"]
Fuente: IN-36-023 p.9 numeral 10 f) iv. These are the same two classes that carry the two response deadlines of IN-36-005 numeral 36, which is why the typification lives beside them here.
Notas: IN-36-023 is version 01 of 30 July 2021 and cross-references the SUPERSEDED Reglamento of 29 January 2021 throughout. The two-class typification is unlikely to have moved, but the article numbering it sits inside has, so the rule is flagged for re-check.

Débito y crédito directo 4

DDC.RETURN_CARRIES_REASON_CODEArt. 41; Art. 79major

An item the receiving institution cannot apply is returned to the administrator with a reason code, and the return is part of the ten-year record.

Artículo: Art. 41; Art. 79
Instrumento: Reglamento de Sistemas de Pago
Resolución: Segunda Resolucion de la Junta Monetaria
Fecha: 2025-08-28
Comprobación: must_be_true
Parámetro: return_has_reason_code
Valor: true
Fuente: Reglamento Art. 41 on records; Art. 79 on settlement of cycle results
Notas: The reason-code list itself is a Lab convention (assumption A-04) until the instructivo for administrators of payment systems is read in full.

DDC.CYCLE_ON_BUSINESS_DAYArt. 79major

Clearing cycles of the direct debit and direct credit systems run on business days.

Artículo: Art. 79
Instrumento: Reglamento de Sistemas de Pago
Resolución: Segunda Resolucion de la Junta Monetaria
Fecha: 2025-08-28
Comprobación: must_be_true
Parámetro: cycle_ran_on_business_day
Valor: true
Fuente: Reglamento Art. 79; the calendar itself is Lab configuration (assumption A-01)

DDC.CREDITING_TIME_IS_DECLARED_NOT_FIXEDIN-36-023 numeral 10 c)critical Pendiente de reverificación: 2025 Reglamento

The normas de funcionamiento of every payment system must state the moment at which transfers of funds or securities are accepted by the system and become irrevocable, and the time to credit those funds to the final beneficiary of payment orders after acceptance. The Central Bank fixes no universal figure; the obligation is to declare one.

Artículo: IN-36-023 numeral 10 c)
Instrumento: Instructivo para los Administradores de Sistemas de Pago o de Liquidacion de Valores
Resolución: IN-36-023 version 01, aprobado por el Gobernador del Banco Central
Fecha: 2021-07-30
Comprobación: must_be_true
Parámetro: system_declares_crediting_time_and_irrevocability_instant
Valor: true
Fuente: IN-36-023 p.9 numeral 10 c). This closes the question the spec asked of this document: the crediting time is DELEGATED to each administrator, so the checkable rule is the obligation to declare it. The simulated administrator declares its own and the run records what it declared, which is exactly the shape assumption A-03 gave the parameter.

DDC.CLAIM_RECEPTION_YEARSIN-36-023 numeral 10 f) iiimajor Pendiente de reverificación: 2025 Reglamento

The normas de funcionamiento must provide a claim-reception period of up to four years, counted from the moment the user becomes aware of the event giving rise to the claim.

Artículo: IN-36-023 numeral 10 f) iii
Instrumento: Instructivo para los Administradores de Sistemas de Pago o de Liquidacion de Valores
Resolución: IN-36-023 version 01, aprobado por el Gobernador del Banco Central
Fecha: 2021-07-30
Comprobación: retention
Parámetro: system_claim_reception_years
Valor: 4 years
Fuente: IN-36-023 p.9 numeral 10 f) iii. The anchor - the user's knowledge - differs from the one IN-36-024 numeral 49 gives the same four years for an electronic payment account.

Cuentas de pago electrónico 16

EPA.BALANCE_CAPArt. 78 SIIcritical

The balance of an electronic payment account may not exceed RD$79,000, the 2026 value of the cap adjusted yearly by the Junta Monetaria.

Artículo: Art. 78 SII
Instrumento: Reglamento de Sistemas de Pago
Resolución: Quinta Resolucion de la Junta Monetaria
Fecha: 2026-01-29
Comprobación: max_amount
Parámetro: balance_cap
Valor: 79000 DOP
Fuente: Reglamento Art. 78 numeral II; value set by the Quinta Resolucion of 29 January 2026
Notas: Re-check every January when the Junta Monetaria adjusts the Reglamento's values.

EPA.FUNDING_CAP_30DArt. 78 SIIcritical

Funding of an electronic payment account may not exceed RD$79,000 within any 30-day window.

Artículo: Art. 78 SII
Instrumento: Reglamento de Sistemas de Pago
Resolución: Quinta Resolucion de la Junta Monetaria
Fecha: 2026-01-29
Comprobación: max_amount
Parámetro: funding_cap_30_days
Valor: 79000 DOP
Fuente: Reglamento Art. 78 numeral II; value set by the Quinta Resolucion of 29 January 2026

EPA.NO_INTERESTArt. 19major

The balance equals the nominal value received, bears no interest and is refundable on demand.

Artículo: Art. 19
Instrumento: Reglamento de Sistemas de Pago
Resolución: Segunda Resolucion de la Junta Monetaria
Fecha: 2025-08-28
Comprobación: must_be_false
Parámetro: interest_accrued
Valor: false
Fuente: Reglamento Art. 19-25

EPA.PERMITTED_OPERATIONArt. 20major

Cash withdrawal, direct credit, direct debit, POS, ATM withdrawal, e-commerce, airtime and data top-ups, bill payment, inbound remittances and social subsidies.

Artículo: Art. 20
Instrumento: Reglamento de Sistemas de Pago
Resolución: Segunda Resolucion de la Junta Monetaria
Fecha: 2025-08-28
Comprobación: must_be_member
Parámetro: operation
Valor: ["cash-withdrawal","direct-credit","direct-debit","pos","atm-withdrawal","e-commerce","top-up","bill-payment","inbound-remittance","social-subsidy"]
Fuente: Reglamento Art. 20

EPA.ADDITIONAL_CREDENTIALSArt. 19 SVminor

An account holder may hold additional credentials on the same balance, each with its own limits.

Artículo: Art. 19 SV
Instrumento: Reglamento de Sistemas de Pago
Resolución: Segunda Resolucion de la Junta Monetaria
Fecha: 2025-08-28
Comprobación: manual
Parámetro: credential_limits_enforced
Valor: true
Fuente: Reglamento Art. 19 numeral V

EPA.FUNDING_AVAILABLE_AFTER_SETTLEMENTIN-36-024 numeral 23 a)critical Pendiente de reverificación: 2025 Reglamento

Availability in the electronic payment account of funding made through other payment instruments carrying deferred crediting must occur at the latest two hours after its settlement, when credited through electronic payment instruments.

Artículo: IN-36-024 numeral 23 a)
Instrumento: Instructivo para las Entidades de Pago Electronico y Cuentas de Pago Electronico
Resolución: IN-36-024 version 01, aprobado por el Gobernador del Banco Central
Fecha: 2021-07-30
Comprobación: max_duration
Parámetro: epa_funding_availability_after_settlement
Valor: 2 h
Fuente: IN-36-024 p.11 numeral 23 a). The reference instant is SETTLEMENT of the funding instrument, not the instruction - the instructivo says "luego de su liquidacion" - which is also the anchor assumption A-11 chose for the Art. 57 four minutes, now supported by analogy rather than only by the Lab's reading.

EPA.FUNDING_AVAILABLE_AFTER_CHEQUEIN-36-024 numeral 23 b)critical Pendiente de reverificación: 2025 Reglamento

Availability in the electronic payment account must occur at the latest thirty minutes after the cheque is credited to the bank account of the electronic payment entity providing the service.

Artículo: IN-36-024 numeral 23 b)
Instrumento: Instructivo para las Entidades de Pago Electronico y Cuentas de Pago Electronico
Resolución: IN-36-024 version 01, aprobado por el Gobernador del Banco Central
Fecha: 2021-07-30
Comprobación: max_duration
Parámetro: epa_funding_availability_after_cheque
Valor: 30 m
Fuente: IN-36-024 p.11 numeral 23 b). The reference instant is the cheque landing in the EPE's OWN bank account, which is a different instant from the cheque being deposited. The SCC that would clear the cheque is Phase 3, so the run supplies that instant explicitly.

EPA.CAP_WINDOW_IS_CALENDAR_DAYSIN-36-024 numeral 18 b)critical Pendiente de reverificación: 2025 Reglamento

The technological solution must show the holder the headroom remaining against the issuance or funding limit permitted within the 30 calendar-day period in which the account currently sits, and must notify the user when that ceiling is reached.

Artículo: IN-36-024 numeral 18 b)
Instrumento: Instructivo para las Entidades de Pago Electronico y Cuentas de Pago Electronico
Resolución: IN-36-024 version 01, aprobado por el Gobernador del Banco Central
Fecha: 2021-07-30
Comprobación: must_equal
Parámetro: epa_cap_window_calendar_days
Valor: 30 calendar days
Fuente: IN-36-024 p.10 numeral 18 b). This settles the UNIT of assumption A-12 - calendar days, not elapsed simulated hours - and the EPE now counts the window on local dates. It does NOT settle rolling versus fixed anchoring: "el periodo de 30 dias calendario en que se encuentre" reads more naturally as a fixed period, and A-12 stays open on that half.

EPA.FUNDING_OVER_CAP_REJECTEDIN-36-024 numeral 19 d)critical Pendiente de reverificación: 2025 Reglamento

The technological solution must have the capacity to reject the funding of accounts when it exceeds the limit established for the user.

Artículo: IN-36-024 numeral 19 d)
Instrumento: Instructivo para las Entidades de Pago Electronico y Cuentas de Pago Electronico
Resolución: IN-36-024 version 01, aprobado por el Gobernador del Banco Central
Fecha: 2021-07-30
Comprobación: must_be_true
Parámetro: epa_over_cap_funding_rejected
Valor: true
Fuente: IN-36-024 p.11 numeral 19 d). Evaluated where the EPE refuses: the observed value is whether the funding was actually rejected once EPA.BALANCE_CAP or EPA.FUNDING_CAP_30D failed, which turns a cap breach from a finding into a refusal.

EPA.NO_OVERDRAFTIN-36-024 numeral 20critical Pendiente de reverificación: 2025 Reglamento

The payment instrument shall not permit overdrafts where funds are insufficient to carry out an operation; in that case the payment order shall be rejected.

Artículo: IN-36-024 numeral 20
Instrumento: Instructivo para las Entidades de Pago Electronico y Cuentas de Pago Electronico
Resolución: IN-36-024 version 01, aprobado por el Gobernador del Banco Central
Fecha: 2021-07-30
Comprobación: must_be_false
Parámetro: epa_overdraft_permitted
Valor: false
Fuente: IN-36-024 p.11 numeral 20; the same numeral also forbids a minimum balance

EPA.FLOAT_FULLY_BACKED_AT_CENTRAL_BANKIN-36-024 numeral 26 a) y c)critical Pendiente de reverificación: 2025 Reglamento

Before managing electronic payment accounts the electronic payment entity must hold in its Central Bank current account the funds corresponding to the account to be managed, provisioned by electronic funds transfer, and must keep account reconciliations so that the funds held for its users correspond to the balance in its Central Bank current account and the resources previously deposited to guarantee the managed balances.

Artículo: IN-36-024 numeral 26 a) y c)
Instrumento: Instructivo para las Entidades de Pago Electronico y Cuentas de Pago Electronico
Resolución: IN-36-024 version 01, aprobado por el Gobernador del Banco Central
Fecha: 2021-07-30
Comprobación: must_be_true
Parámetro: epa_float_covers_managed_balances
Valor: true
Fuente: IN-36-024 p.12 numeral 26 opening, a) and c). This is a full-reserve invariant the Lab's reconciliation layer can assert directly, and it is stronger than the network-wide mirror-sum-zero check that assumption A-14 describes.

EPA.DAILY_REPORT_TO_CENTRAL_BANKIN-36-024 numeral 26 d)major Pendiente de reverificación: 2025 Reglamento

The electronic payment entity must report daily to the Central Bank, through the mechanisms it provides, information on the enablement of electronic payment accounts, the funding and the withdrawals made by its users, and the total balance held in their favour.

Artículo: IN-36-024 numeral 26 d)
Instrumento: Instructivo para las Entidades de Pago Electronico y Cuentas de Pago Electronico
Resolución: IN-36-024 version 01, aprobado por el Gobernador del Banco Central
Fecha: 2021-07-30
Comprobación: must_be_true
Parámetro: epa_daily_report_submitted
Valor: true
Fuente: IN-36-024 p.12 numeral 26 d). The mechanism the Central Bank provides is not described, so the Lab sends the report over the bus to the simulated Central Bank and reports the four figures the numeral names, and nothing more.

EPA.CLAIM_RECEPTION_YEARSIN-36-024 numeral 49major Pendiente de reverificación: 2025 Reglamento

Users of an electronic payment account may bring claims before the electronic payment entity within a period of no more than four years, counted from the moment the event giving rise to the claim occurs.

Artículo: IN-36-024 numeral 49
Instrumento: Instructivo para las Entidades de Pago Electronico y Cuentas de Pago Electronico
Resolución: IN-36-024 version 01, aprobado por el Gobernador del Banco Central
Fecha: 2021-07-30
Comprobación: retention
Parámetro: epa_claim_reception_years
Valor: 4 years
Fuente: IN-36-024 p.19 numeral 49. Note the anchor differs from IN-36-023 numeral 10 f) iii, which runs the same four years from the user's KNOWLEDGE of the event rather than from the event. The two documents are not reconciled and the Lab does not reconcile them.

EPA.CLAIM_RESPONSE_DAYSIN-36-024 numeral 49major Pendiente de reverificación: 2025 Reglamento

The entity must have agile and reasonable claim-reception mechanisms and must answer claims within a maximum of thirty calendar days from the date of receipt.

Artículo: IN-36-024 numeral 49
Instrumento: Instructivo para las Entidades de Pago Electronico y Cuentas de Pago Electronico
Resolución: IN-36-024 version 01, aprobado por el Gobernador del Banco Central
Fecha: 2021-07-30
Comprobación: max_count
Parámetro: epa_claim_response_calendar_days
Valor: 30 calendar days
Fuente: IN-36-024 p.19 numeral 49, continuing on p.20

EPA.NO_FEE_FOR_CLAIMSIN-36-024 numeral 47 e) y f)major Pendiente de reverificación: 2025 Reglamento

In its relationship with users the electronic payment entity shall not charge commissions or fees for claims made, and shall immediately rectify the situations giving rise to a claim where the outcome so determines.

Artículo: IN-36-024 numeral 47 e) y f)
Instrumento: Instructivo para las Entidades de Pago Electronico y Cuentas de Pago Electronico
Resolución: IN-36-024 version 01, aprobado por el Gobernador del Banco Central
Fecha: 2021-07-30
Comprobación: must_equal
Parámetro: epa_claim_fee_minor
Valor: 0 DOP
Fuente: IN-36-024 p.19 numeral 47 e) and f)

EPA.FLOAT_ONLY_AT_CENTRAL_BANKArt. 22critical

The funds an electronic payment entity holds against the balances it manages may be kept ONLY in its current account at the Central Bank, or in securities issued by the Central Bank or the Ministerio de Hacienda pledged in favour of the Central Bank. They may not be held in a commercial bank, and they may not be invested in anything else.

Artículo: Art. 22
Instrumento: Reglamento de Sistemas de Pago
Resolución: Segunda Resolucion de la Junta Monetaria
Fecha: 2025-08-28
Comprobación: must_be_member
Parámetro: epa_float_placement
Valor: ["central-bank-current-account","pledged-bcrd-securities","pledged-hacienda-securities"]
Fuente: Reglamento Art. 22, verified on 2026-09-05. This is the placement rule and it is stronger than the coverage rule: IN-36-024 numeral 26 requires the float to COVER the managed balances, and Art. 22 says WHERE it may sit. A float fully covering its balances but held at a commercial bank satisfies the first and breaches the second.
Notas: The pledged-securities placements are catalogued and unexercised: the ecosystem has no securities settlement system before Phase 3, so the only placement a run can take is the Central Bank current account.

Moneda extranjera 1

FX.CONVERSION_RECORDEDArt. 41-42major

A conversion performed on a transfer is part of the transaction record: the currencies, the rate applied, the amount debited and the amount credited are retained for ten years with the transaction they belong to, and are available to the account holder and to the supervisors.

Artículo: Art. 41-42
Instrumento: Reglamento de Sistemas de Pago
Resolución: Segunda Resolucion de la Junta Monetaria
Fecha: 2025-08-28
Comprobación: must_be_true
Parámetro: conversion_recorded
Valor: true
Fuente: Reglamento Arts. 41-42. The rates themselves are Lab configuration and are deliberately fictitious (assumption A-21); no published rate is used anywhere in this repository.

Iniciación de pagos 1

INITIATION.NEVER_HOLDS_FUNDSArt. 4 mm, 38-40critical

Initiation of payment orders on a user's account happens by verifiable consent through secure interfaces; the provider never holds the funds.

Artículo: Art. 4 mm, 38-40
Instrumento: Reglamento de Sistemas de Pago
Resolución: Segunda Resolucion de la Junta Monetaria
Fecha: 2025-08-28
Comprobación: must_be_false
Parámetro: initiator_held_funds
Valor: false
Fuente: Reglamento Art. 4 mm and Arts. 38-40

Gobernanza del Lab 2

LAB.NOT_AMBIENTE_DE_PRUEBAArt. 83critical

The simulation involves no real providers and no real external users, so it does not fall under the no-objection regime of Art. 83. A run is never a substitute for the Central Bank's no objection; its report is evidence for a request, nothing more.

Artículo: Art. 83
Instrumento: Reglamento de Sistemas de Pago
Resolución: Segunda Resolucion de la Junta Monetaria
Fecha: 2025-08-28
Comprobación: must_be_true
Parámetro: run_involves_only_simulated_counterparts
Valor: true
Fuente: Reglamento Art. 83; plan section 10

LAB.SIMULATOR_CARRIES_LAB_NAMEgovernancecritical

No simulator presents itself as the entity it is modelled after. No real credentials, keys, BINs, routing identifiers, aliases or certificates exist anywhere in a run.

Artículo: governance
Instrumento: CEMI Financial Innovation Lab governance
Resolución: Plan approved by Carlos Miranda Levy
Fecha: 2026-09-04
Comprobación: must_be_true
Parámetro: simulator_uses_lab_identity
Valor: true
Fuente: plan section 10

LBTR: liquidación, prioridad, firmeza 14

LBTR.THIRD_PARTY_CREDITArt. 57critical

A credit in favour of a third party must be posted within four minutes of the receiving participant's account being affected.

Artículo: Art. 57
Instrumento: Reglamento de Sistemas de Pago
Resolución: Segunda Resolucion de la Junta Monetaria
Fecha: 2025-08-28
Comprobación: max_duration
Parámetro: third_party_credit_minutes
Valor: 4 m
Fuente: Reglamento Art. 57

LBTR.IRREVOCABLE_ONCE_SETTLEDArt. 66critical

An order settled in the LBTR is irrevocable; only a queued order may be revoked.

Artículo: Art. 66
Instrumento: Reglamento de Sistemas de Pago
Resolución: Segunda Resolucion de la Junta Monetaria
Fecha: 2025-08-28
Comprobación: must_be_false
Parámetro: revocation_accepted_after_settlement
Valor: false
Fuente: Reglamento Art. 66; BCRD Sistema LBTR page

LBTR.REVOCABLE_WHILE_QUEUEDArt. 66major

While an order sits in the LBTR queue and has not settled, the submitting participant may revoke it.

Artículo: Art. 66
Instrumento: Reglamento de Sistemas de Pago
Resolución: Segunda Resolucion de la Junta Monetaria
Fecha: 2025-08-28
Comprobación: must_be_true
Parámetro: revocation_accepted_while_queued
Valor: true
Fuente: Reglamento Art. 66; BCRD Sistema LBTR page

LBTR.SETTLEMENT_CURRENCYBCRD Sistema LBTRmajor

The real-time gross settlement system settles continuously in Dominican pesos, US dollars and euros.

Artículo: BCRD Sistema LBTR
Instrumento: BCRD published description of the LBTR
Resolución: BCRD Sistema LBTR page
Fecha: 2026-09-04
Comprobación: must_be_member
Parámetro: settlement_currency
Valor: ["DOP","USD","EUR"]
Fuente: BCRD Sistema LBTR page

LBTR.HIGH_VALUE_THRESHOLDIN-36-005 numeral 69critical

Electronic funds transfers exceeding RD$15,800,000.00, or the equivalent in foreign currency, are high-value transfers and must necessarily settle through the Central Bank's LBTR. Lower amounts may go through the LBTR or through any authorized payment system. The figure is adjusted annually by the year-on-year change in the Consumer Price Index published by the Central Bank, so it is re-checked each year exactly as the 2026 Junta Monetaria values are.

Artículo: IN-36-005 numeral 69
Instrumento: Instructivo del Sistema de Liquidacion Bruta en Tiempo Real
Resolución: IN-36-005 version 03, aprobado por el Gobernador del Banco Central
Fecha: 2026-04-09
Comprobación: max_amount
Parámetro: non_lbtr_transfer_amount
Valor: 15800000 DOP
Fuente: IN-36-005 p.22 numeral 69 and Parrafos I-II. Evaluated on every payment routed on a rail OTHER than the LBTR proper - an SGPI instant payment and a Pagos al Instante order - which is where the obligation bites. CPI-adjusted annually; re-check each year.
Notas: The equivalence in foreign currency is stated by the instructivo but the conversion basis is not; a run in USD or EUR therefore does not evaluate this rule and says so.

LBTR.PRIORITY_RANGE_PARTICIPANTIN-36-005 numeral 22 Parrafo Imajor

The LBTR offers participants 80 priorities, 20 being the highest and 99 the lowest. Assigning a priority is optional.

Artículo: IN-36-005 numeral 22 Parrafo I
Instrumento: Instructivo del Sistema de Liquidacion Bruta en Tiempo Real
Resolución: IN-36-005 version 03, aprobado por el Gobernador del Banco Central
Fecha: 2026-04-09
Comprobación: within_range
Parámetro: participant_priority
Valor: [20,99]
Fuente: IN-36-005 p.13 numeral 22 Parrafo I

LBTR.PRIORITY_DEFAULTIN-36-005 numeral 22 Parrafos I-IImajor

Where the originating participant assigns no priority, the LBTR assigns priority 98. The same default applies to a securities-settlement delivery-versus-payment instruction whose administrator set none.

Artículo: IN-36-005 numeral 22 Parrafos I-II
Instrumento: Instructivo del Sistema de Liquidacion Bruta en Tiempo Real
Resolución: IN-36-005 version 03, aprobado por el Gobernador del Banco Central
Fecha: 2026-04-09
Comprobación: must_equal
Parámetro: default_priority
Valor: 98
Fuente: IN-36-005 p.13 numeral 22 Parrafos I y II

LBTR.PRIORITY_RESERVED_TO_CENTRAL_BANKIN-36-005 numeral 22 Parrafo IIImajor

The Central Bank holds, exclusively and permanently, the priority range 0 to 14. No participant instruction may carry a priority inside it.

Artículo: IN-36-005 numeral 22 Parrafo III
Instrumento: Instructivo del Sistema de Liquidacion Bruta en Tiempo Real
Resolución: IN-36-005 version 03, aprobado por el Gobernador del Banco Central
Fecha: 2026-04-09
Comprobación: must_be_false
Parámetro: participant_instruction_uses_reserved_priority
Valor: false
Fuente: IN-36-005 p.13 numeral 22 Parrafo III

LBTR.PRIORITY_RANGE_DVPIN-36-005 numeral 22 Parrafo IIminor

Funds-transfer instructions sent by the administrator of a securities settlement system under delivery-versus-payment may be assigned a priority in the range 15 to 98.

Artículo: IN-36-005 numeral 22 Parrafo II
Instrumento: Instructivo del Sistema de Liquidacion Bruta en Tiempo Real
Resolución: IN-36-005 version 03, aprobado por el Gobernador del Banco Central
Fecha: 2026-04-09
Comprobación: within_range
Parámetro: dvp_priority
Valor: [15,98]
Fuente: IN-36-005 p.13 numeral 22 Parrafo II. Catalogued and unexercised: no securities settlement system exists in the ecosystem before Phase 3, so nothing sends a DvP instruction yet.

LBTR.SETTLEMENT_PRELATIONIN-36-005 numeral 21major

Settlement precedence, highest to lowest, is: Central Bank operations debiting participant accounts; Sistema Electronico de Subastas operations; SGPI results; cheque clearing (SCC) results; Plataforma Cambiaria BCRD results; results of deferred net settlement systems run by other administrators; and participant funds transfers for own or third-party account.

Artículo: IN-36-005 numeral 21
Instrumento: Instructivo del Sistema de Liquidacion Bruta en Tiempo Real
Resolución: IN-36-005 version 03, aprobado por el Gobernador del Banco Central
Fecha: 2026-04-09
Comprobación: must_be_member
Parámetro: settlement_prelation
Valor: ["central-bank-debit","auction-css","sgpi-results","cheque-clearing-scc","plataforma-cambiaria","deferred-net-settlement","participant-transfer"]
Fuente: IN-36-005 p.12 numeral 21 a-g. The ORDER of the list is the rule, and the queue in packages/central-bank/src/central-bank.ts drains in exactly this order, then by priority, then by time of submission. Two of the seven classes have no actor in the ecosystem yet - the auction system and the Plataforma Cambiaria - and the SCC arrives in Phase 3.

LBTR.QUEUE_ON_INSUFFICIENT_FUNDSIN-36-005 numerales 16 y 23major

The LBTR settles instructions one by one on their value date provided the originating participant has funds in its Central Bank current account. On an insufficient balance the instruction queues, in state Listo, awaiting sufficient funds.

Artículo: IN-36-005 numerales 16 y 23
Instrumento: Instructivo del Sistema de Liquidacion Bruta en Tiempo Real
Resolución: IN-36-005 version 03, aprobado por el Gobernador del Banco Central
Fecha: 2026-04-09
Comprobación: must_be_true
Parámetro: insufficient_funds_queues_not_rejects
Valor: true
Fuente: IN-36-005 p.10 numeral 16, p.13 numeral 23

LBTR.REVOCABLE_UNTIL_SETTLEDIN-36-005 numeral 18major

Funds-transfer instructions may be cancelled by the participant that made them or by the Central Bank, at any time, so long as they have not settled in the LBTR. This refines LBTR.REVOCABLE_WHILE_QUEUED, which models only the participant's own revocation.

Artículo: IN-36-005 numeral 18
Instrumento: Instructivo del Sistema de Liquidacion Bruta en Tiempo Real
Resolución: IN-36-005 version 03, aprobado por el Gobernador del Banco Central
Fecha: 2026-04-09
Comprobación: must_be_true
Parámetro: central_bank_may_cancel_unsettled_order
Valor: true
Fuente: IN-36-005 p.11 numeral 18

LBTR.END_OF_DAY_QUEUE_FLUSHIN-36-005 numeral 25major

At the hour set in the daily operating cycle, and before closing LBTR operations, the Central Bank may remove from the queue instructions dated for settlement that day which the issuer has not already cancelled. That removal is deemed equivalent to revocation by the issuing participant, and the Central Bank bears no liability for the consequences.

Artículo: IN-36-005 numeral 25
Instrumento: Instructivo del Sistema de Liquidacion Bruta en Tiempo Real
Resolución: IN-36-005 version 03, aprobado por el Gobernador del Banco Central
Fecha: 2026-04-09
Comprobación: must_be_true
Parámetro: queued_order_flushed_at_close_is_revoked
Valor: true
Fuente: IN-36-005 p.13 numeral 25 and Parrafo. The HOUR is set by the daily operating cycle, which the instructivo defers to a Circular of the Gerencia the Lab has not read (numeral 95), so the flush is an operation the scenario invokes rather than a clock event the Lab invents.

LBTR.ORDER_STATEIN-36-005 numeral 19major

The state of a funds-transfer instruction in the LBTR is one of Almacenado, Anulado, Ingresado, Liquidado, Listo, Pendiente or Rechazado.

Artículo: IN-36-005 numeral 19
Instrumento: Instructivo del Sistema de Liquidacion Bruta en Tiempo Real
Resolución: IN-36-005 version 03, aprobado por el Gobernador del Banco Central
Fecha: 2026-04-09
Comprobación: must_be_member
Parámetro: lbtr_order_state
Valor: ["Almacenado","Anulado","Ingresado","Liquidado","Listo","Pendiente","Rechazado"]
Fuente: IN-36-005 p.11 numeral 19 a-g. The simulator's own four statuses map onto these: queued is Listo, settled is Liquidado, revoked is Anulado, rejected is Rechazado. The mapping is the Lab's, the vocabulary is the instructivo's.

Liquidación neta 2

NET.SETTLES_IN_LBTRArt. 79critical

The results of each clearing cycle of the electronic-instrument systems settle in the real-time gross settlement system.

Artículo: Art. 79
Instrumento: Reglamento de Sistemas de Pago
Resolución: Segunda Resolucion de la Junta Monetaria
Fecha: 2025-08-28
Comprobación: must_be_true
Parámetro: cycle_settled_in_lbtr
Valor: true
Fuente: Reglamento Art. 79; Art. 67 for deferred-net finality

NET.DEFERRED_FINALITYArt. 67major

A deferred-net system carries its own irrevocability and finality rules for the settled net result.

Artículo: Art. 67
Instrumento: Reglamento de Sistemas de Pago
Resolución: Segunda Resolucion de la Junta Monetaria
Fecha: 2025-08-28
Comprobación: must_be_true
Parámetro: net_result_final_once_settled
Valor: true
Fuente: Reglamento Art. 67

Pagos al Instante BCRD 10

PAI.FINAL_CREDITBCRD Pagos al Instantecritical

A Pagos al Instante BCRD transfer reaches the beneficiary as a final credit within eight minutes.

Artículo: BCRD Pagos al Instante
Instrumento: BCRD published description of Pagos al Instante BCRD
Resolución: BCRD Pagos al Instante BCRD page
Fecha: 2026-09-04
Comprobación: max_duration
Parámetro: final_credit_minutes
Valor: 8 m
Fuente: BCRD Pagos al Instante BCRD page; runs on the LBTR

PAI.OPERATING_WINDOWBCRD Pagos al Instantemajor

Available seven days a week from 07:00 to 23:00 local time, with a pause on weekdays between 16:00 and 18:30. An order given outside that schedule is not refused: it becomes effective at 08:00 on the next business day (PAI.DEFERRED_TO_NEXT_BUSINESS_DAY).

Artículo: BCRD Pagos al Instante
Instrumento: BCRD published description of Pagos al Instante BCRD
Resolución: BCRD Pagos al Instante BCRD page
Fecha: 2026-09-04
Comprobación: within_window
Parámetro: instruction_instant
Valor: "07:00-23:00 with a weekday pause 16:00-18:30"
Fuente: BCRD Pagos al Instante page, https://www.bancentral.gov.do/a/d/2665-descripcion. Verified against the page on 2026-09-05.

PAI.DEFERRED_TO_NEXT_BUSINESS_DAYBCRD Pagos al Instantemajor

Orders instructed outside the Pagos al Instante schedule «se hacen efectivos a las 8:00 a.m. del siguiente dia laborable»: they become effective at 08:00 on the NEXT BUSINESS DAY. A Friday-night order therefore becomes effective on Monday morning, not on Saturday.

Artículo: BCRD Pagos al Instante
Instrumento: BCRD published description of Pagos al Instante BCRD
Resolución: BCRD Pagos al Instante BCRD page
Fecha: 2026-09-05
Comprobación: must_equal
Parámetro: deferred_execution_local_time
Valor: "08:00"
Fuente: BCRD Pagos al Instante page, https://www.bancentral.gov.do/a/d/2665-descripcion, read on 2026-09-05: «se hacen efectivos a las 8:00 a.m. del siguiente dia laborable». This CORRECTS the Lab's earlier reading, which deferred to 07:00 on the next calendar day - two mistakes in one: the wrong hour, and a calendar day where the page says a business day.
Notas: The page says «fuera del horario» without distinguishing the after-hours case from the weekday pause, so the Lab applies the same deferral to both. Treating the 16:00-18:30 pause as «fuera del horario» is the Lab's reading and not the page's words; see assumption A-10.

PAI.FIXED_FEE_ONLYBCRD Pagos al Instantemajor

The fee for a Pagos al Instante transfer is a fixed amount; a percentage of the transferred amount is not permitted.

Artículo: BCRD Pagos al Instante
Instrumento: BCRD published description of Pagos al Instante BCRD
Resolución: BCRD Pagos al Instante BCRD page
Fecha: 2026-09-04
Comprobación: must_be_true
Parámetro: fee_is_fixed_amount
Valor: true
Fuente: BCRD Pagos al Instante BCRD page

PAI.NO_DEDUCTION_BY_RECEIVING_BANKBCRD Pagos al Instantecritical

The beneficiary's institution may not deduct anything from the amount transferred.

Artículo: BCRD Pagos al Instante
Instrumento: BCRD published description of Pagos al Instante BCRD
Resolución: BCRD Pagos al Instante BCRD page
Fecha: 2026-09-04
Comprobación: must_be_false
Parámetro: receiving_institution_deducted
Valor: false
Fuente: BCRD Pagos al Instante BCRD page; see also Reglamento Art. 81

PAI.FEE_REVERSED_ON_MISSED_DEADLINEIN-36-005 numeral 34 Parrafomajor

Where the transfer or payment is not applied within the established period for reasons attributable to the originating or the receiving entity, the originating client receives an automatic reversal of the fee charged, borne by the entity in breach.

Artículo: IN-36-005 numeral 34 Parrafo
Instrumento: Instructivo del Sistema de Liquidacion Bruta en Tiempo Real
Resolución: IN-36-005 version 03, aprobado por el Gobernador del Banco Central
Fecha: 2026-04-09
Comprobación: must_be_true
Parámetro: fee_reversed_when_deadline_missed
Valor: true
Fuente: IN-36-005 p.16 numeral 34 Parrafo. The "established period" is the eight minutes of PAI.FINAL_CREDIT, whose own anchor remains assumption A-10 - so the consequence is the instructivo's and the deadline it hangs on is still partly the Lab's.

PAI.CLAIM_RESPONSE_OPERATIONALIN-36-005 numeral 36 a)major

Where a participant makes a Pagos al Instante claim against another participant, the latter answers within up to two business days for requests attributable to the participants' own operational or technological errors.

Artículo: IN-36-005 numeral 36 a)
Instrumento: Instructivo del Sistema de Liquidacion Bruta en Tiempo Real
Resolución: IN-36-005 version 03, aprobado por el Gobernador del Banco Central
Fecha: 2026-04-09
Comprobación: max_count
Parámetro: claim_response_business_days
Valor: 2 business days
Fuente: IN-36-005 p.17 numeral 36 a). Counted in BUSINESS days by the run's own calendar, which is Lab configuration (assumption A-01), so the count is only as right as the holiday list.

PAI.CLAIM_RESPONSE_CLIENTIN-36-005 numeral 36 b)major

The same claim mechanism allows up to five business days for requests arising from claims made by the client.

Artículo: IN-36-005 numeral 36 b)
Instrumento: Instructivo del Sistema de Liquidacion Bruta en Tiempo Real
Resolución: IN-36-005 version 03, aprobado por el Gobernador del Banco Central
Fecha: 2026-04-09
Comprobación: max_count
Parámetro: claim_response_business_days
Valor: 5 business days
Fuente: IN-36-005 p.17 numeral 36 b); the same calendar caveat as PAI.CLAIM_RESPONSE_OPERATIONAL

PAI.USD_NO_CORRESPONDENTBCRD Pagos al instantemajor

Transfers in United States dollars through Pagos al Instante BCRD move between participants without a correspondent bank: they settle in the LBTR, which settles in Dominican pesos, US dollars and euros.

Artículo: BCRD Pagos al instante
Instrumento: BCRD published description of Pagos al Instante BCRD
Resolución: BCRD Pagos al instante page
Fecha: 2026-09-04
Comprobación: must_be_false
Parámetro: correspondent_used
Valor: false
Fuente: BCRD Pagos al instante page; BCRD Sistema LBTR page for the settlement currencies (Art. 56, national and foreign currency)

PAI.ORIGINATOR_CONVERTSBCRD Pagos al instantemajor

Where the beneficiary's account is held in a currency other than the one the order is instructed in, the originating institution may perform the conversion, and the beneficiary is credited in the currency of their own account.

Artículo: BCRD Pagos al instante
Instrumento: BCRD published description of Pagos al Instante BCRD
Resolución: BCRD Pagos al instante page
Fecha: 2026-09-04
Comprobación: must_be_true
Parámetro: originating_institution_converted
Valor: true
Fuente: BCRD Pagos al instante page. Whether the conversion is a permission or an obligation is read here as a permission: the rule fires only when a conversion was actually needed.

QR 1

QR.PRESENT_AND_READArt. 78 SIVmajor

Every payment-service provider must be able to present and read a QR code carrying the data needed to initiate a payment order, to the standard the Central Bank sets by instructivo.

Artículo: Art. 78 SIV
Instrumento: Reglamento de Sistemas de Pago
Resolución: Segunda Resolucion de la Junta Monetaria
Fecha: 2025-08-28
Comprobación: manual
Parámetro: qr_present_and_read
Valor: true
Fuente: Reglamento Art. 78 numeral IV; the QR instructivo is pending publication

Registros 2

RECORDS.RETENTION_YEARSArt. 41-42major

Providers and participants store every transaction, including rejected ones and adjustments, for ten years, with full user access and delivery to the Central Bank and supervisors without undue delay.

Artículo: Art. 41-42
Instrumento: Reglamento de Sistemas de Pago
Resolución: Segunda Resolucion de la Junta Monetaria
Fecha: 2025-08-28
Comprobación: retention
Parámetro: retention_years
Valor: 10 years
Fuente: Reglamento Art. 41-42

RECORDS.INCLUDES_REJECTEDArt. 41major

Rejected transactions and adjustments are part of the retained record, not only settled ones.

Artículo: Art. 41
Instrumento: Reglamento de Sistemas de Pago
Resolución: Segunda Resolucion de la Junta Monetaria
Fecha: 2025-08-28
Comprobación: must_be_true
Parámetro: rejected_transactions_recorded
Valor: true
Fuente: Reglamento Art. 41

Pagos instantáneos del SGPI 5

SGPI.FINAL_CREDITBCRD SGPI pagecritical

The Sistema de Gestion de Pagos Instantaneos credits the beneficiary finally within ten seconds of the instruction.

Artículo: BCRD SGPI page
Instrumento: BCRD published description of the SGPI
Resolución: BCRD SGPI page
Fecha: 2026-09-05
Comprobación: max_duration
Parámetro: final_credit_seconds
Valor: 10 s
Fuente: BCRD SGPI page, https://www.bancentral.gov.do/a/d/6142. Verified on 2026-09-05. THE TEN SECONDS ARE NOT IN THE REGLAMENTO. Arts. 60-61 establish the SGPI, its administration and who must participate in it; the ten-second parameter is published on the Central Bank's own page and nowhere in the articles. The citation was corrected on 2026-09-05, because a threshold with an article beside it that the article does not carry is exactly the fabricated regulatory fact this catalogue exists to prevent.
Notas: Where the ten seconds is measured from and to is still the Lab's reading (assumption A-09); what is settled is where the figure comes from.

SGPI.AVAILABILITYBCRD SGPI pagecritical

The SGPI operates 24/7/365; there is no operating window and no cut-off.

Artículo: BCRD SGPI page
Instrumento: BCRD published description of the SGPI
Resolución: BCRD SGPI page
Fecha: 2026-09-05
Comprobación: must_be_true
Parámetro: available_at_instruction_time
Valor: true
Fuente: BCRD SGPI page, https://www.bancentral.gov.do/a/d/6142. Verified on 2026-09-05. Like the ten seconds, the 24/7/365 availability is published on the page and is not an article of the Reglamento; the citation was corrected on 2026-09-05. It is CONFIRMED independently by IN-36-005 pp.6-7 numeral 3 mm), which defines the SGPI as operating in real time, 24 hours a day, 7 days a week.

SGPI.MANDATORY_PARTICIPATIONArt. 61 SIcritical

All financial-intermediation entities, electronic-payment entities, acquirers and sub-acquirers are mandatory participants of the SGPI.

Artículo: Art. 61 SI
Instrumento: Reglamento de Sistemas de Pago
Resolución: Segunda Resolucion de la Junta Monetaria
Fecha: 2025-08-28
Comprobación: must_be_true
Parámetro: participant_registered_in_sgpi
Valor: true
Fuente: Reglamento Art. 61 numeral I

SGPI.NOTIFY_BOTH_PARTIESArt. 61major

Payer and beneficiary are both notified immediately once the instant payment is credited.

Artículo: Art. 61
Instrumento: Reglamento de Sistemas de Pago
Resolución: Segunda Resolucion de la Junta Monetaria
Fecha: 2025-08-28
Comprobación: must_be_true
Parámetro: both_parties_notified
Valor: true
Fuente: BCRD SGPI page; Reglamento Art. 61

SGPI.ALIAS_ADDRESSINGArt. 60-61major

An instant payment may be addressed to an alias resolved by the Central Bank's directory.

Artículo: Art. 60-61
Instrumento: Reglamento de Sistemas de Pago
Resolución: Segunda Resolucion de la Junta Monetaria
Fecha: 2025-08-28
Comprobación: must_be_true
Parámetro: alias_resolved
Valor: true
Fuente: BCRD SGPI page

Transferencias regionales SIPA 2

SIPA.OPERATING_WINDOWBCRD SIPAmajor

Regional real-time USD transfers with Costa Rica, El Salvador, Guatemala, Honduras and Nicaragua run on weekdays from 07:00 to 17:00 Dominican time.

Artículo: BCRD SIPA
Instrumento: BCRD published description of the SIPA
Resolución: BCRD SIPA page
Fecha: 2026-09-04
Comprobación: within_window
Parámetro: instruction_instant
Valor: "weekdays 07:00-17:00"
Fuente: BCRD SIPA page

SIPA.ORIGINATOR_FEEBCRD SIPAmajor

A SIPA transfer carries a US$5 fee, paid by the originator.

Artículo: BCRD SIPA
Instrumento: BCRD published description of the SIPA
Resolución: BCRD SIPA page
Fecha: 2026-09-04
Comprobación: must_equal
Parámetro: originator_fee_usd
Valor: 5 USD
Fuente: BCRD SIPA page

Participación e interoperabilidad en el SIPARD 3

SIPARD.DIRECT_PARTICIPANT_HAS_CB_ACCOUNTArt. 4 zz-bbbcritical

Direct participants in the SIPARD hold current accounts at the Central Bank; indirect participants settle through a direct one.

Artículo: Art. 4 zz-bbb
Instrumento: Reglamento de Sistemas de Pago
Resolución: Segunda Resolucion de la Junta Monetaria
Fecha: 2025-08-28
Comprobación: must_be_true
Parámetro: has_central_bank_current_account
Valor: true
Fuente: Reglamento Art. 4 zz-bbb; BCRD SIPARD page

SIPARD.INTEROPERABILITYArt. 10major

Every administrator of a payment system must be interoperable.

Artículo: Art. 10
Instrumento: Reglamento de Sistemas de Pago
Resolución: Segunda Resolucion de la Junta Monetaria
Fecha: 2025-08-28
Comprobación: manual
Parámetro: administrator_is_interoperable
Valor: true
Fuente: Reglamento Art. 10

SIPARD.SGPI_MANAGED_BY_CENTRAL_BANKArt. 62critical

The SIPARD is a public service owned exclusively by the Central Bank; SGPI management is not delegable.

Artículo: Art. 62
Instrumento: Reglamento de Sistemas de Pago
Resolución: Segunda Resolucion de la Junta Monetaria
Fecha: 2025-08-28
Comprobación: must_be_true
Parámetro: sgpi_administrator_is_central_bank
Valor: true
Fuente: Reglamento Art. 60, 62; Ley 183-02 Art. 27

Transferencias 1

TRANSFER.NO_CHARGE_TO_BENEFICIARYArt. 81; Art. 56 SIIcritical

No charge may be applied to the beneficiary of a transfer or payment; the cost is borne by the ordering party.

Artículo: Art. 81; Art. 56 SII
Instrumento: Reglamento de Sistemas de Pago
Resolución: Segunda Resolucion de la Junta Monetaria
Fecha: 2025-08-28
Comprobación: must_be_false
Parámetro: charge_applied_to_beneficiary
Valor: false
Fuente: Reglamento Art. 81 and Art. 56 numeral II

9Versionado y política de cambios

Tres cosas llevan versión, y se mueven por razones distintas.

Qué	Dónde se lee	Cuándo cambia
El catálogo de reglas	`ruleCatalogue` en `/v1/health`, y en cada informe de corrida	se agrega una regla, se ajusta un valor o se corrige una cita. Fechada, `AAAA.MM.DD`.
El contrato OpenAPI	`info.version` en /openapi.json	cambia un endpoint, un campo o la forma de una respuesta
Este manual	el pie de cada página	se regenera desde las fuentes en cada despliegue; no puede ser más antiguo que lo que documenta

Qué le hará y qué no le hará el Lab

Los cambios aditivos llegan sin aviso, y su integración debería tolerarlos: un endpoint nuevo, un campo nuevo en una respuesta, una regla nueva en el catálogo, un escenario nuevo, un actor nuevo en el bus. Ignore los campos que no reconozca.
Un cambio incompatible en una petición o una respuesta se anuncia antes, en la bitácora de cambios y a cada equipo con llave, con la fecha en que entra en vigor.
Que cambie un valor regulatorio no es un cambio incompatible. Si la Junta Monetaria ajusta un tope, o el IPC mueve el umbral de alto valor, el catálogo cambia y sus corridas empiezan a fallar donde antes pasaban. Eso es el ecosistema funcionando. La resolutionDate de la regla le dice contra qué cosecha se le está juzgando.
Nunca se le reinicia el mundo sin pedirlo. Solo su propio equipo puede reiniciar su mundo, y un administrador únicamente a solicitud.

Reproducibilidad a través de un cambio

El informe de una corrida lleva la versión del catálogo de reglas, la semilla, el modo de reloj y el nivel de fidelidad de cada actor. Una corrida que pasó bajo el catálogo 2026.09.05 es una aprobación sobre ese catálogo, y el informe lo dice en su portada. Eso es lo que permite entregar un informe a un supervisor meses después y que siga significando algo preciso.

10Límites y uso razonable

El Lab paga esta instancia con su propio presupuesto. No hay facturación, no hay página de cuotas y no está previsto añadir una; lo que hay, en su lugar, es una expectativa dicha con claridad.

Qué es la instancia


Cómputo	Un único servicio pequeño de Cloud Run que escala a cero. La primera llamada tras un periodo de inactividad paga un arranque en frío de unos segundos.
Su mundo	Se construye en su primera llamada y se mantiene en memoria mientras viva la instancia. Un mundo no sobrevive a un redespliegue ni a un escalado a cero: se reconstruye desde la misma semilla, de modo que las personas y sus documentos regresan y lo que usted hizo, no. Trate el mundo como superficie de trabajo y el informe de la corrida como el registro.
Sus informes	Están en el Firestore del proyecto, y sí sobreviven. Son el registro, y la semilla que llevan es lo que hace reproducible la corrida.
Concurrencia	Una corrida ocupa un mundo mientras se ejecuta. Varios equipos corriendo a la vez está bien; un equipo disparando cientos de corridas simultáneas, no, y el primero en notar la lentitud será ese equipo.

Lo que pedimos

No haga pruebas de carga contra la instancia. No es un banco de rendimiento y sus tiempos son configuración del Lab, no medición de nada. Si quiere ejercitar rendimiento, solicite un nodo patrocinado.
No consulte /v1/runs en un bucle apretado. Una corrida le informa su identificador al terminar; para lo demás existen los webhooks.
No introduzca en este ecosistema una credencial real, un PAN real, un número de documento real ni datos personales reales. No hay lugar apropiado para ellos, todo queda registrado en una traza y nada de esto es sistema de registro de los datos de nadie. Este es el único límite que no es cortesía.
No presente una corrida como una aprobación. Véase la sección de gobernanza: es breve e importa más que todo lo demás de esta página.
Una llave, un equipo. Si un segundo equipo de su organización necesita acceso, solicite una segunda llave para que ambos tengan mundos separados. Compartir llave es compartir mundo, y entonces dos equipos depuran el estado del otro.

Si tropieza con algo que parece un límite y no está documentado aquí, probablemente sea un defecto. Dígalo en el formulario de retroalimentación: para eso existe exactamente.

11Soporte, y cómo pedir más

Dos formularios, y llegan al mismo lugar

Solicitar una llave de equipo: para una organización que quiere conectar algo. Díganos quiénes son, qué ejercitarían y aproximadamente cuándo; el Lab acuña una llave y un mundo y le entrega la llave. Nada se emite automáticamente, y es a propósito.
Comentarios, sugerencias, correcciones y defectos, incluido «esta regla cita el artículo equivocado», que es lo más valioso que alguien puede enviarnos. Indique el artículo o el documento y lo cotejaremos contra la fuente para corregir el catálogo.

Por correo

Para	Escriba a
alianzas, llaves, nodos patrocinados	partners@cemi.ai
una llave filtrada, o cualquier asunto de seguridad	security@cemi.ai
consultas legales y de gobernanza	legal@cemi.ai
cualquier otra cosa	contact@cemi.ai

Un nodo patrocinado

Un nodo patrocinado es una instancia del ecosistema que lleva la configuración propia de una institución: su personalidad, sus políticas, sus tasas, su carril privado para sus proveedores y para las startups con las que trabaja. La instancia compartida del Lab lleva deliberadamente tasas de cambio ficticias y umbrales del Lab, porque una instancia compartida es el lugar equivocado para una tabla real. Un nodo patrocinado es el lugar correcto, y es el mecanismo por el cual un banco, un procesador o un regulador obtiene un ecosistema con la forma del suyo.

Solicítelo mediante el formulario de solicitud de llave, indicándolo en el campo de uso previsto, o escriba a partners@cemi.ai.

El Lab

La Simulación del Ecosistema Financiero Virtual es el cuarto banco de pruebas del Laboratorio de Innovación Financiera de CEMI, junto a Máquinas Inteligentes, el Sandbox Abierto y el Living Lab.

12Gobernanza

Qué es un informe, y qué no es

El informe de una corrida dice qué se probó: el escenario, la variante, la semilla, el nivel de fidelidad de cada actor, el modo de reloj y la versión del catálogo de reglas. Una «aprobación» es una aprobación en esa corrida, contra ese catálogo, en esos niveles de fidelidad.

Es evidencia de que usted ejercitó un proceso de extremo a extremo contra las reglas tal como el Lab las ha catalogado, reproducible por cualquiera que tenga la semilla.
No es una certificación, una autorización, una no objeción, ni una declaración de que alguna institución haya revisado nada. Ninguna institución aquí modelada ha respaldado este ecosistema.

La regla sobre la que está construido todo el catálogo

Una regla para la que no se puede citar un artículo no es una regla. O es un supuesto - y pertenece a los supuestos numerados, con su razón y con qué lo resolvería - o es un control del Lab, que entra al catálogo con article: "Lab control" y una fuente que declara sin rodeos que no es una afirmación regulatoria. Tomar prestado un artículo cercano que no dice lo que se pretende es la única jugada que nunca está disponible.

Ningún dato personal real

La población sintética se genera desde la semilla de la corrida y su generador es auditable. Nada en ella corresponde a una persona real, y el esquema de identificadores está construido para que nada en ella pueda confundirse con una. No introduzca datos personales reales.

De dónde salen los valores

Cada cifra regulatoria del catálogo es rastreable hasta un instrumento publicado: el Reglamento de Sistemas de Pago aprobado por la Segunda Resolución de la Junta Monetaria del 28 de agosto de 2025, y los instructivos del Banco Central IN-36-005, IN-36-023 e IN-36-024. Donde hubo que elegir un valor porque el código no puede abstenerse, queda registrado como supuesto numerado del Lab y jamás disfrazado de regulación. Si encuentra una cita que no dice lo que afirmamos que dice, avísenos: el formulario de retroalimentación tiene una categoría exactamente para eso.

13Bitácora de cambios

Lo más reciente primero. Una entrada fechada aquí es el aviso que recibe un cambio incompatible.

2026-09-05 - La consola y los formularios hablan tres idiomas

La consola es trilingüe. Inglés, español y francés, con el selector en la cabecera y la elección recordada entre recargas. Cada texto visible sale de un solo diccionario (console/i18n.js); fechas, cifras e importes se formatean con Intl para la configuración regional activa, de modo que un lector francés ve 20 000,00 RD$ donde uno en inglés ve RD$20,000.00. El idioma se fija con ?lang=en|es|fr, que es lo que debe llevar el enlace de una demostración.
Los dos formularios se publican también en francés, en /request-key/fr/ y /feedback/fr/, generados desde los mismos vocabularios que la pasarela valida.
Un formulario rechazado responde ahora con códigos, no con prosa. El arreglo errors de un 422 lleva identificadores estables - organization-required, email-required-to-answer, reference-required - y la página los redacta en el idioma que su lector ya está leyendo. Si su integración comparaba contra las frases en inglés, compare contra los códigos.
El inicio de sesión cae a una redirección cuando el navegador rechaza la ventana emergente, que es lo que hace un perfil corporativo restringido.
Este manual sigue en inglés y español; la edición en francés viene en camino, y la navegación lo dice.

2026-09-05 - Equipos, la Población del Lab, los instructivos y tres correcciones

Corrección, Pagos al Instante. Una orden dada fuera del horario se hace efectiva a las 8:00 a.m. del siguiente día LABORABLE, según la propia página del Banco Central. El Lab venía difiriéndolas a las 07:00 del siguiente día calendario: hora equivocada y clase de día equivocada. Una orden de viernes por la noche se ejecutaba el sábado por la mañana y ahora espera hasta el lunes, es decir, todo el fin de semana. Si su integración afirmaba el comportamiento anterior, esto cambiará sus resultados.
Corrección, los parámetros del SGPI. El crédito final en diez segundos y la disponibilidad 24/7/365 están publicados en la página del SGPI del Banco Central y no son artículos del Reglamento. El catálogo venía citando los Arts. 60-61 junto a ambas cifras; esos artículos establecen el SGPI e indican quiénes deben participar, y no contienen ninguno de los dos números. Ambas reglas citan ahora la página. Un umbral con un artículo al lado que ese artículo no contiene es exactamente el hecho regulatorio fabricado que este catálogo existe para impedir, y este lo era.
Regla nueva, Art. 22. Una entidad de pago electrónico puede mantener los fondos que respaldan los saldos que administra únicamente en su cuenta corriente en el Banco Central, o en valores del Banco Central o del Ministerio de Hacienda pignorados a favor del Banco Central; nunca en un banco comercial. Es una pregunta distinta de si el flotante cubre los saldos, y un flotante puede satisfacer una y quebrantar la otra.
Un hallazgo lleva ahora el instrument al que pertenece el artículo, porque Art. 22 e IN-36-005 numeral 22 son ambos artículos y solo el instrumento indica qué documento debe abrir quien lea.
Un mundo por equipo. La llave de equipo ahora lleva consigo su equipo, y cada equipo recibe un ecosistema aislado: su propia semilla, su reloj, sus libros y su directorio de alias. Un equipo lista sus corridas y las de nadie más.
La llave de equipo abre todo el carril. Antes abría solo el carril de máquinas en una instancia con sesión, lo que impedía por completo que una integración sin interfaz condujera el plano de control. La restricción existía porque una llave era un equipo y un equipo no estaba aislado de nada; ahora una llave alcanza exactamente un mundo, así que desapareció. Es el único cambio de comportamiento que podría afectar a una integración existente, y solo amplía lo que una llave puede hacer.
La Población del Lab. Cada mundo nace con tres bancos, una EPE, el administrador DD/DC, cuatro máquinas, 200 personas, 40 empresas, cuentas, tarjetas, alias y doce adversarios marcados. GET /v1/directory le entrega todo eso.
Endpoints nuevos: GET /v1/directory, POST /v1/worlds/reset, GET /v1/worlds.
26 reglas incorporadas desde los instructivos del BCRD, llevando el catálogo de 48 a 76 junto a las dos correcciones anteriores: el umbral de alto valor de RD$15,800,000, el modelo de prioridad y la prelación de liquidación del LBTR, el barrido de cola al cierre, los techos de disponibilidad de fondeo de las cuentas de pago electrónico, la ventana del tope en días calendario, el flotante de reserva plena, la prohibición de sobregiro y los plazos de reclamación. Las reglas provenientes de los dos instructivos de 2021 llevan needsRecheck.
Este manual, en español e inglés, generado desde las fuentes.

2026-09-04 - Desplegado

La instancia propia del Lab en el proyecto financial-ecosystem: la pasarela en Cloud Run, la consola en Firebase Hosting, los informes en Firestore.
Inicio de sesión en la consola con Firebase Auth, y una lista de permitidos que decide quién puede iniciar una corrida.
Informes detrás de un backend, de modo que un informe sobreviva al reinicio de una instancia.