CEMI · Financial Innovation Lab · 6 de septiembre de 2026
Anexo a la comunicación institucional dirigida al Banco Central de la República Dominicana.

---

Preámbulo

La Simulación del Ecosistema Financiero Virtual es un conjunto de contrapartes simuladas de todo aquello con lo que una aplicación financiera debe hablar en el país —bancos, el LBTR, el SGPI, redes de tarjetas, adquirentes y subadquirentes, entidades de pago electrónico, burós de crédito, identidad, supervisores y la UAF—, que hablan formatos reales, mantienen estado y ejecutan como verificaciones las reglas del Reglamento de Sistemas de Pago, con un informe instrumentado de cada corrida. Están organizadas como el propio Banco Central organiza el sistema real: los sistemas que integran el SIPARD, los participantes que mantienen cuentas en él, los proveedores que el Reglamento reconoce, los instrumentos que clasifica y las entidades de apoyo que los rodean.

Dos precisiones que preferimos hacer nosotros mismos. La primera: la literatura verificada define un gemelo digital como un modelo acoplado en tiempo real al sistema vivo, y hoy esto es una simulación, no un gemelo digital en sentido estricto —todavía no existe un sistema terminado del cual ser gemelo, puesto que el sistema de gestión de pagos instantáneos se está construyendo ahora. Nuestro propósito es llegar a ser el verdadero gemelo digital del ecosistema financiero dominicano a medida que éste toma forma, siguiendo el trabajo y las orientaciones del Banco Central, de la Superintendencia de Bancos y de la industria. La segunda: en el Ecosistema no intervienen proveedores reales, ni usuarios externos reales, ni dinero real, y por tanto no constituye un «ambiente de prueba» de los que el Artículo 83 del Reglamento somete a la no objeción del Banco Central; nunca lo presentaremos como tal ni como sustituto de ella.

De una disciplina del Lab nace este anexo: nunca enunciar un hecho regulatorio sin su cita. Donde el código no podía diferir la decisión —porque un programa no puede abstenerse de elegir un valor— la elección se registra como supuesto del Lab, no se disfraza de norma. Los tres instructivos vigentes (IN-36-005 del sistema LBTR, IN-36-023 de administradores y adquirentes, IN-36-024 de entidades y cuentas de pago electrónico) fueron leídos íntegramente, página por página, el 5 de septiembre de 2026. Los once puntos que siguen quedaron abiertos después de esa lectura: los documentos remiten la respuesta a una Circular de la Gerencia, a las normas de funcionamiento de cada sistema, a la Guía de Operaciones o a un instructivo aún no publicado. Cada supuesto está declarado en el catálogo público de reglas, cada regla que depende de uno lo cita, y el informe de cada corrida nombra los supuestos bajo los cuales se ejecutó. Una respuesta de la institución —aun preliminar, aun de criterio técnico— reemplaza un supuesto del Lab por un parámetro fundado.

---

1. Calendario de días hábiles y horarios de liquidación (supuesto A-01)

El punto. Toda regla de reloj del simulador —cortes, ejecución al siguiente día hábil, ventanas operativas— se evalúa contra un calendario y un desfase horario local.

Lo que dicen los instructivos. IN-36-005, p. 28 numeral 93: «El sistema LBTR operará todos los días hábiles de acuerdo con la regulación vigente para sus operaciones regulares y en horario extendido para el servicio de Pagos al Instante BCRD», y su Párrafo: «En el caso de las operaciones de Pagos al Instante BCRD, el sistema LBTR operará los días calendario». Los horarios mismos quedan diferidos: la Gerencia del Banco Central los informará «mediante Circular» (numeral 95), con cinco días hábiles de anticipación a toda modificación (numeral 95 Párrafo II). IN-36-023, p. 12-13 numeral 12 b) i, hace del «Incumplimiento de los ciclos de horarios de sus sistemas» un hecho de reporte inmediato, pero no publica ciclo alguno.

Lo que el simulador supone. Hora local UTC−4 sin horario de verano y una lista de feriados que cada escenario declara, vacía por defecto. Sin correspondencia entre hora local e instante simulado no puede evaluarse ventana alguna, y un desfase equivocado las movería todas por horas.

La consulta. ¿Qué calendario de días hábiles y feriados observan el LBTR y los sistemas de compensación, y dónde se publica cada año? ¿Puede el Lab conocer, aunque sea de forma indicativa y a los solos fines de la simulación, los horarios que la Circular de la Gerencia establece?

2. Estructura del número de cuenta estandarizado (supuesto A-02)

El punto. La resolución de alias y la validación de cuentas siguen la estructura del número de cuenta.

Lo que dicen los instructivos. Ninguno de los tres menciona el número de cuenta estandarizado regional ni la Novena Resolución del 18 de noviembre de 2010. El único estándar de identificación nombrado es el BIC bajo ISO 9362 (IN-36-005, p. 3 g)), exigible incluso a quienes no usan SWIFT: «Los participantes no usuarios de la plataforma SWIFT, deben poseer un código de identificación bancaria (BIC, por sus siglas en inglés) de usuario no conectado a la Red de Comunicaciones SWIFT» (p. 23 numeral 75).

Lo que el simulador supone. Un número de cuenta de laboratorio de veinticuatro caracteres, con prefijo LB —deliberadamente no DO, para que jamás pueda confundirse con uno real—, dos dígitos de control ISO 7064 mod 97-10, un código de institución y dieciséis dígitos: se necesitaban anchos fijos, dígito de control y componente de institución para que la validación y el enrutamiento se ejerciten.

La consulta. ¿Está publicada la estructura de campos del número de cuenta estandarizado, y puede reproducirse en un simulador bajo un prefijo distinto del país? ¿Debe el catálogo incorporar además la exigencia de BIC para cada participante simulado?

3. Códigos de motivo de devolución de débitos y créditos directos (supuesto A-04)

El punto. Una regla del catálogo obliga a que toda devolución viaje con un código de motivo. La obligación es del Reglamento; el vocabulario es nuestro.

Lo que dicen los instructivos. IN-36-023 no contiene tabla alguna de códigos de devolución. Su única taxonomía vecina es la tipificación de las reclamaciones en dos clases (p. 9 numeral 10 f) iv), en un registro auditable, según sean «Atribuibles a errores operacionales o tecnológicos» o «Derivadas de reclamaciones realizadas por los clientes». Lo más cercano a un vocabulario real es la lista de rechazos del LBTR —«Entre los motivos de rechazos están los siguientes» (IN-36-005, pp. 11-12 numeral 19 g))—, que es otra cosa: validación de mensajes en el LBTR, no devolución de un débito directo, y declarada no exhaustiva.

Lo que el simulador supone. Seis códigos de convención propia (fondos insuficientes, cuenta cerrada, cuenta inexistente, número inválido, ausencia de mandato, solicitud del originador), escritos para que el flujo exista. La forma —código breve más razón legible, viajando con la partida devuelta y hacia el registro del originador— sobrevivirá al cambio de vocabulario.

La consulta. ¿Publica el Banco Central, o corresponde a cada administrador publicar en sus normas de funcionamiento, la lista de códigos de motivo de devolución que los sistemas reales utilizan? De existir, ¿puede el Lab adoptarla?

4. Correspondencia entre la falla del participante y el código de devolución (supuesto A-05)

El punto. El administrador simulado convierte una falla en la institución receptora en una devolución codificada.

Lo que dicen los instructivos. La misma ausencia del punto 3. Lo que IN-36-024 sí confirma es la conducta que dos de nuestros códigos expresan: la solución debe tener «Capacidad de rechazar el fondeo de cuentas cuando exceda el límite establecido para el usuario» (p. 11 numeral 19 d)), y el instrumento «no permitirá sobregiros en caso de fondos insuficientes … En este último caso, la orden de pago será rechazada» (p. 11 numeral 20).

Lo que el simulador supone. Una correspondencia directa entre falla y código, con un código para el exceso del tope regulatorio inventado por el Lab precisamente porque una cuenta que excedería el tope del Artículo 78 numeral II no está cerrada. Toda otra falla recae en «número de cuenta inválido», respaldo aproximado que declaramos como tal.

La consulta. ¿A qué condiciones de error corresponde cada código de la lista real? En particular, ¿existe uno para el rechazo por exceso del tope de la cuenta de pago electrónico, distinto del de cuenta cerrada?

5. Versión y perfil de ISO 8583 para el carril de tarjetas (supuesto A-07)

El punto. El carril de tarjetas del Ecosistema reserva un subconjunto de mensajes y elementos de datos.

Lo que dicen los instructivos. ISO 8583 no se menciona. Los únicos estándares de tarjetas nombrados son de seguridad: IN-36-023, p. 7 numeral 7 y p. 19 numeral 29, exigen evidencia de cumplimiento de «PCI-DSS», «Seguridad de Transacciones con PIN (PCI-PTS)» y «Seguridad para Aplicaciones de Pago (PA-DSS)».

Lo que el simulador supone. Un conjunto de tipos de mensaje y doce elementos de datos, porque el host de cajeros, el adquirente y los procesadores necesitaban un contrato contra el cual implementar. Los números de campo son del propio estándar; la selección es una conjetura del Lab.

La consulta. ¿Qué versión de ISO 8583 y qué perfil de elementos de datos utilizan el conmutador doméstico y las marcas que operan en el país? Entendemos que la respuesta puede corresponder a cada red; agradeceríamos en tal caso la orientación sobre a quién dirigirla.

6. Esquema de seguridad de los mensajes (supuesto A-08)

El punto. La capa de comunicaciones del Ecosistema exige mensajes firmados y con sello de tiempo.

Lo que dicen los instructivos. Ningún esquema de seguridad de mensajes se publica. IN-36-005, p. 22 numeral 71, muestra un modelo distinto del que el Lab implementó: los tokens y dispositivos de acceso son suministrados y configurados exclusivamente por el Banco Central, con cargo a la cuenta corriente del participante — una credencial que el administrador emite, no una firma que el participante calcula. La mensajería real se apoya en la red SWIFT dentro del grupo cerrado de usuarios del país (p. 23 numeral 73), en la VPN privada del Banco Central para participantes no SWIFT (p. 23 numeral 74) y en archivos XML sobre SRIF (p. 21 numeral 68); los formatos viven en la Guía de Operaciones y las operaciones se identifican por un código TRN notificado por el Departamento de Sistemas de Pagos (p. 28 numerales 94-95).

Lo que el simulador supone. Una firma HMAC-SHA256 sobre una serialización canónica, con clave derivada de la semilla de la corrida. No es un control de seguridad y así se declara: hace detectable una traza alterada y mantiene las corridas reproducibles. Nada en el Ecosistema debe protegerse jamás con una clave real.

La consulta. ¿Qué esquema de seguridad de mensajes —firma, sello de tiempo, autoridad certificadora, o el modelo de token suministrado por el Banco Central— se exigirá a los participantes en los sistemas del SIPARD, y en particular en el SGPI?

7. Inicio del plazo de Pagos al Instante y conducta fuera del horario (supuesto A-10)

El punto. La regla de nivel de servicio de Pagos al Instante y la conducta de una orden instruida fuera de la ventana.

Lo que dicen los instructivos. El plazo de ocho minutos no aparece en los tres documentos. IN-36-005, p. 16 numeral 33 d) ii, obliga a notificar al cliente la «No aceptación o tramitación en el plazo establecido», sin fijar el plazo. Sí aparece una consecuencia, p. 16 numeral 34 Párrafo: «En caso de no aplicarse la transferencia o el pago en el plazo establecido, por razones atribuibles a la entidad originadora o receptora de este, el cliente originador recibirá la reversión automática del cargo por concepto de tarifa, debiendo ser cubierto por la entidad en incumplimiento».

Lo que el simulador supone. Que los ocho minutos —figura de la página pública del Banco Central sobre Pagos al Instante, no del Reglamento— corren desde la aceptación dentro de la ventana y no desde la instrucción, porque medir desde la instrucción haría fallar a toda orden diferida una regla que no incumplió; y que una orden instruida fuera del horario se hace efectiva a las 08:00 del siguiente día hábil, tratando la pausa de media tarde igual que la noche. Esto último es una inferencia nuestra sobre la expresión «fuera del horario», y como inferencia queda registrada.

La consulta. ¿Desde qué instante corre el plazo: desde la aceptación por la entidad originadora, desde la recepción en el LBTR, o desde otro momento? ¿Y las órdenes dadas fuera del horario, incluidas las dadas durante la pausa de la tarde en día laborable, se hacen efectivas todas a las 08:00 del siguiente día hábil?

8. Instante de referencia del plazo de acreditación a terceros del Artículo 57 (supuesto A-11)

El punto. La regla que verifica la acreditación al beneficiario dentro del plazo del Artículo 57.

Lo que dicen los instructivos. El plazo de cuatro minutos no aparece. Pero IN-36-024, p. 11 numeral 23, muestra cómo ancla el Banco Central esta clase de plazos cuando fija uno: la disponibilidad por fondeos con acreditación diferida debe efectuarse «A más tardar 2 (dos) horas luego de su liquidación, cuando se abonen a través de instrumentos de pagos electrónicos» y «A más tardar 30 (treinta) minutos luego de la acreditación del cheque». El ancla es la liquidación, no la instrucción.

Lo que el simulador supone. Que el plazo corre desde el instante en que la orden liquida —cuando la cuenta corriente del participante receptor resulta afectada— hasta que la institución receptora ha acreditado al beneficiario. Es la lectura que el numeral 23 respalda por analogía, lo cual no equivale a estar respaldada por el artículo.

La consulta. ¿Desde qué instante se cuenta el plazo del Artículo 57: desde la aceptación en el emisor, desde la recepción en el sistema, desde la afectación de la cuenta del participante receptor, o desde el acuse de éste?

9. Anclaje del período de treinta días del tope de fondeo (supuesto A-12)

El punto. El tope de fondeo de la cuenta de pago electrónico dentro de un período de treinta días.

Lo que dicen los instructivos. IN-36-024, p. 10 numeral 18 b), resuelve la unidad y añade dos deberes: la solución debe almacenar y permitir descargar la «Disponibilidad respecto al límite de emisión o fondeo permitido dentro del período de 30 (treinta) días calendario en que se encuentre, así como las notificaciones al usuario cuando este tope sea alcanzado»; y p. 11 numeral 19 d) exige la «Capacidad de rechazar el fondeo de cuentas cuando exceda el límite establecido para el usuario».

Lo que el simulador supone. Días calendario, ya corregido a partir de este numeral y contado sobre fechas locales; el simulador expone la disponibilidad restante, notifica al alcanzarse el tope y rechaza el fondeo que lo excede. Queda abierto si el período es móvil —anclado en cada instante de evaluación, lectura conservadora y la que aplicamos— o fijo: «el período de 30 días calendario en que se encuentre» se lee con más naturalidad como un período vigente dentro del cual la cuenta se halla.

La consulta. ¿El período de treinta días calendario es móvil respecto de cada fondeo, o fijo respecto de un ciclo? En el segundo caso, ¿desde qué evento comienza — la apertura de la cuenta, el primer fondeo, el inicio del mes calendario?

10. Participantes obligatorios del SGPI (supuesto A-13)

El punto. Las reglas de admisión de participantes y el elenco de contrapartes simuladas del carril de pagos instantáneos.

Lo que dicen los instructivos. El Artículo 61 numeral I no se reproduce en ninguno de los tres documentos. Lo que IN-36-005 confirma es contiguo y prudente traer a su lectura: «La participación de las entidades de intermediación financiera en el sistema LBTR es obligatoria, tal como lo dispone la Ley Monetaria y Financiera» (p. 8 numeral 5), mientras que las entidades de pago electrónico y las empresas de adquirencia se incorporan sujetas a autorización de la Junta Monetaria (p. 9 numeral 6), disponiendo unas y otras de hasta 45 días hábiles para iniciar operaciones. Para el LBTR, entonces, los roles no son simétricos — razón para no presumir que lo sean para el SGPI.

Lo que el simulador supone. Que son participantes obligatorios los roles de banco, entidad de pago electrónico, adquirente y subadquirente, transcribiendo el Artículo 61 numeral I. El supuesto está sólo en que el rol de banco corresponde exactamente a la entidad de intermediación financiera y en que ningún otro rol modelado cae dentro del artículo.

La consulta. ¿Qué entidades deben incorporarse obligatoriamente al SGPI, y en qué plazo? ¿Quedan dentro o fuera los administradores de redes de cajeros, los proveedores de billeteras, los proveedores de iniciación de pagos y los proveedores de pasarela?

11. Vocabulario de operaciones de la cuenta de pago electrónico (supuesto A-15)

El punto. Los registros y los reportes al supervisor y a la UAF nombran cada operación de la cuenta de pago electrónico con una etiqueta.

Lo que dicen los instructivos. IN-36-024 exige que las «Operaciones permitidas» se muestren al titular (p. 10 numeral 18 d)) pero nunca las enumera: ni la lista del Artículo 20 ni denominación alternativa alguna aparece, y las remesas entrantes y los subsidios sociales no se mencionan. Sí queda confirmado, p. 9 numeral 13, que «Las cuentas de pago electrónico serán emitidas y gestionadas en moneda nacional a favor de una persona física o jurídica», exigencia que el catálogo ya incorpora.

Lo que el simulador supone. Una transcripción de la lista del Artículo 20 —retiro en efectivo, crédito directo, débito directo, punto de venta, retiro en cajero, comercio electrónico, recargas, pago de servicios, remesas entrantes y subsidios sociales— con etiquetas de nomenclatura propia, agrupando las recargas de voz y datos en una sola. Un depósito sin etiqueta cae en un valor por defecto que existe únicamente para que la llamada falle de forma visible contra el vocabulario, y no en silencio.

La consulta. ¿Existe un vocabulario publicado de operaciones de la cuenta de pago electrónico, para efectos de registro y de reporte? De no existir, ¿tiene el Banco Central preferencia por una denominación, de cara a los reportes que la entidad debe remitir?

---

12. El estándar de código QR y las normas de funcionamiento del SGPI

El Artículo 78 numeral IV exige a todo proveedor presentar y leer un código QR con los datos necesarios para iniciar una orden de pago, conforme a un estándar que el Banco Central fijará por instructivo. Ese instructivo no está publicado y el código QR no se menciona en ninguno de los tres leídos. El Lab no inventa el estándar: construye un perfil propio, lo declara como tal dentro de la propia carga útil, y mantiene en el catálogo una regla que comenzará a fallar el día en que el instructivo se publique y algo siga presentando el perfil del Lab. Del mismo modo, la proyección de mensajes que el Ecosistema utiliza para transferencias es un contrato del Lab y no una guía de uso dominicana, que no existe entre las fuentes leídas.

La consulta. Cuando el instructivo del código QR y las normas de funcionamiento del SGPI se publiquen, el catálogo de reglas los adoptará. Una lectura temprana, aunque sea en borrador y sin carácter vinculante, permitiría que el simulador se alinee antes que el mercado — que es exactamente el valor que este trabajo puede prestar.

13. Un asiento en la Fase 0 y la función de vigilancia

La invitación que la carta formula se concreta aquí: que el Banco Central tome asiento ahora en el Ecosistema, en la especificación, que es la que decide qué reglas se ejecutan y cómo — con sus instructivos, su lectura del Reglamento de Sistemas de Pago (Segunda Resolución de la Junta Monetaria del 28 de agosto de 2025, con los valores ajustados por la Quinta Resolución del 29 de enero de 2026) y los escenarios que la institución considere prioritarios. Entendemos que la función de vigilancia sobre el SIPARD, los sistemas de bajo valor y los proveedores (Artículos 45 a 51), separada del rol de administración (Artículo 48), es el interlocutor natural para este trabajo. Preferimos construirlo con la autoridad desde el primer catálogo de actores y de reglas, y no mostrárselo terminado.

14. Confirmación sobre el Artículo 83

Sometemos a confirmación expresa la posición que el Lab ya sostiene y publica: que una corrida en el Ecosistema simulado —sin proveedores reales, sin usuarios externos reales y sin dinero real— no constituye un «ambiente de prueba» de los que el Artículo 83 somete a la no objeción del Banco Central, y que, cuando un proveedor autorizado sí deba solicitar esa no objeción, el informe instrumentado de una corrida puede servirle únicamente de evidencia —descripción, esquema operativo, participantes y entidades de apoyo, insumos para el análisis de materialidad del riesgo—, nunca de sustituto. Preparamos evidencia; la decisión es y seguirá siendo del Banco Central. Si el criterio de la institución fuera otro, el Lab ajustará su posición pública y su documentación de inmediato.

---

Segunda parte — Activos virtuales, dinero tokenizado y registros distribuidos

Los once puntos anteriores nacen de la lectura íntegra de los tres instructivos vigentes. Los seis que siguen son de otra naturaleza y lo declaramos de entrada: nacen de la lectura íntegra del propio Reglamento, no corresponden a ningún componente construido y el Lab no propone construirlos antes de conocer el criterio de la institución. Se someten porque, al releer el Reglamento término por término el 6 de septiembre de 2026, encontramos algo que nuestra propia documentación anterior daba por inexistente, y corregirlo en silencio sería contrario a la disciplina que este anexo declara.

La corrección, primero. Sosteníamos que el Reglamento de Sistemas de Pago no contenía disposición alguna sobre activos virtuales. Es inexacto. El Artículo 4, literal a), define el activo virtual como «Representación digital de valor que puede comercializarse o transferirse digitalmente y utilizarse para fines de pago o inversión, sin que en ningún caso se entienda como activo virtual a la moneda de curso legal en el territorio nacional, las divisas ni cualquier otro activo»; y siete artículos de obligaciones repiten, con idéntica redacción, el deber de «No ofrecer productos ni servicios basados en activos virtuales» — Artículo 11 v) para el administrador de un sistema de pago o de liquidación de valores, 17 w) para la entidad de pago electrónico, 31 t) para la empresa de adquirencia, 33 l) para la de subadquirencia, 35 p) para el administrador de una red de cajeros automáticos, 37 j) para el proveedor de billetera digital y 39 l) para el proveedor de servicios de iniciación de pago. Lo que sí es exacto es que las palabras «token», «DLT», «cadena de bloques» y «distribuido» no aparecen en ninguna de las setenta y tres páginas, y que ninguno de los tres instructivos leídos menciona la materia. El catálogo de reglas del Lab incorporará la prohibición como regla ejecutable, citando sus siete artículos; es la única parte de esta materia que puede citar un artículo del Reglamento, y por eso es la única que construiremos sin esperar respuesta.

Y una segunda corrección, del 7 de septiembre de 2026, que nos obliga a rectificar también el alcance de la primera. Sosteníamos, además, que la posición dominicana publicada sobre activos virtuales era la del Banco Central. Tampoco es exacto. La Circular Núm. 04/23 de la Superintendencia del Mercado de Valores, del 9 de marzo de 2023, informa al mercado y al público que «actualmente no existen regulaciones oficiales en la República Dominicana para la oferta o promoción de activos virtuales o criptoactivos u otros activos similares, o de unidades de valor denominadas «tókenes»» y que «los activos virtuales no son regulados ni supervisados por la Superintendencia del Mercado de Valores ni otra autoridad competente de la República Dominicana»; y reitera a los intermediarios de valores que «no podrán invertir ni realizar actividades de intermediación con activos virtuales, aún si tales instrumentos son reconocidos como valores en otras jurisdicciones, de conformidad a lo establecido en el artículo 121 del Reglamento para los Intermediarios de Valores». La circular no llegó a nuestra lectura anterior porque el sitio de la Superintendencia rechaza el acceso automatizado; se leyó íntegra el 7 de septiembre de 2026 desde la copia que el Internet Archive conserva del propio archivo de la institución, y su existencia y objeto constan además en la Guía para la Regulación ALA/CFT de Activos Virtuales y PSAV del GAFILAT, de agosto de 2023.

Existen, por tanto, dos prohibiciones dominicanas sobre activos virtuales, de dos supervisores, sobre dos poblaciones distintas de proveedores y con redacciones distintas. De ahí nace el punto 20 de este anexo, que es nuevo. Registramos también, con el mismo criterio, que el propio Banco Central sí ha publicado investigación sobre moneda digital de banca central —el Documento de Trabajo 2025-01, que declara expresamente que «esta agenda de investigación no implica una decisión institucional acerca de si se emitirá o no una CBDC en el país»—, extremo que nuestra documentación anterior daba por inexistente; el Lab no atribuye a la institución intención alguna a partir de ello, y así lo dice en su propio texto.

15. Alcance de la prohibición de productos basados en activos virtuales (Artículos 11 v, 17 w, 31 t, 33 l, 35 p, 37 j y 39 l)

El punto. El simulador debe decidir cuándo un proveedor simulado está obligado a rechazar, y el disparador del rechazo no es evidente en el texto.

Lo que dice el Reglamento. La obligación es de no ofrecer productos ni servicios basados en activos virtuales. No dice si alcanza al proveedor que únicamente recibe una instrucción cuya pata de fondeo fue un activo virtual en el exterior, ni si alcanza a quien presta un servicio a un tercero que sí los ofrece. Observamos además que el proveedor de pasarela de pago es el único proveedor reconocido que no tiene artículo de obligaciones —el Artículo 91 sólo impone a otros notificar al Banco Central el contrato con uno— y que, por tanto, la prohibición no lo alcanza en el texto.

Lo que el simulador supone. Nada todavía: la regla está escrita para el supuesto estrecho —ofrecer el producto— y el supuesto amplio queda sin modelar hasta conocer el criterio.

La consulta. ¿Alcanza la prohibición a quien únicamente recibe una orden fondeada en el exterior con un activo virtual? ¿Es deliberada la ausencia de la prohibición en el régimen del proveedor de pasarela de pago?

Añadido el 7 de septiembre de 2026: la prohibición del Reglamento ya no es la única del ordenamiento. La Circular 04/23 de la Superintendencia del Mercado de Valores impone a los intermediarios de valores un deber distinto —no invertir ni intermediar— con otra redacción y otro artículo. La pregunta sobre el disparador debe formularse, por tanto, sobre ambos instrumentos, y su interacción es el punto 20 de este anexo.

16. Si el régimen de la cuenta de pago electrónico alcanza a un instrumento registrado en un libro distribuido

El punto. El Artículo 19 otorga a la cuenta de pago electrónico tres propiedades —balance igual al valor nominal recibido, ausencia de intereses y devolución a solicitud del titular en cualquier momento y sin penalidad— que son, término por término, las mismas que exigen a una moneda estable de pago el Reglamento (UE) 2023/1114 en su Artículo 49 y la Ley Pública 119-27 de los Estados Unidos en su Sección 4(a)(11). El Reglamento dominicano llegó a ellas antes y por otro camino.

Lo que dice el Reglamento. El Artículo 78 clasifica los instrumentos de pago electrónicos en una lista cerrada de tres: transferencias electrónicas de fondos, tarjetas de pago y cuentas de pago electrónico. Un instrumento al portador registrado en un libro distribuido no figura en ninguna de las tres líneas. El Artículo 4 a) define el activo virtual con una exclusión expresa de la moneda de curso legal y de las divisas.

Lo que el simulador supone. Nada. Es precisamente la pregunta cuya respuesta decide si un instrumento así se modela dentro del carril existente de cuentas de pago electrónico o como una contraparte fuera de todo perímetro dominicano.

La consulta. Un instrumento con las tres propiedades del Artículo 19, registrado en un libro distribuido y transferible entre tenedores: ¿es una cuenta de pago electrónico de los Artículos 19 a 25, un instrumento ajeno a la lista cerrada del Artículo 78, o un activo virtual del Artículo 4 a)?

17. Si una entidad de pago electrónico podría emitirlo, y dónde estaría su respaldo

El punto. Dónde se mantiene el respaldo es la única decisión de diseño que el simulador no puede tomar sin equivocarse de institución.

Lo que dice el Reglamento. El Artículo 22 es más exigente que la mayoría de los regímenes internacionales de moneda estable, y ya está vigente: los fondos de las cuentas de pago electrónico gestionadas por entidades de pago electrónico «deberán estar depositados en una cuenta corriente en el Banco Central a favor de dicha entidad o en valores emitidos por el Banco Central o el Ministerio de Hacienda, pignorados a modo de garantía a favor del Banco Central… Dichos fondos estarán separados del patrimonio de la entidad». El Artículo 21 fija el tope de fondeo y de balance en un período de treinta días calendario, ajustado anualmente por la Junta Monetaria.

Lo que el simulador supone. Que el respaldo de un emisor simulado se mantiene como un balance real en un banco simulado del ecosistema —convención del Lab, tomada de los perfiles de referencia extranjeros y declarada como tal—, porque el Artículo 22 no alcanza a un emisor que no es entidad de pago electrónico.

La consulta. De estar el instrumento dentro del régimen, ¿alcanzaría el Artículo 22 a su respaldo, y le sería aplicable el tope del Artículo 21?

18. Si un proveedor de servicios de activos virtuales es sujeto obligado

El punto. El ecosistema ya tiene una unidad de análisis financiero simulada y una unidad de monitoreo que leen los registros que los Artículos 41 a 44 hacen disponibles. Lo que no puede decidir por sí mismo es bajo qué norma reporta un proveedor de servicios de activos virtuales simulado.

Lo que dice el Reglamento y lo que dice la Ley. El Artículo 43 extiende las obligaciones de la Ley 155-17 a los proveedores de servicios de pago y a los participantes del SIPARD; un proveedor de servicios de activos virtuales no es ninguno de los dos en la taxonomía del propio Reglamento. En la Ley 155-17, los Artículos 32 y 33 no lo enumeran entre los sujetos obligados financieros ni no financieros. El Artículo 32, Párrafo I, sí prevé la vía: «Reglamentariamente, el Comité Nacional Contra el Lavado de Activos podrá incluir como sujetos obligados a quienes realicen otras actividades no incluidas en la presente ley».

Lo que el simulador supone. Que la conducta de prevención de un proveedor así es un control del Lab tomado de un perfil de referencia extranjero, declarado como tal en cada hallazgo, y jamás una regla dominicana.

Lo que hemos podido establecer desde entonces, y que no responde la consulta. El Informe Estadístico 2025 de la Unidad de Análisis Financiero sitúa las «transacciones que involucran criptoactivos» dentro de la categoría residual de motivos de reportes de operaciones sospechosas —expresamente la de los delitos «que presentaron una frecuencia inferior a un 1%»— y consigna Activos Virtuales como uno de los temas de una jornada de concienciación de la institución. El GAFILAT registra, por su parte, que en 2021 la República Dominicana incluyó un módulo sobre activos virtuales y sus proveedores en la actualización de su Evaluación Nacional de Riesgos. Son señales de atención institucional, no de derecho positivo, y las citamos precisamente para no confundir una cosa con la otra.

La consulta. ¿Es un proveedor de servicios de activos virtuales sujeto obligado bajo la Ley 155-17 y sus reglamentos de aplicación? ¿Qué organismo de supervisión recibiría sus registros a los fines del Artículo 44?

19. Depósitos tokenizados y una ficha mayorista de liquidación

El punto. Un depósito tokenizado es la misma obligación de la misma entidad supervisada, transferible por otro carril. La pata interbancaria de esa transferencia liquidaría, si liquidase en algún sitio, en el LBTR.

Lo que dice el Reglamento. Nada sobre la materia. El Artículo 79 sí dispone que la liquidación de los resultados de cada ciclo de compensación de los sistemas de instrumentos de pago electrónicos se realiza a través del sistema LBTR, y los Artículos 60 a 62 hacen indelegable la administración del sistema de gestión de pagos instantáneos.

Lo que el simulador supone. Nada, y lo declaramos con especial cuidado en el segundo extremo de esta consulta: el Lab no atribuye al Banco Central ninguna intención, estudio ni posición sobre una ficha de banca central. Nada de lo publicado por la institución que hemos leído menciona la materia, y una eventual representación de una ficha mayorista existiría únicamente dentro de un mundo declarado como hipótesis del Lab, con nombre propio de laboratorio y un aviso adicional en la cabecera de todo informe.

La consulta. ¿Tiene el Banco Central un criterio sobre una obligación de depósito de una entidad de intermediación financiera supervisada hecha transferible en un libro distribuido, y sobre la liquidación de su pata interbancaria en el LBTR? Y —formulado como pregunta y en ningún caso como sugerencia— ¿prefiere la institución que la simulación no represente una ficha mayorista de liquidación en absoluto?

20. Qué negativa gobierna qué objeto, y si alguna alcanza a la población de la otra

(Punto nuevo, 7 de septiembre de 2026, nacido de la segunda corrección del preámbulo de esta parte.)

El punto. Un simulador debe decidir, ante una carga útil, por qué rama del ordenamiento entra. Hoy conviven dos negativas dominicanas sobre poblaciones distintas y con redacciones distintas, y el Lab no puede resolver por sí mismo cómo se articulan.

Lo que dicen los instrumentos. El Reglamento de Sistemas de Pago prohíbe a siete categorías de proveedores «ofrecer productos ni servicios basados en activos virtuales» (Artículos 11 v, 17 w, 31 t, 33 l, 35 p, 37 j y 39 l), sobre la definición del Artículo 4, literal a). La Circular Núm. 04/23 de la Superintendencia del Mercado de Valores, del 9 de marzo de 2023, reitera a los intermediarios de valores que «no podrán invertir ni realizar actividades de intermediación con activos virtuales, aún si tales instrumentos son reconocidos como valores en otras jurisdicciones, de conformidad a lo establecido en el artículo 121 del Reglamento para los Intermediarios de Valores». Los verbos son distintos —ofrecer frente a invertir o intermediar—, las poblaciones son distintas, y la circular está redactada de modo que una calificación extranjera del instrumento no la desactive.

Lo que el simulador supone. Nada. La regla ejecutable que construiremos cita únicamente los siete artículos del Reglamento y jamás fundirá en ella el instrumento del regulador de valores: un informe del sistema de pagos no debe mostrar nunca un hallazgo citando a la Superintendencia del Mercado de Valores.

La consulta. ¿Un instrumento que fuese valor conforme a la Ley 249-17 queda bajo el régimen de la Superintendencia del Mercado de Valores en lugar del Artículo 4, literal a), del Reglamento, o bajo ambos? ¿Una entidad de intermediación financiera que sea a la vez intermediario de valores queda alcanzada por los dos deberes simultáneamente? ¿Entiende el Banco Central que ambas prohibiciones son acumulativas, o que cada una se circunscribe a la actividad que su propio instrumento regula? Un criterio técnico, aun preliminar, nos basta.

---

Cómo el Lab incorporará las respuestas

Cada respuesta del Banco Central, cualquiera sea su forma, se incorporará del mismo modo y con la misma disciplina:

1. El supuesto correspondiente del registro público de supuestos deja de ser un supuesto del Lab y pasa a citar la respuesta de la institución, con su fecha.
2. Cada regla del catálogo que dependía de él se revisa, y su campo de fuente pasa a nombrar la respuesta del Banco Central en lugar de la convención del Lab.
3. La revisión queda publicada en el catálogo público de reglas con su versión, de modo que el informe de cualquier corrida anterior siga siendo legible contra los supuestos bajo los cuales se ejecutó, y cualquier corrida posterior lo sea contra la respuesta de la autoridad.
4. Donde una respuesta contradiga lo que el simulador hace hoy, el cambio se implementa y se declara como corrección, no como ajuste silencioso.

Ninguna respuesta del Banco Central se presentará jamás como aval, certificación ni conformidad regulatoria del Lab, de una corrida o de un tercero. Se presentará por lo que es: la fuente de un parámetro que hasta hoy tuvimos que suponer.

Quedamos a la entera disposición de la institución para ampliar cualquiera de estos puntos, presentar el Ecosistema a sus equipos técnicos, o recibir estas respuestas en el formato y por la vía que el Banco Central estime apropiados.

Con el mayor respeto,

Carlos Miranda Levy
Coordinador de las Inteligencias Aumentadas de CEMI.ai
CEMI · Financial Innovation Lab
partners@cemi.ai