U.S. patent application number 15/622594 was filed with the patent office on 2017-12-21 for system and method to push payment to beneficiary account using an alias.
The applicant listed for this patent is MasterCard International Incorporated. Invention is credited to Dana J. Lorberg, Sandeep Malhotra, Shanthan Subramaniam.
Application Number | 20170364910 15/622594 |
Document ID | / |
Family ID | 59091668 |
Filed Date | 2017-12-21 |
United States Patent
Application |
20170364910 |
Kind Code |
A1 |
Malhotra; Sandeep ; et
al. |
December 21, 2017 |
SYSTEM AND METHOD TO PUSH PAYMENT TO BENEFICIARY ACCOUNT USING AN
ALIAS
Abstract
A method includes receiving a funds transfer request. The
request includes an alias character string. The request is for
requesting a funds transfer. The alias character string is
translated to payment routing information. The payment routing
information specifies a recipient's financial institution deposit
account. The funds request is routed via a payment network for the
purpose of being credited to the specified deposit account.
Inventors: |
Malhotra; Sandeep;
(Greenwich, CT) ; Subramaniam; Shanthan; (Baldwin
Place, NY) ; Lorberg; Dana J.; (St. Louis,
MO) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
MasterCard International Incorporated |
Purchase |
NY |
US |
|
|
Family ID: |
59091668 |
Appl. No.: |
15/622594 |
Filed: |
June 14, 2017 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62350322 |
Jun 15, 2016 |
|
|
|
62350335 |
Jun 15, 2016 |
|
|
|
62350407 |
Jun 15, 2016 |
|
|
|
62351155 |
Jun 16, 2016 |
|
|
|
62350821 |
Jun 16, 2016 |
|
|
|
62351016 |
Jun 16, 2016 |
|
|
|
62351227 |
Jun 16, 2016 |
|
|
|
62350831 |
Jun 16, 2016 |
|
|
|
62350416 |
Jun 15, 2016 |
|
|
|
62351164 |
Jun 16, 2016 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06Q 20/405 20130101;
G06Q 20/105 20130101; G06Q 20/027 20130101; G06Q 20/3221 20130101;
G06Q 20/204 20130101; G06Q 20/40 20130101; G06Q 40/02 20130101;
G06Q 20/36 20130101; G06Q 10/107 20130101; G06Q 20/34 20130101;
G06Q 20/401 20130101; G06Q 20/4016 20130101; G06Q 20/023 20130101;
G06Q 20/385 20130101; G06Q 20/341 20130101; G06Q 20/387 20130101;
G06Q 20/108 20130101; G06Q 20/102 20130101; G06Q 20/202 20130101;
G06Q 20/4012 20130101; G06Q 20/10 20130101; G06Q 20/38 20130101;
G06N 20/00 20190101; G06Q 20/322 20130101; G06Q 20/325
20130101 |
International
Class: |
G06Q 20/38 20120101
G06Q020/38; G06Q 20/36 20120101 G06Q020/36; G06Q 20/10 20120101
G06Q020/10; G06Q 20/02 20120101 G06Q020/02; G06Q 20/40 20120101
G06Q020/40; G06Q 20/32 20120101 G06Q020/32 |
Claims
1. A method comprising: receiving a funds transfer request, the
request including an alias character string; the request for
requesting a funds transfer; translating the alias character string
to payment routing information that specifies a recipient's
financial institution deposit account; and routing the requested
funds transfer via a payment network for crediting to the specified
deposit account.
2. The method of claim 1, wherein the alias character string is a
telephone number.
3. The method of claim 1, wherein the alias character string is an
email address.
4. The method of claim 1, wherein the payment routing information
is in an IBAN (International Bank Account Number) format.
5. The method of claim 1, wherein the payment network is an EFT
(electronic funds transfer) network.
6. The method of claim 5, wherein the EFT network is an ACH
(automated clearing house) network.
7. A method comprising: receiving an alias character string in a
message from a service provider; using the alias character string
to route a request to an issuer of a user bank account, the request
for obtaining credit information about a user who owns said user
bank account; receiving a response to the request from the issuer
of the user bank account, said response providing a positive or
negative indication regarding the user; and transmitting said
positive or negative indication to the service provider.
8. The method of claim 7, wherein the message from the service
provider is not a payment card account transaction authorization
message and is not a request for a funds transfer.
9. The method of claim 8, wherein the alias character string is a
telephone number.
10. The method of claim 8, wherein the alias character string is an
email address.
11. The method of claim 8, wherein said receiving and transmitting
steps are performed by a computer operated by an operator of a
payment card account network.
12. The method of claim 11, wherein said message is not received
via a transaction acquirer or payment processor.
13. The method of claim 8, further comprising: receiving a
translation of the alias character string into a bank account
number that identifies said user bank account.
14. The method of claim 13, wherein said bank account number
identifies said issuer of said user bank account.
15. The method of claim 8, wherein the service provider is a
telecommunications service provider.
16. The method of claim 15, wherein the service provider is a
mobile network operator.
17. A method comprising: receiving a funds transfer request, the
funds transfer request including target account information, the
target account information for identifying a bank account to which
funds are to be transferred pursuant to the request; determining
that the target account information does not include a bank account
number; and in response to determining that the target account
information does not include a bank account number, initiating a
process to translate an alias character string contained in the
target account information to a bank account number.
18. The method of claim 17, wherein the alias character string is a
telephone number.
19. The method of claim 17, wherein the alias character string is
an email address.
20. The method of claim 17, wherein the process to translate the
alias character string includes accessing an alias directory.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the benefit of U.S. Provisional
Patent Application Nos. 62/350,322 (filed on Jun. 15, 2016);
62/350,335 (filed Jun. 15, 2016); 62/350,407 (filed Jun. 15, 2016);
62/351,155 (filed Jun. 16, 2016); 62/350,821 (filed Jun. 16, 2016);
62/351,016 (filed Jun. 16, 2016); 62/351,227 (filed Jun. 16, 2016);
62/350,831 (filed Jun. 16, 2016); 62/350,416 (filed Jun. 15, 2016);
and 62/351,164 (filed Jun. 16, 2016); the contents of which
provisional applications are hereby incorporated by reference for
all purposes.
BACKGROUND
[0002] Funds to be transferred from one account to another between
financial institutions typically require destination account
details such as account number, routing number and bank code. This
information is potentially vulnerable to being compromised as it is
communicated, for example, to the originator's bank. When a
successful attack occurs, there may be an unauthorized withdrawal
of funds from the account specified in the destination account
details.
[0003] The present inventors have now recognized that there are
opportunities to reduce the possibility of successful attacks on
requested funds transfers in EFT (electronic funds transfer)
systems.
BRIEF DESCRIPTION OF THE DRAWINGS
[0004] Features and advantages of some embodiments of the present
disclosure, and the manner in which the same are accomplished, will
become more readily apparent upon consideration of the following
detailed description of the invention taken in conjunction with the
accompanying drawings, which illustrate preferred and example
embodiments and which are not necessarily drawn to scale,
wherein:
[0005] FIG. 1 is a block diagram of a payment card account
system.
[0006] FIG. 2 is block diagram of a payment system such as an EFT
(electronic funds transfer) system.
[0007] FIG. 3 is a block diagram of a payment transaction system
provided in accordance with aspects of the present disclosure.
[0008] FIGS. 4 and 5 are block diagrams of example computer systems
that may perform functions in the system of FIG. 3.
[0009] FIGS. 6, 7 and 8 are flow charts that illustrate processes
that may be performed in the system of FIG. 3 in accordance with
aspects of the present disclosure.
[0010] FIG. 9 is a block diagram that shows aspects of the payment
transaction system of FIG. 3 as provided in accordance with other
embodiments.
[0011] FIG. 10 is a flow chart that illustrates a process that may
be performed in the system as depicted in FIG. 9.
DESCRIPTION
[0012] In general, and for the purpose of introducing concepts of
embodiments of the present disclosure, an alias (e.g., a telephone
number, an email address, or another type of character string) may
be selected to replace account information in EFT system funds
transfer requests. When a funds transfer request is received that
includes such an alias as a beneficiary account designation, an
alias directory is accessed to translate the alias into the
relevant destination account details. The account details thus
obtained are used to route the funds transfer in the EFT
system.
[0013] By using an alias instead of the actual account details
during potentially vulnerable communications between the funds
transfer requester and his/her financial institution, the risk of
compromise of the account details may be reduced.
[0014] FIG. 1 is a block diagram that illustrates a payment card
account system 100.
[0015] The system 100 includes a customer device 102 such as a
magnetic stripe card, a payment IC (integrated circuit) card
(contactless and/or contact), or a payment-enabled mobile device.
Block 104 in FIG. 1 represents a merchant device such as a POS
(point of sale) terminal/card reader. The merchant device 104 may
also be considered part of the payment card account system 100. The
customer device 102 may be presented to the merchant device 104, to
consummate a purchase transaction and to permit the merchant device
104 to read payment card account data (including, e.g., a payment
account number) from the customer device 102. In other situations,
the merchant device 104 may be an e-commerce server computer, and
the customer device 102 may be a personal computer, a mobile device
running a mobile browser, etc.; in such situations, the customer
device 102 may engage in an online shopping session with an
e-commerce website hosted by the merchant device 104.
[0016] A computer 106 operated by an acquirer (acquiring financial
institution) is also shown as part of the system 100 in FIG. 1. The
acquirer computer 106 may receive a payment account system
authorization request message for the transaction from the merchant
device 104. The acquirer computer 106 may route the authorization
request message via a card network 108 to a server computer 110
operated by the issuer of a payment account that is associated with
the account number obtained by the merchant device 104 (e.g., from
the customer device 102) and included in the authorization request
message. The authorization response message generated by the
payment issuer server computer 110 may be routed back to the
merchant device 104 via the card network 108 and the acquirer
computer 106.
[0017] One well known example of a card network is referred to as
the "Banknet" system, and is operated by MasterCard International
Incorporated, which is the assignee hereof.
[0018] The payment account issuer server computer 110 may be
operated by or on behalf of a financial institution ("FI") that
issues payment accounts to individual users such as the customer
who presented or operated the customer device 102 referred to
above. For example, the payment card issuer server computer 110 may
perform such functions as (a) receiving and responding to requests
for authorization of payment account transactions to be charged to
payment accounts issued by the FI; and (b) tracking and storing
transactions and maintaining account records.
[0019] The payment card account system communications among the
merchants, acquirers, card network and/or issuers may conform to a
known standard such as ISO 8583.
[0020] The components of the system 100 as depicted in FIG. 1 are
only those that are needed for processing a single transaction. A
typical payment system may process many purchase transactions
(including simultaneous transactions) and may include a
considerable number of payment account issuers and their computers,
a considerable number of acquirers and their computers, and
numerous merchants and their devices, as well as a very large
number of customer devices.
[0021] FIG. 2 is a block diagram that illustrates a payment network
system 200, of which one example is the ACH (automated clearing
house) system operated in the United States.
[0022] The system 200 includes an originator device 202, which may
be a computer operated by an originator of a transaction. Common
kinds of transactions are credit transactions and debit
transactions. The originator is the party that initiates the
transaction. The originator may be, for example, an individual or a
corporation or other organization.
[0023] The system 200 further includes an originator PSP (payment
services provider) computer 204. The originator PSP computer 204
receives payment instructions from the originator and forwards data
entries that reflect the instructions to a payment system
switch/network 206, which is also part of the system 200. The
originator PSP computer 204 may be operated by an originator PSP of
which the originator is a customer. The switch/network 206 may be
operated by a governmental or private entity that serves as a
clearing facility for the system 200.
[0024] Also included in the system 200 is a beneficiary PSP
computer 208. The beneficiary PSP computer 208 receives entries
from the payment system switch/network 206 and posts entries to
accounts of depositors.
[0025] Still further, the system 200 includes a beneficiary 210
that is one of the depositors of the beneficiary PSP. In the case
of a credit transaction, the account at the beneficiary PSP of the
beneficiary may be credited with the amount instructed to be paid
by the originator device 202. The beneficiary may be, for example,
an individual or a corporation or other organization. Both PSPs may
typically be banks or other financial institutions (FIs).
[0026] The communications among the parties in the system 200 may
typically be conducted using XML (eXtensible Markup Language) and
may comply with a standard according to ISO 20022.
[0027] The components of the system 200 as depicted in FIG. 2 are
only those that are needed for processing a single transaction. A
typical payment network system may process many transactions
(including simultaneous transactions) and may include a
considerable number of PSPs and their computers, one or more
clearing operators, and numerous originators and beneficiaries
[0028] FIG. 3 is a block diagram of a payment transaction system
300 provided in accordance with aspects of the present
disclosure.
[0029] The payment transaction system 300 may include an originator
or funds transaction requestor 302. The description of the
originator 202 in regard to FIG. 2 may also be applicable to the
originator 302 shown in FIG. 3. The system 300 may also include an
originator PSP 304 in communication with the originator 302. The
description of the originator PSP 204 in regard to FIG. 2 may also
be applicable to the originator PSP 304 shown in FIG. 3. The
originator PSP 304 may also be in communication with a gateway
computer 306. The gateway computer 306, in turn, is shown
operatively connected between a payment card network 310 and a
payment switch/network 308. Although the gateway computer 306 is
shown separately from the payment card network 310, it may, in some
embodiments, be a component or components associated with or
provided by and/or operated by the operator of the payment card
network 310. The payment card network 310 may generally resemble
and provide functionality like that of the card network 108 shown
in and discussed in connection with FIG. 1. The payment
switch/network 308 may generally resemble and provide functionality
like that of the payment switch network 206 shown in and discussed
in connection with FIG. 2.
[0030] In some embodiments, the gateway computer 306 is configured
to bridge the payment switch/network 308 and the payment card
network 310. This may occur at the application layer level and/or
the presentation layer level. The gateway computer 306 may serve as
a central switching platform that is the seat of the interrelated
operations of the networks 308 and 310 and may work independently
of the chosen protocol of the network participants.
[0031] The payment card network 310 is shown in FIG. 3 as providing
routing services for routing of payment card account system
transactions to account issuers/FIs (financial institutions) 312.
The issuer FIs 312 may operate substantially as described above
with respect to the issuer 110 shown in and discussed in connection
with FIG. 1.
[0032] The gateway computer 306 is also shown connected to an alias
directory 314. The purpose and functioning of the alias directory
314 will be described further below. The alias directory may
translate a beneficiary/recipient's alias into destination account
information and may supply the destination account information to
the gateway computer 306.
[0033] The alias directory 314 may map non-sensitive aliases to
critical and sensitive account details. The alias directory 314 may
be managed by a central trusted party (such as the clearing
party/payment switch/network or the payment card network). The
directory service can then be used by any trusted/secure service
provider, e.g., by financial institutions such as, e.g., the
originator PSP 304, where the service provider allows for
initiation of funds transfers. With use of aliases in the
instructions to initiate a funds transfer, the service provider may
provide a portal to allow the instructions to be received,
including the aliases. The aliases may be, for example, phone
numbers or email addresses or other unique but non-sensitive
identifiers. The sender of the funds transfer will only need the
recipient's unique alias to send funds. In many cases the alias may
be the recipient's phone number or email address, which may already
be known to the sender, or which the recipient may not be reluctant
to provide to the sender.
[0034] The payment switch/network 308 is in communication with the
beneficiary PSP 316. The description of the beneficiary PSP 208 in
regard to FIG. 2 may be applicable to the beneficiary PSP 316 shown
in FIG. 3. The beneficiary/recipient 318 is also shown in FIG. 3 in
association with the beneficiary PSP 316. The description of the
beneficiary 210 in regard to FIG. 2 may also be applicable to the
beneficiary 318 shown in FIG. 3.
[0035] Also shown in phantom is a provider 320 of goods and/or
services (hereinafter "service provider 320"). The service provider
320 may be in communication with the gateway computer 306 to allow
the service provider 320 to benefit from alias translation services
in a manner to be described below with respect to FIG. 8.
[0036] Although aspects of a payment card network and related FIs
are illustrated in FIG. 3, in some embodiments the same may be
absent, with transfers in the system 300 in such cases entirely
consisting of ACH/EFT transfers or the like. Moreover,
functionality ascribed herein to the gateway computer 306 may
instead be incorporated at least partially in the payment
switch/network 308, such that no gateway computer 306 need
necessarily be present, and alias translation may be sought and
obtained by the payment switch/network 308. In such embodiments,
the payment switch/network 308 may be in communication with the
alias directory 314 and/or may be accessible for alias translation
services by the service provider 320. In other embodiments, alias
translation may be sought and obtained by the originator PSP
304.
[0037] Any one or more of the blocks shown in FIG. 3, in addition
to representing the indicated entity, may also be considered to
represent one or more computer systems or other computing devices
(e.g. smartphones or other mobile devices) operated by such
entity.
[0038] FIG. 4 is a block diagram of an example computer system 402
that may perform functions in the system of FIG. 3. The computer
system 402 will nominally be referred to as a "beneficiary PSP
computer system", although some or all of the functions ascribed to
it may be performed by other components of the system 300.
[0039] Referring now to FIG. 4, the beneficiary PSP computer system
402 may, in its hardware aspects, resemble a typical server
computer and/or mainframe computer, but may be controlled by
software to cause it to function as described herein.
[0040] The beneficiary PSP computer system 402 may include a
computer processor 400 operatively coupled to a communication
device 401, a storage device 404, an input device 406 and an output
device 408. The communications device 401, the storage device 404,
the input device 406 and the output device 408 may all be in
communication with the processor 400.
[0041] The computer processor 400 may be constituted by one or more
processors. Processor 400 operates to execute processor-executable
steps, contained in program instructions described below, so as to
control the beneficiary PSP computer system 402 to provide desired
functionality.
[0042] Communication device 401 may be used to facilitate
communication with, for example, other devices (such as other
components of the payment system 300, as well as mobile devices
and/or computing devices operated by account holders).
Communication device 401 may comprise numerous communication ports
(not separately shown), to allow the beneficiary PSP computer
system 402 to communicate simultaneously with a number of other
computers and other devices, including communications as required
to simultaneously handle numerous interactions with other devices
and/or numerous transactions such as funds transfers.
[0043] Input device 406 may comprise one or more of any type of
peripheral device typically used to input data into a computer. For
example, the input device 406 may include a keyboard and a mouse.
Output device 408 may comprise, for example, a display and/or a
printer.
[0044] Storage device 404 may comprise any appropriate information
storage device, including combinations of magnetic storage devices
(e.g., hard disk drives), optical storage devices such as CDs
and/or DVDs, and/or semiconductor memory devices such as Random
Access Memory (RAM) devices and Read Only Memory (ROM) devices, as
well as so-called flash memory. Any one or more of such information
storage devices may be considered to be a computer-readable storage
medium or a computer usable medium or a memory.
[0045] Storage device 404 stores one or more programs for
controlling processor 400. The programs comprise program
instructions (which may be referred to as computer readable program
code means) that contain processor-executable process steps of the
beneficiary PSP computer system 402, executed by the processor 400
(and/or executed by other processors) to cause the beneficiary PSP
computer system 402 (and/or other computer systems) to function as
described herein.
[0046] The programs may include one or more conventional operating
systems (not shown) that control the processor 400 so as to manage
and coordinate activities and sharing of resources in the
beneficiary PSP computer system 402, and to serve as a host for
application programs (described below) that run on the beneficiary
PSP computer system 402.
[0047] The programs stored in the storage device 404 may include,
for example, a transaction handling application program 410. The
transaction handling application program 410 may operate to handle
transactions such as funds transfers in a manner or manners to be
described below.
[0048] Another program that may be stored in the storage device 404
is an application program 412 for handling set-up requests received
from deposit account holders. The purpose of the set-up requests
may be to select aliases to represent deposit accounts held by the
requesting individuals. Details of handling of set-up requests will
also be described below.
[0049] The storage device 404 may also store web hosting software
414. The web hosting software 414 may control the processor 400 to
enable the beneficiary PSP computer system 402 to maintain a
website by which account holders may access and interact with the
beneficiary PSP computer system 402.
[0050] The storage device 404 may further store one or more
software modules (block 416) that serve as software interfaces
between the beneficiary PSP computer system 402 and one or more
other components of the system 300.
[0051] The storage device 404 may also store, and the beneficiary
PSP computer system 402 may also execute, other programs, which are
not shown. For example, such programs may include communications
software and a reporting application. The latter program may
respond to requests from system administrators for reports on the
activities performed by the beneficiary PSP computer system 402.
The other programs may also include, e.g., device drivers, database
management software, etc.
[0052] The storage device 404 may also store one or more databases
418 needed for operation of the beneficiary PSP computer system
402.
[0053] FIG. 5 is a block diagram that illustrates an example
embodiment of the gateway computer 306. The gateway computer 306
may be similar in its hardware aspects to the beneficiary PSP
computer system 402 that was just described. Accordingly, the
gateway computer 306 may include a processor 500 in communication
with a communication device 501, a storage device 504, an input
device 506 and an output device 508.
[0054] Storage device 504 stores one or more programs for
controlling processor 500. The programs comprise program
instructions (which may be referred to as computer readable program
code means) that contain processor-executable process steps of the
gateway computer 306, executed by the processor 500 (and/or
executed by other processors) to cause the gateway computer 306
(and/or other computer systems) to function as described
herein.
[0055] The programs may include one or more conventional operating
systems (not shown) that control the processor 500 so as to manage
and coordinate activities and sharing of resources in the gateway
computer 306, and to serve as a host for application programs
(described below) that run on the gateway computer 306.
[0056] The programs stored in the storage device 504 may include,
for example, a transaction handling application program 510. The
transaction handling application program 510 may control the
processor 500 to enable the gateway computer 306 to handle
transactions in a manner or manners to be described below.
[0057] Another program that may be stored in the storage device 504
is an application program 512 for handling translation of alias
strings received by the gateway computer 306 in connection with
transaction requests. Details of alias translation will be provided
below.
[0058] The storage device 504 may further store one or more
software modules (block 514) that serve as software interfaces
between the gateway computer 306 and one or more other components
of the system 300, including the alias directory 314 (FIG. 3).
[0059] Continuing to refer to FIG. 5, the storage device 504 may
also store, and the gateway computer 306 may also execute, other
programs, which are not shown. For example, such programs may
include communications software and a reporting application. The
latter program may respond to requests from system administrators
for reports on the activities performed by the gateway computer
306. The other programs may also include, e.g., device drivers,
database management software, etc.
[0060] The storage device 504 may also store one or more databases
516 needed for operation of the gateway computer 306.
[0061] Other computerized components of the system 300 may be
constituted by computer hardware having the same type of components
and hardware architecture as described herein with reference to
FIG. 4.
[0062] FIG. 6 is a flow chart that illustrates a process that may
be performed in the system of FIG. 3 in accordance with aspects of
the present disclosure. In particular, the process of FIG. 6
relates to handling a request to select an alias to represent a
deposit account.
[0063] At 602 in FIG. 6 a user request is received for selecting an
alias to represent the user's deposit account. The user request may
be received via any one of a number of channels, including but not
limited to mobile phone apps, web based portals, merchant card on
file systems, digital wallets, mobile browsers or web-browsing PCs,
or over the counter.
[0064] At 604, user authentication takes place. This may be done in
any manner that the beneficiary PSP deems to be prudent. For
example, submission and verification of a PIN may be employed, or
the user may submit and the beneficiary PSP may verify a biometric
measure. More generally, if deemed appropriate or necessary,
ID&V (identification and verification) procedures like those
used in connection with payment card account provisioning may be
employed to obtain reasonable assurance of user authentication.
[0065] At 606, the requestor/user may select an alias to represent
the user's account details. The alias may be, for example, a phone
number, an email address, a unique set of characters or a phrase or
social media handle. The alias may then be mapped by the alias
directory 314 to the user's account details. In some embodiments or
use cases, the alias can be mapped to multiple accounts, though it
may be advisable for a default account to be selected by the user.
The default account may be the account that the alias directory 314
returns when a translation is requested.
[0066] As shown in phantom at 608, in some embodiments or use
cases, the user may cause several aliases to be created to match a
given account.
[0067] FIG. 7 is a flow chart that illustrates a process that may
be performed in the system of FIG. 3 in accordance with aspects of
the present disclosure. In particular, the process of FIG. 7
relates to handling a request for a funds transfer that may involve
an alias selected and mapped per the process of FIG. 6.
[0068] At 702, a funds transfer request is received at the gateway
computer 306.
[0069] A decision block 704 may follow block 702 in the process of
FIG. 7. At decision block 704, the gateway computer 306 may
determine whether transaction routing information in the funds
transfer request (received at 702) includes a bank account number
that identifies a deposit bank account that is the target/recipient
account for the requested funds transfer.
[0070] In some embodiments, the determination at decision block 704
may include parsing a destination account number data field of the
request to determine whether data in that field is in the format of
a bank account number. If not, then the gateway computer may
conclude that the data field contains an alias string that is
standing in for the bank account number for the recipient
account.
[0071] In other embodiments, a flag or the like in the request may
indicate that the request contains an alias string rather than a
recipient bank account number.
[0072] If a negative determination is made at decision block 704
(i.e., if the gateway computer 306 determines that the funds
transfer request does not contain the recipient bank account
number), then block 706 may follow decision block 704 in the
process of FIG. 7.
[0073] At block 706, the alias is translated (e.g., at the alias
directory 314, FIG. 3; e.g., at the request of the gateway computer
306) to the corresponding deposit account details. It will be
assumed that the gateway computer 306 (or other computer performing
like functions) is a trusted service provider with all relevant
security and screening in place, and with secure communication
channels with the alias directory 314. The translation of the alias
at the alias directory 314 provides the required sensitive details
(account details) needed by the system 300 to initiate and route a
funds transfer. With this approach, all sensitive details needed in
performing the funds transfer are maintained within trusted
entities following stringent standards with respect to sensitive
information. It will be appreciated that the alias is never used or
usable to initiate a transfer of funds from the account represented
by the alias.
[0074] Block 708 may follow block 706 in the process of FIG. 7.
Block 708 represents initiation, routing and completion of the
funds transfer utilizing the deposit account details obtained by
translating the alias at 706. In some embodiments, the gateway
computer 306 may communicate with the payment switch/network 308 or
the originator PSP 304 to permit the requested funds transfer to
proceed using the recipient bank account number obtained at 706 by
translating the alias.
[0075] Referring again to decision block 704, if a positive
determination is made at that decision block (i.e., if the gateway
computer 306 determines that the recipient bank account number is
present in the funds transfer request as received at 702), then the
process of FIG. 7 may branch (as indicated at 710) from decision
block 704 directly to block 708. In this circumstance, initiation,
routing and completion of the funds transfer occurs (per block 708)
without alias translation.
[0076] In the process of FIG. 7, the alias translation and funds
transfer process may occur behind the scenes in the EFT network and
in a manner that is transparent to the sender and the
recipient.
[0077] With arrangements as described herein, funds may be credited
to a deposit account via a funds transfer without any need to
reveal account details. From the sender's perspective, all that is
required to transfer funds is the alias that represents the
account, with no need for the sender to deal with the inconvenient
or burdensome details typically required for EFT transfers.
[0078] The process of FIG. 7 may include and/or be part of, or
suitably alter, one or more of the transaction flows described
below.
[0079] According to one alternative network flow, a virtual or
physical merchant card acceptance terminal initiates a transaction
that is transmitted via a merchant system. Prior to transmitting
the request, the merchant system may evaluate the payment
credentials, and if the same are tokenized, may call a
detokenization service provided by a Token Service Provider. Also
prior to transmitting the request, the merchant system may
determine the originator PSP (O-PSP), and build the transaction
request message. The transaction request message is then submitted
by the merchant system to the O-PSP. The O-PSP evaluates the
transaction request message and authenticates the consumer
credentials and debits the originator/consumer account. The flow
then proceeds to the payment network (EFT network), which
determines the routing path and routes to the beneficiary PSP
(B-PSP). The B-PSP evaluates the messages, checks the validity of
the beneficiary account, authorizes the transaction request message
and posts the transaction (immediately or at a later point in time)
against the beneficiary account. The B-PSP returns a response
message to the O-PSP via the payment network (EFT network). The
O-PSP returns the response to the merchant system/merchant card
acceptance terminal.
[0080] According to another alternative network flow, a virtual or
physical merchant card acceptance terminal initiates a transaction
that is transmitted via a merchant system. The merchant system
builds and submits the transaction request message to the merchant
acquirer. The merchant acquirer may evaluate the payment
credentials in the message, and if the same are tokenized, may call
a detokenization service provided by a Token Service Provider. The
merchant acquirer may determine the O-PSP and transmit the message
to the O-PSP. The O-PSP evaluates the transaction request message
and authenticates the consumer credentials and debits the
originator/consumer account. The O-PSP also routes the message to
the payment network (EFT network). The payment network determines
the routing path and routes the message to the B-PSP. The B-PSP
evaluates the message, checks the validity of the beneficiary
account, authorizes the transaction request message and posts the
transaction (immediately or at a later point in time) against the
beneficiary account. The B-PSP returns a response message to the
O-PSP via the payment network (EFT network). The O-PSP returns the
response to the merchant system/merchant card acceptance
terminal.
[0081] According to still another alternative network flow, a
virtual or physical merchant card acceptance terminal initiates a
transaction that is transmitted via a merchant system. The merchant
system builds and submits the transaction request message to the
merchant acquirer. The merchant acquirer may evaluate the payment
credentials in the message, and may determine the payment network
(EFT network). The payment network may evaluate the message and
evaluate the payment credentials in the message, and if the same
are tokenized, may call a detokenization service provided by a
Token Service Provider. Further, the payment network may determine
the O-PSP and transmit the message to the O-PSP. The O-PSP may
evaluate the message and authenticate the consumer credentials and
debit the originator/consumer account. Also, the O-PSP may return
the response to the payment network, which determines the routing
path and routes the message to the B-PSP. The B-PSP evaluates the
message, checks the validity of the beneficiary account, authorizes
the transaction request message and posts the transaction
(immediately or at a later point in time) against the beneficiary
account. The B-PSP returns a response message to the O-PSP via the
payment network (EFT network). The O-PSP returns the response to
the merchant system/merchant card acceptance terminal.
[0082] When the user engages in checkout from such an interface
using a deposit account as the underlying source of funds, any one
of the above alternative transaction flows may occur in various use
cases. As another alternative, the following further alternative
flow may take place.
[0083] Via the merchant device a digital wallet acceptance
interface may be invoked, with user/customer authentication or with
the customer pre-authenticated. The digital wallet provider may
evaluate the payment credentials, and if the same are tokenized,
may call a detokenization service provided by a Token Service
Provider. The digital wallet provider determines the O-PSP and
builds and submits a transaction request message to the O-PSP. The
O-PSP evaluates the message and authenticates the consumer
credentials and then forwards the message to the payment network
(EFT network). The payment network determines the routing path and
routes the message to the B-PSP. The B-PSP evaluates the message,
checks the validity of the beneficiary account, authorizes the
transaction request message and posts the transaction (immediately
or at a later point in time) against the beneficiary account. The
B-PSP returns a response message to the O-PSP via the payment
network (EFT network). The O-PSP returns the response message to
the merchant via the payment network and via the digital wallet
provider. The merchant may also receive other information such as
billing address, shipping address, and loyalty account information
in addition to a payment confirmation message.
[0084] There may be intermediate steps in the above flow, where the
digital wallet provider may act as B-PSP for the funding leg of the
transaction, with the consumer originator account being debited and
a B-PSP account (which can be a pooled account) of the digital
wallet provider posted and credited. In the payment leg of the
transaction, the digital wallet provider may act as O-PSP of the
transaction where the digital wallet provider account is debited
and the B-PSP account of the beneficiary will be posted and
credited.
[0085] In some embodiments, the payment credentials may be a bank
account number and bank routing information (IBAN, IFSC code, SWIFT
code, etc.) and/or card number (credit, debit, prepaid, commercial,
or a push card instrument tied to a deposit account). Mapping of
tokens and payment credentials may allow for the merchant only to
see the token and not the real payment credentials. In some
embodiments, the merchant/merchant bank account may be indicated by
an alias, until the same is translated as part of the transaction
flow.
[0086] In previous discussion herein a use case was described in
which a request for a funds transfer included an alias that was
translated into account details. According to another use case, an
alias can be applied in a scenario in which a user wishes to
authenticate or qualify himself/herself to a merchant. For example,
in some situations, the merchant may be a telephone company (e.g.,
a mobile network operator) and the user may be seeking to open a
post-paid telecommunications services account. In such a situation,
the user may provide his/her alias to the telco/merchant (again the
alias may for example be an email address or a phone number). The
telco/merchant may send the alias to the user's financial
institution/beneficiary PSP using the payment network's API to get
a positive or negative response from the FI/beneficiary PSP. The
payment network operator may in the background facilitate
translation of the alias to the account details and may send the
request to the FI/beneficiary PSP with the relevant details seeking
an authentication. In another use case, the beneficiary PSP may
receive a request to perform a user authentication/ID&V process
relative to the user, with the user and account details being
represented by an alias included in the request for user
authentication.
[0087] FIG. 8 is a flow chart that illustrates another process that
may be performed in the system 300 of FIG. 3 according to other
aspects of the present disclosure. The process of FIG. 8 is
concerned with allowing the service provider 320 to obtain credit
reference or the like with respect to a prospective customer by
using an alias for a bank account owned by the prospective
customer. The process of FIG. 8 proceeds on the assumption that the
prospective customer has provided the alias to the service provider
320. According to one example, the service provider may be a mobile
telephone network operator, and the prospective customer may be
seeking to show that he/she is sufficiently creditworthy to obtain
a post-paid mobile telephone service arrangement.
[0088] At 802 in FIG. 8, the gateway computer 306 may receive a
message from the service provider 320. The message may request an
indication of financial responsibility as to the prospective
customer. The prospective customer and his/her bank account may be
identified in the message only by an alias string, such as mobile
phone number or email address.
[0089] At 804, the gateway computer 306 may use the alias to route
a request to the FI that issued the prospective customer's bank
account. That is, the gateway computer 306 may obtain the bank
account number by having the alias (received at 802) translated by
the alias directory 314. From the bank account number, the gateway
computer may identify the issuing FI and may route the request to
the issuing FI, including the bank account number in the request.
The routing of the request may not be via the same communication
channels utilized for funds transfer requests.
[0090] At 806, the gateway computer 306 may receive a response from
the issuing FI. The response may, for example, contain the
prospective customer's name as listed on the bank account, and may
also include an indication as to whether the prospective customer
is deemed financially responsible, as determined by the issuing FI
based on its experience with the bank account in question. It will
be appreciated that the indication may be a positive or negative
indication as to the prospective customer's creditworthiness.
[0091] At 808, the gateway computer 306 may transmit information to
the service provider 320 based on the response received by the
gateway computer 306 at 806. The information provided at 808 may
include the prospective customer's name (as provided by the issuing
FI) and the indication as to whether the prospective customer is
deemed financially responsible. Based on the information, the
service provider 320 may be able to confirm the prospective
customer's identity (as provided by the prospective customer to the
service provider 320) and may also make a prudent decision as to
whether to extend credit to the prospective customer. This may
occur without the prospective customer revealing sensitive
information such as his/her bank account number to the service
provider 320.
[0092] FIG. 9 is a block diagram that shows aspects of the payment
transaction system 300 of FIG. 3 as provided in accordance with
other embodiments. In FIG. 9, the payment transaction system is
generally indicated by reference numeral 300a. Some or all
components of the system 300 of FIG. 3 may be present in the system
300a, although not explicitly depicted in FIG. 9.
[0093] The payment transaction system 300a may include a merchant
device 902 which is provided in accordance with teachings of the
present transaction. The merchant device 902 may in many ways
resemble a typical POS terminal, but it is assumed that the
merchant device 902 has been programmed to generate an optical code
to support transaction processing as described herein. The merchant
device may print out the optical code (reference numeral 904) on a
piece of paper via its printer component (not separately shown)
and/or may display the optical code on its display component (not
separately shown). Suitable types of optical codes may include a QR
(quick response) code or other type of barcode, but other types of
optical codes may be used, including, for example, a suitable
string/block of alphanumeric characters.
[0094] The customer (not shown) at the point of sale is assumed to
be in possession of a suitable customer device 906. The customer
device 906 may be a smartphone programmed with a mobile app that
facilitates the payment process as described herein. The customer
device 906 may alternatively be another type of suitably programmed
mobile device other than a smartphone. The customer device 906 is
assumed to have a camera component (not separately shown)--as most
smartphones do--with which the customer device 906, under control
of the relevant mobile app, captures (reference numeral 908) an
image of the optical code 904 as printed out or displayed by the
merchant device 902.
[0095] The system 300 further includes components of an EFT/ACH
system similar to those described above in connection with FIG. 2.
In particular, the system 300a includes a payment switch/network
910. The payment switch/network 910 may resemble the payment
switch/network 206 of FIG. 2, but with additional capabilities for
receiving and translating optical code images sent to the payment
switch/network 910 from customer devices that are located at a
point of sale. Also shown in FIG. 9 are an originator PSP 912 and a
beneficiary PSP 914, which may correspond, respectively, to the
items 204 and 208 described above in connection with FIG. 2.
[0096] Any one or more of the blocks shown in FIG. 3, in addition
to representing the indicated entity, may also be considered to
represent one or more computer systems operated by such entity.
[0097] One or more computers that are components of the system 300a
may have the same type of hardware aspects as were described in
connection with FIG. 4. Thus, for example, one or more components
of the system 300a may include a processor in communication with a
communication device, a storage device, an input device and an
output device. One or more of the components (e.g., the payment
switch/network 910 and/or the originator PSP 912) may run program
instructions to provide functionality as described below in
conjunction with FIG. 10.
[0098] FIG. 10 is a flow chart that illustrates a process that may
be performed in the system 300a as depicted in FIG. 9. In
particular, the process of FIG. 10 relates to a payment process
that allows a merchant to accept EFT payment by producing an
optical code.
[0099] The process of FIG. 10 assumes that the merchant has
previously enrolled in an optical-code-EFT acceptance program. Such
registration may, for example, occur by the merchant interacting
online with a website hosted, e.g., by a computer operated by the
EFT network operator/clearing facility. During the online
interaction, the merchant may enter its identification details
(name and address of merchant) and bank account details and may
agree to terms and conditions of participating in the program. The
merchant may then print out and display decals to inform customers
of the merchant's participation in the optical-code-EFT acceptance
program.
[0100] The process of FIG. 10 further assumes that the customer has
registered for the program. This may involve downloading the mobile
app for the program to the customer's smartphone (customer device
906, FIG. 9). Also, the customer may register himself/herself
through the app by providing a delegation of user authentication to
the app in order to initiate push transactions to credit business
or other individual accounts.
[0101] At 1002 in FIG. 10, a purchase transaction is commenced at
the point of sale. This may take place after the customer has
entered the merchant's store, selected merchandise, and approached
the checkout counter. The customer may also have opened the
relevant app on his/her smartphone and authenticated
himself/herself in a secure manner to the app (i.e., in a manner
that is satisfactory to the banking partners participating in the
program).
[0102] At 1004, the merchant device generates and prints/displays
the above mentioned optical code (item 904 in FIG. 9).
[0103] At 1006, the customer's smartphone, via the app for the
optical code acceptance program, captures an image of the optical
code 904.
[0104] At 1008, the customer's smartphone (via the app) prompts the
customer to confirm that the customer is approving the transaction
and the indicated payment to the merchant's account. Assuming the
customer indicates confirmation/approval, then block 1010 follows
block 1008.
[0105] At 1010, the optical acceptance app in the
smartphone/customer device 906 communicates with the payment
switch/network 910 (or the originator PSP 912) to transmit the
image of the optical code to the payment switch/network 910 (or to
the originator PSP, as the case may be). It may be assumed that the
same communication identifies the customer via registration details
to the payment switch/network 910.
[0106] At 1012, the payment switch/network 910 translates the
optical code image into transaction details, including the
merchant's bank account details and the transaction amount.
[0107] At 1014, the payment switch network 1010 executes a funds
transfer in which the funds are debited from the customer's bank
account and credited almost immediately to the merchant's bank
account. The result may be a very rapid EFT credit to the merchant
virtually in real time as the purchase transaction is being
consummated.
[0108] In some embodiments, the optical code may be
translated/interpreted at the originator PSP 912 and/or at the
customer device 906.
[0109] As used herein and in the appended claims, the term
"computer" should be understood to encompass a single computer or
two or more computers in communication with each other.
[0110] As used herein and in the appended claims, the term
"processor" should be understood to encompass a single processor or
two or more processors in communication with each other.
[0111] As used herein and in the appended claims, the term "memory"
should be understood to encompass a single memory or storage device
or two or more memories or storage devices.
[0112] As used herein and in the appended claims, a "server"
includes a computer device or system that responds to numerous
requests for service from other devices.
[0113] The above descriptions and illustrations of processes herein
should not be considered to imply a fixed order for performing the
process steps. Rather, the process steps may be performed in any
order that is practicable, including simultaneous performance of at
least some steps.
[0114] As used herein and in the appended claims, the term "payment
card system account" includes a credit card account, a deposit
account that the account holder may access using a debit card, a
prepaid card account, or any other type of account from which
payment transactions may be consummated. The terms "payment card
system account" and "payment card account" and "payment account"
are used interchangeably herein. The term "payment card account
number" includes a number that identifies a payment card system
account or a number carried by a payment card, or a number that is
used to route a transaction in a payment system that handles
payment card transactions. The term "payment card" includes a
credit card, debit card, prepaid card, or other type of payment
instrument, whether an actual physical card, electronic, or
virtual.
[0115] As used herein and in the appended claims, the term "payment
card system" or "payment account system" refers to a system for
handling purchase transactions and related transactions. An example
of such a system is the one operated by MasterCard International
Incorporated, the assignee of the present disclosure. In some
embodiments, the term "payment card system" may be limited to
systems in which member financial institutions issue payment card
accounts to individuals, businesses and/or other organizations.
[0116] Although the present invention has been described in
connection with specific example embodiments, it should be
understood that various changes, substitutions, and alterations
apparent to those skilled in the art can be made to the disclosed
embodiments without departing from the spirit and scope of the
invention as set forth in the appended claims.
* * * * *