MX2014013530A - Sistemas y metodos para el acceso a cuentas en tiempo real. - Google Patents

Sistemas y metodos para el acceso a cuentas en tiempo real.

Info

Publication number
MX2014013530A
MX2014013530A MX2014013530A MX2014013530A MX2014013530A MX 2014013530 A MX2014013530 A MX 2014013530A MX 2014013530 A MX2014013530 A MX 2014013530A MX 2014013530 A MX2014013530 A MX 2014013530A MX 2014013530 A MX2014013530 A MX 2014013530A
Authority
MX
Mexico
Prior art keywords
account
transaction
financial
financial institution
request
Prior art date
Application number
MX2014013530A
Other languages
English (en)
Inventor
Neil Marcous
Robert Woodbury
Peter Gordon
Original Assignee
Paynet Payments Network Llc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US14/081,590 external-priority patent/US10535064B2/en
Application filed by Paynet Payments Network Llc filed Critical Paynet Payments Network Llc
Publication of MX2014013530A publication Critical patent/MX2014013530A/es

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G06Q20/027—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] involving a payment switch or gateway
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Se proveen sistemas, métodos, y medios legibles por computadora para procesar y liquidar transacciones financieras. Un método ejemplar comprende recibir una transacción desde un ordenante. La transacción comprende información asociada con una identificación de un usuario iniciador o la cuenta. El método comprende determinar el número de cuenta real, transmitir una petición de transacción de servicios financieros que comprende el número de cuenta real a una institución financiera, recibir una respuesta, y transmitir una respuesta de regreso al ordenante. Otro método comprende recibir, desde el dispositivo de un usuario, una petición para asociar una cuenta financiera con una cuenta de usuario. El método comprende generar y enviar un mensaje de asociación con una red de pagos y recibir una clave asociada con la cuenta financiera para usarse en la iniciación de transacciones financieras. Otro método comprende utilizar tal clave para generar y procesar una petición de transacción. También se proveen otros sistemas, métodos, y medios.

Description

SISTEMAS Y MÉTODOS PARA EL ACCESO A CUENTAS EN TIEMPO REAL Campo de la Descripción Las modalidades descritas se dirigen generalmente a sistemas y métodos para el acceso a cuentas en tiempo real.
Antecedentes de la Invención Referencias a solicitudes relacionadas Esta solicitud es una continuación en parte de y reivindica la prioridad de la Solicitud de Patente de los Estados Unidos de América No. 13/835,452, presentada el 15 de Marzo del 2013, la cual reivindica una prioridad de la Solicitud Provisional de los Estados Unidos de América No. 61/612,897, presentada el 19 de Marzo del 2012, ambas de las cuales son incorporadas aquí como referencias en la presente solicitud.
Las infraestructuras de procesamiento de red, tales como el procesamiento de red EFT (Electronic Funds Transfer: Transferencia Electrónica de Fondos), son usadas para procesar pagos a partir de transacciones tradicionales de tarjetas de crédito o tarjetas de débito. La EFT permite proveer información de la cuenta y otra información relacionada para débitos, créditos, transferencias de cuenta a cuenta, compras, pagos de facturas, y para otros propósitos. Por ejemplo, cuando un tarjetahabiente busca comprar un artículo en una tienda, el tarjetahabiente generalmente entregará su tarjeta al comerciante y el comerciante deslizará la tarjeta a través de una terminal capaz de leer la información de la cinta magnética para leer la información de la tarjeta. La información de la tarjeta incluye, por ejemplo, un número de tarjeta, fecha de vencimiento, y el nombre del tarjetahabiente. Los números de la tarjeta típicamente son de 13 a 19 dígitos de largo, y únicamente identifican la cuenta de crédito o débito del usuario.
Después de que el número de tarjeta es capturado por la terminal del comerciante, la terminal del comerciante envía información sobre la tarjeta y la transacción, tal como, por ejemplo, el número de tarjeta, la fecha de vencimiento, el nombre del tarjetahabiente, el precio de la transacción, la fecha de la transacción, el tiempo de la transacción, y la ubicación de la transacción, a una red de pagos. El primer conjunto de dígitos en el número de tarjeta normalmente identifica la compañía del pago o la autoridad de registro que licenció o registró el prefijo de la tarjeta al “emisor” (por ejemplo, la institución financiera que expidió la tarjeta). De este modo, por ejemplo, un número de tarjeta que comienza con “4", por ejemplo, 4000 1234 56789012, identifica a VISA como la compañía de pago que licenció el prefijo de la tarjeta a un emisor de tarjeta en particular. Cada emisor de institución financiera típicamente tiene un conjunto de identificadores numéricos (prefijos de tarjeta) que son usados en las tarjetas que expidió (por ejemplo, un número de cifras iniciales en el número de la tarjeta). La red de pago dirige la información recibida desde la terminal del comerciante al emisor de la tarjeta apropiado en base al número de la tarjeta.
El emisor apropiado (en el caso de una transacción de tarjeta, una institución financiera o su procesador de autorización de transacción contratado) entonces consultará sus registros para determinar la cuenta apropiada y verificar si la cuenta contiene suficientes fondos o crédito disponible para autorizar una transacción (por ejemplo, una compra). El resultado de esta determinación es regresado para informar al comerciante si el tarjetahabiente puede comprar el artículo.
Sin embargo, este proceso requiere que el tarjetahabiente dé a una entidad que potencialmente no es de confianza (el comerciante) un número de tarjeta identificable único. Un empleado deshonesto del comerciante o una persona no autorizada que intercepte los datos de la tarjeta puede intentar reusar el número de tarjeta sin el permiso del tarjetahabiente, por ejemplo, para comprar artículos para sí mismo o para obtener dinero en efectivo en un cajero automático.
Adicionalmente, en algunas situaciones, no está disponible un número de tarjeta para tener acceso a la cuenta del cliente. Por ejemplo, si un cliente decide pagar con cheque, el comerciante debe capturar el RTN (Número de Transito de Ruta) para la institución financiera que expidió el cheque y el número de cuenta personal del cliente. El comerciante debe entonces usar un servicio provisto por un banco o un proveedor de aceptación de cheques para tener acceso a la cámara de compensación automatizada (Automated Clearing House, ACH), pedir que el cheque sea liberado, y pedir un crédito. El sistema ACH se maneja por lotes y de este modo el proceso para financiar una compra puede tomar mucho más tiempo que una transacción basada en tarjeta. De este modo, el uso de cheques como pago aumenta la cantidad de tiempo que el comerciante requiere para adquirir los fondos prometidos. El uso de la ACH incluye una posibilidad de aceptar pagos que después se sabe no son susceptibles de recolectarse (también conocidos como “cheques rebotados”). Los comerciantes pueden emplear proveedores de garantía de cheques para reducir el riesgo. Sin embargo, tales proveedores típicamente cargan un alto porcentaje del monto del cheque, haciendo que este servicio sea potencialmente más caro que un pago de tarjeta de crédito o débito.
Son deseables mejoras en las téenicas para procesar transacciones financieras.
Compendio de la Invención En una modalidad descrita, un primer método es descrito para procesar transacciones financieras en una red de pagos. El método comprende recibir, desde un dispositivo ordenante, una petición de transacción asociada con un usuario inicial y una cuenta de una institución financiera. La petición de transacción comprende información asociada con una identificación del usuario iniciador o la cuenta de la institución financiera. El método además comprende determinar un identificador de cuenta para la cuenta en base a la identificación, y transmitir, sobre una red, una transacción de servicios financieros que comprende al identificador de cuenta asociado con la cuenta a una institución financiera asociada con la cuenta. El método además comprende el recibir, a partir de la institución financiera, una respuesta para la transacción de servicios financieros, y transmitir una respuesta a la petición de transacción al dispositivo ordenante.
También se describe un sistema para procesar transacciones financieras. El sistema comprende un sistema procesador (esto es, uno o más procesadores electrónicos) y una memoria que almacena instrucciones. Cuando se ejecutan, las instrucciones causan que el sistema del procesador lleve a cabo el primer método anteriormente referido.
En otra modalidad descrita, un segundo método se describe para asociar una cuenta de institución financiera y una cuenta ordenante. El método comprende el recibir desde un dispositivo de usuario una petición para asociar una cuenta de institución financiera con una cuenta ordenante. El método además comprende el generar un mensaje de asociación que incluye detalles acerca de la cuenta de la institución financiera, y enviar el mensaje de asociación a una red de pagos. El método comprende el recibir una respuesta de asociación, determinar si la respuesta de asociación incluye una clave asociada con la cuenta financiera, y si es así, almacenar la clave recibida parar usarla en peticiones de transacción iniciales y enviar una indicación al dispositivo del usuario de que las cuentas están asociadas.
También se describe un sistema para asociar una cuenta de institución financiera y una cuenta ordenante. El sistema comprende un sistema procesador (esto es, uno o más procesadores de transacción de fondos electrónicos) y una memoria que almacena instrucciones. Cuando se ejecutan, las instrucciones causan que el sistema procesador lleve a cabo el método anterior.
En otra modalidad descrita, se describe un tercer método para procesar peticiones de transacción. El método comprende recibir una petición de transacción desde un dispositivo asociado. La petición de transacción comprende una petición para iniciar una transacción en nombre de un usuario e información sobre una cuenta financiera. La petición de transacción no incluye un número de cuenta asociado con la cuenta financiera. El método además comprende incrementar un contador de transacción asociado con la cuenta financiera, determinar una clave asociada con la cuenta financiera, y generar un mensaje de transacción de servicios financieros. El mensaje de transacción de servicios financieros incluye un criptograma. El criptograma se basa en una clave determinada, información de la petición de transacción, y el contador de transacción. El método además comprende enviar el mensaje de transacción de servicios financieros a una red de pagos para su procesamiento.
También se describe un sistema para procesar transacciones financieras. El sistema comprende un sistema de procesador (esto es, uno o más procesadores de transacción de fondos electrónicos) y una memoria que almacena instrucciones. Cuando se ejecutan, las instrucciones causan que el sistema del procesador lleve a cabo el tercer método mencionado anteriormente.
En otra modalidad descrita, un cuarto método se describe para procesar peticiones de transacción. El método comprende recibir una petición de transacción desde un dispositivo asociado. La petición de transacción comprende una petición para iniciar una transacción en nombre de un usuario e información sobre una cuenta financiera. El método además comprende incrementar un contador de transacción asociado con la cuenta financiera, determinar una clave asociada con la cuenta financiera, y generar un mensaje de transacción de servicios financieros. El mensaje de transacción incluye un criptograma generado en base a la clave determinada, información de la petición de transacción, y el contador de transacción. El método además comprende enviar el mensaje de transacción de servicios financieros a una red de pagos.
También se describe un sistema para procesar las transacciones financieras. El sistema comprende un sistema procesador (esto es, uno o más procesadores de transacción de fondos electrónicos) y una memoria que almacena instrucciones. Cuando se ejecutan, las instrucciones causan que el sistema del procesador lleve a cabo el cuarto método anteriormente mencionado.
En otra modalidad descrita, se describe un quinto método para procesar peticiones de transacción. El método comprende recibir una petición de transacción desde un ordenante. La petición de transacción incluye un criptograma y no incluye un número de cuenta de la cuenta de la institución financiera. El método comprende determinar una clave asociada con la cuenta de la institución financiera y validar al criptograma usando la clave asociada con la cuenta de la institución financiera. El método además comprende determinar un identificador de cuenta de la cuenta de la institución financiera, generar una petición de transacción en base a información almacenada en el criptograma y el identificador de cuenta determinado, enviar la petición de transacción a una institución financiera, y recibir una respuesta. El método además comprende enviar una respuesta al ordenante.
También se describe un sistema para procesar transacciones financieras. El sistema comprende un sistema de procesador (esto es, uno o más procesadores de transacción de fondos electrónicos) y una memoria que almacena instrucciones. Cuando se ejecutan, las instrucciones causan que el sistema del procesador lleve a cabo el quinto método anteriormente referido.
Aspectos adicionales relacionados con las modalidades serán establecidos en parte en la descripción siguiente, y en parte serán obvias a partir de la descripción, o pueden aprenderse por medio de la práctica de las modalidades. Los dibujos que la acompañan, son incorporados y constituyen una parte de esta especificación, ilustran una variedad de modalidades y conjuntamente con la descripción, sirven para explicar los principios de las modalidades. Deberá entenderse que tanto la descripción general anterior como la descripción detallada siguiente son ejemplares y explicativas solamente y no son restrictivas de la invención, como se reivindica.
Breve Descripción de los Dibujos La Figura 1 ilustra una red ejemplar de dispositivos para implementar modalidades de la descripción.
La Figura 2 ilustra modalidades de una red de pagos consistente con las modalidades descritas.
La Figura 3 ilustra un proceso ejemplar para procesar una petición de transacción en una red de pagos, consistente con las modalidades descritas.
La Figura 4A ilustra un proceso ejemplar para inicializar las claves necesarias para un Punto Ordenante de Transacción (TOP) para trabajar en conjunto con una red de pagos, consistente con las modalidades descritas.
La Figura 4B ilustra un proceso ejemplar para asociar una cuenta de institución financiera con una cuenta de un usuario ordenante, consistente con las modalidades descritas.
La Figura 4C ilustra un proceso opcional ejemplar para asociar una cuenta de institución financiera con una cuenta de usuario con un usuario iniciador.
La Figura 4D ilustra un proceso ejemplar para usar un TOP para procesar una transacción, consistente con las modalidades descritas.
La Figura 5 ilustra un sistema de cómputo ejemplar para implementar las modalidades descritas.
Descripción de Modalidades Preferidas de la Invención Ahora se hará referencia en detalle a modalidades de la descripción, ejemplos de las cuales son ilustrados en los dibujos que la acompañan. Siempre que sea posible, los mismos números de referencia serán usados a través de todos los dibujos para referirse a las mismas o partes similares.
Modalidades de la descripción permiten, por ejemplo, el procesamiento de transacciones financieras usando redes de pago. Por ejemplo, una red de pago puede recibir una transacción desde un ordenante, tal como un comerciante o banco. La transacción puede comprender información asociada con una identificación de un usuario iniciador o una cuenta de institución financiera. La transacción, sin embargo, no contiene necesariamente un número de cuenta asociado con la cuenta de institución financiera. Usando la información de identificación, la red de pagos puede determinar un identificador de cuenta, y generar y enviar una petición de transacción de servicios financieros a una institución financiera. La red de pagos puede entonces recibir una respuesta a la petición de transacción de servicios financieros de la institución financiera, y puede transmitir una respuesta de regreso al ordenante. Otras modalidades y variaciones son explicadas aquí.
La Figura 1 ilustra un ejemplo de una red particular para implementar modalidades de esta descripción. La red ilustrada en la Figura 1 incluye bloques que representan un usuario iniciador 101, un ordenante 102, un procesador 103, una red de pagos 105, una base de datos 105A, un procesador receptor 106, un receptor 107, un Archivo de Información del Cliente (CIF) 107A, un procesador receptor exterior 108, un receptor exterior 109, y un CIF 109A. Cada bloque ilustrado en la Figura 1 puede ser implementado usando software, hardware, firmware, o una combinación de estos.
El usuario iniciador 101 representa un usuario que quiere iniciar una transacción usando un ordenante 102. El usuario iniciador 101, en algunas modalidades, usa un dispositivo, tal como un teléfono celular o computadora, que puede almacenar y ejecutar una aplicación de origen de transacción. La aplicación permite al usuario iniciador 101 originar una transacción, tal como una compra en línea, el pago de una factura, o similares. La aplicación de origen de transacción también permite enviar credenciales asociadas con el usuario iniciador 101 para iniciar tales transacciones. El usuario iniciador 101, en otras modalidades, representa un consumidor que provee un dispositivo de pago o testigo de autentificación (token) (como un nombre de usuario u otro identificador) al ordenante 102, con el fin de efectuar la transacción.
El ordenante 102 representa una entidad que inicia peticiones de transacción de servicios financieros en nombre del usuario iniciador 101. Las peticiones de transacción de servicios financieros pueden tomar muchas formas. En algunas modalidades, las peticiones pueden incluir solicitudes de balance (una petición para el balance actual en una cuenta), peticiones de autorización de cheque (para determinar si una cuenta tiene fondos suficientes para una compra hecha por cheque), peticiones de financiamiento de cuentas (para pedir que una nueva cuenta sea financiada usando una cuenta actual), validación de cuenta o peticiones de status (para determinar si la información acerca de una cuenta de institución financiera ofrecida por el usuario iniciador 101 es válida, abierta, en cobro, en buena posición, etcétera), peticiones de financiamiento de remesas internacionales, peticiones de financiamiento de pago de cuentas, peticiones de transferencia de fondos de persona a persona (P2P), peticiones de retiro, peticiones de compra, peticiones de reembolso, peticiones de crédito varias (productos de préstamos, productos de seguros, etcétera) peticiones de revocación/ajuste de transacción, o similares.
El ordenante 102 puede ser cualquiera de una institución financiera, una red de Transferencia Electrónica de Fondos (EFT), un comerciante o procesador de comercio, una plataforma de remesas, un servicio de pagos, un proveedor de monedero móvil, un servicio de remesas pre-pagadas por celular, o similares. Las instituciones financieras incluyen, por ejemplo, bancos, bancos de ahorro, uniones de credito, firmas de corretaje, o proveedores de fondos mutuos. Las instituciones financieras pueden, por ejemplo, procesar transacciones en nombre de un usuario iniciador 101 u otras entidades o transferir dinero entre cuentas en la institución financiera y/o cuentas fuera de la institución financiera. A diferencia de las redes de pago, las instituciones financieras administran cuentas en nombre de usuarios, por ejemplo, al mantener registros de los depósitos y retiros de la cuenta, y mantener un registro de un balance en la cuenta.
Los comerciantes incluyen, por ejemplo, comerciantes de ladrillos y mortero, comerciantes electrónicos o en línea, o proveedores de servicios que facturan a usuarios por servicios tales como operadores de teléfonos inalámbricos, compañías de servicios públicos, proveedores de seguros, o entidades de gobierno locales, estatales o federales. En algunas modalidades, los comerciantes están equipados para iniciar las transacciones de servicios financieros por ellos mismos. Sin embargo, en otras modalidades, los comerciantes pueden utilizar un procesador de comerciante para ese propósito. Los procesadores de comerciante reciben detalles de transacción financiera de los comerciantes y generan transacciones de servicios financieros correspondientes en nombre de los comerciantes. En otras palabras, los comerciantes pueden comunicar detalles de la transacción financiera a un procesador mercantil, y el procesador mercantil puede crear la transacción de servicios financieros para enviarla a la red de pagos.
Las redes de EFT incluyen redes interbancarias y otras redes de transferencia electrónica de fondos, las cuales permiten transferir fondos entre diferentes bancos. Las redes de EFT, en algunas modalidades, transfieren dinero usando transacciones de la Cámara de Compensación Automatizada (ACH) por lotes.
Las plataformas de remesas incluyen sistemas para enviar dinero de una persona a otra persona. Como un ejemplo de una plataforma de remesas conocida, el sistema de Western Union permite a una persona depositar dinero en el sistema y otro usuario recoge ese dinero en otra ubicación del sistema. Alguien capacitado en la téenica entenderá que otros tipos de plataformas de remesas son posibles también.
Los proveedores de monederos móviles incluyen sistemas que permitirán al usuario iniciador 101 utilizar un dispositivo móvil para transmitir detalles de la cuenta (tales como el Número de Transito de Ruta (RTN) y el número de cuenta o información alias para la cuenta) a un comerciante. En algunas modalidades, los proveedores de monedero móvil proveen aplicaciones móviles al usuario iniciador 101 que permiten al usuario iniciador 101 iniciar una transacción con un comerciante u ordenante.
El ordenante 102 recibe instrucciones del usuario iniciador 101 pidiendo que tenga lugar una transacción financiera. El ordenante 102 genera y envía una transacción de servicios financieros a otro dispositivo o entidad, la petición incluye información asociada con la transacción de servicios financieros solicitada por el usuario iniciador 101. Como ejemplo, el ordenante 102 (por ejemplo, una primera institución financiera) puede recibir instrucciones de un tarjetahabiente para enviar dinero a una cuenta en una segunda institución financiera. El ordenante 102 genera una transacción de servicios financieros y la envía al procesador 103.
El ordenante 102 puede recibir credenciales del usuario iniciador 101 para iniciar una transacción de servicios financieros. Las credencias del usuario iniciador 101 incluyen una o más formas de información usada para identificar al usuario iniciador 101. Las credenciales pueden incluir cuando menos uno de un testigo autentificador físico (tal como un dispositivo electrónico o mecanismo de pago similar a una tarjeta), información que el usuario iniciador 101 conoce (tal como un número de seguro social, nombre de usuario, dirección de correo electrónico, fecha de nacimiento, password o PIN, o similares), información que el usuario iniciador 101 tiene (tal como una cadena de caracteres generada dinámicamente), o similares.
En algunas modalidades, el ordenante 102 representa una entidad que el usuario iniciador 101 contacta por adelantado con el fin de registrarse como un usuario. El usuario iniciador 101 puede proveer información de credenciales tal como información asociada con una cuenta de depósito en una institución financiera, o información de identificación tal como un nombre, dirección, número de seguro social, o fecha de nacimiento, con el fin de registrarse con el ordenante 102. Este proceso de registro puede comprender el que el usuario iniciador 101 establezca información de credenciales nuevas para una relación entre el usuario iniciador 101 y el ordenante 102 (tal como una ID del usuario y un password establecidos específicamente para iniciar transacciones con el ordenante 102). Después, cuando se reciben instrucciones para una transacción financiera del usuario iniciador 101, el usuario iniciador 101 puede proveer tales credenciales al ordenante 102, el ordenante 102 puede llevar a cabo una búsqueda en una base de datos para determinar información necesaria para procesar las instrucciones, y el ordenante 102 puede entonces determinar cómo iniciar una transacción de servicios financieros respectiva, y puede generar una petición de transacción de servicios financieros correspondiente a la transacción.
En algunas modalidades, el ordenante 102 puede ser una “entidad patrocinada”. Las entidades patrocinadas son entidades que no son instituciones financieras pero son “patrocinadas” por una institución financiera que tiene una relación con la red de pagos 105. Una institución financiera que “patrocina” una entidad patrocinada asume todas las responsabilidades por las acciones o inacciones de la entidad patrocinada, incluyendo todas las transacciones de red de pago iniciadas por la entidad patrocinada. Un ejemplo de una entidad patrocinada sería un comerciante. La responsabilidad de liquidación de fondos asociados con transacciones sería asumida por la institución financiera que patrocina al comerciante.
En un modo de operación, “modo nativo”, el ordenante 102 crea una petición de transacción de servicios financieros que cumple con un estándar conocido, por ejemplo, el estándar ISO 8583. El ISO 8583 es un formato de comunicación estándar para sistemas que intercambian transacciones electrónicas hechas por tarjetahabientes que usan tarjetas de pago. En los mensajes ISO 8583 típicos, el número de cuenta primario (Primary Account Number: PAN) (tal como, por ejemplo, un número de tarjeta correspondiente a la cuenta que el usuario está usando para pagar una compra) se incluye en un campo conocido como el “campo PAN”. En algunas modalidades, este campo PAN puede estar en un rango de 13 dígitos a 19 dígitos de longitud. En algunas modalidades, las tarjetas de pago y los números de pago no son usados por el ordenante 102 en el procesamiento de las transacciones de servicios financieros. En estas modalidades, el ordenante 102 genera peticiones de transacción de servicios financieros que cumplen con el estándar ISO 8583, pero no incluyen un número de tarjeta de pago en el campo PAN. En el modo nativo, la petición de transacción de servicios financieros incluye información alternativa en el campo PAN. Esta información es referida como el “RTA” (“número de Cuenta y Transito de Ruta” [Routing Transit and Account number], también conocido como el “Número de Ruta de Cuenta” (ARN, Account Routing Number) o “PAN construido”). El RTA comprende un valor (por ejemplo, “59”) que indica que los dígitos que siguen al valor deben ser interpretados como información de la cuenta más que como un número de tarjeta. El RTA también comprende información de la cuenta que identifica cuando menos una cuenta del tarjeta habiente. El RTA puede estar almacenado en la petición de transacción de servicios financieros como: Cada “x” en la tabla anterior significa un dígito en el Número de Transito de Ruta (“RTN”, también conocido como un “Número de la Asociación de Banqueros Americanos” o “número ABA”) asociado con la institución financiera que administra o mantiene la cuenta del usuario iniciador 101. Cada “y” en la tabla indica un dígito de la cuenta asociada con el usuario iniciador 101. En algunas modalidades, el número de cuenta completo se incluye en el RTA, mientras que en otras modalidades solo una porción del número de cuenta (tal como los ocho dígitos más a la derecha del número de cuenta) se almacenan en la cadena, mientras que los dígitos remanentes del número de cuenta, o el número de cuenta mismo, incluido en otro campo en la transacción de servicios financieros. La longitud y conformación del RTA puede variar en algunas modalidades.
Si el usuario iniciador 101 inicia una transacción de servicios financieros a través del ordenante 102 para pagar por una compra, los dígitos “x" en el RTA pueden incluir el número de ruta asociado con una cuenta del usuario iniciador 101 y los dígitos “y” en el RTA pueden incluir cuando menos algunos de los números de cuenta asociados con la cuenta del usuario iniciador 101.
En un segundo modo, “referencia cruzada” o “X-REF”, el ordenante 102 genera una petición de transacción de servicios financieros que incluye información de identificación que está asociada con una cuenta de una institución financiera. Sin embargo, ni el RTN ni el número de cuenta se incluye en la petición de transacción de servicios financieros. En vez de esto, la información de identificación puede ser incluida en la forma de un Testigo de Autenticación de Acceso a Cuenta (AAT). Los AATs permiten la identificación única de la cuenta de usuario en una institución financiera pero no incluyen directamente la información de la cuenta para esa cuenta. En vez de esto, los AATs incluyen información de identificación tal como un nombre de usuario, información de identificación personal (por ejemplo, un número de seguro social, un nombre, una dirección, una dirección de correo electrónico, un número de teléfono, una identificación de ingreso), un número de cuenta sustituto (por ejemplo, un número que parezca un número de cuenta valido pero que no es el número de cuenta real para la cuenta), o similares. Los AATs pueden ser generados en nombre del usuario iniciador 101 por medio de una variedad de entidades. Por ejemplo, en algunas modalidades, los AATs son generados por cuando menos un ordenante 102, red de pagos 105, receptor 107, o un receptor exterior 109. En otras modalidades, los AATs son generados por otra entidad tal como un banco central o una autoridad monetaria (por ejemplo, la Reserva Federal de los Estados Unidos de América, o el Banco Central Europeo). En otras modalidades, los AATs son generados por una parte que está autorizada por la red de pago 105 para generar AATs (una “parte auténtica”).
En algunas modalidades, las peticiones de transacción de servicios financieros pueden ser generadas en formato XML, o cumplir con un estándar como el ISO 20022 o ISO 8583. Las peticiones de transacción de servicios financieros generadas por el ordenante 102 incluyen uno o más tipos de transacciones. Si bien se proporcionan algunos ejemplos aquí, alguien capacitado en la téenica entenderá que otros tipos de transacciones de servicios financieros pueden ser generadas por el ordenante 102.
Como un primer ejemplo, peticiones de transacción de servicios financieros generadas por el ordenante 102 indican una solicitud del balance actual de una cuenta a la que hace referencia el usuario iniciador 101. Si el ordenante 102 es un comerciante, el usuario iniciador 101 puede intentar pagar por una compra con un cheque. El ordenante 102 puede generar una petición para determinar si debe aceptar el cheque o no. La petición de transacción puede comprender la cantidad del cheque que el usuario iniciador 101 ha escrito y ofrecido al ordenante 102 para el pago y un identificador asociado con la cuenta. El ordenante 102 puede recibir una respuesta en cuanto a si el cheque se puede hacer efectivo en base a los fondos disponibles en aquel momento en el tiempo, y puede negar o aprobar la transacción del usuario iniciador 101.
Como un segundo ejemplo, peticiones de transacción de servicios financieros generadas por el ordenante 102 indican una solicitud para validar la propiedad o existencia de una cuenta particular. En este ejemplo el usuario iniciador 101 puede intentar asociar una cuenta en el ordenante 102 y una cuenta de institución financiera propiedad del usuario iniciador 101 (por ejemplo, una cuenta de banco). El usuario iniciador 101 puede ofrecer detalles de la cuenta de la institución financiera (por ejemplo, un número de cuenta) al ordenante 102 con el fin de establecer la cuenta ordenante. El ordenante 102 puede generar una solicitud para validar la existencia y/o propiedad de la cuenta de institución financiera. La petición de transacción puede comprender una identidad asociada con la cuenta de institución financiera. El ordenante 102 puede entonces recibir una respuesta que confirme o niegue que la cuenta de institución financiera existe y/o es realmente propiedad del usuario inicial 101. Si se confirma, esto permite que el usuario iniciador 101 inicie transacciones usando la cuenta en el ordenante 102.
Como tercer ejemplo, peticiones de transacción de servicios financieros generadas por el ordenante 102 indican una solicitud para enviar un crédito a una cuenta a la que hace referencia el usuario iniciador 101. Si el ordenante 102 es una plataforma de remesas (por ejemplo, una plataforma que envía dinero de una persona a otra persona), el usuario iniciador 101 puede pedir que una cantidad de dinero particular sea depositada en la cuenta de referencia o la haga disponible por medio de otro método de desembolso a un segundo usuario. El usuario iniciador 101 puede dar detalles de la cuenta de destino al ordenante 102, tal como un RTN y un número de cuenta, un nombre de usuario o dirección asociada con el segundo usuario, u otra información asociada con la cuenta de destino o su propietario. El ordenante 102 puede generar una solicitud para acreditar a la cuenta a la que hace referencia el usuario iniciador 101 o hacer que los fondos solicitados estén disponibles para el segundo usuario. La petición de transacción puede comprender una identidad de la cuenta y la cantidad que el usuario iniciador 101 desea acreditar a la cuenta. El ordenante 102 puede entonces recibir una respuesta que indica si el abono fue exitoso.
Como un cuarto ejemplo, peticiones de transacción de servicios financieros generadas por el ordenante 102 indican una solicitud para cargar fondos a partir de una cuenta a la que se hace referencia por el usuario iniciador 101. En este ejemplo el usuario iniciador 101 puede intentar pagar una factura expedida por el ordenante 102 por medio de la provisión de información de la cuenta. El usuario iniciador 101 puede dar detalles de la cuenta fuente al originador 103, tal como un RTN y/o número de cuenta. El ordenante 102 puede generar una solicitud para cargar a la cuenta a la que hace referencia el usuario iniciador 101. La petición de transacción puede comprender una identidad de la cuenta y la cantidad que el usuario iniciador 101 desea cargar a la cuenta. El ordenante 102 puede entonces recibir una respuesta que indique si el cargo fue exitoso.
Como un quinto ejemplo, peticiones de transacción de servicios financieros generadas por el ordenante 102 incluyen peticiones de excepción. En algunas modalidades, el ordenante 102 puede generar una petición de excepción al determinar que hay una discrepancia entre un importe de liquidación recibido de la red de pagos 105 y una cantidad que el ordenante 102 cree que debe recibirse. Por ejemplo, el ordenante 102 puede iniciar una petición de excepción de ajuste (una petición para corregir una posición financiera del ordenante 102 en base a un error asociado con una transacción particular, dentro de los 10 días calendario de la fecha de liquidación de la transacción), una petición de excepción de representación (una disputa por una devolución de cargo iniciada por el receptor 107), una petición de ajuste de buena fe (una petición para corregir un balance del ordenante 102 en base a un error asociado con una transacción particular, por ejemplo, más de 45 días después de la fecha de liquidación de la transacción), una petición de excepción de ajuste tardío (una petición para corregir un balance del ordenante 102 en base a un error asociado con una transacción particular, por ejemplo, más de 10 días después pero dentro de 45 días de la fecha de liquidación de la transacción), o similares.
El ordenante 102 también puede estar asociado con uno o más Puntos de Ordenante de Transacción (TOPs). Los TOPs permiten que el usuario iniciador 101 envíe información sobre cuentas que son propiedad del usuario iniciador 101 al ordenante 102 y realizar transacciones usando al ordenante 102. De este modo, por ejemplo, si el ordenante 102 provee un monedero móvil para usarse por usuarios, el TOP asociado podría ser una aplicación de proveedor de monedero que reciba instrucciones para pagar por una compra en un dispositivo móvil. Como otro ejemplo, si el ordenante 102 es un proveedor de servicios inalámbricos, el TOP asociado podría ser un sitio web de pago de facturas o una aplicación móvil de pago de facturas implementada en un sitio web. Como otro ejemplo, si el ordenante 102 es una institución financiera, el TOP asociado podría ser una terminal de acceso a cuenta en sucursal (como un Cajero Automático o ATM), o un sitio web de transferencia de fondos. Adicionalmente, en algunas modalidades, a una cuenta ordenante en el ordenante 102 se puede tener acceso a través de un TOP asociado con el ordenante 102 (y puede entonces ser referida como una “cuenta de usuario TOP”).
En algunas modalidades, el ordenante 102 también puede almacenar una Clave de Instrumento de Pago (PIK, Payment Instrument Key) asociada con una cuenta a la que hace referencia el usuario iniciador 101. En algunas modalidades, una PIK puede ser generada por medio de una red de pagos 105 u otra entidad, usando una clave asociada con el ordenante 102 y una clave asociada con el receptor 107. El ordenante 102 puede utilizar la PIK al generar la petición de transacción de servicios financieros en nombre del usuario iniciador 101.
El procesador 103 puede ser programado para recibir transacciones de servicios financieros del ordenante 102. El procesador 103 puede ser implementado como un dispositivo especialmente programado para recibir petición de transacción de servicios financieros, determinar una red de pago apropiada para enviar las peticiones de transacción, y enviar las peticiones de transacción a la red de pagos determinada. El procesador 103 puede recibir peticiones de liquidación en nombre del ordenante 102, los mensajes de reformateado destinados a y recibidos desde la red de pagos en mensajes que puedan entonces ser procesados por el ordenante 102 en su formato, mantener bases de datos en nombre del ordenante 102 (que contienen, por ejemplo, datos de los usuarios y/o cuentas asociadas), procesar documentos de excepción en nombre del ordenante 102, o similares. En algunas modalidades, el procesador 103 y el ordenante 102 pueden tener una relación contractual entre ellos y/o con una red de pago 105.
En algunas modalidades, la red de pagos 105 es una red interbancaria, la cual permite a una variedad de dispositivos, tales como cajeros automáticos (ATM), proveedores de monedero móvil, dispositivos de Punto De Venta (POS), comerciantes, TOPs, o similares, comunicarse entre ellos y tener acceso a cuentas de institución financiera. Las redes de pago 105 pueden ser, por ejemplo, regionales, nacionales, o internacionales en su alcance. Las redes de pago 105, en algunas modalidades, envían transacciones de servicios financieros al procesador 106 de receptor o al receptor 107 para pedir la validación de la propiedad de cuenta, información del balance, o la retención, destino, o transferencia de fondos asociados con una transacción financiera y sus respectivos titulares de cuentas.
En algunas modalidades, las redes de pagos 105 llevan a cabo procesos de liquidación como parte del procesamiento de transacción de servicios financieros. En algunas modalidades, cuando la red de pagos 105 recibe peticiones de transacción, la red de pagos 105 calcula las cantidades que necesitan ser transferidas entre las partes y “liquidará” el neto de estas cantidades. Como un ejemplo, si el usuario iniciador 101 inicia una transacción para pagar $100.00 a un segundo usuario y el segundo usuario inicia una transacción para pagar al usuario iniciador 101 $80.00, la red de pagos 105 combinará las dos cantidades de transacción para determinar una liquidación neta que represente la cantidad de dinero que debe ser cargada y acreditada a las instituciones financieras que representan a cada usuario. En este ejemplo, cada institución financiera acredita (o “destina”) la cantidad total de cada transacción separada, esto es, los $100.00 y $80.00 del ejemplo, a cada cuenta respectiva del usuario, y la red de pagos 105 iniciara una entrada de débito de $20.00 a una institución financiera y una entrada de crédito de $20.00 a la otra institución financiera para efectuar la liquidación neta apropiada entre las dos partes. La red de pagos 105 causa que los fondos se muevan entre las partes por medio de la preparación de archivos de la cámara de compensación automatizada (ACH) que se inician a través de un banco de ACH asociado con la red de pagos 105 para cada institución financiera respectiva de usuario, procesador emisor, comerciante/procesador mercantil, red de EFT, plataforma de remesas, o similares. Estos archivos de ACH reflejan las cantidades de liquidación neta a ser liquidadas entre las varias partes involucradas en el flujo de la transacción. Cada balance de cuenta de usuario es cargada o acreditada como un resultado de las peticiones de transacción en línea aprobadas. En algunas modalidades, las entradas de liquidación en tales archivos de ACH se crean a la conclusión de un periodo de tiempo particular, tal como, por ejemplo, un periodo de 24 horas entre las 3:30PM del tiempo local en un día y las 3:30PM del día siguiente.
En algunas modalidades, la red de pagos 105 lleva a cabo un proceso de traducción para dirigir una petición de transacción de servicios financieros a una institución financiera u otro receptor. En base a la información en una petición de transacción de servicios financieros recibida, la red de pagos 105 puede determinar si se necesita información adicional o alternativa para dirigir la petición. Por ejemplo, si la petición de transacción de servicios financieros incluye un AAT (Testigo de Autenticación de Acceso a Cuenta) asociado con el usuario iniciador 101, y la petición de transacción indica el uso del “modo X-REF”, la red de pagos 105 puede usar una base de datos 105A para determinar un RTN y un número de cuenta asociado con el usuario iniciador 101 en base al AAT en la petición de transacción de servicios financieros. La red de pagos 105 también puede usar una base de datos 105A para determinar un identificador de cuenta que no contenga un número de cuenta pero que esté asociado con la cuenta a la que hace referencia la petición de servicios financieros.
Si la transacción de servicios financieros recibida incluye un RTN y un número de cuenta e indica el uso del “modo nativo,” la red de pagos 105 puede usar una base de datos 105A para determinar si el RTN recibido y el número de cuenta están asociados con un RTN alternativo o número de cuenta. La red de pagos 105 también puede determinar que la petición de transacción de servicios financieros tampoco fue generada en el modo X-REF ni requiere de un RTN alternativo o número de cuenta, y puede presumir que el RTN recibido y el número de cuenta son los números reales asociados con la cuenta del usuario iniciador 101. En tal situación, la red de pagos 105 puede dirigir la petición de transacción de servicios financieros a otra red de pagos (no mostrada) para su procesamiento.
La red de pagos 105, en algunas modalidades, también genera claves para usarse en el procesamiento de peticiones de transacción de servicios financieros. Por ejemplo, la red de pagos 105 puede generar una Clave Maestra de Proveedor de Servicios (SPMK Service Provider Master Key) correspondiente al ordenante 102 o un Punto Ordenante de Transacción (TOP) asociado, puede utilizar la SPMK para generar una Clave de Autentificación de Participante (PAK, Participant Authentication Key) asociada con una institución financiera (tal como el receptor 107), y puede utilizar la PAK para generar una Clave de Instrumento de Pago (PIK, Payment Instrument Key) asociada con una cuenta en la cuenta financiera (tal como una cuenta que es propiedad del usuario iniciador 101). En algunas modalidades, la red de pagos 105 puede comprender un Módulo de Seguridad de Hardware (HSM, Hardware Security Module) para generar y almacenar estas claves. El HSM puede ser implementado en hardware, software, firmware, o una combinación de estos.
El procesador de receptor 106 es una entidad que recibe peticiones de transacción financiera de la red de pagos 105. En algunas modalidades, el procesador de receptor puede ser implementado como una compuerta de pagos o red de Transferencia Electrónica de Fondos programada para enviar transacciones de servicios financieros al receptor 107. El procesador de receptor 106 recibe una transacción se servicios financieros, determina el receptor apropiado (tal como una institución financiera o la entidad que tiene la información de la cuenta, o similares), y envía la petición de transacción financiera a ese receptor. En algunas modalidades, el procesador de receptor 106 permite la comunicación con las instituciones financieras u otras compañías que tienen la cuenta contratadas con el procesador de receptor 106 para servicios de procesamiento de transacciones en línea.
El receptor 107 representa una entidad que recibe una petición de transacción de servicios financieros. En algunas modalidades, el receptor 107 es una institución financiera. Las instituciones financieras incluyen, por ejemplo, bancos, bancos de ahorro, uniones de crédito, firmas de corretaje, o proveedores de fondos mutuos. Las instituciones financieras pueden, por ejemplo, procesar transacciones o transferir dinero entre cuentas en la institución financiera y/o cuentas fuera de la institución financiera. A diferencia de las redes de pagos, las instituciones financieras administran cuentas en nombre de usuarios, por ejemplo, manteniendo registros de depósitos y retiros en la cuenta, y manteniendo un registro del balance de la cuenta.
En algunas modalidades, el receptor 107 recibe peticiones de transacciones de servicios financieros directamente de la red de pagos 105. En otras modalidades, el receptor 107 recibe peticiones de transacción de servicios financieros del procesador de receptor 106, el cual las recibe de la red de pagos 105.
En algunas modalidades, el receptor 107 inicia peticiones de transacción de servicios financieros que incluyen solicitudes de excepción. Por ejemplo, el receptor 107 puede generar y enviar peticiones de transacción de servicios financieros que incluyen una petición de excepción de devolución de cargo (que indica que una petición de transacción de servicios financieros correspondiente para cargar o acreditar fue por error, y debe ser revertida o reembolsada, en su totalidad o en parte) o solicitudes de excepción de revocación de devolución de cargos (que indican que una solicitud de excepción de devolución de cargo iniciada por un ordenante fue por error y deberá ser revertida).
Un Archivo de Información de Cliente (CIF, Client Information File) 107A contiene, por ejemplo, información acerca de las cuentas que tiene el receptor 107. (Una cuenta es “tenida" por el receptor 107 si la cuenta y/o sus fondos son mantenidos por el receptor 107.) El CIF 107A incluye información del propietario de la cuenta tal como nombres, direcciones, códigos postales, fechas de nacimiento, números de seguro social/número de identificación de contribuidor de impuestos, números de teléfono, direcciones de correo electrónico, direcciones de trabajo, número de licencia de manejo, información de testigo de autenticación, nombres de usuario/claves, o similares. El receptor 107 usa un CIF 107A para validad/autentificar la propiedad de cuentas que tiene el receptor 107, al ser solicitado por una entidad tal como un ordenante 102.
El receptor externo 109 representa un receptor localizado en un país diferente al país en el que la red de pagos 105 se localiza. El receptor exterior 109 se comunica con la red de pagos 105 directamente o a través de su procesador de receptor exterior 108. La red de pagos 105 puede permitir que las peticiones de transacción de servicios financieros internacionales sean procesadas (por ejemplo, una petición para una acreditación del usuario iniciador 101 a una cuenta en el receptor exterior 109). El procesador de receptor exterior 108, el cual puede estar localizado en un país diferente al país de la red de pagos 105, puede recibir peticiones de transacción de servicios financieros en nombre del receptor exterior 109 y enviarlas al receptor exterior 109 para su procesamiento. El procesador de receptor exterior 108 también puede representar una compañía que desembolsa remesas directamente a beneficiarios, en lugar de enviar la petición al receptor externo 109.
La Figura 2 ilustra modalidades de red de pagos 105 consistentes con las modalidades descritas. La red de pagos 105 incluye un conmutador 201, un portal web 202, un motor de remesas 203, y un motor de integración 204. Cada bloque ilustrado en la Figura 2 puede ser implementado usando software, hardware, firmware, o una combinación de estos.
El conmutador 201 recibe transacciones de servicios financieros desde, por ejemplo, ordenantes y procesadores. El conmutador 201 puede ser implementado usando software, hardware, firmware, o una combinación de estos. En algunas modalidades, el conmutador 201 determina información acerca de transacciones de servicios financieros, tal como, por ejemplo, el modo de una transacción de servicios financieros (por ejemplo X-REF o modo nativo) y a donde la petición debe ser dirigida en base a esa información. El conmutador 201 también puede enviar información a, y recibir información de, cualquier portal web 202, motor de remesas 203, y motor de integración 204. El conmutador 201 también puede recibir transacciones que se originan desde dispositivos tales como los cajeros automáticos (ATM) o dispositivos POS, que se comunican con otras redes de pagos (por ejemplo, para enviar transacciones de servicios financieros o recibir transacciones de servicios financieros enviadas), o similares. En algunas modalidades, el conmutador 201 puede ser implementado usando el software de pagos de transferencia electrónica de fondos en una plataforma tolerante a fallas, auto recuperable. Por ejemplo, el conmutador 201 puede ser implementado usando software FIS CONNEX implementado en la plataforma HP NONSTOP.
El portal web 202 es un punto de acceso para ordenantes, procesadores, procesadores de receptor, receptores, procesadores de receptores externos, o receptores, para Iniciar y recibir solicitudes de excepción, recuperar archivos enviados por la red de pagos 105, o tener acceso a documentos de soporte publicados por la red de pagos 105. El portal web 202 permite que los ordenantes y receptores recuperen reportes sobre actividad llevada a cabo usando la red de pagos 105. Por ejemplo, los ordenantes y receptores pueden recuperar reportes de liquidación diarios, reportes de transacción de excepción y facturas de pagos. Los ordenantes, receptores y procesadores también pueden ver el historial de transacciones, transmitir archivos negativos (indicando, por ejemplo, usuarios particulares que deben ser bloqueados de recibir o enviar comunicaciones en la red de pagos 105), o similares. El portal web 202 puede ser implementado usando software, hardware, firmware, o una combinación de estos.
El motor de remesas 203 permite que el conmutador 201 liquide peticiones de transacción recibidas de ordenantes y procesadores. En algunas modalidades, el motor de remesas 203 lleva a cabo un proceso de liquidación periódico, en el cual el motor de remesas 203 calcula, en base a las transacciones aprobadas, las cantidades netas que necesitan ser transferidas entre las partes, y genera un archivo ACH con entradas correspondientes a las cantidades netas que requieren fondos para ser movidos entre las cuentas de liquidación. El motor de remesas 203 genera entonces el archivo ACH y reportes relacionados. El archivo ACH es enviado a un banco de ACH asociado con la red de pagos 105 para liquidación. Reportes relacionados se hacen disponibles para su recuperación y son transmitidos a las partes apropiadas o se hacen disponibles a través del portal web 202.
En algunas modalidades, el motor de remesas 203 lleva a cabo tales procesos de liquidación en una base diaria para todas las peticiones de transacción recibidas durante un periodo de 24 horas particular. Por ejemplo, a las 3:30 PM del Tiempo Estándar del Este en cada día, el motor de remesas 203 puede llevar a cabo los procesos de liquidación para todas las peticiones de transacción que requieren movimiento de fondos (incluyendo transacciones de excepción) recibidas desde las 3:30 PM del Tiempo Estándar del Este en el día anterior. El motor de remesas 203 puede entonces generar un archivo de entrada ACH que indica los resultados netos del proceso de liquidación.
El motor de remesas 203 puede recibir mensajes de transacción desde el conmutador 201. Estos mensajes de transacción pueden ser recibidos en tiempo real, periódicamente en lotes a lo largo del día, o al final de un periodo de 24 horas. El motor de remesas 203 también puede llevar a cabo revisiones de integridad en esos mensajes de transacción y preparar archivos ACH que correspondan a los valores de “liquidación neta” calculados. Liquidación neta significa que para cada entrada de cargo en una cuenta de liquidación, existe una entrada de crédito correspondiente en cuando menos alguna otra cuenta de liquidación.
El motor de remesas 203 puede ser implementado usando software, hardware, firmware, o una combinación de estos. En algunas modalidades, el motor de remesas 203 puede ser implementado usando un software de liquidación de transferencia electrónica de fondos en una plataforma de ordenador central. Por ejemplo, el motor de remesas 203 puede ser implementado usando software FIS CONNEX implementado en la plataforma IBM.
El motor de integración 204 puede ser un sistema (tal como un dispositivo o software) para integrar y agregar información procedente de una variedad de fuentes. El motor de integración 204 puede permitir que el conmutador 201 se comunique con una variedad de otros servicios que no se implementan necesariamente como parte de la red de pago 105. Por ejemplo, el motor de integración 204 puede proveer comunicación con sistemas de fraude y cumplimiento, proveedores de pago de terceras partes, sistemas de cajeros de banco, sistemas de pago de persona a persona, o similares. El motor de integración 204 puede permitir la interconectividad de aplicaciones de terceras personas, servicios publicados, y redes de pagos 105. El motor de integración 204 también puede ser programado para permitir la auditoria, ingreso, monitoreo, enrutamiento y procesos de seguridad relacionados con el procesamiento de datos de estas fuentes, aplicaciones de terceras partes, y redes de pago 105. El motor de integración 204 puede ser implementado usando software, hardware, firmware, o una combinación de estos.
La Figura 3 ilustra un proceso ejemplar 300 para procesar una transacción de servicios financieros, consistente con las modalidades descritas. El proceso 300 comienza en el paso 301, en el cual el ordenante 102 recibe una petición de transacción del usuario iniciador 101. Por ejemplo, el ordenante 102 puede recibir una petición de transacción del usuario iniciador 101 para pagar un bien o servicio. El usuario iniciador 101 puede hacer referencia a una cuenta para ser usada para la transacción. En algunas modalidades, el usuario iniciador 101 puede ofrecer un RTN y un número de cuenta asociado con la cuenta, un AAT (Testigo de Autenticación de Acceso de Cuenta) asociado con el usuario/cuenta, o similares.
El ordenante 102 puede generar una petición de transacción de servicios financieros que incluye la información ofrecida por el usuario. La petición de transacción de servicios financieros tambien puede incluir información concerniente al propósito de la petición de transacción de servicios financieros. Por ejemplo, la petición de transacción puede incluir cualquiera de; una solicitud del balance actual de una cuenta propiedad del usuario iniciador 101, una solicitud para validar la propiedad de una cuenta a la que hace referencia el usuario iniciador 101 , una solicitud de depósito de fondos en una cuenta a la que hace referencia el usuario 101, una solicitud de retiro de fondos en una cuenta a la que hace referencia el usuario iniciador 101, o similares.
En el paso 302, el ordenante 102 envía la petición de transacción de servicios financieros generada a la red de pagos 105. En algunas modalidades, el ordenante 102 envía la petición a un procesador (tal como el procesador 103 en la Figura 1) para enviarse a la red de pagos 105, pero en otras modalidades el ordenante 102 envía la petición directamente a la red de pagos 105.
En el paso 303, la red de pagos 105 determina si la petición de transacción de servicios financieros fue generada usando el modo X-REF o usando el modo nativo. La red de pagos 105 hace esta determinación en base a la información contenida en la petición de transacción de servicios financieros. Por ejemplo, si la petición contiene un número RTN, un número de cuenta de banco, parte de un número de cuenta de banco, número similar al de tarjeta, u otros números, que indican que la petición de transacción de servicios financieros fue generada en modo nativo, la red de pagos 105 puede determinar que la petición fue generada usando modo nativo, y puede proceder al paso 304 para un procesamiento adicional de la petición. De otra forma, si la red de pagos 105 determina que la petición de transacción de servicios financieros incluye un AAT (Testigo de Autenticación de Acceso de Cuenta), tal como un nombre de usuario, información de identificación personal (por ejemplo, número de seguro social, nombre, dirección, dirección de correo electrónico, número de teléfono, o similares), un número de cuenta sustituto (por ejemplo, un número de cuenta que parezca un número de cuenta valido pero que no es el número de cuenta real para la cuenta), o similares, la red de pagos 105 puede determinar que la petición fue generada usando el modo X-REF, y puede proceder al paso 309 para el procesamiento adicional de la transacción.
Si la red de pagos 105 determina que la petición fue generada usando el modo nativo, entonces, en el paso 304, la red de pagos 105 determina si la petición de transacción de servicios financieros incluye un RTA (Número de Cuenta de Transito de Ruta) con un valor indicador en particular. El valor indicador, en algunas modalidades, puede ser almacenado en el inicio del inicio de un campo del PAN en la petición. En algunas modalidades, el valor indicador puede ser elegido de forma que sea distinguible de valores iniciales asociados con tarjetas de pago, para evitar la confusión con las transacciones de tarjeta de pago. Por ejemplo, las tarjetas VISA tienen un “4” en el inicio de sus números de tarjeta y las tarjetas American Express tienen un “3” en el inicio de sus números de tarjeta. El valor indicador puede ser elegido para evitar la confusión con otros proveedores de tarjetas. En algunas modalidades, el valor indicador es “59”.
Si la petición de transacción de servicios financieros recibida no incluye un RTA con el valor indicador, entonces el proceso 300 puede continuar al paso 305, en el cual la red de pagos 105 envía la petición de transacción financiera a una red de Transferencia Electrónica de Fondos (EFT) u otra red de pagos para enviar al destino final (por ejemplo, el receptor 107). Sin embargo, si en el paso 304 la red de pagos 105 determina que el RTA en la petición de transacción financiera incluye el valor indicador, el proceso 300 continúa al paso 306.
En el paso 306, la red de pagos 105 determina la institución financiera apropiada en base a la información recibida en la petición de transacción de servicios financieros. Existen múltiples formas de determinar la institución financiera apropiada. Por ejemplo, la red de pagos 105 puede determinar la institución financiera en base a un RTN incluido en la petición de transacción de servicios financieros. Como otro ejemplo, la red de pagos 105 puede consultar una base de datos (tal como la base de datos 105A en la Figura 1) para determinar un RTN sustituto correspondiente a los datos en la petición. Una vez que la red de pago 105 determina el RTN apropiado, el proceso 300 avanza al paso 307.
En el paso 307, la red de pagos 105 determina un número de cuenta asociado con el usuario iniciador en base a la información recibida en la petición de transacción de servicios financieros. Existen múltiples formas de determinar el número de cuenta apropiado. Por ejemplo, la red de pagos 105 puede determinar que el número de cuenta completo está contenido en la petición. Como otro ejemplo, la petición de transacción de servicios financieros puede solo incluir una parte del número de cuenta, tal como los ocho dígitos que están más a la izquierda. En tal caso, la red de pagos 105 puede consultar una base de datos (tal como una base de datos 105A en la Figura 1) para determinar los dígitos remanentes del número de cuenta. Como otro ejemplo, el número de cuenta contenido en la petición puede incluir un número de cuenta no existente y/o un sustituto para el número de cuenta real. En tales situaciones, la red de pagos 105 puede consultar la base de datos 105A para determinar un número de cuenta sustituto.
En algunas modalidades, el paso 307 representa una red de pagos 105 que determina un identificador de cuenta asociado con el ARN y la cuenta. En algunas modalidades, este identificador de cuenta no contiene el número de cuenta asociado con la cuenta. Un receptor que administra la cuenta almacena una correspondencia entre el identificador de la cuenta y un número de cuenta real asociado con la cuenta (almacenado, por ejemplo, en asociación con otro en una base de datos).
Una vez que la red de pagos 105 determina el número de cuenta apropiado o identificador de cuenta, el proceso 300 avanza al paso 308. En el paso 308, la red de pagos 105 genera una nueva petición de transacción de servicios financieros. Esta petición incluye información de la petición de transacción de servicios financieros recibida y cualquier sustituto de RTN determinado, números de cuenta, o identificadores de cuenta. La red de pagos 105 envía la petición de transacción de servicios financieros generada al receptor/procesador de receptor asociado con el RTN determinado.
Si, en el paso 303, la red de pagos 105 determina que la petición de transacción de servicios financieros fue generada usando un modo X-REF, el proceso 300 continúa al paso 309. En el paso 309, la red de pagos 105 consulta un archivo de traducción para determinar la información de cuenta asociada con la transacción de servicios financieros. En el modo X-REF, la petición de transacción de servicios financieros incluye identificar información que se asocia con un número de cuenta y/o un RTN. Sin embargo, ni el RTN ni el número de cuenta se incluye en la transacción de servicios financieros. En lugar de esto, la identificación de la información puede estar en la forma de un AAT (Testigo de Autenticación de Acceso de Cuenta). Un AAT permite la identificación de una cuenta de usuario en una institución financiera sin el número de cuenta asociado por la institución financiera. Los AATs incluyen información de identificación tal como un nombre de usuario, información de identificación personal (por ejemplo, un número de seguro social, nombre, dirección, dirección de correo electrónico, número de telefono, o similares,) o similares.
La red de pagos 105 puede consultar un archivo de traducción para determinar un RTN y par de números de cuenta asociados con el AAT en la transacción de servicios financieros. En algunas modalidades, el archivo de traducción puede ser almacenado en una base de datos a la que se tiene acceso por medio de la red de pagos 105 (tal como la base de datos 105A en la Figura 1).
En algunas modalidades, el paso 309 representa que la red de pagos 105 determina un identificador de cuenta asociado con el AAT y la cuenta. En algunas modalidades, este identificador de cuenta no contiene un número de cuenta asociado con la cuenta. Un receptor que administra la cuenta almacena una correspondencia entre el identificador de cuenta y el número de la cuenta real asociado con la cuenta (almacenado, por ejemplo, en asociación uno con otro en una base de datos).
El proceso 300 puede entonces avanzar al paso 310. En el paso 310, la red de pago 105 genera una transacción de servicios financieros. Esta transacción puede incluir información de la transacción de servicios financieros recibida y el RTN determinado y el número de cuenta o un identificador de cuenta determinado. La red de pagos 105 entonces envía la transacción de servicios financieros generada al receptor determinado.
Sin importar la información en la petición de transacción de servicios financieros recibida en el paso 302, en el paso 311, la red de pagos 105 recibe una respuesta del receptor determinado en uno de los pasos 305, 308, o 310. La respuesta puede incluir Información relacionada con la petición de transacción de servicios financieros y puede representar una “respuesta” de un procesador de receptor, un receptor, un receptor exterior, o un procesador de receptor exterior que se relaciona con la cuenta a la que se hace referencia en la petición.
La respuesta incluye una o más indicaciones concernientes a la cuenta. Los tipos de indicaciones posibles pueden incluir: una indicación de que el balance disponible es menor que (o mayor que) la cantidad en la petición de transacción; una indicación de que el balance de control es menor que (o mayor que) la cantidad en la petición de transacción (el balance de control difiere del balance disponible por cualquier cargo o credito pendiente en la cuenta); una indicación del balance disponible o de control actual real; una indicación del status de la cuenta (por ejemplo, si la cuenta está abierta y/o en una buena condición); una indicación de cuánto tiempo ha estado abierta la cuenta; una indicación de cualquier historia negativa asociada con la cuenta; rangos de balance promedio; una indicación de validación de la información de identidad/propiedad de la cuenta provista por un usuario iniciador; datos que indican el nombre del usuario de la cuenta, dirección, o fecha en la que se abrió la cuenta; u otra información acerca del propietario de la cuenta.
La figura 4A ilustra un proceso ejemplar 400 para inicializar claves necesarias para un Punto Ordenante de Transacción (TOP) 402 para operar en conjunto con la red de pagos 105, consistente con las modalidades descritas. El TOP 402 representa un dispositivo o mecanismo por medio del cual un ordenante (tal como un ordenante 102 en la Figura 1) recibe datos concernientes a un usuario, con el propósito de procesar una transacción iniciada por el usuario usando la red de pagos 105.
Cada ordenante puede tener uno o más de los TOP 402 asociados para usarse en el procesamiento de transacciones iniciadas por usuarios. Por lo tanto, por ejemplo, si un ordenante provee un monedero móvil para usarse por los usuarios, el TOP 402 podría ser un sistema proveedor de monedero que recibe instrucciones para pagar por una compra. Como otro ejemplo, si el ordenante es un proveedor de servicios inalámbricos, el TOP 402 podría ser un sitio web de pago de facturas o una aplicación de pago de facturas móvil. Como otro ejemplo, si el ordenante es una institución financiera, el TOP 402 podría ser una estación de cajero, un quiosco, una terminal de acceso a cuenta en sucursal (como un cajero automático o ATM), o un sitio web de transferencia de fondos.
El proceso 400 permite que el TOP 402 establezca una relación autentificada con la red de pagos 105 de una manera segura. Esta relación permite que aquellos asociados con el TOP 402, tal como usuarios, comerciantes, plataformas de remesas, redes de EFT, o instituciones financieras, inicien de manera segura las transacciones financieras con la red de pagos 105 usando el TOP 402. En el paso 401, el TOP 402 envía una petición a una red de pagos 105 para pedir la iniciación de una conexión autentificada entre el TOP 402 y la red de pagos 105.
En algunas modalidades, la petición enviada en el paso 401 también incluye una petición para configurar una Clave de Intercambio de Clave (KEK) para usarse en el intercambio de información entre el TOP 402 y la red de pagos 105. El TOP 402 y la red de pagos 105 pueden implementar un proceso para establecer la KEK. Por ejemplo, el TOP 402 y la red de pagos 105 pueden implementar el algoritmo de intercambio de claves conocido como de Diffie-Hellman. Sin embargo, ningún método particular del sistema para generar un KEK se requiere en todas las modalidades.
El proceso 400 entonces avanza al paso 403. En el paso 403, una red de pagos 105 genera una Clave Maestra de Proveedor de Servicio (SPMK). El TOP 402 tiene una SPMK única generada por medio de la red de pagos 105. En algunas modalidades la SPMK puede ser generada usando un generador de números aleatorios o pseudoaleatorios o un algoritmo de generación de claves. Adicionalmente, en algunas modalidades, dos TOPs no tendrían la misma SMPK. Sin embargo, en otras modalidades, TOPs asociados con el mismo ordenante compartirían un SPMK.
En el paso 403, la red de pagos 105 también puede generar una KEK. La KEK puede ser utilizada para intercambiar información de manera segura entre el TOP 402 y la red de pago 105, y puede ser generada usando un generador de números aleatorio o pseudo aleatorio o un algoritmo de generación de claves. La red de pagos 105 también puede generar una Clave de Testigo de Autenticación (TK, Token Key). La TK permite que el TOP 402 encripte ciertos elementos en una petición de transacción de servicios financieros. En algunas modalidades, la TK podría ser usada para encriptar elementos de datos para los cuales la distribución debería ser limitada (tales como un número de cuenta, identificador de cuenta, PAN, u otra información sensible).
En el paso 405, la red de pagos 105 encripta y almacena la SPMK generada en un Módulo de Seguridad de Hardware (HSM). En algunas modalidades, el HSM genera claves de encriptación y descifrado, almacena claves de encriptación y descifrado y otros datos, encripta y descifra datos usando las claves almacenadas, y genera una “Clave de Archivo Maestro” (MFK, Master File Key) para encriptar otras claves de encriptación y descifrado. El HSM puede ser implementado en hardware, software, firmware, o una combinación de estos. En algunas modalidades, la red de pagos 105 puede encriptar la SPMK usando una MFK asociada con el HSM. En el paso 405, la red de pagos 105 también puede almacenar la KEK generada (o una porción de esta) y la TK en el HSM. La red de pagos 105 también puede enviar la KEK y la TK al TOP 402, el cual las recibe en el paso 406. En algunas modalidades, el TOP 402 almacena la KEK y la TK en su propio HSM.
La Figura 4B ilustra un proceso ejemplar 408 para asociar una cuenta de institución financiera con una cuenta de usuario de TOP, de acuerdo con las modalidades descritas. En el paso 407, el usuario iniciador 101 opera un dispositivo, tal como una computadora o dispositivo móvil, para asociar una cuenta de institución financiera (por ejemplo, cuenta de depósito) con una cuenta de usuario de TOP. En el paso 409, el TOP 402 recibe la petición del usuario iniciador 101 para asociar la cuenta de institución financiera con la cuenta del usuario de TOP, y genera un mensaje de petición de autentificación de cuenta para asociar la cuenta de institución financiera con la cuenta de usuario de TOP, para enviarse a la red de pagos 105. La petición comprende información acerca de la cuenta de institución financiera. Esto incluye, por ejemplo, un RTN y un par de números de cuenta, un RTA, un Número de Cuenta Primario (PAN) tal como un número similar a tarjeta, un Testigo de Autenticación de Acceso a Cuenta (AAT), o similares. El TOP 402 entonces envía el mensaje de petición de autentificación de cuenta a la red de pago 105.
La red de pago 105 puede operar un proceso opcional, ilustrado en la Figura 4C, que permite un nivel de seguridad mayor para el usuario 101 y el TOP 402 en asociación con la cuenta de institución financiera con la cuenta de usuario de TOP. (Este proceso puede ser ofrecido al TOP 402 como un servicio opcional o por una tarifa extra). Si la red de pago 105 opera tal proceso opcional en nombre del TOP 402, el proceso continúa al paso 425 en la Figura 4C. Si, sin embargo, la red de pagos no opera el proceso opcional ilustrado en la Figura 4C, el proceso en lugar de esto continua al paso 411.
En el paso 411 , una red de pagos 105 acepta y procesa el mensaje de solicitud de autentificación de la cuenta. La red de pagos 105 genera una Clave de Autentificación de Participante (PAK) usando un Módulo de Seguridad de Hardware (HSM). La PAK puede ser generada por medio de la encriptación de información acerca de la institución financiera que administra la cuenta del usuario iniciador 101 que desea asociar con la cuenta del usuario de TOP, usando como clave una Clave Maestra de Proveedor de Servicio (SPMK) almacenada en el HSM y asociada con el TOP 402. En algunas modalidades, esta información encriptada usando la SPMK incluye un RTN, un Número de Identificación de Banco (BIN), u otro identificador relacionado con la institución financiera. En algunas modalidades, el algoritmo usado para encriptar y generar la PAK de esta información es Triple-DES (3DES).
En el paso 413, la red de pagos 105 usa el HSM para generar una Clave de Instrucción de Pago (PIK, Payment Instruction Key). En algunas modalidades, la PIK puede ser generada por medio de la generación de un hash criptográfico con clave (también conocido como “Código de Autentificación de Mensaje” o “MAC”) de información acerca de la cuenta de institución financiera, usando la PAK generada en el paso 411 como una clave. Por ejemplo, la PIK puede ser generada aplicando la función hash a un número de cuenta de banco asociado con la cuenta, un PAN asociado con la cuenta, u otro identificador asociado con la cuenta.
En el paso 415, la red de pagos 105 encripta al PIK usando una Clave de Intercambio de Clave (KEK). La KEK, en algunas modalidades, se acuerda entre el TOP 402 y la red de pagos 105 durante un proceso previo (por ejemplo, durante el proceso ilustrado en la Figura 4A).
En el paso 417, la red de pago 105 genera una respuesta que incluye al PIK encriptado, y la envía al TOP 402. En el paso 419, el TOP 402 recibe y procesa el mensaje de respuesta que incluye la PIK. El TOP 402 posteriormente descifra la PIK usando la KEK, y almacena la PIK en un Módulo de Seguridad de Hardware (HSM) operado por el TOP 402. En el paso 421, el TOP 402 envía un mensaje al usuario iniciador 101 que indica que la petición para asociar una cuenta de institución financiera con la cuenta del usuario de TOP fue aprobada. El TOP 402 puede entonces utilizar la PIK para iniciar una petición de transacción de servicios financieros en nombre del usuario iniciador 101.
La Figura 4C ilustra un proceso opcional ejemplar 424 para asociar una cuenta de institución financiera con una cuenta de usuario con el usuario iniciador 101. Tal como se explicó anteriormente, sí la red de pago 105 ofrece el proceso en la Figura 4C como un servicio opcional para el TOP 402, el proceso continuará después del paso 409 en la Figura 4B. El paso 425 procede desde el paso 409 en la Figura 4B, durante el cual el TOP 402 recibe un comando para asociar una cuenta de institución financiera (por ejemplo, una cuenta de depósitos) con una cuenta de usuario de TOP (Punto Ordenante de Transacción). En respuesta el, TOP 402 genera y envía una petición al usuario iniciador 101. La petición incluye un aviso para piezas particulares de información (referidas como “snips”) conocidas tanto para el usuario iniciador 101 como para la institución financiera 413. Los snips ejemplares pedidos por el usuario iniciador 101 incluyen un balance actual en la cuenta, dígitos particulares del número de seguro social/número de identificación de contribuyente de impuestos asociado con el usuario iniciador 101 (tal como los últimos cinco dígitos), un Valor de Verificación de Tarjeta (CW), de la parte posterior de una tarjeta de pago asociada con la cuenta, dígitos particulares de un número de teléfono asociado con el usuario iniciador 101 (tal como los primeros tres dígitos después del código de área), un secreto compartido entre el usuario iniciador 101 y la institución financiera 413 (tal como un password), o similares.
En el paso 427, el usuario iniciador 101 recibe las peticiones de snips e ingresa los snips en el dispositivo para enviar al TOP 402. En algunas modalidades, la respuesta enviada en el paso 427 es enviada en forma de texto común al TOP 402. Sin embargo, en otras modalidades, el usuario iniciador 101 encripta, resume criptográficamente, o de otra forma confunde la información antes de generar y enviar la respuesta al TOP 402.
En el paso 429, el TOP 402 recibe la respuesta, e inserta los snips recibidos (en texto común, resumen criptográfico, encriptado o de otra forma) en el mensaje de la petición de autentificación generada en el paso 409 de la Figura 4B conjuntamente con una petición para validar los snips. En algunas modalidades, el mensaje de solicitud de autentificación comprende un elemento de datos poblado con los snips recibidos. Cada snip es etiquetado con una “etiqueta” que indica lo que significa.
Por ejemplo, el elemento de datos puede comprender una etiqueta que indica que el elemento de datos comprende snips correspondientes al usuario iniciador 101, una longitud del elemento de datos, y posteriormente subconjuntos de información múltiples, cada subconjunto correspondiendo a un snip diferente recibido del usuario 101. Cada subconjunto comprende una sub etiqueta que indica lo que la información representa, una longitud del snip, y un valor correspondiente al snip (ya sea en forma de texto común o complicado). De este modo, si un elemento de datos comprende 5 snips, el elemento de datos puede ser representado como: en donde “Tag” indica que el elemento de datos comprende snips correspondientes al usuario iniciador 101, “Len” representa la longitud del elemento de datos, cada “ST” indica el tipo de información que los snips representan, cada “L” representa la longitud del snip, y cada “”V” represente al snip mismo. Esta colocación particular se provee solo como un ejemplo ilustrativo.
El TOP 402 entonces envía el mensaje de petición de autentificación a la red de pagos 105. En algunas modalidades, el mensaje de petición de autentificación es enviado en forma de texto común a la red de pago 105. Sin embargo, en otras modalidades, el TOP 402 encripta, resume criptográficamente, o de otra forma confunde la información en el mensaje de petición de autentificación antes de enviarlo a la red de pagos 105.
En el paso 431, la red de pagos 105 recibe el mensaje de solicitud de autentificación, y genera un mensaje de petición de identificación de cuenta. El mensaje de petición de identificación de cuenta comprende datos recibidos del TOP 402, incluyendo el elemento de datos y snips correspondientes. Este mensaje de petición de identificación de cuenta es enviado a la institución financiera 413.
En el paso 433, la institución financiera 413 valida la información en el mensaje de petición de identificación de cuenta comparándolo con información en una base de datos asociada con la institución financiera 413. Por ejemplo, la institución financiera 413 puede comparar información recibida con información en un CIF (“Archivo de Información de Cliente’) (tal como CIF 107A) en la Figura 1. Si los snips en el elemento de datos del usuario iniciador 101 están en texto común, la institución financiera 413 compara el elemento de datos del TOP 402 con la información almacenada en el CIF.
Si, sin embargo, los snips en el elemento de datos están en una forma confundida, tal como en un formato de resumen criptográfico, un formato encriptado, o similares, la institución financiera 413 determina las sub etiquetas en el elemento de datos, reúne los datos correspondientes a esas sub etiquetas del CIF, y confunde los datos reunidos en la misma manera que los datos fueron confundidos por el usuario iniciador 101 o TOP 402 (por ejemplo, por medio de encriptación o resumen criptográfico). Posteriormente la institución financiera 413 compara los snips confusos para determinar si son idénticos.
Sin importar el tipo de comparación, en el paso 435, la institución financiera 413 genera una respuesta que indica cuales snips recibidos del usuario iniciador 101 empatan con los datos en el CIF. Por ejemplo, si el primer, tercero, y cuarto snips recibidos del usuario iniciador 101 concuerdan con los datos en el CIF pero el segundo y quinto snips recibidos del usuario iniciador 101 no corresponden con los datos en el CIF, la institución financiera 413 puede generar una respuesta indicando que solo algunos de los snips corresponden. En algunas modalidades, la respuesta correspondiente puede ser implementada como un mapa de bits que indica que snips corresponden con la información en el CIF.
La institución financiera 413 genera un mensaje de respuesta de validación de cuenta, que incluye la respuesta generada que indica el número de snips empatados, y la envía a la red de pagos 105. En el paso 437, la red de pagos 105 recibe el mensaje de respuesta de la institución financiera 413, y avanza de regreso a la Figura 4B al paso 410.
En el paso 410 en la Figura 4B, la red de pago 105 determina si se asocia la cuenta de institución financiera con la cuenta del usuario de TOP y genera un mensaje correspondiente para enviar al usuario iniciador 101. Por ejemplo, la red de pagos 105 puede determinar que la cuenta financiera y la cuenta de usuario de TOP deben estar asociadas entre ellas si una mayoría (esto es, más del 50%) de snips provistos por el usuario 101 en el paso 427 empatan con datos almacenados por la institución financiera 413. Si es así, el proceso continúa al paso 411, en donde la red de pago 105 genera la clave PAK, tal como se describió anteriormente. Si, sin embargo, la red de pago 105 determina que la institución financiera 413 no empata suficiente información con los snips provistos por el usuario 101, el proceso puede continuar al paso 422, en donde la respuesta (incluyendo, en algunas modalidades, un mapa de bits u otra indicación del resultado de la correspondencia de los snips) puede ser enviado al TOP 402, indicando que la petición para asociar la cuenta de institución financiera con la cuenta de usuario de TOP debe ser negada. El TOP 402 entonces envía una respuesta al usuario iniciador 101 en el paso 423 indicando que la solicitud para asociar la cuenta de institución financiera con la cuenta de usuario de TOP fue negada.
La Figura 4D ilustra un proceso ejemplar 438 para usar el TOP 402 para iniciar una petición de transacción. El proceso 438 involucra la comunicación entre el usuario iniciador 101, el ordenante 102, el TOP 402, la red de pago 105, y la institución financiera 403. Los pasos en el proceso 438 permiten al usuario iniciador 101 y al ordenante 102 lograr una transacción financiera sobre la red de pago 105, usando una cuenta en una institución financiera 413 (tal como una cuenta de depósito) que está asociada con una cuenta de usuario de TOP en el TOP 402.
Una aplicación TOP provista al usuario iniciador 101, en algunas modalidades, comprende una aplicación programada para entregar información a un comerciante o una terminal mercantil (tal como un dispositivo de Punto de Venta (POS)) con relación a una compra u otra transacción financiera que el usuario iniciador 101 desea hacer. Por ejemplo, la aplicación TOP puede transmitir información por vía inalámbrica relacionada con la cuenta de usuario de monedero móvil. La aplicación TOP puede ser implementada como una aplicación de monedero móvil, un sitio web de pago de facturas, o similares.
En el paso 439, el usuario iniciador 101 utiliza una aplicación TOP para iniciar una transacción relacionada con una compra. Por ejemplo, la aplicación TOP puede generar un mensaje que incluya, una petición para iniciar una compra, información acerca de la cuenta de usuario de TOP, la cantidad de dinero a pagar, o similares, y puede enviarla al ordenante 102. En el paso 441, el ordenante 102 genera y envía una transacción de servicios financieros al TOP 402.
En el paso 443, el TOP 402 recibe la petición de transacción de servicios financieros del TOP 402, e incrementa un contador de transacción de monedero (WTC). El WTC puede ser usado por el TOP 402 y la red de pagos para verificar que el uso de la aplicación TOP y/o TOP 402 sea autorizada por el usuario iniciador 101.
En el paso 445, el TOP 402 genera un Criptograma de Petición de Aplicación (ARQC). En algunas modalidades, la generación del ARQC comprende el uso de un Módulo de Seguridad de Hardware (HSM) para encriptar una variedad de datos con una Clave de Instrumento de Pago (PIK) que se asocia con la cuenta de usuario. Los datos encriptados para generar el ARQC pueden incluir, por ejemplo, un código que representa la moneda para la transacción (por ejemplo “USD” u “840” para el dólar estadounidense), una fecha asociada con la transacción, la cantidad de la transacción, código de país asociado con el ordenante 102, el contador de transacción de monedero incrementado en el paso 407, un número aleatorio, o similares. En algunas modalidades, el ARQC se genera para conformarse con la especificación EMV (abreviatura para Europay, MasterCard, y Visa), el cual define requerimientos para implementar transacciones de “chip y pin” usando las tarjetas de pago con circuitos integrados. En algunas modalidades, ciertos elementos de datos incluidos en el ARQC pueden ser encriptados antes de ser colocados dentro del ARQC. Por ejemplo, el elemento de datos para el cual la distribución debe ser limitada (tal como un número de cuenta, PAN, u otra información sensible) puede ser encriptado usando una Clave de Testigo Autenticador (TK). (El TOP 402 adquiere una TK, en algunas modalidades, recibiendolo en un proceso tal como el ilustrado en la Figura 4A).
En el paso 447, el TOP 402 genera una petición de transacción de servicios financieros y la rellena con el ARQC generado así como con elementos de datos relacionados con la transacción requerida. Estos elementos de datos incluyen, por ejemplo, información acerca de la cuenta de usuario de TOP o la cuenta de institución financiera, una cantidad de dinero involucrada en la transacción, o similares. En el paso 447, el TOP 402 envía el mensaje a la red de pago 105.
En el paso 449, una red de pago 105 deriva una PIK (Clave de Autentlficación de Participante) y una PAK (Clave de Instrumento de Pago). En algunas modalidades, la PIK y la PAK se basan en la Clave Maestra de Proveedor de Servicio (SPMK) asociada con el TOP 402. La PAK se relaciona con la institución financiera 413 y es generada usando la SPMK. La PIK se relaciona con la cuenta particular en la institución financiera 413 y se genera usando la PAK. De este modo, debido a que la SPMK es accesible a la red de pagos 105, la red de pagos 105 puede derivar al PAK usando el SPMK y puede derivar al PIK usando el PAK derivado.
En el paso 451, la red de pago 105 valida el ARQC recibido usando la PIK. Por ejemplo, la red de pagos 105 usa la PIK derivada para asegurar que el ARQC se envió realmente al TOP 402 (por ejemplo, descifrando el ARQC usando la PIK o generando un ARQC duplicado y comparándolo con el ARQC recibido). Si la red de pago 105 valida el ARQC, el proceso 400 continua al paso 453. En el paso 453, la red de pago 105 valida el valor del contador de transacciones de monedero (WTC) incluido en la petición de transacción de servicios financieros. La red de pagos 105 determina si el valor del WTC está dentro de un rango aceptable de un valor del WTC recibido previamente. Por ejemplo, la red de pagos 105 puede determinar si el valor del WTC recibido en la petición de transacción de servicios financieros actual está dentro de los tres dígitos de un valor del WTC recibido en una petición de transacción de servicios financieros previa (por ejemplo, si el valor del WTC en la petición de transacción de servicios financieros previa es 50, determina si el valor del WTC en esta petición está entre 51 y 53). Si la red de pagos 105 determina que el valor del WTC está dentro de un rango aceptable del valor del WTC previo, el proceso 400 continua al paso 455.
En el paso 455, la red de pagos 105 reformatea la petición de transacción de servicios financieros y la envía a la institución financiera 413 para procesarla. La institución financiera 413 puede ser implementada como un procesador de receptor (por ejemplo, el procesador de receptor 106 en la Figura 1), un receptor (por ejemplo, el receptor 107 en la Figura 1), un procesador de receptor exterior (por ejemplo, el procesador de receptor exterior 108 en la Figura 1) o un receptor exterior (por ejemplo el receptor exterior 109 en la Figura 1). En algunas modalidades, el envío del mensaje reformateado a la institución financiera 413 puede comprender cuando menos uno de: envío de la petición a un procesador de receptor para enviarla a un receptor, envío de la petición directamente a un receptor, envío de la petición a un procesador de receptor exterior para enviarla a un receptor exterior, o similares. (En algunas modalidades, el proceso en el paso 455 puede ser ¡mplementado tal como se describió anteriormente con respecto a los pasos 303-310 en la Figura 3.) En el paso 457, la institución financiera 413 recibe la petición de transacción de servicios financieros reformateada y determina como responder. Por ejemplo, si la petición reformateada comprende una solicitud del ordenante para determinar si hay fondos suficientes en una cuenta para comprar, la institución financiera 413 determina si los fondos son suficientes y genera una respuesta apropiada. La institución financiera 413 entonces envía a la red de pagos 105 una respuesta a la petición de transacción de servicios financieros.
En el paso 459, la red de pagos 105 recibe, envía, e ingresa a la respuesta dirigida a esta en el paso 457. La red de pagos 105 entonces envía el mensaje de respuesta al TOP 402. En el paso 461, el TOP 402 recibe, envía, e ingresa la respuesta, y la envía al ordenante 102. El ordenante 102 acepta y procesa el mensaje y provee una respuesta apropiada al usuario iniciador 101. Por ejemplo, si el usuario iniciador 101 intentó comprar un artículo del ordenante 102 en el paso 439 y la respuesta recibida en el paso 461 indica que hay fondos insuficientes en la cuenta a la que hace referencia el usuario iniciador 101 , el ordenante 102 puede negar la transacción de compra.
La Figura 5 ilustra un sistema de cómputo ejemplar 500 para implementar las modalidades descritas. Cada componente ilustrado en la Figura 1 (por ejemplo el usuario 101, ordenante 102, procesador 103, red de pago 105, base de datos 105A, procesador de receptor 106, receptor 107, CIF 107A, procesador de receptor exterior 108, receptor exterior 109 o CIF 109A) puede ser ¡mplementado como se ilustra en el sistema de cómputo 500. En algunas modalidades, los componentes en la Figura 5 pueden ser duplicados, sustituidos, u omitidos. En algunas modalidades, el sistema 500 puede ser ¡mplementado, de manera apropiada, como un teléfono celular, un dispositivo móvil, un dispositivo de POS (punto de venta), un servidor, un dispositivo inalámbrico, o cualquier otro sistema que incluya cuando menos alguno de los componentes de la Figura 5.
El sistema 500 comprende una unidad de energía 501. La unidad de energía 501 puede ser implementada como una batería, una fuente de energía, o similares. La unidad de energía 501 provee la electricidad necesaria para energlzar los otros componentes en el sistema 500. Por ejemplo, el CPU 502 necesita energía para operar. La unidad de energía 501 puede proveer la corriente eléctrica necesaria para energizar este componente.
El sistema 500 contiene una Unidad de Procesamiento Central (CPU) 502, la cual permite que los datos fluyan entre los otros componentes y de otra forma administra la operación de los otros componentes en el sistema de cómputo 500. La CPU 502, en algunas modalidades, puede ser implementada como un procesador de propósito general (tal como un procesador de la marca Intel o AMD), un procesador de propósito especial (por ejemplo, un procesador de tarjeta de gráficos o un procesador móvil), o cualquier otra especie de procesador que permita la entrada y salida de datos.
El sistema 500 también comprende el dispositivo de salida 503. El dispositivo de salida 503 puede ser implementado como un monitor, impresora, bocina, graficador, o cualquier otro dispositivo que presente los datos procesados, recibidos, o enviados por el sistema de cómputo 500.
El sistema 500 también comprende un adaptador de red 504. El adaptador de red 504, en algunas modalidades, permite la comunicación con otros dispositivos que son implementados en la misma o maneras similares que el sistema de cómputo 500. El adaptador de red 504, en algunas modalidades, puede permitir la comunicación a y/o desde una red tal como la Internet. El adaptador de red 504 puede ser implementado usando cualquiera o todas las hasta ahora desconocidas teenologías alámbricas o inalámbricas (tales como Ethernet, 802.11a/b/g/n (aka Wi-Fi), celular (por ejemplo, GSM, CMDA, LTE), o similares).
El sistema 500 también comprende un dispositivo de entrada 505. En algunas modalidades, el dispositivo de entrada 505 puede ser cualquier dispositivo que permita al usuario u otra entidad ingresar datos. Por ejemplo, el dispositivo de entrada 505 podría ser un teclado, un ratón, un pad o una pantalla sensible al tacto, o similares. El dispositivo de entrada 505 puede ser usado para controlar la operación de los otros componentes ilustrados en la Figura 5.
El sistema 500 también incluye un dispositivo de almacenamiento 506. El dispositivo de almacenamiento 506 almacena datos que son usables por otros componentes en el sistema 500. El dispositivo de almacenamiento 506 puede, en algunas modalidades, ser implementado como un disco duro, memoria temporal, memoria permanente, memoria óptica, o cualquier otro tipo de dispositivo de almacenamiento temporal o permanente.
El dispositivo de almacenamiento 506 puede almacenar uno o más módulos de instrucciones de programa de computadora y/o código que crea un medio ambiente de ejecución para el programa de computadora en cuestión, tal como, por ejemplo, el firmware del procesador, una pila de protocolo, un sistema de administración de base de datos, un sistema operativo, o una combinación de estos.
El termino “sistema de procesador”, tal como se usa aquí, se refiere a uno o más procesadores (tales como el CPU 502). Los sistemas descritos pueden ser implementados en parte o completamente en varias computadoras, dispositivos electrónicos, medios legibles por computadora (tales como CDs, DVDs, discos flash, discos duros, u otro almacenamiento), u otros dispositivos electrónicos o dispositivos de almacenamiento. Los métodos y flujos lógicos descritos en esta especificación pueden ser llevados a cabo por uno o más procesadores programables que ejecutan uno o más programas de computadora para llevar a cabo funciones por medio de la operación de datos de entrada y generar una salida. Los procesos y flujos lógicos también pueden ser llevados a cabo por, y un aparato también puede ser implementado como, una circuitería lógica de propósito especial, por ejemplo, un FPGA (Arreglo de Compuerta Programable de Campo) o un ASIC (circuito integrado de aplicación específica). Si bien los procesos descritos incluyen flujos de proceso particulares, flujos u órdenes alternativos también son posibles en modalidades alternativas.
Ciertas características las cuales, por claridad, son descritas en esta especificación en el contexto de modalidades separadas, también pueden proveerse en combinación en una modalidad sencilla. Inversamente, varias características las cuales, por brevedad, son descritas en el contexto de una sola modalidad, también pueden ser provistas en modalidades múltiples por separado o en cualquier sub combinación adecuada. Además, aunque las características pueden ser descritas anteriormente como actuando en ciertas combinaciones e incluso inicialmente reivindicadas como tales, una o más características de una combinación reivindicada en algunos casos puede ser separada de la combinación, y la combinación reivindicada puede ser dirigida a una sub combinación o variación de una sub combinación.
Modalidades particulares han sido descritas. Otras modalidades están dentro del alcance de las siguientes reivindicaciones.

Claims (28)

Reivindicaciones
1. Un método de asociación de una cuenta de institución financiera y una cuenta ordenante, el método comprende: recibir de un dispositivo de usuario una petición para asociar una cuenta de institución financiera con una cuenta ordenante, la cuenta de institución financiera siendo mantenida en una institución financiera; generar un mensaje de asociación que comprende los detalles de la cuenta de la institución financiera; enviar el mensaje de asociación a una red de pago, y responsiva a esta, recibiendo una respuesta de asociación; determinar si la respuesta de asociación incluye una clave asociada con la cuenta de la institución financiera, y si lo es almacenar la clave recibida para usar en el inicio de una petición de transacción; y enviar al dispositivo del usuario, una indicación de que la cuenta de la institución financiera ha sido asociada con la cuenta ordenante.
2. El método de la reivindicación 1 , el cual además comprende: recibir una petición de transacción desde un dispositivo ordenante para iniciar una transacción, la petición asociada con una petición para iniciar la transacción desde el dispositivo del usuario; generar y enviar el mensaje de transacción de los servicios financieros que incluyen la clave recibida a la red de pagos; y recibir, desde la red de pagos, una respuesta al mensaje de transacción de servicios financieros.
3. El método de la reivindicación 2, en donde la generación de un mensaje de transacción de servicios financieros comprende adicionalmente: incrementar un contador de transacción asociado con la cuenta de la institución financiera; generar un criptograma en base a la clave recibida, el contador de transacción, e información acerca de la petición de transacción de servicios financieros; y poblar el mensaje de transacción de servicios financieros con el criptograma.
4. El método de la reivindicación 1 , en donde la clave asociada con la cuenta de institución financiera se basa en la información asociada con la cuenta de la institución financiera, información asociada con la institución financiera, y una clave asociada con el ordenante.
5. El método de la reivindicación 1, el cual además comprende: en respuesta a la recepción de la petición para asociar una cuenta de institución financiera con una cuenta ordenante, enviar una petición para cuando menos una pieza de información; recibir la cuando menos una pieza de información; generar un mensaje de petición de identificación de cuenta que incluye la cuando menos una pieza de información; enviar el mensaje de petición de identificación de la cuenta a la red de pagos; determinar si la respuesta de asociación indica una negación, y si lo es, enviar una negación al dispositivo de usuario que indique que la cuenta de la institución financiera no ha sido asociada con la cuenta ordenante.
6. Un sistema para asociar una cuenta de institución financiera y una cuenta ordenante; el cual comprende: un sistema de procesador; y una memoria que comprende instrucciones que, cuando se ejecutan por un sistema de procesador, causan que el sistema de procesador lleve a cabo las operaciones que comprenden: recibir de un dispositivo de un usuario una petición para asociar una cuenta de institución financiera con una cuenta ordenante, la cuenta de la institución financiera siendo mantenida en una institución financiera; generar un mensaje de asociación que comprende los detalles de la cuenta de la institución financiera; enviar el mensaje de asociación a una red de pago, y en respuesta a esta, recibir una respuesta de asociación; determinar si la respuesta de asociación incluye una clave asociada con la cuenta de la institución financiera y si lo es, almacenar la clave recibida para usarse en la iniciación de una petición de transacción; y enviar, al dispositivo de usuario, una indicación de que la cuenta de la institución financiera ha sido asociada con la cuenta ordenante.
7. El sistema de la reivindicación 6, en donde las instrucciones adicionalmente causan que el procesador: reciba una petición de transacción del dispositivo ordenante para iniciar una transacción, la petición asociada con una petición para iniciar una transacción desde el dispositivo del usuario; generar y enviar un mensaje de transacción de servicios financieros que incluye la clave recibida a la red de pagos; y recibir, desde la red de pagos, una respuesta al mensaje de transacción de los servicios financieros.
8. El sistema de la reivindicación 7, en donde la generación de un mensaje de transacción de servicios financieros además comprende los pasos de: incrementar un contador de transacción asociado con la cuenta financiera; generar un criptograma en base a la clave recibida, el contador de transacción, y la información acerca de la petición de transacción de servicios financieros; y poblar el mensaje de transacción de servicios financieros con el criptograma.
9. El sistema de la reivindicación 6, en donde la clave asociada con la cuenta de la institución financiera se basa en información asociada con la cuenta de la institución financiera, la información asociada con la institución financiera, y una clave asociada con el ordenante.
10. El sistema de la reivindicación 6, en donde las instrucciones además causan que el procesador: en respuesta a la recepción de la petición, asocie una cuenta de institución financiera con una cuenta ordenante, envíe una petición para cuando menos una pieza de información; reciba la cuando menos una pieza de información; genere un mensaje de petición de identificación de la cuenta que incluye la cuando menos una pieza de información; envíe el mensaje de petición de identificación de la cuenta a la red de pago; determine si la respuesta de asociación indica una negación, y si lo es, enviar una negación al dispositivo de usuario indicando que la cuenta de la institución financiera no ha sido asociada con la cuenta ordenante.
11. Un método para procesar peticiones de transacción, el cual comprende: recibir una petición de transacción desde un dispositivo asociado, que comprende una petición para iniciar una transacción en nombre de un usuario e información sobre una cuenta financiera, la petición de transacción no incluye un número de cuenta asociado con la cuenta financiera; incrementar un contador de transacción asociado con la cuenta financiera; determinar una clave asociada con la cuenta financiera; generar un mensaje de transacción de servicios financieros que incluye un criptograma, el criptograma en base a la clave determinada, información de la petición de transacción, y el contador de transacción; y enviar el mensaje de transacción de servicios financieros a una red de pagos.
12. El método de la reivindicación 11 , en donde la clave asociada con la cuenta financiera se basa en una clave asociada con la institución financiera que mantiene la cuenta financiera, y en donde la clave asociada con la institución financiera se basa en una clave asociada con el dispositivo asociado.
13. El método de la reivindicación 11, en donde el criptograma se genera por encriptación, usando la clave asociada con la cuenta financiera, cuando menos uno de un código que representa la moneda de la transacción, una fecha asociada con la transacción, la cantidad de la transacción, un código de país asociado con el dispositivo asociado, contador de transacción de monedero, o un número aleatorio.
14. El método de la reivindicación 11, en donde el dispositivo asociado es uno de una institución financiera, una red de transferencia electrónica de fondos, un comerciante, un procesador mercantil, un procesador de remesas, un punto ordenante de transacción, o un proveedor de monedero móvil.
15. Un sistema para procesar peticiones de transacción, el cual comprende: un sistema de procesador; y una memoria que comprende instrucciones que, cuando se ejecutan por un sistema de procesador, causan que el sistema de procesador lleve a cabo las operaciones que comprenden: recibir una petición de transacción de un dispositivo asociado, que comprende una petición para iniciar una transacción en nombre de un usuario e información sobre una cuenta financiera, la petición de transacción no incluye un número de cuenta asociado con la cuenta financiera; incrementar un contador de transacción asociado con la cuenta financiera; determinar una clave asociada con la cuenta financiera; generar un mensaje de transacción de servicios financieros que incluye un criptograma, el criptograma en base a la clave determinada, información de la petición de transacción, y el contador de transacción; y enviar el mensaje de transacción de servicios financieros a una red de pagos.
16. El sistema de la reivindicación 15, en donde la clave asociada con la cuenta financiera se basa en una clave asociada con la institución financiera que mantiene la cuenta financiera, y en donde la clave asociada con la institución financiera se basa en una clave asociada con el dispositivo asociado.
17. El sistema de la reivindicación 15, en donde las instrucciones son programadas para generar el criptograma por encriptación, usando la clave asociada con la cuenta financiera, cuando menos un código que representa la moneda de la transacción, una fecha asociada con la transacción, la cantidad de la transacción, un código de país asociado con el dispositivo asociado, una cuenta de transacción de monedero, o un número aleatorio.
18. El sistema de la reivindicación 15, en donde el dispositivo asociado es uno de una institución financiera, una red de transferencia electrónica de fondos, un comerciante, un procesador mercantil, un procesador de remesas, un punto ordenante de transacción, o un proveedor de monedero móvil.
19. Un método para procesar peticiones de transacción, el cual comprende: recibir, desde un ordenante, una petición de transacción de servicios financieros que incluye un criptograma, la petición de transacción de servicios financieros no incluye un número de cuenta de una cuenta de institución financiera; determinar una clave asociada con la cuenta de institución financiera; validar al criptograma usando la clave asociada con la cuenta de institución financiera; determinar un identificador de cuenta de la cuenta de institución financiera; generar una petición de transacción en base a la información almacenada en el criptograma y al identificador de la cuenta determinada; enviar la petición de la transacción a una institución financiera asociada con la cuenta de institución financiera; recibir una respuesta; y enviar una respuesta a la petición de transacción de servicios financieros al ordenante.
20. El método de la reivindicación 19, en donde la validación del criptograma comprende: generar un segundo criptograma usando información almacenada en la petición de transacción; determinar si el segundo criptograma corresponde ai criptograma recibido; determinar si el contador de transacción en el criptograma recibido está dentro de un rango en base a un contador de transacción recibido previamente y asociado con la cuenta financiera.
21. El método de la reivindicación 19, en donde la determinación de la clave de cuenta de la institución financiera comprende: determinar, usando una clave asociada con el ordenante, una clave de institución financiera asociada con una institución financiera que mantiene la cuenta de institución financiera; y determinar, usando la clave de institución financiera, la clave de la cuenta de institución financiera.
22. El método de la reivindicación 19, en donde el ordenante es una de uno de una institución financiera, una red de transferencia electrónica de fondos, un comerciante, un procesador mercantil, un procesador de remesas, un punto ordenante de transacción, o un proveedor de monedero móvil.
23. El método de la reivindicación 19, en donde el criptograma se basa en una clave asociada con la cuenta de institución financiera, información asociada con una transacción solicitada, y un contador de transacción asociado con la cuenta de institución financiera.
24. Un sistema para procesar peticiones de transacción, el cual comprende; un sistema de procesador; y una memoria que comprende instrucciones programadas para, cuando se ejecutan por un sistema de procesador, causa que el sistema de procesador lleve a cabo las operaciones que comprenden: recibir, desde un ordenante, una petición de transacción de servicios financieros que incluye un criptograma, la petición de transacción de servicios financieros no incluye un número de cuenta de una cuenta de institución financiera; determinar una clave asociada con la cuenta de institución financiera; validar al criptograma usando la clave asociada con la cuenta de institución financiera; determinar un identificador de cuenta de la cuenta de institución financiera; generar una petición de transacción en base a la información almacenada en el criptograma y al identificador de cuenta determinado; enviar la petición de transacción a una institución financiera asociada con la cuenta de institución financiera; recibir una respuesta; y enviar una respuesta a la petición de la transacción de servicios financieros al ordenante.
25. El sistema de la reivindicación 24, en donde la validación del criptograma comprende: generar un segundo criptograma usando información almacenada en la petición de la transacción; determinar si el segundo criptograma corresponde con el criptograma recibido; determinar si el contador de transacción en el criptograma recibido está dentro de un rango en base a un contador de transacción recibido previamente y asociado con la cuenta financiera.
26. El sistema de la reivindicación 24, en donde la determinación de la clave de la cuenta de institución financiera comprende: determinar, usando una clave asociada con el ordenante, una clave de institución financiera asociada con una institución financiera que mantiene la cuenta de Institución financiera; y determinar, usando la clave de institución financiera, la clave de la cuenta de institución financiera.
27. El sistema de la reivindicación 24, en donde el ordenante es uno de una institución financiera, una red de transferencia electrónica de fondos, un comerciante, un procesador mercantil, un procesador de remesas, un punto ordenante de transacción, o un proveedor de monedero móvil.
28. El sistema de la reivindicación 24, en donde el criptograma se basa en una clave asociada con la cuenta de institución financiera, información asociada con una transacción solicitada, y un contador de transacción asociado con la cuenta de institución financiera.
MX2014013530A 2013-11-15 2014-11-07 Sistemas y metodos para el acceso a cuentas en tiempo real. MX2014013530A (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US14/081,590 US10535064B2 (en) 2012-03-19 2013-11-15 Systems and methods for real-time account access

Publications (1)

Publication Number Publication Date
MX2014013530A true MX2014013530A (es) 2015-08-12

Family

ID=51900762

Family Applications (1)

Application Number Title Priority Date Filing Date
MX2014013530A MX2014013530A (es) 2013-11-15 2014-11-07 Sistemas y metodos para el acceso a cuentas en tiempo real.

Country Status (8)

Country Link
EP (2) EP2874112A1 (es)
CN (2) CN112418831A (es)
AU (3) AU2014256396B2 (es)
BR (1) BR102014028305A2 (es)
CA (1) CA2870844A1 (es)
HK (1) HK1210537A1 (es)
IN (1) IN2014DE03249A (es)
MX (1) MX2014013530A (es)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11436598B2 (en) 2017-12-15 2022-09-06 Fmr Llc Social data tracking datastructures, apparatuses, methods and systems
US10778439B2 (en) 2015-07-14 2020-09-15 Fmr Llc Seed splitting and firmware extension for secure cryptocurrency key backup, restore, and transaction signing platform apparatuses, methods and systems
US10644885B2 (en) 2015-07-14 2020-05-05 Fmr Llc Firmware extension for secure cryptocurrency key backup, restore, and transaction signing platform apparatuses, methods and systems
US10339523B2 (en) 2015-07-14 2019-07-02 Fmr Llc Point-to-point transaction guidance apparatuses, methods and systems
US11636471B2 (en) 2017-12-15 2023-04-25 Fmr Llc Social data tracking datastructures, apparatuses, methods and systems
US11488147B2 (en) 2015-07-14 2022-11-01 Fmr Llc Computationally efficient transfer processing and auditing apparatuses, methods and systems
US10504179B1 (en) 2015-12-08 2019-12-10 Fmr Llc Social aggregated fractional equity transaction partitioned acquisition apparatuses, methods and systems
US10992469B2 (en) 2015-07-14 2021-04-27 Fmr Llc Seed splitting and firmware extension for secure cryptocurrency key backup, restore, and transaction signing platform apparatuses, methods and systems
US10489777B2 (en) * 2016-01-05 2019-11-26 Visa International Service Association Universal access to an electronic wallet
KR102664269B1 (ko) * 2016-05-03 2024-05-10 비자 인터네셔널 서비스 어소시에이션 기기 기반 자원 카탈로그를 위한 플랫폼
US20170372417A1 (en) * 2016-06-28 2017-12-28 Sivanarayana Gaddam Digital asset account management
CN108074083B (zh) * 2016-11-18 2021-02-05 腾讯科技（深圳）有限公司 一种请求处理方法、服务器及客户端
US11631085B2 (en) 2018-03-12 2023-04-18 Visa International Service Association Digital access code
US10546444B2 (en) * 2018-06-21 2020-01-28 Capital One Services, Llc Systems and methods for secure read-only authentication
US11651369B2 (en) * 2018-07-12 2023-05-16 American Express Travel Related Services Company, Inc. Remote EMV payment applications
SG11202102158XA (en) * 2018-09-05 2021-04-29 Visa Int Service Ass Global remittance system and method
US11250393B2 (en) 2018-11-09 2022-02-15 Visa International Service Association Rapid transaction settlement using virtual account
SG10202001079QA (en) * 2020-02-06 2020-07-29 Alipay Labs Singapore Pte Ltd Method and System for Processing a Transaction
CN111552982B (zh) * 2020-04-27 2023-03-10 支付宝(杭州)信息技术有限公司 保护隐私的账户关联关系识别方法及装置
CN113688405B (zh) * 2021-07-08 2023-05-26 电子科技大学 一种基于区块链的双向认证混合加密方法
CN113449005B (zh) * 2021-07-15 2024-02-23 中国银行股份有限公司 账户管理方法及装置
CN114866258A (zh) * 2022-05-16 2022-08-05 卡奥斯工业智能研究院(青岛)有限公司 一种访问关系的建立方法、装置、电子设备及存储介质

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001043084A2 (en) * 1999-12-06 2001-06-14 Pielemeier Ted A Method of masking the identity of a purchaser during a credit transaction
US6978369B2 (en) * 2000-08-04 2005-12-20 First Data Corporation Person-centric account-based digital signature system
US7225156B2 (en) * 2001-07-11 2007-05-29 Fisher Douglas C Persistent dynamic payment service
AUPS087602A0 (en) * 2002-03-04 2002-03-28 Ong, Yong Kin (Michael) Electronic fund transfer system
US20090265272A1 (en) * 2007-10-17 2009-10-22 The Western Union Company Money transfers utilizing a unique receiver identifier
US20090106152A1 (en) * 2007-10-17 2009-04-23 The Western Union Company Money transfers utilizing unique receiver identifier
GB0807676D0 (en) * 2008-04-28 2008-06-04 Royal Bank Of Scotland Plc The Transaction system and method
MX365511B (es) * 2009-10-19 2019-06-05 Mobile Equity Corp Metodo para controlar un sistema de comunicacion.
WO2011088508A1 (en) * 2010-01-19 2011-07-28 Glencurr Pty Ltd Method, device and system for securing payment data for transmission over open communication networks
SG183988A1 (en) * 2010-04-09 2012-10-30 Visa Int Service Ass System and method for securely validating transactions
US20120016799A1 (en) * 2010-07-16 2012-01-19 Patrick Killian Money transfer system gateway service
WO2012150491A1 (en) * 2011-05-04 2012-11-08 NIEMEYER, Alice Method and system for funds transfer bill payment, and purchasing using drag and drop
CA2867697C (en) * 2012-03-19 2022-03-29 Paynet Payments Network, Llc Systems and methods for real-time account access
CN102789612A (zh) * 2012-07-16 2012-11-21 深圳宝嘉电子设备有限公司 一种数字印章支付验证系统及其方法

Also Published As

Publication number Publication date
AU2014256396A1 (en) 2015-06-04
EP3598367A1 (en) 2020-01-22
AU2020267193A1 (en) 2020-12-03
AU2020267193B2 (en) 2022-06-30
AU2022231708A1 (en) 2022-10-06
EP2874112A1 (en) 2015-05-20
CA2870844A1 (en) 2015-05-15
IN2014DE03249A (es) 2015-07-17
BR102014028305A2 (pt) 2016-08-02
HK1210537A1 (en) 2016-04-22
CN104657848B (zh) 2020-11-06
CN112418831A (zh) 2021-02-26
AU2014256396B2 (en) 2020-08-20
CN104657848A (zh) 2015-05-27

Similar Documents

Publication Publication Date Title
US11983708B2 (en) Systems and methods for real-time account access
AU2020267193B2 (en) Systems and methods for real-time account access
US20230274240A1 (en) Transaction signing utilizing asymmetric cryptography
CN107851281B (zh) 用于基于区块链的交易的欺诈控制的系统和方法
CN107851245B (zh) 用于将基于区块链的资产关联到法定货币账户的方法和系统
CN107851246B (zh) 用于在现有支付网络上处理基于区块链的交易的系统和方法
US20180330342A1 (en) Digital asset account management
US11245513B2 (en) System and method for authorizing transactions in an authorized member network
US20180322489A1 (en) System and method for restricted transaction processing
CN112912909A (zh) 使用数字货币促进交易的系统和方法
US20140365363A1 (en) Secure integrative vault of consumer payment instruments for use in payment processing system and method
US11138593B1 (en) Systems and methods for contactless smart card authentication
US10977624B2 (en) System for generating paper and digital resource distribution documents with multi-level secure authorization requirements

Legal Events

Date Code Title Description
FG Grant or registration