Fraude micro (y no tan micro) en las empresas; el futuro de las transacciones machine-to-machine y la muerte del maldito digipass.

• ¿Qué harías si el mundo se parara 24 horas y pudieras hacer lo que se te de la gana, sin consecuencias?
• Hmm, primero, me robaría un auto y….

La mayoría de las personas a las que les he hecho esa pregunta, comienzan por robar algo para su purga permitida. Se la robé a la gran Diana Palacios de Shinkansen y casi siempre la gente comienza con robar algún medio de transporte.

No hay una respuesta correcta o incorrecta. No estoy midiendo honestidad ni moralidad. De hecho, en conversaciones, prácticamente todos llegamos a la conclusión que el que dice que no va a robar algo, está mintiendo por cordialidad.

Y así es como debe sentirse alguien que hace un fraude en una empresa. Nadie lo hace pensando en que se van a enterar. Hace poco, nuestro CEO, Leo Soto, escribió sobre tesorería digital vs fraude interno. Y que usualmente hay que balancear el costo del fraude con el costo de prevenir ese fraude.

¿Cuál es el truco? Que no sabes cuánto te está costando ese fraude, porque ni te has enterado que existe. 

¿Qué solución usamos entonces? El digipass o token de aprobaciones.

¿Pero, cómo? ¡Si el digipass es lo más seguro que hay!

Sí, claro. Por eso cuando los apoderados aprueban pagos saben perfectamente lo que están aprobando. Y lo que se subió al banco no tiene intervención ni errores (intencionados o no) humanos.

Nope. No es así. El proceso se ve más parecido a esto: 

• Se crea un archivo de pagos en el ERP de la empresa.
• Se descarga un archivo txt o csv al equipo de una persona de tesorería.
• Se sube a cada banco para su pago.
• Se persigue a los apoderados que tienen los digipasses/tokens para que aprueben.
  • En los casos más extremos, se espera afuera de su oficina  haciendo guardia para que no vaya a pasar una hora más sin aprobar el pago urgente.
• Los apoderados aprueban, no con muchas ganas, algo que no tienen certeza de lo que están aprobando. 
• Esa aprobación se hace por cada cuenta en cada banco.
• Y los apoderados tienen un “arbol de navidad” de digipasses que se ve así:

El digipass no mitigó el riesgo de que haya existido un pago duplicado. Tampoco alertó sobre un pago a un destinatario nuevo ni discriminó entre la aprobación de 100 mil pesos o la de 100 millones de pesos. Ni siquiera me dio la trazabilidad de saber si es la persona la que está aprobando o alguien usando su digipass o token a nombre de esa persona.

Ahora, quiero ser justo. No es el digipass el culpable de los fraudes que hemos visto en el último tiempo en las empresas. Ni tampoco de los errores humanos no-intencionales, pero que tienen un resultado similar.

Pero vale la pena la pregunta, entonces. A quien quiere cometer un micro-fraude, ¿lo limita que exista un digipass? O a quien quiere cometer un esquema fraudulento, ¿lo asusta el hecho que hay un digipass al final del proceso?

No lo creo. Y viceversa, ¿harías un micro-fraude sabiendo que hay un sistema que puede alertar a ese apoderado? ¿O que un auditor puede encontrar transacciones irregulares en segundos? 

Probablemente no. Tal como ninguno de nosotros robaría si no existiese la situación ficticia de 24 horas donde el mundo se detiene y nadie se va a enterar.

Bueno , ¿y los digipasses qué tienen que ver?

Tienen que ver por cómo se comporta todo el proceso. Como lo describió Leo, la información del pago a proveedores está disponible. En algún ERP, en algún CRM o en alguna parte existe la información de por qué se está pagando esto, por cuánto y a quién. 

Pero cuando el apoderado entra a las cuatro plataformas de banco, abre su estuche con los diferentes digipasses, y empieza a aprobar, no tiene esa información disponible.

Entonces la solución está en que no haya intervención humana. Me conecto directo al banco y ya.

Good luck with that.

Banco y empresas

¿Qué imagen se les viene cuando hablamos de banco y empresas?

Probablemente algo como esto. Sistemas Host-To-Host (H2H) con conexiones antiguas pensadas para mainframes. Procesos burocráticos. Contratos, diligencias, sucursales, papelitos. De alguna forma todo vuelve a Windows 95.

¿Pero cómo no va a ser más fácil? Si en Chile hay mucha bancarización, transferencias en tiempo real y muchas fintechs. ¡Y nuestros pagos son un ejemplo mundial!

Es cierto. Los ciudadanos tenemos acceso a muy buenos productos financieros. Lo que ha impulsado el Estado desde diferentes ámbitos (Ley Fintec o el SFA desde la CMF) y en buena parte, la banca y startups, ha tenido consecuencias muy positivas. Incluso, que Shinkansen pueda crear la primera cámara de pagos de las fintech.

Pero eso no es una realidad para nuestros queridos clientes que siguen con su “árbol de navidad” de digipasses y al mismo tiempo, problemas de fraudes internos.

Y, claro. Este no es un problema para los 20 millones de personas ciudadanos de Chile que tenemos acceso a buenos productos financieros. Los digipasses están de salida, reemplazados por métodos (a veces) más modernos y amigables.

No es un problema tampoco para las 700.000 micro y pequeñas empresas. Su bancarización tiene mucho más foco en los recaudos y el fraude es menos común porque esta todo más centralizado en sus dueños. El SFA, por ejemplo, traerá beneficios importantes para este segmento, como ha sucedido con regulaciones similares en UK o Brasil.

Este es un problema de nicho. De la mediana y gran empresa que son 35 mil. Es un problema pequeño, del que poco y nada se habla. Pero una tremenda oportunidad de negocio: el open finance como negocio, no como obligación.

El inevitable futuro para prevenir el fraude: Transferencias Machine-To-Machine (M2M).

La comunicación entre empresas y el banco debe, entonces, automatizarse. El trabajo manual que hacen la mayoría de los equipos de tesorería debe evolucionar. Tanto por un riesgo de fraude como de tecnología accesible hoy en día (en cuanto disponibilidad técnica y económica, que antes no era así) para evitar dicho fraude. 

No en una visión catastrófica de que nadie trabajará más. Sino que la tecnología disponible hoy en día permite que los seres humanos no tengamos que estar revisando si la información del dato A calza con la línea de Excel del banco B. O que un ser humano tenga que ingresar las coordenadas de uno de los llaveros que tiene como token físico en su elegante estuche.

Las conexiones máquina a máquina, entre empresas y bancos, serán el estándar de comunicación.

El tema es el estado del arte de esas conexiones. Este tiene tres problemas (o desafíos) principales:

• Al banco, las integraciones le toman meses de trabajo de sus ingenieros/as.
• A las empresas, las integraciones a los múltiples bancos que usa le toman trimestres y N customizaciones por el N de bancos que utilicen.
• Esas integraciones son tiempo y dinero para las empresas y los bancos.

¿En qué se traduce esto?

Para la empresa, en integraciones traumáticas, con costos altísimos que nadie quiere volver a tocar. 

Para el banco, en KPI de integración mediocres y varias preguntas como consecuencia: 

• ¿Creo mi propia API y que mis clientes se integren más rápido? 
• ¿Pero cómo diablos voy a migrar a todas estas empresas a la nueva API si me ha tomado décadas integrarlos a mi H2H?
• Y mientras creo mi API… ¿sigo integrando a los que están en la fila al H2H?

Para las empresas también implica un dolor. Si cada banco hace su API con el estándar que se le ocurre a la consultora de turno, tenemos varias integraciones con diferentes formas. Pueden ser más rápidas y mejores que el H2H, pero tendré formas de funcionar distintas por cada banco. Y depende de los productos que hayan APIficado. ¿Hay transferencias bancarias de bajo valor? ¿Hay transferencias de alto valor (por ej. LBTR en Chile)? ¿Hay payins? ¿Hay transacciones en otras monedas y SWIFT?

Espera. ¡Pero justamente para eso es que el open banking establece los estándares de API para los bancos po’!

Sí. Para los ciudadanos, votantes, pymes, que son un grupo mayoritario que se ve impactado. En ninguna parte están estandarizados estos problemas de un nicho de empresas que requieren servicios de cash management más sofisticados.

He. Ahí. La oportunidad (y tu posibilidad de identificar el fraude)

[Lo que viene es publicidad de Shinkansen. Pero es genuina, porque es el problema que estamos resolviendo con empresas que han sufrido estos problemas.]

Introducing Shinkansen:

Hacer N integraciones por el N de bancos que se tenga es ineficiente y traumático para el equipo de tecnología. Asimismo, para el banco es un mal negocio estar moviendo a los clientes en sus migraciones de sistemas internos.

En Shinkansen ofrecemos una sola integración para resolver eso. Si el banco A tiene una API, el banco B un H2H y banco C un webservice, Shinkansen ofrece la misma API. 

Una sola integración a los N bancos. En Chile, Perú, Colombia y México.

Shinkansen se convierte en un riel para conectar empresas con bancos. Esto tiene dos sabores:

1. Primero, empresas de tecnología que se integran directamente a nuestra API. Fintechs o startups que buscan ese tipo de integraciones para automatizar sus procesos de tesorería (y que, al igual que yo, sienten un odio profundo por los digipasses). Mensajería compatible con ISO 20022 y protocolos seguros de encriptación y firmas digitales, para que la comunicación entre empresas y bancos (vía Shinkansen) sea segura y no-repudiable.

2. Segundo, grandes empresas que quieren automatizar sus procesos de tesorería, pero que no quieren/pueden dejar todo automatizado vía API. Los equipos de tesorería sufren con las nóminas, revisiones y yendo a buscar a los apoderados cada vez que hay que aprobar un pago. Los apoderados se arrancan o bien, los interrumpen varias veces al día para hacer aprobaciones. Si el apoderado no revisa, tiene un problema de estar aprobando transacciones que no revisó. Si el apoderado revisa, la empresa tiene el problema de que la hora hombre del apoderado debe ser de las más costosas de la compañía. Por lo que esa revisión, varias veces al día, todos los días de la semana, está costando bien caro.

Para ellos construimos Shinkansen Cash-Management. La misma API de Shinkansen funcionando por debajo con las mismas integraciones a los bancos con los que trabajamos en Latam, pero una interfaz amable para equipos no-técnicos. Misma seguridad, misma integración y tecnología, pero integrada al ERP-CRM de la empresa. Con el Copiloto de Shinkansen que permite hacer conciliaciones automáticas o asistidas, establecer reglas de pagos personalizadas por la empresa o agregar-quitar fricción a los pagos para hacer la operación más eficiente y mayor trazabilidad de todo lo que sucede en los pagos (ergo, menor exposición a fraudes).

Esto tiene varios beneficios:

Para las empresas:

• Una sola integración con Shinkansen para cada país. Nosotros integramos los bancos, no el equipo interno de la empresa.
• Redundancia en el servicio (si se cae el banco al que estoy integrado, no me quedo sin servicio). Esto es particularmente importante cuando dependo del website para empresas del banco que se cae todos los 30 de cada mes. En Shinkansen eso no ocurre, ya que estamos conectados al interior del banco y no dependemos del website.
• Tu contraparte es Shinkansen. Lo que significa que la integración y el soporte es de nuestros/as ingenieros/as de software y con la agilidad de una fintech.
• El dinero sigue estando en tu cuenta de banco. No nos metemos a tu cuenta ni te pedimos que nos fondees a nosotros. Tu dinero, tu cuenta de banco, tus destinatarios.
• Puedes establecer reglas de negocio que automaticen procesos que prevengan el fraude, como estas:

(imagen de los flujos de aprobación que se hacen desde Shinkansen. Cuando el pago viene desde SAP, y el monto es menor a $10millones, se aprueba automáticamente, sin intervención (i.e. fraude) humana. O si viene de SAP y es mayor a $10millones, lo aprueba el CFO).

¿Y para los bancos?

El futuro de la relación empresas-bancos es machine-to-machine (M2M). Shinkansen es un facilitador para que el banco se adapte rápidamente a ese futuro. Esto significa que el banco tiene:

• Integraciones 10x más rápido a sus sistemas (de 3-12 meses que le tarda al banco, Shinkansen lo hace entre 1-4 semanas).
• Soporte externalizado de alto nivel: Shinkansen es la cara para los clientes. Mayor disponibilidad de respuesta y de respuestas técnicamente correctas (no es vía un call center).
• Seguridad y compliance: Usamos firmas digitales, que puedes validar en tiempo real o auditar ex-post. Monitoreamos comportamiento. Somos AML-friendly (no mezclamos flujos diversos, el dinero siempre está en la cuenta del cliente).
• Time to market: El banco ofrece hoy las API que necesitan las empresas aunque no tengan el roadmap completo con todos los servicios automatizados. Luego hacemos upgrades junto al banco. Sus clientes parten ahora, pero no quedan amarrados al legacy.

Bueno, bueno. Y al ciudadano de a pie, ¿qué? ¿En qué lo beneficia?

En que nosotros ponemos los rieles, pero los pasajeros son nuestros clientes.

Cuando Xepelin envía una transacción en dos minutos por la compra de una factura, le está dando liquidez inmediata a una pyme.

Cuando Buk ofrece un adelanto de sueldo un domingo en la mañana en segundos, le está dando una opción de no endeudarse al trabajador de una empresa.

Cuando easycancha le paga en tiempo récord a los clubes deportivos usando nuestra API, le está dando liquidez a emprendedores y mejores tarifas de adquirencia a las que jamás podrían acceder por sí mismos.

Y que cuando una empresa puede identificar el fraude, ganamos todos como sociedad. El fraude de una gran empresa que no conocías, sí te afecta. Afecta a la credibilidad de todo nuestro sistema. 

El mejor ambiente para hacer negocios no ese mundo ficticio donde todo se detiene y puedo robar sin consecuencias. Es mayor trazabilidad para evitar ese fraude. Ese es el futuro.

Y el futuro de la relación empresa-banco es Machine-To-Machine (M2M). No hay de otra. Un futuro inevitable, donde el digipass pasará a la historia. Y sí, ese futuro es mejor para los equipos de tesorería, para los bancos y para todos quienes hayan usado ese aparato.