Migración incremental,
sin apagar nada.
Cómo el CMS entra primero como plano de control y después como plano de transacción.
Siete fases reversibles a lo largo de 24 meses. En ninguna de ellas se corta el servicio, y en todas se puede volver atrás con un cambio en la tabla de enrutamiento. La sustitución del procesador actual es la última consecuencia del proceso, nunca su primer paso.
Por qué la migración tiene que ser incremental
No es una preferencia de método. Son tres restricciones simultáneas que descartan cualquier sustitución de golpe.
Las certificaciones tardan más que el proceso
SOC 2 Tipo II exige una ventana de observación de 6 a 12 meses; el informe de PCI-DSS Nivel 1, entre 6 y 9. PROSA, E-Global, VISA VAP y Mastercard Processor tienen sus propios calendarios. Ninguna se obtiene dentro del plazo de un RFP.
Hay una cartera viva de más de 200,000 clientes
Una migración de golpe pone en riesgo, el mismo día, la autorización de todo el portafolio. El costo de una hora de declinaciones masivas no se compara con el de un proyecto más largo.
El procesador actual sigue operando
Cualquier plan que dependa de apagarlo en una fecha concreta hereda todos los riesgos de esa fecha. La convivencia prolongada no es una debilidad del plan: es su mecanismo de seguridad.
Plano de control antes que plano de transacción
Un procesador se sustituye por el camino difícil: el tráfico. Un CMS entra por el camino fácil: la administración. Y una vez dentro, el tráfico lo sigue.
Observar
El CMS ingiere los archivos y las bitácoras del procesador actual. No decide nada. Aporta visibilidad y deja la primera evidencia comparable, con riesgo cero.
Gobernar
El CMS pasa a ser el registro de verdad de tarjetas, productos, BINes, reglas y límites, y empuja esos parámetros al procesador actual. El tráfico sigue igual; el control ya cambió de manos.
Autorizar
Solo entonces el autorizador empieza a recibir tráfico: primero una copia en sombra, después un BIN piloto y después cohortes. Cada paso se revierte cambiando una regla de enrutamiento.
Lo que hace reversible cada paso
Los componentes de la plataforma
Qué existe hoy, qué está especificado y qué está por construir. El estado real, no el deseable: es lo que determina en qué fase puede entrar cada pieza.
CMS de tarjetas
33 módulos: emisión, ciclo de vida, tokenización, reglas y límites, disputas, cumplimiento del CID, liquidación y reportería. Es la pieza que entra primero.
Scoring crediticio
Desplegado y conectado al core: puntaje, banda, monto por capacidad de pago, CAT, reserva preventiva y dictamen. Evalúa clientes reales hoy.
Switch ISO 8583
Mensajería 1987 con jPOS y DUKPT verificado. Faltan la variante 1993, los tokens del campo 63 y los adaptadores a PROSA y E-Global.
Autorizador
Motor de reglas y límites del lado emisor. Falta el perfil adquirente y la medición de latencia sobre arquitectura productiva.
Portal de APIs
272 endpoints documentados a nivel funcional en 16 dominios. Faltan el contrato OpenAPI y los SDK.
Liquidación en pesos
Ciclo D+1 por SPEI, separación contable de fondos, reservas por comercio y conciliación en formatos TC46, MCBS y PROSA.
Entidad comercio
Alta digital con KYB mexicano, monitoreo de comportamiento, umbrales VAMP y MATCH, y el modelo PAYFAC con sub-comercios.
Cumplimiento del CID
34 capítulos y 152 anexos trazados como reglas del producto, con motor de plazos y evidencia sellada. Diseñado; su construcción es parte de la propuesta.
Cómo se mueve el tráfico, fase por fase
Las gotas representan la proporción de autorizaciones que atiende cada plataforma. El color ámbar indica tráfico en sombra: Alodiga recibe una copia y decide en paralelo, pero su decisión no se aplica.
Las siete fases, con su criterio de salida
No se avanza de fase por calendario. Se avanza cuando la métrica de la fase anterior cruza su umbral, y se retrocede si deja de cumplirlo.
Cómo se vuelve atrás en cada fase
La pregunta que decide un proyecto de migración no es qué pasa si sale bien, sino qué pasa a las tres de la madrugada cuando sale mal.
| Fase | Qué puede fallar | Cómo se revierte | Tiempo de vuelta |
|---|
Las certificaciones corren mientras la migración avanza
Esta es la razón de fondo por la que la migración incremental no es solo más segura, sino la única viable: convierte el tiempo de certificación en tiempo productivo.
Calendario de habilitación
| PCI-DSS v4.0 Nivel 1 | Meses 1 a 9 | Requisito de la fase 3 |
| SOC 2 Tipo II | Meses 1 a 13 | Ventana de observación de 12 meses |
| PROSA y E-Global | Meses 3 a 12 | Bloquea la fase 3 |
| VISA VAP y Mastercard | Meses 4 a 14 | Bloquea la fase 4 |
| EMV L1, L2 y L3 | Meses 8 a 16 | Solo si hay parque POS propio |
| SoftPOS con CPoC | Meses 10 a 18 | Requisito de la fase 5 |
Lo que sí exige una decisión ahora
Qué necesitamos de finsus
La fase 0 puede arrancar en semanas. Estas son las piezas que no dependen de nosotros.
Sin esto no se puede observar
Sin esto no se puede construir
El CMS no reemplaza al procesador.
Lo va dejando sin trabajo.
Empieza observando, sigue gobernando los parámetros, después decide en sombra, y solo entonces recibe tráfico —primero un BIN, después cohortes, al final la cartera completa y la adquirencia—. En ninguno de los siete pasos hay una fecha de corte, y en todos se puede volver atrás moviendo un porcentaje.
Meses 0 a 6
Sin certificaciones, sin riesgo y sin tocar una sola autorización. Se puede empezar ahora.
Meses 6 a 14
Primer tráfico real. Exige las certificaciones, propias o por alianza.
Meses 14 a 24
Adquirencia, comercios y terminales. El procesador actual se apaga al final, no al principio.