alerta Si el documento se presenta incompleto en el margen derecho, es que contiene tablas que rebasan el ancho predeterminado. Si es el caso, haga click aquí para visualizarlo correctamente.
 
DOF: 04/06/2020
DISPOSICIONES de carácter general relativas a las interfaces de programación de aplicaciones informáticas estandarizadas a que hace referencia la Ley para Regular las Instituciones de Tecnología Financiera

DISPOSICIONES de carácter general relativas a las interfaces de programación de aplicaciones informáticas estandarizadas a que hace referencia la Ley para Regular las Instituciones de Tecnología Financiera.

Al margen un sello con el Escudo Nacional, que dice: Estados Unidos Mexicanos.- HACIENDA.- Secretaría de Hacienda y Crédito Público.- Comisión Nacional Bancaria y de Valores.

La Comisión Nacional Bancaria y de Valores, con fundamento en lo dispuesto por los artículos 76, párrafos tercero, octavo, décimo primero, décimo segundo y décimo tercero de la Ley para Regular las Instituciones de Tecnología Financiera, así como los artículos 4, fracciones XXXVI y XXXVIII; 16, fracción I y 19 de la Ley de la Comisión Nacional Bancaria y de Valores, y
CONSIDERANDO
Que en atención al artículo 78 de la Ley General de Mejora Regulatoria y con la finalidad de reducir el costo de cumplimiento de las presentes disposiciones, la Comisión Nacional Bancaria y de Valores mediante resolución publicada en el Diario Oficial de la Federación el 22 de enero de 2018, reformó las "Disposiciones de carácter general aplicables a las instituciones de crédito", con el fin de flexibilizar el plazo para constituir requerimientos de capital y constituir dichos requerimientos de forma gradual;
Que el 9 de marzo de 2018 se publicó en el Diario Oficial de la Federación el "Decreto por el que se expide la Ley para Regular las Instituciones de Tecnología Financiera y se reforman y adicionan diversas disposiciones de la Ley de Instituciones de Crédito, de la Ley del Mercado de Valores, de la Ley General de Organizaciones y Actividades Auxiliares del Crédito, de la Ley para la Transparencia y Ordenamiento de los Servicios Financieros, de la Ley para Regular las Sociedades de Información Crediticia, de la Ley de Protección y Defensa al Usuario de Servicios Financieros, de la Ley para Regular las Agrupaciones Financieras, de la Ley de la Comisión Nacional Bancaria y de Valores y, de la Ley Federal para la Prevención e Identificación de Operaciones de Procedencia Ilícita";
Que el artículo 76 de la Ley para Regular las Instituciones de Tecnología Financiera establece la obligación para las entidades financieras, transmisores de dinero y las sociedades autorizadas para operar con Modelos Novedosos, de intercambiar datos a través del uso de interfaces de programación de aplicaciones estandarizadas a efecto de fomentar la competencia en los mercados, así como la inclusión financiera, al tiempo de facultar a la Comisión Nacional Bancaria y de Valores para emitir disposiciones de carácter general en dicha materia;
Que procurando que el intercambio de información se realice de una forma adecuada, transparente y equitativa, se establece el procedimiento para la autorización y registro de las contraprestaciones a cobrar por el uso de las interfaces de programación de aplicaciones estandarizadas;
Que tomando en cuenta que los datos financieros abiertos no contienen información de la considerada como confidencial, pues se trata de aquella de productos y servicios que se ofrecen al público en general, de la ubicación de oficinas y sucursales, así como de información de cajeros automáticos, entre otra; el compartirla libremente, no constituye un riesgo para quienes la generan;
Que con la finalidad de establecer formas de cumplimiento más sencillas que las previstas en la Ley, así como para evitar la creación de trámites innecesarios que representen costos adicionales a los destinatarios de la norma, se prevé una manera más expedita de obtener, de la Comisión Nacional Bancaria y de Valores, la autorización para acceder a los datos financieros abiertos a través de interfaces de programación de aplicaciones informáticas estandarizadas;
Que en ejercicio de la facultad a que alude el artículo 76 ya citado de la Ley para Regular las Instituciones de Tecnología Financiera y con el objeto de permitir que, ante algún incumplimiento por parte de las entidades financieras, transmisores de dinero y sociedades autorizadas para operar con Modelos Novedosos, se siga intercambiando la información a través de las interfaces de programación de aplicaciones estandarizadas, resulta indispensable normar los requisitos de los programas de regularización que deberán observarse en caso de incumplimientos; ha resuelto expedir las siguientes:
DISPOSICIONES DE CARÁCTER GENERAL RELATIVAS A LAS INTERFACES DE PROGRAMACIÓN DE
APLICACIONES INFORMÁTICAS ESTANDARIZADAS A QUE HACE REFERENCIA LA LEY PARA
REGULAR LAS INSTITUCIONES DE TECNOLOGÍA FINANCIERA
CAPÍTULO I
Disposiciones comunes
CAPÍTULO II
De los Solicitantes de Datos
CAPÍTULO III
De los Proveedores de Datos
CAPÍTULO IV
De los programas de regularización
Anexo 1
Lineamiento de seguridad para datos abiertos que deberán observar proveedores de datos y solicitantes de datos
Anexo 2
Lineamientos de la arquitectura de datos para el intercambio de información de datos abiertos
Anexo 3
Diccionario de datos abiertos de cajeros automáticos.
Capítulo I
Disposiciones comunes
Artículo 1.- Para efectos de las presentes disposiciones, en adición a las definiciones previstas en la Ley, se entenderá, en singular o plural, por:
I.      API, por sus siglas en inglés (Application Programming Interface), a las interfaces de programación de aplicaciones informáticas estandarizadas que posibilitan el intercambio de Datos.
II.     Autenticación, al conjunto de técnicas y procedimientos utilizados por el Proveedor de Datos para verificar la identidad de un Solicitante de Datos y su condición para acceder a los Datos disponibles a través de APIs.
III.    Datos, a los datos abiertos a que hace referencia la fracción I del artículo 76 de la Ley.
IV.   Evento de Seguridad de la Información, a cualquier suceso, interno o externo, relacionado con Clientes, terceros contratados por los Solicitantes de Datos o Proveedores de Datos, personas o procesos operativos, así como con componentes de la Infraestructura, u otros elementos que almacenen información, entre otros, que pueda suponer una afectación en la confidencialidad, integridad o disponibilidad de la información que dicho Proveedor de Datos o Solicitante de Datos gestione o conozca, o en la propia Infraestructura.
V.    Incidente de Seguridad de la Información, al Evento de Seguridad de la Información del Proveedor de Datos cuando se actualice alguno de los siguientes supuestos:
a)   Haya comprometido la confidencialidad, integridad o disponibilidad de uno o más componentes
de la Infraestructura utilizada por un Solicitante de Datos o Proveedor de Datos, o bien, de los Datos que se envíen o reciban a través de dicha Infraestructura, con un efecto adverso para cualquiera de ellos, o bien, para terceros contratados por el Proveedor de Datos para administrar o desarrollar APIs, entre otros.
b)   Vulnere la Infraestructura, comprometiendo los Datos que procesa, almacena o transmite.
c)   Constituya una violación de las políticas y procedimientos de seguridad a que hace referencia el artículo 5 de las presentes disposiciones.
d)   Constituya la materialización de un menoscabo, ya sea por extracción, alteración o extravío de la información; por fallas derivadas del uso del hardware, software, sistemas, aplicaciones, redes y cualquier otro canal de transmisión de información; por accesos no autorizados que deriven en el uso indebido de la información o de los sistemas; por fraude, robo o en interrupción de los servicios, atentados contra las infraestructuras interconectadas, conocidos como ciberataques.
VI.    Infraestructura, a los equipos de cómputo, instalaciones de procesamiento de datos y comunicaciones, equipos y redes de comunicaciones, sistemas operativos, bases de datos, aplicaciones y sistemas que utilizan los Solicitantes de Datos o Proveedores de Datos para soportar la operación de las APIs.
VII.   Ley, a la Ley para Regular las Instituciones de Tecnología Financiera.
VIII.  Proveedores de Datos, a las Entidades Financieras, ITF, sociedades autorizadas por la CNBV para operar con Modelos Novedosos y transmisores de dinero, que conforme al primer párrafo del artículo 76 de la Ley, estén obligados a establecer APIs con el fin de compartir Datos.
IX.   Solicitantes de Datos, a las Entidades Financieras, ITF, sociedades autorizadas para operar con Modelos Novedosos, transmisores de dinero y terceros especializados en tecnologías de información.
X.    Usuarios, a las personas que utilicen los productos o servicios que ofrezcan los Solicitantes de Datos.
Capítulo II
De los Solicitantes de Datos
Artículo 2.- Los Solicitantes de Datos cuyas APIs desarrolladas o administradas por estos cumplan con lo establecido en los Anexos 1, 2 y 3 de las presentes disposiciones, se tendrán por autorizados por la CNBV, sin necesidad de declaración alguna, para acceder a los Datos de los distintos Proveedores de Datos a los que solicite su acceso a través de dichas APIs.
Capítulo III
De los Proveedores de Datos
Artículo 3.- Los Proveedores de Datos en el desarrollo o administración de sus APIs deberán cumplir con los Anexos 1, 2 y 3 de las presentes disposiciones.
Los Proveedores de Datos publicarán, de forma clara, precisa y en idioma español, en su página de Internet o cualquier otro medio de comunicación electrónica, aplicaciones informáticas o digitales, el proceso que deberán seguir los Solicitantes de Datos para acceder a los Datos a través de APIs y las contraprestaciones que, en su caso, deberán pagar por el intercambio de Datos.
Los términos y condiciones que establezcan los Proveedores de Datos con los Solicitantes de Datos para llevar a cabo el intercambio de Datos a través de APIs, deberán establecer mecanismos y controles que aseguren la confidencialidad e integridad de los Datos en su acceso, procesamiento y almacenamiento por parte de los Solicitantes de Datos.
Artículo 4.- Los Proveedores de Datos deberán contar con una política de seguridad de la información que proteja en todo momento la Infraestructura, propia o de terceros contratados por estos, así como la confidencialidad e integridad de los Datos que, en su caso, compartan a través de APIs. La mencionada política de seguridad deberá contener procedimientos continuos, mecanismos y controles considerando, al menos, lo siguiente:
I.     Configuración segura de los componentes tecnológicos de su Infraestructura, incluyendo, entre otros, cierre de puertos y servicios, instalación de mecanismos para detección y prevención de virus, códigos maliciosos y detección de intrusos, así como actualizaciones del fabricante.
II.     Mecanismos de identificación y autenticación del personal responsable del manejo de APIs bajo el principio de mínimo privilegio. Se entenderá como principio de mínimo privilegio a la habilitación del acceso únicamente a la información y recursos necesarios para el desarrollo de las funciones propias del personal referido.
III.    Cifrado de la información almacenada y de los canales a través de los que se envíen los Datos, así como mecanismos de identificación y autenticación, que cumplan con los Anexos 1 y 2 de las presentes disposiciones.
IV.   Procesos de gestión para la atención de Incidentes de Seguridad de la Información que se presenten en la operación de las APIs, que aseguren la detección, atención y contención, investigación y, en su caso, análisis forense digital, diagnóstico, solución, seguimiento y reporte a la CNBV a que hace referencia el artículo 6 de estas disposiciones.
V.    Programa de pruebas de escaneo de vulnerabilidades y amenazas en el acceso y administración de las APIs, el cual podrá ser realizado por un tercero. El mencionado programa deberá considerar la realización de dichas pruebas al menos una vez cada 3 meses, así como con un plan de remediación para las vulnerabilidades críticas detectadas.
VI.   Programa de pruebas de penetración, el cual establezca que se realizarán al menos dos pruebas al año sobre sistemas y aplicativos que estén relacionados o conectados con APIs, o bien, cuando lo ordene la CNBV. Dichas pruebas se deberán realizar por un tercero independiente que cuente con personal con capacidad técnica comprobable mediante certificaciones especializadas de la industria en la materia. Asimismo, se deberá contar con un plan de remediación para las vulnerabilidades críticas detectadas.
VII.   Mecanismos de respaldo y procedimientos de recuperación de la información que mitiguen el riesgo de interrupción de la operación.
VIII.  Registros de auditoría íntegros, incluyendo la información detallada de los accesos o intentos de acceso y la operación o actividad efectuada por el Solicitante de Datos con la información obtenida. La información a que se refiere el presente numeral deberá conservarse por, al menos, un año.
Tratándose de Proveedores de Datos cuyo régimen normativo establezca disposiciones en materia de seguridad de la información, lo previsto en este artículo deberá ser incorporado en las políticas y procedimientos que deban establecer conforme a dicho régimen.
Artículo 5.- Los Proveedores de Datos, deberán asegurar que su Infraestructura para compartir Datos por medio de APIs cumpla con lo siguiente:
I.      Contar con una configuración que garantice que el acceso a los Datos compartidos sea solamente de lectura.
II.     Que la Infraestructura se encuentre segregada de aquella que soporte cualquier operación y que
cuente con mecanismos de seguridad que limiten el acceso desde el servicio de APIs hacia este último, bajo el principio de mínimo privilegio.
       Se entenderá como principio de mínimo privilegio a la habilitación del acceso únicamente a la información y recursos necesarios para el desarrollo de las funciones propias del personal responsable del manejo de APIs.
III.    Cuenten con procedimientos que garanticen la disponibilidad del servicio relacionado con el intercambio de Datos.
IV.   Registros de auditoría íntegros, incluyendo la información detallada de los accesos o intentos de acceso y la operación o actividad efectuada en la Infraestructura.
Artículo 6.- En los casos en que se presente un Incidente de Seguridad de la Información, los Proveedores de Datos deberán reportarlo a la CNBV, de manera inmediata y, a través del correo electrónico ciberseguridad-cnbv@cnbv.gob.mx. En dicha notificación se deberá indicar, al menos, la fecha y hora de inicio del Incidente de Seguridad de la Información de que se trate y, en su caso, la indicación de si continúa o ha concluido y su duración; una descripción de dicho incidente, así como una evaluación del mismo.
Artículo 7.- Los Proveedores de Datos, en los casos en que interrumpan el acceso de información por el incumplimiento del Solicitante de Datos a los términos y condiciones pactados para el intercambio de Datos, deberán notificarlo, vía correo electrónico, a la dirección general de la CNBV encargada de su supervisión. En dicha notificación se deberán señalar las razones que justifiquen la interrupción del acceso a la información y los supuestos de incumplimiento a los términos y condiciones pactados, adjuntando la evidencia de tales incumplimientos.
Artículo 8.- Los Proveedores de Datos deberán presentar ante la CNBV, para su autorización, registro y, en su caso, modificación, las contraprestaciones que pretendan cobrar a los Solicitantes de Datos por el intercambio de Datos, debiendo proporcionar, por cada tipo de API, el método, la información y las variables empleadas para determinar las contraprestaciones, así como cualquier otra consideración utilizada en tal determinación.
Los Proveedores de Datos para efectos de realizar el registro de las contraprestaciones, deberán presentar la siguiente información:
I.     Nombre, denominación o razón social, sin abreviaturas.
II.     En su caso, nombre comercial.
III.    Registro Federal de Contribuyentes.
IV.   Nombre de la API a la cual aplicará la contraprestación.
V.    Descripción del método empleado para determinar la contraprestación.
VI.   Monto de la contraprestación, en moneda nacional.
VII.   Número telefónico de las personas encargadas de implementar la API.
VIII.  Correo electrónico de las personas encargadas de implementar la API.
IX.   Periodicidad con la que la contraprestación será exigible, o bien, algún otro parámetro utilizado.
El procedimiento para la autorización de las contraprestaciones, así como para su incremento o reducción, se ajustará a lo establecido en el artículo 76 de la Ley.
Capítulo IV
De los programas de regularización
Artículo 9.- Las Entidades Financieras, las ITF, las sociedades autorizadas por la CNBV para operar con Modelos Novedosos y los transmisores de dinero, en el supuesto previsto en el párrafo décimo segundo del artículo 76 de la Ley y al ejercer su derecho de audiencia, podrán presentar, para aprobación de la CNBV, un programa de regularización, el cual deberá contemplar, cuando menos, los requisitos siguientes:
I.     Señalar las acciones que habrán de implementar para observar las obligaciones previstas en las presentes disposiciones que hayan incumplido.
II.     Especificar las etapas y plazos de cada una de las acciones a implementar, así como las personas responsables de llevar a cabo tales acciones. En ningún caso la ejecución y cumplimiento del programa de regularización deberá exceder de 3 meses contados a partir de su autorización.
III.    Las medidas tendientes a prevenir nuevos incumplimientos.
La CNBV tendrá 20 días hábiles, contados a partir de que reciba el programa de regularización respectivo, para resolver al respecto. La CNBV podrá prevenir al interesado, por una sola ocasión y dentro de los 10 días hábiles al plazo que tiene para resolver, de la falta de requisitos en el contenido del programa o para solicitar mayor información; por lo que, en estos casos, se ampliará por 5 días hábiles más, el plazo para que la CNBV resuelva lo conducente.
El interesado tendrá 5 días hábiles contados a partir de que reciba la prevención de la CNBV, para atender el requerimiento de información; de lo contrario, la CNBV resolverá con la información con la que cuente.
TRANSITORIO
ÚNICO. - Las presentes disposiciones entrarán en vigor el día siguiente al de su publicación en el Diario Oficial de la Federación.
Atentamente
Ciudad de México a 16 de abril de 2020.- El Presidente de la Comisión Nacional Bancaria y de Valores, Juan Pablo Graf Noriega.- Rúbrica.
ANEXO 1
LINEAMIENTOS DE SEGURIDAD PARA DATOS ABIERTOS QUE DEBERÁN OBSERVAR
PROVEEDORES DE DATOS Y SOLICITANTES DE DATOS
1. Glosario de términos
Para efectos de este documento, se utilizarán las siguientes definiciones:
I.        Autoridad Certificadora: Entidad que cuenta con la infraestructura tecnológica para la emisión, administración y registro de certificados digitales, así como para proporcionar servicios relacionados con los mismos.
II.       HTTPS: Siglas en inglés de Hypertext Transfer Protocol Secure, protocolo de comunicación segura para transmitir información a través de Internet.
III.      JSON: Siglas en inglés de JavaScript Object Notation, formato de datos utilizado en comunicaciones de servidores de navegación informática
IV.      JSON Web Token (JWT): Es un estándar abierto basado en JSON propuesto por Internet Engineering Task Force (IETF) para la creación de Tokens de Acceso que permiten la propagación de identidad y privilegios.
V.       Métodos HTTP: Las acciones que se pueden ejecutar en una API, utilizando el protocolo HTTP. Los métodos principales son:
a)    GET: Es el método que se utilizará para la lectura de los recursos disponibles a través de
APIs. Para efectos de estos lineamientos se entenderá como recursos, a los datos que se pueden obtener de las APIs.
b)    POST/PUT: Es el método que crea o modifica datos relacionados a una URL (siglas en inglés de Uniform Resource Locator) existente.
c)     DELETE: Es el método que elimina un dato.
VI.      OAuth 2.0: Estructura de autorización que le permite a las aplicaciones obtener acceso limitado a cuentas de usuario en un servicio HTTP. Delega la autenticación del usuario al servicio que aloja la cuenta del mismo y autoriza a las aplicaciones de terceros el acceso a dicha cuenta de usuario.
VII.     RFC: Siglas en inglés de Request For Comments, documentos que definen estándares y protocolos para las mejores prácticas del uso y la programación de Internet publicados por la IETF. Cada documento RFC se identifica por una clave numérica.
VIII.    TLS: Siglas en inglés de Transport Layer Security, protocolo de criptografía diseñado para garantizar la seguridad de la información cuando esta es comunicada a través de una red informática.
IX.      Tokens de Acceso: Identificador alfanumérico único que permite el acceso del Solicitante de Datos a la API proporcionada por el Proveedor de datos para el consumo de los datos.
2. Estándar
2.1. Seguridad de las sesiones
El Proveedor de Datos deberá de utilizar el protocolo HTTPS con el objetivo de garantizar el cifrado de la información durante el intercambio de la misma, para lo cual deberá:
I.        Utilizar certificados digitales por parte de los Proveedores de Datos, emitidos por Autoridades Certificadoras. El certificado digital empleado deberá basarse en el estándar internacional de infraestructura de llaves públicas conocido como X.509 (RFC 5280) implementando para ello el protocolo de criptografía conocido como TLS, en la versión que se encuentre vigente al momento de la implementación de los mecanismos de seguridad.
II.       Verificar que dentro de la configuración del protocolo HTTPS, se observe lo siguiente:
a)   Restricción de Métodos HTTPS: El Proveedor de Datos rechazará las peticiones de consulta realizadas a las APIs, cuando estas ejecuten Métodos HTTPS diferentes a GET para el acceso a lectura de datos. El método POST/PUT se podrá utilizar solamente para efectos de autenticación.
b)   Implementación de HSTS (conocido como HTTP Strict Transport Security): Con el objetivo de especificar que los navegadores de internet solo puedan establecer conexiones mediante el protocolo seguro HTTPS.
c)   Valor del parámetro X-Content-Type-Options: Deberá de contener el valor "nosniff".
d)   Valor del parámetro X-Frame-Options. Deberá de contener el valor "deny".
El Proveedor de Datos deberá asegurar que dicha configuración considere la deshabilitación de protocolos que no cuenten con esquemas de seguridad en los componentes tecnológicos diferentes a la Infraestructura de APIs.
 
III.      Limitar el tipo de contenido que se podrá intercambiar a través de las APIs, el cual estará restringido al tipo "application/json". Las peticiones de consulta que se reciban con un tipo de contenido diferente serán rechazadas.
2.2. Seguridad de acceso
El Proveedor de Datos podrá identificar al Solicitante de Datos manteniendo la vigencia del Token de Acceso por un máximo de 30 días para la consulta de datos, utilizando alguno de los siguientes métodos:
I.        Llaves de Aplicación: (por sus siglas en inglés, API Keys) Token de Acceso proporcionado por el Proveedor de Datos al Solicitante de Datos para identificarlo.
II.       OAuth 2.0: Se debe de utilizar el flujo de "Client Credentials Grant" de OAuth 2.0 (de acuerdo con lo definido en el RFC 6749), generando un Token de Acceso de tipo JSON Web Token (JWT).
Asimismo, el Proveedor de Datos deberá generar y almacenar durante 1 año, las bitácoras de acceso para tener trazabilidad de los eventos del sistema, las cuales deben de contener como mínimo lo siguiente: Usuario, IP origen, IP destino, fecha, hora, nombre de la API, tipo de petición, versión, código de respuesta, respuesta.
2.3. Seguridad de desarrollo e infraestructura
El Proveedor de Datos implementará mecanismos, tanto a nivel desarrollo de software, como en la Infraestructura con la que provee el servicio de APIs, para mitigar ataques o intrusiones, tales como inyección de código, alteración de privilegios de acceso, fuga de información, denegación de servicio, entre otros, de manera que las peticiones de consulta de datos que provengan de los Solicitantes de Datos se encuentren revisadas y validadas antes de devolver cualquier tipo de información.
Para mitigar los ataques o intrusiones a los que se refiere el párrafo anterior, el Proveedor de Datos implementará un plan de actualización de los componentes de su Infraestructura cuando:
I.        Identifique vulnerabilidades.
II.       Identifique alguna brecha de seguridad.
III.      La Infraestructura se vuelva obsoleta, sin posibilidad de actualización.
IV.      Lo disponga la CNBV.
ANEXO 2
LINEAMIENTOS DE LA ARQUITECTURA DE DATOS PARA EL INTERCAMBIO DE INFORMACIÓN DE
DATOS ABIERTOS
Esta especificación permite a los Proveedores de Datos desarrollar puntos de consulta de API (API endpoints) estandarizados para que puedan ser accesados por los Solicitantes de Datos con el objetivo de desarrollar soluciones para el usuario final.
La especificación de API está basada en el formato de especificación API Swagger versión 2.0, la cual utiliza servicios REST y formato JSON para el intercambio de datos.
En este documento se contienen los elementos de arquitectura que deberán constituir la estructura de los mensajes transmitidos vía APIs, en particular:
1.       El significado de los encabezados y cómo deben ser aplicados en el contexto del Proveedor de Datos.
 
2.       Los mensajes de respuesta exitosa y de error que se devuelven como resultado de las peticiones de consulta de datos.
Estructura del Mensaje de Datos
Los Proveedores de Datos deberán construir el mensaje de datos conforme a la estructura antes mencionada; asimismo, se deberá considerar que todos los campos son obligatorios, a menos que se indique lo contrario. Para efectos de la construcción del mensaje de datos especificado, los Proveedores de Datos podrán utilizar herramientas de desarrollo diferentes a Swagger, siempre y cuando, las herramientas se apeguen a la especificación definida en el presente documento y el Anexo 3 de estas disposiciones.
 
Campos de la estructura del mensaje de acuerdo a la
especificación Swagger versión 2.0
Observaciones
Title
 
{
 
"swagger": "2.0",
 
"info": {
 
"version": "v1.0.0",
La versión de la especificación de API que se documenta.
"title": " Open data ATM API specification"
Título de la especificación de API que indica el Dato que se podrá compartir mediante esta.
"description": "Location and services offered by ATMs"
Descripción de la funcionalidad de la API.
},
 
 
 
Host
 
"host": " openapi.bankname.com",
Es la URI base del Proveedor de Datos
"basePath": "/v1.0.0",
Es la ruta del recurso. Para este caso, v1' se refiere a la versión de la especificación de API
"schemes": [
 
"https"
Indica que el esquema de comunicación de datos es HTTPS
]
 
 
 
Produces
 
"produces": [
 
" application/ json"
Indica cómo responderá la API. En este caso, la respuesta es una representación en formato JSON de la especificación contenida en la versión v1.0
 
 
 
Tags
 
"tags": [
 
{
 
"name": "ATM",
 
"description": "Endpoint to request ATM data"
Es una etiqueta que indica que las respuestas de datos se relacionan a un recurso de tipo ATM.
 
Paths
 
"paths": {
 
"/atms": {
Es el punto de consulta (endpoint, en inglés) para acceder al recurso
"get": {
El método de solicitud que se utiliza para acceder al recurso.
"tags": [
 
"ATM"
 
],
 
"description": "Gets a list of all `ATM` objects.",
Descripción de la funcionalidad del método GET
Parameters
Se refiere a valores que pueden ser incluidos como parte de la petición de consulta que causen que el recurso responda de una manera particular.
 
 
"parameters": [
 
{
 
"name": "If-Modified-Since",
Nombre del parámetro.
"type": "string",
El tipo de objeto que se espera que sea devuelto.
"description": "Used for conditional request, to retrieve data only if modified since a given data",
Descripción de la funcionalidad del parámetro. Evita que sea devuelta una carga útil(1) completa, si el recurso que se está consultando no ha sido actualizado desde la última vez en que se accedió al mismo.
"in": "header",
Especifica en donde se debe de devolver el valor, en este caso, en el encabezado del mensaje.
"required": false
Indica si el valor requiere ser devuelto o no. En este caso, no es requerido.
},
 
{
 
"name": "If-None-Match",
Nombre del parámetro.
"type": "string",
El tipo de objeto que se espera que sea devuelto.
"description": "Used for conditional request, to retrieve data only if the given Etag value does not match",
Descripción de la funcionalidad del parámetro. Evita que sea devuelta una carga útil completa, si el valor de la etiqueta Etag no coincide.
"in": "header",
Especifica en donde se debe devolver el valor, en este caso, en el encabezado del mensaje.
 
"required": false
Indica si el valor requiere ser devuelto o no. En este caso, no es requerido.
}
 
],
 
 
 
Responses
Respuestas de la API a la petición de consulta de Datos. Los códigos de respuesta que se muestran en esta especificación serán mandatorios, el detalle completo se puede consultar en la Tabla de Códigos HTTPS, misma que se describe en este documento. El Proveedor de Datos podrá incluir otros códigos de respuesta estándar, de los definidos por el protocolo HTTPS, en caso de que así lo considere.
 
 
"responses": {
 
"200": {
Es el código de respuesta estándar que devuelve el servidor después de la ejecución exitosa del método GET sobre el recurso ATM.
"description": "Successful response with a list of `ATM` data",
 
"headers": {
 
"Strict-Transport-Security": {
 
"type": "string",
 
"description": "HTTPS strict transport security header",
 
"default": "max-age=31536000"
Especifica el tiempo en segundos (un año) en el cual el recurso puede ser accedido mediante el protocolo HTTPS. El código de tiempo de este campo puede ser diferente siempre y cuando su valor no sea menor.
},
 
"Etag": {
 
"type": "string",
 
"description": "A unique ID identifying whether this resource has changed"
Un identificador único que especifica si el recurso ha sido actualizado o no.
},
 
"Cache-Control": {
 
"type": "string",
 
"description": "Describes how long this response can be cached",
 
"default": "max-age=15552000"
Indica que la respuesta puede ser almacenada de manera confiable (cached, en inglés) cierto tiempo antes de consultar al endpoint por alguna actualización. Tratándose de datos abiertos, se definen 6 meses (expresados en segundos), el valor se puede modificar siempre y cuando este número no sea menor.
 
},
 
"X-Frame-Options": {
 
"type": "string",
 
 
"description": "Prevent this request from being loaded in any iframes",
 
"default": "DENY"
Previene que la respuesta sea cargada en un marco o frame.
},
 
"X-Content-Type-Options": {
 
"type": "string",
 
"description": "Ensures each page has a content type and prevents browsers from doing MIME type sniffing",
 
"default": "nosniff"
Evita que se devuelva otro tipo de formato que no sea JSON
}
 
},
 
 
Schema y Meta Data
Es la información complementaria de la carga útil; son valores que se deben incluir en el cuerpo de dicha carga útil.
 
 
"schema": {
 
"type": "object",
Devuelve un tipo de objeto JSON con los metadatos: LastUpdated; TotalResults; Agreement; License y TermsOfUse.
"properties": {
 
"meta": {
 
"title": "Meta data",
 
"type": "object",
 
"properties": {
 
"LastUpdated": {
 
"type": "string",
 
"format": "date-time"
Indica cuándo la carga útil del endpoint fue actualizada la última vez.
},
 
"TotalResults": {
 
"type": "integer"
Indica el número de registros en la carga útil
},
 
"Agreement": {
Hace referencia a que existe un acuerdo definido por cada Proveedor de Datos para el uso de la API con relación a los términos y condiciones que establezca dicho Proveedor de Datos.
"type": "string",
 
"enum": [
 
" El uso de la API y el dato que sea intercambiado a través de esta será sujeto a los términos y condiciones establecidos por el Proveedor de Datos"
 
]
 
},
 
"License": {
El contenido de los campos License y TermsOfUse será definido por el acuerdo que cada Institución realice con el Solicitante de Datos.
"description": "To be confirmed",
 
"type": "string",
 
"format": "uri",
 
 
"enum": [
 
" To be confirmed"
 
]
 
},
 
"TermsOfUse": {
 
"description": " To be confirmed",
 
"type": "string",
 
"format": "uri",
 
"enum": [
 
"To be confirmed"
 
]
 
}
 
},
 
"required": [
 
"LastUpdated",
Indica que estos metadatos deben ser devueltos en cada respuesta.
"TotalResults",
Indica que estos metadatos deben ser devueltos en cada respuesta.
"Agreement",
Indica que estos metadatos deben ser devueltos en cada respuesta.
"License",
Indica que estos metadatos deben ser devueltos en cada respuesta.
"TermsOfUse"
Indica que estos metadatos deben ser devueltos en cada respuesta.
],
 
"additionalProperties": false
 
 
Se puede consultar una versión implementada en la siguiente liga: https://app.swaggerhub.com/apis/CNBV9/atm_open_data_specification/1.0.0
Tabla de Códigos HTTPS
Código de respuesta
Descripción en inglés
Descripción en español
200
Successful response with a list of `ATM` data.
Respuesta exitosa con una lista de datos del Cajero Automático
400
You have sent a request which could not be understood.
Usted ha enviado una solicitud de consulta que no se entiende.
408
Your client has failed to submit a request, and a timeout has occurred.
La solicitud de consulta ha fallado y el tiempo ha caducado.
429
You have requested this resource too often.
Usted ha solicitado consultar este recurso demasiadas veces.
500
An error occurred on the server.
Un error ha ocurrido en el servidor.
503
The service is temporarily unavailable.
El servicio no está disponible temporalmente.
 
Lineamientos relacionados con capacidades de la solución
I.        El Proveedor de Datos podrá limitar el número de solicitudes a la API para mejorar el desempeño utilizando el algoritmo de bucket de tokens, esto mediante la configuración de dos parámetros:
a)    Límite de razón de solicitudes (en inglés rate limit) a 3,000 por segundo, que representa el máximo de solicitudes que la API puede atender de forma estable, consistente y exitosa en un periodo de tiempo.
b)    Límite de ráfaga (en inglés throttling) a 1,000 que representa el número máximo de solicitudes atendidas simultáneamente (1 milisegundo) por la API, sin devolver respuestas 429.
II.       El Proveedor de Datos podrá cumplir con un nivel de servicio de 5 segundos como tiempo de respuesta por petición a la API, considerando un tamaño máximo de 5MB en la respuesta.
 
ANEXO 3
DICCIONARIO DE DATOS ABIERTOS DE CAJEROS AUTOMÁTICOS
Aclaraciones sobre el uso del diccionario de datos
Elemento
Aclaración
Categorías Mandatorios/Opcionales
Cuando la categoría es opcional, la designación de M/O de los subcampos solo aplica si esa categoría es utilizada.
Columna K - Presence
Esta columna explica el número de veces que se podrá encontrar información en esa categoría.
Mandatory = Mandatory . Presence = 1...many
Esto indica que la categoría es obligatoria y se espera como mínimo de 1 contenido de información hasta varios.
Mandatory = Mandatory . Presence = 1...1
Esto indica que el subcampo es obligatorio y se espera 1 contenido de información solamente.
Mandatory = Optional . Presence = 0...1
Esto indica que la categoría o subcampo es opcional y se espera 1 contenido de información si es seleccionada.
Mandatory = Optional . Presence = 0...many
Esto indica que la categoría o subcampo es opcional y se esperan varios campos de información si es seleccionada.
Postal Address - AddressLine con Presence = 0..7
La razón es que, aunque hayan 6 subcategorías, se permite repetir una de ellas en caso de que la longitud del campo lo requiera.
Consulta de Movimientos - Codigo ATTS
El código ATTS - Consulta de Movimientos, se refiere a consulta de movimientos para clientes del mismo banco.
 
Vista técnica

Vista Jerárquica
 

Listado de Códigos
CATEGORIA
CAMPOS
CODE NAME SPANISH
SPANISH DEFINITION
ATM SERVICES
 
 
 
 
ATBA
ConsultaDeSaldo
Consulta de Saldo
 
ATBP
PagoServiciosEfectivoOnUs
Pago de Servicios en Efectivo Clientes Propios
 
ATBB
PagoServiciosEfectivoOffUs
Pago de Servicios en Efectivo Otros Clientes
 
ATBM
PagoServiciosCargoACuentaOnUs
Pago de Servicios con Cargo a Cuenta Clientes Propios
 
ATBO
PagoServiciosCargoACuentaOffUs
Pago de Servicios con Cargo a Cuenta Otros Clientes
 
ATCA
DepositosEfectivo
Depósitos de Efectivo
 
ATCD
Donativos
Donativos
 
ATCQ
DepositosCheques
Depósitos de Cheques
 
ATCT
RetiroConTarjeta
Retiro con tarjeta
 
ATST
RetiroSinTarjeta
Retiro sin tarjeta
 
ATFC
RetiroRapido
Montos predeterminados para retiro de efectivo rápido como
primera opción después de autenticar al cliente
 
ATMB
RegistroBancaMovil
Registro de servicios de Banca Móvil
 
ATMP
RegistroWallets
Registro de/asociación de wallets
 
ATMM
CompraTiempoAireClienteMismoBanco
Compra tiempo aire cliente mismo banco
 
ATMO
CompraTiempoAireClienteOtrosBancos
Compra tiempo aire cliente otros bancos
 
ATOS
EnvioEstadoCuenta
Solicitud de envío de estado de cuenta
 
ATOT
Otro
Otro
 
ATPA
ActivacionTarjeta
Activación de tarjeta
 
ATPC
CambiodeNIP
Cambio de NIP
 
ATPU
DesbloqueoNIP
Desbloqueo de NIP
 
ATIC
ConsultaCLABE
Consulta de cuenta CLABE
 
ATCM
ConsultaSaldoCreditosONUS
Consulta de Saldos de Créditos que el cliente tenga con el
banco: Ej. Crédito de nómina - Mismo Banco
 
ATCO
ConsultaSaldoCreditosOffUs
Consulta de Saldos de Créditos que el cliente tenga con otro
banco: Ej. Crédito de nómina - Otros Bancos
 
 
ATTM
TransferenciaTercerosOnUs
Transferencias entre cuentas mismo banco
 
ATTO
TransferenciaTercerosOffUs
Transferencias entre cuentas de otros bancos
 
ATTC
TransferenciaCuentaPropia
Transferencias entre cuentas propias del cliente
 
ATPM
PagoTarjetaOnUs
Pago de tarjeta mismo banco
 
ATPO
PagoTarjetaOffUs
Pago de tarjeta otros bancos
 
ATTS
ConsultaMovimientos
Consulta de Movimientos
 
 
 
 
ATM ACCESSIBILITY
 
 
 
 
ATAC
EntradaAudifonos
Entrada para audífonos
 
ATAD
PuertasAutomaticas
Puertas automáticas
 
ATER
RampaAccesoExterna
Rampa de acceso externa
 
ATIR
RampaAccesoInterna
Rampa de acceso interna
 
ATLA
AccesoSinEscalerasORampas
Acceso que no requiere subir/bajar escaleras o rampas
 
ATLL
AlturaSillaRuedas
Altura adecuada para usuarios con silla de ruedas
 
ATOT
OtrasUbicaciones
Otros ambientes, como por ejemplo aeropuerto, centros
comerciales
 
ATPT
PantallaTouch
Equipo de autoservicio con pantalla touch
 
ATWA
AccesoSillaRuedas
Acceso para silla de ruedas
 
 
 
 
LOCATION CATEGORY
 
 
 
 
ATBE
AccesoIndependienteASucursal
Con acceso independiente a la sucursal
 
ATBI
InteriorSucursal
Ubicado al interior de la sucursal, disponible durante
horarios de servicio
 
ATBL
LobbySucursal
Ubicado en el lobby accesible por clientes del banco
 
ATOT
OtrasUbicaciones
Otros ambientes, como por ejemplo aeropuerto, centros
comerciales
 
ATRO
UbicadoComercio
Cajero ubicado en un comercio
 
ATRU
UnidadMovil
Cajero es parte de una unidad bancaria móvil
Listado de Objetos y Atributos
XPath
FieldName
CodeName Spanish
Spanish Definition
CodeName
Field/Code Description
Constraint(s) rule
Mandatory
Presence
Pattern
ISO Data Type / DataType
Comment
openBankingATM
openBankingATM
NA
NA
Environment of the ATM.
 
openBankingATM/Brand
Brand
Marca
Marca del adquirente de las transacciones capturadas en el Cajero Automático
Brand of the Acquirer of transactions captured by the ATM
Mandatory
1..many
 
openBankingATM/Brand/BrandName
BrandName
NombreMarca
Nombre o marca usada por una organización para identificar sus productos o servicios
Brand Name that an organization uses to market its products or services to a consumer
Mandatory
1
Max140Text
 
openBankingATM/Brand/ATM
ATM
ATM
Información sobre el Cajero Automático
ATM information.
Mandatory
1..many
AutomatedTellerMachine10
 
openBankingATM/Brand/ATM/Identification
Identification
IDCajero
ID de Cajero
ATM terminal device identification for the acquirer and the issuer.
Mandatory
1..1
Max35Text
 
openBankingATM/Brand/ATM/SupportedLanguages
SupportedLanguages
LenguajesDisponibles
Lenguajes disponibles que contiene el ATM
Identification of the language name according to the ISO 639-1 codes. The type is validated by the list of values coded with two alphabetic characters, defined in the standard.
Optional
0..many
[a-z]{2}
ISO2ALanguageCode
 
openBankingATM/Brand/ATM/ATMServices
ATMServices
ServiciosATM
Servicios ATM
Describes the type of transaction available for a customer on an ATM.
C2:Only those CodeNames that are in the codelist can be supplied. If there is a missing code, then use 'OTHER' and fill out the CodeName and Description in the "OtherCodeType" block
Mandatory
1..many
ATMServiceType1Code
 
openBankingATM/Brand/ATM/ATMServices:code:ATBA
ConsultaDeSaldo
Consulta de Saldo
Balance
Balance inquiry.
 
openBankingATM/Brand/ATM/ATMServices:code:ATBP
PagoServiciosEfectivoOnUs
Pago de Servicios en Efectivo Clientes Propios
BillPayments
Funds transfer to pay a third party.
 
openBankingATM/Brand/ATM/ATMServices:code:ATBB
PagoServiciosEfectivoOffUs
Pago de Servicios en Efectivo Otros Clientes
 
openBankingATM/Brand/ATM/ATMServices:code:ATBM
PagoServiciosCargoACuentaOnUs
Pago de Servicios con Cargo a Cuenta Clientes Propios
 
openBankingATM/Brand/ATM/ATMServices:code:ATBO
PagoServiciosCargoACuentaOffUs
Pago de Servicios con Cargo a Cuenta Otros Clientes
 
openBankingATM/Brand/ATM/ATMServices:code:ATCA
DepositosEfectivo
Depósitos de Efectivo
CashDeposits
Deposit of cash
 
openBankingATM/Brand/ATM/ATMServices:code:ATCD
Donativos
Donativos
CharityDonation
Funds transfer to make a charity donation
 
openBankingATM/Brand/ATM/ATMServices:code:ATCQ
DepositosCheques
Depósitos de Cheques
ChequeDeposits
Deposit of cheques
 
openBankingATM/Brand/ATM/ATMServices:code:ATCT
RetiroConTarjeta
Retiro con tarjeta
 
openBankingATM/Brand/ATM/ATMServices:code:ATST
RetiroSinTarjeta
Retiro sin tarjeta
 
openBankingATM/Brand/ATM/ATMServices:code:ATFC
RetiroRapido
Montos predeterminados para retiro de efectivo rápido como primera opción después de autenticar al cliente
FastCash
Deposit of media items verified by the ATM.
Se acordó que la definición de este campo se aplica al uso en México, por lo cual la definición en Inglés es diferente a la acordada en Español.
openBankingATM/Brand/ATM/ATMServices:code:ATMB
RegistroBancaMovil
Registro de servicios de Banca Móvil
MobileBankingRegistration
The ATM is capable of registering the user for mobile banking
 
openBankingATM/Brand/ATM/ATMServices:code:ATMP
RegistroWallets
Registro de/asociación de wallets
MobilePaymentRegistration
The ATM is capable of registering the user for Mobile Payment Services
 
openBankingATM/Brand/ATM/ATMServices:code:ATMM
CompraTiempoAireClienteMismoBanco
Compra tiempo aire cliente mismo banco
 
 
openBankingATM/Brand/ATM/ATMServices:code:ATMO
CompraTiempoAireClienteOtrosBancos
Compra tiempo aire cliente otros bancos
 
openBankingATM/Brand/ATM/ATMServices:code:ATOS
EnvioEstadoCuenta
Solicitud de envío de estado de cuenta
OrderStatement
The ATM is capable of ordering a bank statement
 
openBankingATM/Brand/ATM/ATMServices:code:ATOT
Otro
Otro
Other
Fillout OtherATMService fields with code name and description of an ATM service which is not in the standard code list.
 
openBankingATM/Brand/ATM/ATMServices:code:ATPA
ActivacionTarjeta
Activación de tarjeta
PINActivation
The ATM is capable of activating a debit card using a PIN
 
openBankingATM/Brand/ATM/ATMServices:code:ATPC
CambiodeNIP
Cambio de NIP
PINChange
Modification of the card PIN value.
 
openBankingATM/Brand/ATM/ATMServices:code:ATPU
DesbloqueoNIP
Desbloqueo de NIP
PINUnblock
Unblock the PIN.
 
openBankingATM/Brand/ATM/ATMServices:code:ATIC
ConsultaCLABE
Consulta de cuenta CLABE
ConsultaCLABE
 
openBankingATM/Brand/ATM/ATMServices:code:ATCM
ConsultaSaldoCreditosOnUs
Consulta de Saldos de Créditos que el cliente tenga con el banco: Ej. Crédito de nómina - Mismo Banco
ConsultaSaldoCreditosONUS
 
openBankingATM/Brand/ATM/ATMServices:code:ATCO
ConsultaSaldoCreditosOffUs
Consulta de Saldos de Créditos que el cliente tenga con otro banco: Ej. Crédito de nómina - Otros Bancos
ConsultaSaldoCreditosOFFUS
 
openBankingATM/Brand/ATM/ATMServices:code:ATTM
TransferenciaTercerosOnUs
Transferencias entre cuentas mismo banco
TransferenciaTercerosONUS
 
openBankingATM/Brand/ATM/ATMServices:code:ATTO
TransferenciaTercerosOffUs
Transferencias entre cuentas de otros bancos
TransferenciaTercerosOFFUS
 
openBankingATM/Brand/ATM/ATMServices:code:ATTC
TransferenciaCuentaPropia
Transferencias entre cuentas propias del cliente
TransferenciaCuentaPropia
Transferencias entre cuentas propias del cliente
 
openBankingATM/Brand/ATM/ATMServices:code:ATPM
PagoTarjetaOnUs
Pago de tarjeta mismo banco
PagoTarjetaONUS
 
openBankingATM/Brand/ATM/ATMServices:code:ATPO
PagoTarjetaOffUs
Pago de tarjeta otros bancos
PagoTarjetaOFFUS
 
openBankingATM/Brand/ATM/ATMServices:code:ATTS
ConsultaMovimientos
Consulta de Movimientos
 
Ask for account mini statement information to a related customer account.
 
openBankingATM/Brand/ATM/Accessibility
Accessibility
Accesibilidad
Accesibilidad. Lista de Opciones
Indicates Types of Accessibility
C2:Only those CodeNames that are in the codelist can be supplied. If there is a missing code, then use 'OTHER' and fill out the CodeName and Description in the "OtherCodeType" block
Optional
0...many
PointOfInteractionCapabilities7
 
openBankingATM/Brand/ATM/Accessibility:code:ATAC
EntradaAudifonos
Entrada para audífonos
AudioCashMachine
The ATM has a headphone jack
 
openBankingATM/Brand/ATM/Accessibility:code:ATAD
PuertasAutomaticas
Puertas automáticas
AutomaticDoors
Access to the ATM is provided by automatic doors
 
openBankingATM/Brand/ATM/Accessibility:code:ATER
RampaAccesoExterna
Rampa de acceso externa
ExternalRamp
Access to the ATM is provided by means of an external ramp
 
openBankingATM/Brand/ATM/Accessibility:code:ATIR
RampaAccesoInterna
Rampa de acceso interna
InternalRamp
Access to the ATM is provided by means of an internal ramp
 
openBankingATM/Brand/ATM/Accessibility:code:ATLA
AccesoSinEscalerasORampas
Acceso que no requiere subir/bajar escaleras o rampas
LevelAccess
Level access to the ATM not impeded by any step or ramp
 
openBankingATM/Brand/ATM/Accessibility:code:ATLL
AlturaSillaRuedas
Altura adecuada para usuarios con silla de ruedas
LowerLevelCounter
Access to the ATM is at a low level suitable for wheelchair users
 
 
openBankingATM/Brand/ATM/Accessibility:code:ATOT
OtrasUbicaciones
Otros ambientes, como por ejemplo aeropuerto, centros comerciales
Other
Used to indicate that the code is not in this standard accessibility list. Note: OtherAccessibility can be used to supply the code, name and description.
 
openBankingATM/Brand/ATM/Accessibility:code:ATPT
PantallaTouch
Equipo de autoservicio con pantalla touch
PantallaTouch
xs:boolean
 
openBankingATM/Brand/ATM/Accessibility:code:ATWA
AccesoSillaRuedas
Acceso para silla de ruedas
WheelchairAccess
The ATM is accessible by wheelchair users
 
openBankingATM/Brand/ATM/Access24HoursIndicator
Access24HoursIndicator
IndicadorAcceso24Horas
Indicador de acceso al ATM las 24 horas
Indicates that the ATM is available for use by customers 24 hours per day
Optional
0..1
xs:boolean
 
openBankingATM/Brand/ATM/SupportedCurrencies
SupportedCurrencies
DivisasDisponibles
Divisas disponibles
All ISO 4217 defined currency supported by the ATM.
Mandatory
1..many
[A-Z]{3}
ActiveCurrencyCode
 
openBankingATM/Brand/ATM/MinimumPossible Amount
MinimumPossibleAmount
MontoMinimoPermitido
Monto mínimo permitido para la transacción
Minimum amount allowed for a transaction in the service.
Optional
0..1
^-?\\d{1,10}\\.?\\d{0,2}$
Este código designa monto y centavos. El signo "$" al final marca que no pueden ser otros números de dígitos o formato que no sea ese. La moneda está determinada en Supported Currencies.
openBankingATM/Brand/ATM/Note
Note
DescripcionAdicional
Descripción adicional sobre el ATM
Summary description of the ATM.
Optional
0..many
Max2000Text
 
openBankingATM/Brand/ATM/OtherAccessibility
OtherAccessibility
OtraAccesibilidad
Código o nombre que describa cualquier otra opción de accesibilidad
Enter a new code , name and description for any other ATM accessibility options
Optional
0..many
OB_OtherCodeType1