bancos

Bancos: Deficiencias en la Operativa- User experience (UX)

Guido Rosales 03/09/2022

Hace unos días pase por un Banco para abrir una caja de ahorro y acceder a sus servicios. Relato mi experiencia con la finalidad de generar mejoras operativas que beneficien no a determinada entidad financiera, sino al sistema mismo. Se habla mucho de LA EXPERIENCIA DEL USUARIO, pero si solo le preguntas como le pareció el Banco después de darle unos regalitos, premios o un cafecito, entonces el resultado nunca será desfavorable

LENTITUD EN LA ATENCION

Si tienes varias personas, pero destinas solo un escritorio para la atención de plataforma por supuesto que generas malestar en los clientes. Sobre todo si no puedes preguntar a que están viniendo para validar si deben o no hacer la espera. Peor si se observa varios funcionarios chateando o viendo tiktoks mientras esperas que la única funcionaria de Plataforma se desocupe. Peor si notas que esta persona es principiante y parece en modo PRACTICA LABORAL dado que pregunta cada paso que da. Imaginen el tiempo de espera, fácilmente 45 minutos. No sé si la regla de los 30 minutos se aplica en plataforma, creo que no. En este punto resalto otra ocasion donde OTRO banco habia destinado a una persona preguntando que tramite venia a hacer. Resulto que podia hacer mi solicitud por un canal digital. Me ayudo para hacerlo y evito una persona en la larga fila.

IMPRESICION EN EL REGISTRO DE DATOS

Por fin llegas al momento de dar tus datos para la apertura de cuenta, pero extrañamente las tipicas preguntas no son realizadas pero cuando revisas el formulario todo esta llenado y algunos datos no son tuyos, de donde salieron? pero ya no tienes humor para lidiar con esto asi que los dejas pasar. Sobre todo los datos de ingresos, ocupaciones y direcciones imprecisas.

Tampoco te piden establecer los limites transaccionales que por defecto son fijados por el banco. En operaciones de ATM esta por debajo de los 1000$US, pero en operaciones POS esta en 50.000Bs. Sin duda es un detalle no explicado pero muy importante para el cliente.

FALTA DE CONTROL OPORTUNO

Cuando piden la cedula supuestamente validan en el SEGIP, pero lastimosamente tengo dos cedulas por motivos que en otro momento serán narrados. Ambas vigentes si a fecha de caducidad nos referimos. Pero según SEGIP solo la última es la facultada para realizar trámites, la otra sirve para identificación pero no tiene la valides plena. El punto es que el funcionario de plataforma no valida esto pese a tener el reporte del SEGIP, esto genera que al día siguiente tenga que volver al Banco a presentar el documento correcto. ¿Pero, como decía el funcionario en el escritorio no sabía que validar?

SUPLANTACION DE IDENTIDAD

Resulta que dias despues, unos 2 recibo un correo donde supuestamente habia sacado un ticket virtual para ser atendido en el Banco, por supuesto el correo tiene todos esos aires de ser algo muy solemne, formal y demas. Pero no era correcto, yo no habia solicitado tal servicio. Reportamos al Canal de RRSS y la tipica, llame al 0800 o pase por la oficina. Es decir para hacer un reclamo de aparente suplantacion de identidad tengo que tomarme todas esas molestias? por favor!! Entonces recurrimos a otros canales pero con mas vehemencia. Nos atienden y despues de unos dias nos dan una explicacion tirada de los pelos. Cuadra por el proceso, pero no en los plazos. Ni modo. Ya el tiempo no deja hacer mas indagaciones o reclamos. Al final supimos que paso, pero no formalmente hasta ahora. Sigue sin respueta oficial el aparente requerimiento de ticket virtual no realizado por mi persona.

Lmentablemente esta canal puede ser habilitado sin

OPERACIONES SIN SEGURO

Al solicitar tarjeta de debito y banca digital el funcionario sugiere optar por la opcion de seguro para la tarjeta de debito, pero no hace mas recomendaciones sobre las opciones de TOKEN, autenticacion y demas controles para la banca digital. Al final del tema del seguro de la Tarjeta de Debito, no es aplicable en casos de fraude digital por suplantacion de identidad. Ahi el detalle. Tenemos un seguro para operaciones de tarjeta, pero no si mediante un phishing perdemos las credenciales y nos bajan los ahorros. Ojo que el funcionario te da los contratos correspondientes para firmar sin hacer ningun enfasis en los aspectos de seguridad que deberian interesar. Al final como mencionamos en punto anterior, tiene varias personas en su fila y trata de terminar tu tramite lo mas pronto posible. Lo mas que hace es decir que todo esta en su sitio web. OJO que el sitio web contiene informacion obsoleta que deberia ser tomada en cuenta en casos de Fraude digital. El contenido de un sitio web deberia tener controles de actualizacion para validar si fue negligencia del cliente o del mismo Banco no declarar o hacer su mejor esfuerzo para minimizar los riesgos. Deben revisar los documentos PDF que estan compartiendo.

REGISTROS BIOMETRICOS SIN USO

Este Banco y en general todo el sistema financiero registra varios datos biométricos como las huellas dactilares, el rostro que podríamos tomar para biometría facial, ¿pero...para que los utiliza?
Gran parte de la identificación y autenticación aún está pensada en procesos físicos. Cuando uno hace una operación en caja le piden quitarse el barbijo para que el cajero haga un reconocimiento facial, que por cierto puede ser de lo más impreciso. ¿Y si el cliente utiliza la banca digital de manera no presencial, para que sirven las huellas y el registro del rostro?
¿Por que el regulador y los regulados no implementan la autenticación multifactor donde se valida la identidad del cliente para aprobar ciertas o mejor todas las transacciones? Aun se están utilizando elementos de autenticación que pueden ser utilizados por personas diferentes al titular de las cuentas.
Los datos de biometría informática no están siendo utilizados de forma óptima y amplia. La banca aun tiene un marcado sesgo a la presencia física y al validador humano.

OJO que no te aclaran como seran utilizados tus datos biometricos. Y la declaracion de privacidad que tiene el Banco en su sitio web es mas escasa.

PARQUEO COMODO

Lo único rescatable de mi experiencia fue el parqueo. Muy cómodo.Pensé que ver una agencia casi vacía haría una atención rápida, pero negativo, la visita duro mas de una hora.

Destaco también la amabilidad de la funcionaria, pero definitivamente NADA MAS

REGIONALIZACION DE ACCESO Y ORIGEN DE DIRECCIONES IP EN PLATAFORMAS DE BANCA DIGITAL

Guido Rosales 04/08/2022

Utilizar controles de bloqueo por listas negras de IP es un buen control en el conjunto de medios de mitigación, lastimosamente no es un tema mandatorio sino dejado al análisis de riesgo institucional, lo cual no siempre es recomendable considerando que prima la LEY DEL MENOR ESFUERZO.

Son muy pocas Entidades de Intermediación financiera: Bancos cooperativas y EFVs que lo hacen. Es en ese sentido precisamente que va este video donde llamamos la atención sobre las listas de origen de IP que están utilizando. Hemos visto que en varios casos el origen no es el correcto. En el video se explica por ejemplo una IP de Mongolia que es interpretada como USA en un caso y como PORTUGAL en otro.

Con la regionalización se minimiza no solo visitas no deseadas son gran cantidad de bots y escaneos no autorizados con IPS internacionales.

Ahora cuando las listas de IPs dan resultados erróneos comprometen la fiabilidad de los LOGs. Sera complicado explicar en un tema forense como es que las conexiones tienen IPs con diferente origen cuando el cliente estaba en otro país. También se podría ofrecer una prueba de concepto y test de acceso para desvirtuar el valor probatorio de los LOGs.

En resumen

El ente regulador debería requerir este control tanto regionalización como listas de ip origen como mandatorio
Las entidades deberían implementar el bloqueo tanto por firewall como por aplicación para mitigar acceso no deseados
Los grupos de QA, IT y seguridad deberían validar que funcione correctamente.
Si algún cliente necesita por temas de viajes o residencia en el exterior se hace la gestión para habilitar IPs definidos.

España: La responsabilidad bancaria en los casos de phishing

Editor YPT2 09/02/2022

La nota distintiva es que la realización de manipulaciones y artificios no está dirigida a otros, sino a máquinas que, en su automatismo y como consecuencia de una conducta artera, actúan en perjuicio de tercero. Dada la complejidad, se amplía la fórmula empleada por el legislador y se admite la comisión del delito a través de diversas modalidades que pueden consistir en la alteración de los elementos físicos de la máquina, de aquellos que permite su programación o por la introducción de datos falsos: creación de órdenes de pago o de transferencias, manipulaciones de entrada o salida de datos en virtud de los que la máquina actúa en su función mecánica propia, etc.

En este contexto, el “phishing” por e-mail fraudulento, tal y como ha quedado definido por tribunales como la Audiencia Provincial de Madrid en su Sentencia de 24 de enero de 2018, “se basa en el envío de correos electrónicos que, aparentando provenir de fuentes fiables, en el caso: de la entidad bancaria de los perjudicados, obtienen o intentan obtener datos confidenciales del usuario como sus claves bancarias, las que posteriormente se utilizan para la realización de la estafa, es decir: para acceder a su cuenta corriente y efectuar trasferencias de dinero dirigidas a un beneficiario, autor directo o colaborador necesario del fraude”.

La Sentencia de la Audiencia Provincial de La Rioja de 3 diciembre explica el significado del concepto phishing de la siguiente manera: “de forma gráfica se dice que el autor "pesca los datos protegidos" - de ahí la denominación phishing -, que permiten el libre acceso a las cuentas del particular y, a partir de ahí, el desapoderamiento”, y la Sentencia de la Audiencia Provincial de Valladolid 263/2010 de 21 de junio de 2010 explica su objetivo aclarando “que, mediante una manipulación informática, se efectúe una transferencia no consentida de activos en perjuicio de un tercero”. Teniendo como particularidad que “en este caso, el acto de disposición patrimonial no se realiza por la víctima del engaño, sino por el propio autor, a través del sistema, por lo que la transferencia debe ser no consentida”.

¿Se puede reclamar al banco?

La Ley 16/2009, de 13 de noviembre, de servicios de pago, fue derogada con efectos de 25 de noviembre, por el Real Decreto-ley 19/2018 de Servicios de pago y otras medidas urgentes en materia financiera, vigente hoy día, con motivo de la transposición al ordenamiento interno de la Directiva (UE) 2015/2366 del Parlamento y del Consejo, de 25 de noviembre, sobre Servicios de Pago en el Mercado Interior.

Esta Directiva, conocida como DSP2, establece normas exhaustivas para los servicios de pago que se complementan con lo establecido en el Reglamento 2018/389, concretamente respecto a las normas para la autenticación reforzada de clientes.

Esto último es lo que nos interesa en este caso, ya que este reglamento obliga a las entidades bancarias (que son las proveedoras de los servicios/medios de pago) a disponer de mecanismos de supervisión de las operaciones que les permitan detectar transferencias de pago no autorizadas o fraudulentas. Es decir, los bancos deben poder detectar que los elementos de autenticación (las claves personales) han sido comprometidas o sustraídas y deben detectar señales de infección por programas informáticos maliciosos en el proceso de autenticación.

En este sentido y a nivel nacional, el RDL 19/2018 dedica entre sus disposiciones, un apartado a las transferencias no consentidas. Así, el artículo 36 hace referencia al consentimiento y a la retirada del mismo, señalando que:

1. Las operaciones de pago se considerarán autorizadas cuando el ordenante haya dado el consentimiento para su ejecución. A falta de tal consentimiento la operación de pago se considerará no autorizada. El consentimiento para la ejecución de una operación de pago podrá darse también por conducto del beneficiario o del proveedor de servicios de iniciación de pagos.

El ordenante y su proveedor de servicios de pago acordarán la forma en que se dará el consentimiento, así como el procedimiento de notificación del mismo.

2. El consentimiento podrá otorgarse con anterioridad a la ejecución de la operación o, si así se hubiese convenido, con posterioridad a la misma, conforme al procedimiento y límites acordados entre el ordenante y su proveedor de servicios de pago.

3. El ordenante podrá retirar el consentimiento en cualquier momento, pero no después de la irrevocabilidad a que se refiere el artículo 52. Cuando el consentimiento se hubiese dado para una serie de operaciones de pago, su retirada implicará que toda futura operación de pago que estuviese cubierta por dicho consentimiento se considerará no autorizada.

Por tanto, en los casos de e-mail fraudulento o ‘phishing’, la transferencia debe entenderse como no autorizada, por lo que mientras la víctima cumpla con lo establecido en el artículo 43 en referencia a la notificación de operaciones de pago no autorizadas sin demora y desde que se tiene conocimiento de los hechos, la responsabilidad recae en el proveedor de servicios de pago, tal y como establece el artículo 45:

1. Sin perjuicio del artículo 43 de este real decreto-ley, en caso de que se ejecute una operación de pago no autorizada, el proveedor de servicios de pago del ordenante devolverá a éste el importe de la operación no autorizada de inmediato y, en cualquier caso, a más tardar al final del día hábil siguiente a aquel en el que haya observado o se le haya notificado la operación, salvo cuando el proveedor de servicios de pago del ordenante tenga motivos razonables para sospechar la existencia de fraude y comunique dichos motivos por escrito al Banco de España, en la forma y con el contenido y plazos que éste determine. En su caso, el proveedor de servicios de pago del ordenante restituirá la cuenta de pago en la cual se haya efectuado el adeudo al estado en el que se habría encontrado de no haberse efectuado la operación no autorizada.

2. Cuando la operación de pago se inicie a través de un proveedor de servicios de iniciación de pagos, el proveedor de servicios de pago gestor de cuenta devolverá inmediatamente y, en cualquier caso, a más tardar al final del día hábil siguiente, el importe de la operación de pago no autorizada y, en su caso, restituirá la cuenta de pago en la cual se haya efectuado el adeudo al estado en el que se habría encontrado de no haberse efectuado la operación no autorizada.

Si el responsable de la operación de pago no autorizada es el proveedor de servicios de iniciación de pagos, deberá resarcir de inmediato al proveedor de servicios de pago gestor de cuenta, a petición de este, por las pérdidas sufridas o las sumas abonadas para efectuar la devolución al ordenante, incluido el importe de la operación de pago no autorizada. De conformidad con el artículo 44.1, corresponderá al proveedor de servicios de iniciación de pagos demostrar que, dentro de su ámbito de competencia, la operación de pago fue autenticada y registrada con exactitud y no se vio afectada por un fallo técnico u otras deficiencias vinculadas al servicio de pago del que es responsable. (…)

De acuerdo con estas disposiciones, nuestros tribunales entienden que las entidades bancarias tienen la obligación de garantizar la seguridad de sus clientes y por tanto, responden por los efectos de sus propios sistemas de autenticación.

Por ejemplo, la Audiencia Provincial de Valencia en su Sentencia de 26 de noviembre de 2014, señala que:

“Estimadas como no autorizadas las operaciones bancarias descritas, habrá de estarse a lo que establece el siguiente artículo 31 de la LSP (hoy artículo 45 de la Ley 19/2018) (…) por lo que, en tal perspectiva, y teniendo en cuenta las irregularidades apreciadas, es pertinente apreciar que la entidad bancaria no desplegó toda la diligencia exigible al buen comerciante en el sector del tráfico de que se trata.”

Y confirma la Audiencia Provincial de Alicante en su Sentencia de 12 de marzo de 2018 aclarando que:

1º.) El proveedor de los servicios de pago (la Entidad Bancaria) “debe implementar las medidas necesarias para asegurar la autenticación e identidad del ordenante a la hora de prestar su consentimiento. Por ello y para su ejecución, el banco debe comprobar en todo caso la autenticidad de la orden”;

2º.) “La falsedad de la transferencia (es decir, que el ordenante no sea el titular de la cuenta) es un riesgo a cargo del banco porque, en principio, el deudor sólo se libera pagando al verdadero acreedor por lo que, si el banco cumple una orden falsa, habrá de reintegrar en la cuenta correspondiente las cantidades cargadas”.

3º.) “La responsabilidad en estos supuestos no puede atribuirse directamente al supuesto ordenante de la transferencia por entenderse ésta autorizada al haberse realizado de acuerdo con los sistemas de autenticación del banco. Los sistemas de autenticación se establecen por los proveedores de servicios de pago y si un banco no ha sido capaz de limitar el acceso al canal de banca electrónica no puede pretender que el presunto ordenante víctima de esta práctica fraudulenta sea el único responsable, pues es el banco quien tiene responsabilidad respecto del buen funcionamiento y la seguridad del mismo”.

4º.) “Las medidas de seguridad no solamente están destinadas a proteger la seguridad de las órdenes de pago emitidas por los clientes, sino que su eficacia exonera a las entidades de crédito de su responsabilidad frente a las órdenes de pago no emitidas por sus clientes de tal forma que el incumplimiento de este específico deber de vigilancia da lugar a una responsabilidad por “culpa invigilando” o responsabilidad objetiva por el mal funcionamiento de los servicios de banca electrónica”.

Por tanto, la jurisprudencia confirma que es la prestadora de los servicios de pago quien tiene la obligación de facilitar un sistema de banca telemática segura, y no son sus clientes- usuarios los que deben prevenir ni averiguar las modalidades de riesgos que el sistema conlleva, ni prevenir con un asesoramiento experto los mismos, no pudiendo en suma la parte obligada legalmente a ofrecer un modelo de servicio de caja que requiere de un especial nivel de seguridad, objetar que el usuario debía conocer aspectos técnicos tales como identificar una web como falsa -cuando no consta que fuera burda y por tanto, evidente de toda falsedad-, ni que no eran fallos técnicos sino riesgos fraudulentos, determinados comportamientos de la plataforma que, no se olvide, son tan factibles que incluso el contrato de banca directa alude -para eludir responsabilidades el prestador- al riesgo de fallos técnicos, errores, interrupciones, desconexiones, sobrecargas y otras formas de defectos en la conexión.