Ciberseguridad para fintechs en Bolivia: ASFI

El ecosistema fintech boliviano en 2026

Bolivia no es el mercado más grande de la región, pero su ecosistema de pagos digitales ha experimentado una transformación notable desde 2020. La combinación de una población joven, alta penetración de teléfonos móviles y un sistema bancario tradicional que históricamente ha excluido a grandes segmentos de la población creó las condiciones perfectas para el despegue de las billeteras digitales y los pagos QR.

Tigo Money sigue siendo el actor dominante del dinero electrónico en Bolivia, con millones de usuarios activos y una red de agentes que llega a municipios donde no existe una sucursal bancaria física. Junto a Tigo Money, Leaf ha construido una propuesta orientada a empresas y pagos B2B, mientras que la Billetera Móvil del Banco Central de Bolivia (BCB) busca establecer una infraestructura de pagos interoperable de carácter público. Las startups más nuevas, muchas de ellas en etapa de obtención de licencia o en operación piloto, completan un ecosistema que la ASFI supervisa con una atención creciente.

Este crecimiento trae consigo una superficie de ataque completamente diferente a la del sistema bancario tradicional. Un CTO de fintech en La Paz o Santa Cruz de la Sierra necesita entender esa diferencia antes de contratar cualquier servicio de ciberseguridad.

Marco regulatorio: ASFI, BCB y las obligaciones de seguridad

Autoridad de Supervisión del Sistema Financiero (ASFI)

La ASFI es el regulador primario para las entidades que emiten dinero electrónico y prestan servicios financieros no bancarios en Bolivia. Las fintechs que operan bajo la Licencia de Empresa de Servicios de Pago (ESP) o bajo la figura de entidad de dinero electrónico deben cumplir con:

Controles de seguridad de la información alineados a estándares internacionales (la ASFI referencia ISO/IEC 27001 en sus circulares de tecnología)
Gestión de incidentes con tiempos de reporte al regulador (incidentes críticos deben notificarse en ventanas de tiempo muy acotadas)
Auditorías de seguridad periódicas, con resultados disponibles para inspección
Controles sobre el ciclo de vida de aplicaciones móviles y APIs expuestas a clientes

La ASFI ha reforzado su marco de supervisión tecnológica en años recientes, con circulares como la 885/25, que regula la constitución y funcionamiento de Empresas de Tecnología Financiera (ETF) e incluye obligaciones de seguridad de la información, y la 945/2026, con requisitos más detallados de infraestructura tecnológica y seguridad de la información. Las fintechs que operan sin un programa formal de pruebas de seguridad están tomando un riesgo regulatorio concreto, no solo un riesgo técnico.

Banco Central de Bolivia: sistema de pagos e interoperabilidad

El BCB establece los estándares para el Sistema de Pagos de Alto Valor (SIPAV) y supervisa la infraestructura de pagos de bajo valor, incluyendo los pagos QR interoperables. Las obligaciones relevantes para fintechs incluyen:

Cumplimiento con los protocolos de mensajería y seguridad para conexiones con el sistema de compensación
Requisitos de autenticación y no repudio en transacciones
Controles sobre la integridad de los datos de transacción

La interoperabilidad entre billeteras —uno de los pilares del sistema boliviano de pagos QR— crea dependencias entre sistemas de distintas empresas. Cada punto de integración es una superficie de ataque potencial que debe estar cubierta por pruebas de seguridad de API.

Superficie de ataque específica del fintech boliviano

Población no bancarizada y mobile-first

Bolivia tiene una de las tasas de inclusión financiera más bajas de Sudamérica, lo que significa que para muchos usuarios, una billetera digital es su primera interacción con el sistema financiero. Estas personas no tienen los patrones de alerta que un usuario bancario tradicional ha desarrollado durante años. El resultado:

Mayor vulnerabilidad a ataques de ingeniería social y phishing por SMS (smishing)
Usuarios que comparten PINs o credenciales sin considerar el riesgo
Onboarding remoto como vector de fraude de identidad

Conectividad 2G/3G y sus implicaciones de seguridad

Buena parte de la población boliviana, especialmente fuera de las ciudades principales, conecta a través de redes 2G o 3G con baja latencia. Esto tiene consecuencias directas sobre la arquitectura de seguridad:

Los controles de seguridad que dependen de latencia baja (second factor por push notification, por ejemplo) pueden fallar o degradarse
Las aplicaciones deben ser resilientes a sesiones interrumpidas, lo que complica la gestión de tokens de sesión
Las pruebas de penetración móvil deben realizarse simulando estas condiciones de conectividad, no solo en entornos de red ideal

Multilingüismo y variabilidad de alfabetización digital

La Constitución Política del Estado reconoce 36 idiomas indígenas además del castellano como idiomas oficiales (Art. 5 CPE). El español es el idioma del sistema financiero formal, pero una fracción significativa de usuarios se comunica principalmente en quechua o aymara. Los materiales de ingeniería social (correos, SMS, llamadas fraudulentas) pueden aprovechar esta brecha. Las fintechs que operan en mercados rurales o periurbanos deben considerar:

Interfaces claras que no generen confusión sobre permisos de la aplicación
Flujos de autenticación que no dependan de comprensión de texto técnico
Capacitación interna del equipo de soporte sobre vectores de ingeniería social locales

Controles cambiarios y arquitectura de sistemas

Bolivia mantiene controles sobre el mercado de divisas y opera con un tipo de cambio administrado para el boliviano. Esto afecta la arquitectura de seguridad de varias formas:

Los sistemas que manejan conversión de moneda o pagos internacionales tienen una capa adicional de riesgo de fraude (manipulación de tasas, transacciones fuera de rango)
Los logs de transacción deben capturar el contexto cambiario para facilitar auditorías forenses
Las integraciones con pasarelas internacionales requieren validación de que los controles de la contraparte son equivalentes

Requisitos PCI DSS para fintechs bolivianas

Aunque Bolivia no tiene una regulación PCI DSS específica de emisión local, cualquier fintech que procese, transmita o almacene datos de tarjetas de pago (incluyendo tarjetas prepago o débito vinculadas a billeteras) está sujeta a las obligaciones contractuales de las redes (Visa, Mastercard). En la práctica, esto significa:

Componente PCI DSS	Relevancia para fintechs bolivianas
Segmentación de red	Separar entornos de datos de tarjetas del resto de infraestructura
Cifrado en tránsito y en reposo	TLS 1.2+ obligatorio; cifrado de base de datos para datos de tarjeta
Gestión de vulnerabilidades	Escaneos trimestrales de vulnerabilidades y pruebas de penetración anuales
Control de acceso	Privilegio mínimo, autenticación multifactor para acceso administrativo
Monitoreo y logging	Retención de logs de transacción según requerimientos del estándar

Las pruebas de penetración para cumplimiento PCI DSS deben ser ejecutadas por proveedores con experiencia en el estándar y capacidad de emitir reportes que satisfagan los requerimientos de los auditores QSA.

Seguridad de APIs: el eslabón más frágil

La interoperabilidad entre billeteras bolivianas, bancos y el sistema BCB funciona sobre APIs. Un error de autenticación o autorización en una API puede tener consecuencias que van más allá de la empresa afectada directamente.

Los vectores más comunes de ataque en APIs de fintechs bolivianas incluyen:

Broken Object Level Authorization (BOLA/IDOR): un usuario accede a los datos de otro usuario cambiando un identificador en la solicitud
Exposición excesiva de datos: endpoints que devuelven más información de la necesaria (números de cuenta, saldos completos, datos personales)
Ausencia de rate limiting: permite ataques de fuerza bruta sobre PINs o tokens de verificación
Tokens de sesión de larga duración: si son interceptados, permiten acceso prolongado sin re-autenticación

Las pruebas de penetración de APIs deben seguir la metodología OWASP API Security Top 10 y deben incluir escenarios de abuso de la lógica de negocio, no solo vulnerabilidades técnicas.

Seguridad de aplicaciones móviles

La aplicación móvil es el canal principal en el fintech boliviano. Las pruebas deben cubrir:

Análisis estático (SAST): revisión del binario de la app en busca de secretos embebidos, configuraciones inseguras, uso de librerías con vulnerabilidades conocidas
Análisis dinámico (DAST): pruebas de la app en ejecución, incluyendo interceptación de tráfico, manipulación de solicitudes y pruebas de lógica de negocio
Pruebas en dispositivos reales con conectividad degradada: simulando condiciones 2G/3G para validar comportamiento de seguridad bajo condiciones reales bolivianas
Validación de controles anti-tampering: verificar que la app detecta rooteo/jailbreak y responde apropiadamente
Pruebas de almacenamiento local: datos sensibles no deben almacenarse en claro en el dispositivo

Qué buscar en un aliado de ciberseguridad para fintech en Bolivia

No todos los proveedores de ciberseguridad están equipados para el mercado fintech boliviano. Las características que distinguen a un aliado genuinamente útil de uno genérico:

Conocimiento regulatorio local

El proveedor debe conocer la estructura de supervisión de la ASFI y los requisitos del BCB. Un reporte de pruebas de penetración que no mapee los hallazgos a los controles que la ASFI revisa en sus inspecciones es un reporte a medias. El aliado debe poder acompañar al equipo técnico en una conversación con el supervisor si es necesario.

Capacidad de trabajo remoto

Bolivia tiene una infraestructura de telecomunicaciones en desarrollo. El aliado debe tener experiencia en compromisos completamente remotos, con procesos claros para el acceso seguro a entornos de prueba, sin requerir presencia física que encarezca el servicio o lo haga inviable para startups en etapa temprana.

Reportes en español con detalle técnico y ejecutivo

Los equipos técnicos bolivianos trabajan en español. Los reportes en inglés, o los reportes en español que son traducciones automáticas de plantillas en inglés, crean fricción. El aliado debe producir documentación que el CTO pueda usar internamente y que el CEO pueda presentar al directorio o al regulador sin necesidad de traducción ni interpretación.

Metodología alineada a estándares reconocidos

OWASP MASVS para móviles, OWASP API Security Top 10 para APIs, PTES para pruebas de penetración de infraestructura, y PCI DSS para componentes de procesamiento de pagos. El aliado debe poder articular qué estándar está aplicando en cada fase del engagement.

Visibilidad continua, no solo auditorías puntuales

Una prueba de penetración anual es necesaria pero no suficiente. El ecosistema de amenazas cambia más rápido que el ciclo de auditoría. Los mejores aliados complementan las pruebas periódicas con herramientas que proporcionan visibilidad continua sobre el estado de seguridad: gestión de vulnerabilidades, monitoreo de la superficie de ataque externa, y alertas sobre nuevas exposiciones.

Entre los proveedores con experiencia en el mercado fintech boliviano, WhiteJaguars trabaja con empresas en LATAM que operan bajo marcos regulatorios locales específicos. Para Bolivia, eso se traduce en hallazgos mapeados a los controles que la ASFI verifica en sus inspecciones tecnológicas; reportes completamente en español —técnico para el equipo de ingeniería, ejecutivo para el directorio o el regulador—; plataforma SaaS donde las fintechs pueden ver el estado de sus vulnerabilidades y el progreso de remediación en tiempo real; engagements 100% remotos sin requerir presencia física; y especialización en aplicaciones móviles y APIs, que son las dos superficies de ataque más críticas del fintech boliviano.

Preguntas frecuentes

¿La ASFI exige pruebas de penetración formales?

La ASFI no especifica en todas sus circulares un requisito explícito de prueba de penetración con ese nombre, pero sus requerimientos de gestión de riesgos tecnológicos y seguridad de la información implican la necesidad de evaluar la seguridad de los sistemas de manera técnica y periódica. En inspecciones, el supervisor ha solicitado evidencia de evaluaciones de vulnerabilidades y pruebas de seguridad. Contar con un programa formal de pruebas de penetración es la forma más directa de cumplir con ese requerimiento implícito y estar preparado para una inspección.

¿Cuánto tiempo toma una prueba de penetración para una app móvil y API fintech?

Para una aplicación móvil de tamaño mediano (iOS y Android) más las APIs de backend, un engagement completo toma entre dos y cuatro semanas. Esto incluye reconocimiento, pruebas activas, análisis de lógica de negocio, informe de hallazgos y sesión de revisión con el equipo técnico. Los plazos varían según la complejidad de la aplicación y el alcance acordado.

¿Una startup en etapa temprana necesita ciberseguridad formal antes de lanzar?

Sí, especialmente si va a manejar dinero real de usuarios. Los errores de seguridad en las primeras versiones de una aplicación financiera son costosos: no solo por el daño a usuarios, sino porque una brecha temprana puede comprometer la relación con el regulador antes de que la empresa haya construido credibilidad. Lo prudente es incluir al menos una revisión de seguridad de la aplicación y las APIs antes del lanzamiento, y establecer un proceso de pruebas continuas desde el inicio.

¿Los proveedores internacionales pueden trabajar con fintechs bolivianas?

Sí. El trabajo de pruebas de penetración se realiza de manera remota en la gran mayoría de los casos. Lo importante es que el proveedor tenga experiencia con el marco regulatorio boliviano y capacidad de comunicación en español. Los contratos y reportes en inglés, o los proveedores que desconocen los requerimientos de la ASFI, generan más fricción de la que eliminan.

Siguiente paso

El ecosistema fintech de Bolivia opera dentro de un marco regulatorio más amplio que abarca a toda la industria financiera: comprender las regulaciones del sector financiero en Bolivia es esencial para dimensionar correctamente los requisitos de cumplimiento y las expectativas del regulador durante una inspección. Para fintechs que están evaluando proveedores de seguridad, el artículo sobre cómo contratar un servicio de pentesting especializado en Bolivia detalla los criterios clave: certificaciones verificables, metodología documentada y modelo de entrega continua.

Aliados de ciberseguridad para fintechs en Bolivia (2026)