The present disclosure relates to executing secure financial transactions5 .
BACKGROUND OF THE INVENTION
[0002] The background description includes information that may be useful in
understanding the present invention. It is not an admission that any of the information
10 provided herein is prior art or relevant to the presently claimed invention, or that any
publication specifically or implicitly referenced is prior art.
[0003] Typically, a financial transaction can get initiated and authenticated from either a
trusted merchant’s interface (eg: an e-commerce site) or from a bank’s trusted interface
(eg: internet banking portal). Recent years have seen substantial growth in electronic
15 commerce, mobile commerce, and electronic peer-to-peer transactions. There has also
been a phenomenal growth and widespread adoption of mobile and other computing
devices (eg: mobile smart phones, smart-watches and tablets). Supporting these devices
are a number of applications (commonly referred to as apps) and/or browser based
services that provide useful or interesting services for its consumers. For example,
20 google.com is widely used for searching the world wide web (Internet), Gmail is a
service that provides its customers an email address and a web based email messaging,
Facebook is an online social network, Twitter is a broadcast-subscribe based model for
micro-messages, Sunrise is a calendar application that allows customers to schedule and
manage events, meetings and their lives. The examples mentioned here are purely
25 indicative in nature and not comprehensive in either their scope or coverage.
[0004] Most of the services mentioned above cater to millions of customers across
geographies, wherein the potential for leveraging their network effect makes these
services a lucrative destination for advertisements and in enabling various forms of
product discovery and customer engagement. For instance, an online marketplace such as
30 Amazon.com may find it attractive to insert an advertisement of their latest bestseller
book within the Facebook newsfeeds of certain categories of customers. Clicking or
3
tapping on these advertisements typically leads to the product page providing further
information that would ultimately lead to a payment and a purchase.
[0005] In such a situation, the act of payment would typically involve multiple steps
where the financial identity (eg: card number, wallet id) of the customer is acquired by
the merchant. In addition authentication information (eg: PIN, password) is taken fro5 m
the customer. Another essential input is the amount being paid. The information thus
collected would travel from the merchant to the transaction acquiring partner bank and
then finally to the financial identity issuing bank of the customer where the transaction
may finally be approved or declined and the result relayed back to the originating
10 merchant.
[0006] In such above-mentioned cases, a customer has to leave the context of the
application from where the intent to purchase is created. For example, if a customer is on
a Facebook homepage, he/she has to completely leave this context and move to
Amazon’s context to fulfill the transaction. There is therefore no effective way to be able
15 to complete the transaction on the third party interface itself (eg: within the comment on
Facebook). Since the merchant and the acquirer are not really trusted entities for the
issuer, and are outside its direct control, it either redirects the customer to its own domain
to take the authentication information or relies on contractual obligations and third party
certifications to ensure that the information collected on these interfaces securely reach
20 them and that no copy of customer’s confidential financial credentials like the
authentication information or the financial identity has been retained anywhere in this
value chain.
[0007] However, as recent breaches with large merchants such as Target and Staples
have shown, there seems to be no way to effectively enforce any of the statutory
25 obligations on third party participants in the nearly global network of transaction
acquiring interfaces.
[0008] There is therefore a need in the art for architectures/systems enabling a secure
financial transaction to be initiated with authentication in even an untrusted partner’s
domain while being truly in-stream i.e there is no need to leave the particular
30 application’s context to fulfill the associated payment transaction.
[0009] All publications herein are incorporated by reference to the same extent as if each
individual publication or patent application were specifically and individually indicated
4
to be incorporated by reference. Where a definition or use of a term in an incorporated
reference is inconsistent or contrary to the definition of that term provided herein, the
definition of that term provided herein applies and the definition of that term in the
reference does not apply.
[0010] In some embodiments, the numbers expressing quantities of ingredients5 ,
properties such as concentration, reaction conditions, and so forth, used to describe and
claim certain embodiments of the invention are to be understood as being modified in
some instances by the term “about.” Accordingly, in some embodiments, the numerical
parameters set forth in the written description and attached claims are approximations
10 that can vary depending upon the desired properties sought to be obtained by a particular
embodiment. In some embodiments, the numerical parameters should be construed in
light of the number of reported significant digits and by applying ordinary rounding
techniques. Notwithstanding that the numerical ranges and parameters setting forth the
broad scope of some embodiments of the invention are approximations, the numerical
15 values set forth in the specific examples are reported as precisely as practicable. The
numerical values presented in some embodiments of the invention may contain certain
errors necessarily resulting from the standard deviation found in their respective testing
measurements.
[0011] As used in the description herein and throughout the claims that follow, the
20 meaning of “a,” “an,” and “the” includes plural reference unless the context clearly
dictates otherwise. Also, as used in the description herein, the meaning of “in” includes
“in” and “on” unless the context clearly dictates otherwise.
[0012] The recitation of ranges of values herein is merely intended to serve as a
shorthand method of referring individually to each separate value falling within the
25 range. Unless otherwise indicated herein, each individual value is incorporated into the
specification as if it were individually recited herein. All methods described herein can
be performed in any suitable order unless otherwise indicated herein or otherwise clearly
contradicted by context. The use of any and all examples, or exemplary language (e.g.
“such as”) provided with respect to certain embodiments herein is intended merely to
30 better illuminate the invention and does not pose a limitation on the scope of the
invention otherwise claimed. No language in the specification should be construed as
indicating any non-claimed element essential to the practice of the invention.
5
[0013] Groupings of alternative elements or embodiments of the invention disclosed
herein are not to be construed as limitations. Each group member can be referred to and
claimed individually or in any combination with other members of the group or other
elements found herein. One or more members of a group can be included in, or deleted
from, a group for reasons of convenience and/or patentability. When any such inclusio5 n
or deletion occurs, the specification is herein deemed to contain the group as modified
thus fulfilling the written description of all Markush groups used in the appended claims.
SUMMARY
10 [0014] An object of the present disclosure is to enable secure financial transactions on
even third-party interfaces that may not be trusted by the issuer of the source of funds.
Yet another object of the present disclosure is to be able to complete the transaction instream,
within the third-party application’s context and interface itself while employing
multiple factors for authentication. Another object of the present disclosure is to securely
15 enable a third party to initiate a transaction that has been pre-authorized by the customer
on a fulfillment interface of the third-party’s choice and convenience but effected on the
customer’s original issuer of electronic funds. Yet another object of the present disclosure
is to simplify the process of the transaction itself by reducing the number of inputs, steps
and processing required.
20 [0015] The present disclosure relates to executing secure financial transactions over user
interfaces that may not be trusted interfaces for the issuer (bank) of electronic funds to
the customer. In an aspect, the present disclosure relates to systems and methods that
enable transactions to be initiated and authenticated on even a third-party interface such
as a social networking website, an email application, a web-based calendar, a remote
25 ATM) that may not be a trusted interface for the bank or the merchant.
[0016] Accordingly, the present disclosure relates to a system and method for initiating a
transaction request on an untrusted interface while also accepting authentication
information along with the customer’s identity and intent to make the payment, the
amount to be paid, and one or more identification identifiers of the recipient of the
30 payment funds.
[0017] In an aspect, the proposed system includes of a third party front end interface,
possibly a third party back-end server interface, a main application server(s) that
6
processes the transactions and integrates with various financial institutions, and switches
that serve as source(s) and destination(s) of the electronic funds, and associated helper
modules.
[0018] According to one embodiment, the main application server can be configured to
capture the transaction that is initiated on a front-end interface, wherein the server ca5 n
convert the customer’s intent to pay and associated information into a financial
transaction format that can be consumed by existing financial institutions, wherein the
institutions can then process the received financial transaction format and provide a
transaction response.
10 [0019] In another aspect, the proposed system can further communicate back
appropriately to the front-end application interface with the transaction response thus
received from the financial institution(s) such that the parties involved in the transaction
can know the status/ result of the transaction they had initiated.
[0020] Further aspects of the present disclosure will become apparent from consideration
15 of the drawings and the ensuing description of preferred embodiments of the invention. A
person skilled in the art will realize that other embodiments of the invention are possible
and that the details of the invention can be modified in a number of respects, all without
departing from the concept. Thus, the following drawings and description are to be
regarded as illustrative in nature and not restrictive. Various objects, features, aspects and
20 advantages of the inventive subject matter will become more apparent from the following
detailed description of preferred embodiments, along with the accompanying drawing
figures in which like numerals represent like components.
BRIEF DESCRIPTION OF DRAWINGS
25 [0021] A complete understanding of the system and method of the present invention may
be obtained by reference to the following drawings:
[0022] FIG. 1 illustrates an exemplary architecture of the proposed third-party interface
based transaction execution in accordance with an embodiment of the present disclosure.
[0023] FIG. 2 illustrates exemplary functional modules of the proposed system in
30 accordance with an embodiment of the present disclosure.
[0024] FIG. 3 illustrates generation of a one-time transaction PIN based on an original
PIN and a tokenization key in accordance with an embodiment of the present disclosure.
7
[0025] FIG. 4 illustrates another set of exemplary modules of the proposed financial
transaction execution system in accordance with an embodiment of the present
disclosure.
[0026] FIG. 5 illustrates another exemplary architecture layout of the proposed financial
transaction execution system in accordance with an embodiment of the presen5 t
disclosure.
[0027] FIGs. 6A to 6B illustrate exemplary representations showing execution of a
financial transaction using a third party application/interface in accordance with an
embodiment of the present disclosure.
10 [0028] FIG. 7 illustrates an exemplary flow diagram showing execution of a financial
transaction using a third party application/interface in accordance with an embodiment of
the present disclosure.
[0029] FIG. 8 illustrates another exemplary flow diagram showing execution of a
financial transaction using a third party application/interface in accordance with an
15 embodiment of the present disclosure.
DETAILED DESCRIPTION OF THE INVENTION
[0030] Throughout the following discussion, numerous references will be made
20 regarding servers, services, interfaces, engines, modules, clients, peers, portals, platforms,
or other systems formed from computing devices. It should be appreciated that the use of
such terms is deemed to represent one or more computing devices having at least one
processor (e.g., ASIC, FPGA, DSP, x86, ARM®, ColdFire®, GPU, etc.) configured to
execute software instructions stored on a computer readable tangible, non-transitory
25 medium (e.g., hard drive, solid state drive, RAM, flash, ROM, etc.). For example, a
server can include one or more computers operating as a web server, database server, or
other type of computer server in a manner to fulfill described roles, responsibilities, or
functions. One should further appreciate the disclosed computer-based algorithms,
processes, methods, or other types of instruction sets can be embodied as a computer
30 program product comprising a non-transitory, tangible computer readable media storing
the instructions that cause a processor to execute the disclosed steps. The various servers,
systems, databases, or interfaces can exchange data using standardized protocols or
8
algorithms, possibly based on HTTP, HTTPS, AES, public-private key exchanges, web
service APIs, known financial transaction protocols, or other electronic information
exchanging methods. Data exchanges can be conducted over a packet-switched network,
the Internet, LAN, WAN, VPN, or other type of packet switched network.
[0031] One should appreciate that the disclosed techniques provide many advantageou5 s
technical effects including configuring and processing various feeds to determine
behaviour, interaction, management, and response of users with respect to feeds and
implement outcome in enhancing overall user experience while delivering feed content
and allied parameters/attributes thereof.
10 [0032] The following discussion provides many example embodiments of the inventive
subject matter. Although each embodiment represents a single combination of inventive
elements, the inventive subject matter is considered to include all possible combinations
of the disclosed elements. Thus if one embodiment comprises elements A, B, and C, and
a second embodiment comprises elements B and D, then the inventive subject matter is
15 also considered to include other remaining combinations of A, B, C, or D, even if not
explicitly disclosed.
[0033] An object of the present disclosure is to enable secure financial transactions on
even third-party interfaces that may not be trusted by the issuer of the source of funds.
Yet another object of the present disclosure is to be able to complete the transaction in20
stream, within the third-party application’s context and interface itself while employing
multiple factors for authentication. Another object of the present disclosure is to securely
enable a third party to initiate a transaction that has been pre-authorized by the customer
on a fulfillment interface of the third-party’s choice and convenience but effected on the
customer’s original issuer of electronic funds. Yet another object of the present disclosure
25 is to simplify the process of the transaction itself by reducing the number of inputs, steps
and processing required.
[0034] The present disclosure relates to executing secure financial transactions over user
interfaces that may not be trusted interfaces for the issuer (bank) of electronic funds to
the customer. In an aspect, the present disclosure relates to systems and methods that
30 enable transactions to be initiated and authenticated on even a third-party interface such
as a social networking website, an email application, a web-based calendar, a remote
ATM) that may not be a trusted interface for the bank or the merchant.
9
[0035] Accordingly, the present disclosure relates to a system and method for initiating a
transaction request on an untrusted interface while also accepting authentication
information along with the customer’s identity and intent to make the payment, the
amount to be paid, and one or more identification identifiers of the recipient of the
payment funds5 .
[0036] In an aspect, the proposed system includes of a third party front end interface,
possibly a third party back-end server interface, a main application server(s) that
processes the transactions and integrates with various financial institutions, and switches
that serve as source(s) and destination(s) of the electronic funds, and associated helper
10 modules.
[0037] According to one embodiment, the main application server can be configured to
capture the transaction that is initiated on a front-end interface, wherein the server can
convert the customer’s intent to pay and associated information into a financial
transaction format that can be consumed by existing financial institutions, wherein the
15 institutions can then process the received financial transaction format and provide a
transaction response.
[0038] In another aspect, the proposed system can further communicate back
appropriately to the front-end application interface with the transaction response thus
received from the financial institution(s) such that the parties involved in the transaction
20 can know the status/ result of the transaction they had initiated.
[0039] In an aspect, a typical financial transaction requires: an entity being debited, an
entity being credited, an amount being credited, authentication from the debited entity
authorizing the issuing financial institution to enact the transaction, and the intent of the
payment itself. There could be a lot of other parameters that come into play such as the
25 geo-location, currency, type of instrument used, timestamps so on and so forth, which are
not usually critical towards the constitution of a financial transaction but may add value
to it.
[0040] In an exemplary implementation, the proposed system can provide an online
interface for customers to sign up for the service by providing one or more of their
30 identity tokens. These identity aliases can include, but are not limited to, their email id,
social network id, tax identification id, voter id, mobile numbers, application user names ,
among any other unique identifier. Single Sign On (SSO) methods may be used to
10
capture these identity tokens. In an aspect, the proposed system can also be configured to
assign its own unique customer identifier to the customer thus enrolled. In a particular
embodiment, the system may generate and issue a custom alias token, which may employ
one of the following embodiments: virtual, magnetic stripe based card, smart card, EMV
compatible chip card, NFC compatible card or sticker, QR code or bar code5 .
[0041] The system can then be configured to capture, from the customer, the financial
identity that links him/her/it to the source of funds and/ or a destination of funds. These
financial end-points could be a bank card, bank account, a wallet or any other form of
value storage that is electronically accessible. In some embodiments, the system may
10 need to be explicitly integrated and associated with the financial institutions to enable this
linkage. In others, this linkage may work through an association with a network that
enables this linkage.
[0042] In another embodiment, the system can be capable of using existing token service
providers for creating alias tokens that would be further mapped instead of the original
15 financial access tokens themselves. In an aspect, association or disassociation of these
identities could happen over a period of time and based on the identities being mapped or
removed, different functionalities would be made available or otherwise. The system
requires and can assume that each source of fund defines its own authentication
parameter for enabling a customer to authorize a transaction on his behalf. The system
20 can also integrate with one or more authentication tokenization methods. According to
one implementation, an authentication tokenization method can enable a customer’s
authentication information to be converted into a one-time use token. Such a solution
may be offered over a mobile application in a customer facing user interface. One such
authentication method is described vide another patent application PCT/IN2011/000128,
25 which effectively enables a customer to transform his/ her PIN into a one-time use
numeric token hereafter referred to as pinTwin.
[0043] In an aspect, the proposed system can have a set of listener services, wherein
these listeners can have their own identities and can include specialized email addresses
such as wizard@pintwin.com, special mobile numbers like +91.9212277543, special
30 short codes like 543, hashtags like #pintwin, #eko, #unpin on Twitter, Pinterest,
Facebook, Instagram. These could be dedicated Facebook, Twitter ids. These listener
end-points can also include a web-site or an API that can get invoked by a third party or
11
through a special integration already made. These listeners can also be capable of
receiving transaction requests received from any third party interfaces. For example, if a
customer intends to initiate a rent payment transaction from her online calendar event,
she would add wizard@pintwin.com to the event. This will enable a specialized listener
pre-configured to receive all changes and content related to that particular event. Fo5 r
example, if the customer has already added landlord@xyz.com as the other entity on the
calendar invite, the listener is able to establish that the customer (who is using her
calendar and thus having her own id say, customer@xyz.com) is intending to pay her
landlord identified by landlord@xyz.com through the calendar event notification.
10 Further, in the calendar event subject, she could type pay $1000. The listener is also
capable of executing natural language processing algorithms to figure out that this is the
amount being transacted. Finally, since the system provides a method for the customer to
tokenize her bank account PIN/ password, this authentication token could also be safely
provided on the calendar subject as a simple text such as say ABCD. One should
15 appreciate that no financial identity or authentication details of the participants of the
transaction are getting exposed on any of the untrusted user interfaces since alias tokens
are being used. Thus, the system protects the customers and the financial institutions
from breaches of confidential information. In addition, since the authentication
tokenization methods employed by the system provide for only one-time use tokens that
20 can be easily typed in on any interface accepting textual input. Thus, any third party
electronic system can become a secure transaction initiation platform, even if it are not
trusted.
[0044] In an aspect, the listener that is attached to the particular interface for initiating
the transaction can then collate all the desired information, look up the financial identities
25 of the debiting and crediting entities, and recreate the original authentication information
(eg: PIN) of the customer. With all this information, the system is able to invoke the
appropriate financial APIs such that this information reaches the issuing financial
institution such that it is able to make the required financial transaction. In addition, the
system is capable of applying additional business rules to such transactions and pass back
30 the transaction responses/ receipts over multiple or original communication channels like
SMS, call, email, Twitter message, Facebook post or a WhatsApp message.
12
[0045] In a different embodiment, the untrusted interface can be an ATM (Automated
Teller Machine), especially an untrusted third party ATM. The proposed disclosure
provided herein enables the customer and his funds issuer to be able to safely use this by
first issuing a card that would be compatible with the fulfilment interface of an ATM,
which acts as the identity alias to an original card/ account number being held by th5 e
customer and by providing a mechanism for the customer to tokenize his/ her ATM PIN
into its pinTwin. In an aspect, both the tokenized card and the tokenized authentication
factor as described in the present disclosure can be used seamlessly on the existing user
interface without any modification whatsoever of the front-end. The solution server at the
10 back-end can be capable of capturing the transaction request thus originated and
transforming it in real-time to the original card and the original PIN of the customer and
passing it on to the original funds issuer of the customer for authorization and for
relaying this information back to the transaction acquiring interface.
[0046] In a slight variation to the embodiment above, the customer using the tokenized
15 identity and the tokenized authentication could be someone other than the original
customer. Since the authentication factor is only one time use and since the scope of the
transaction (eg: amount, location, time of fulfilment) can be set by the customer, the
authentication token could be shared with another customer and the transaction
dynamically linked to another customer’s identity token easily, which allows for use
20 cases such as enabling remote withdrawal of funds from a customer’s funds by another
customer, over even an untrusted interface as long as the other customer has been
explicitly authorized to do so and the authentication token is shared with the other party.
Therefore, combining tokenization of financial identity, authentication and through a
system of smart transaction listeners, dispatchers and messaging systems, the proposed
25 system is able to enable various methods for making secure financial transactions over
even non-trusted interfaces and even by other customers.
[0047] FIG. 1 illustrates an exemplary architecture of the proposed third-party interface
based transaction execution in accordance with an embodiment of the present disclosure.
As shown, the architecture 100 can include an issuer 102 that is operatively coupled with
30 a computing device 104 on which a third-party application 106 including but not limited
to an email application, a social networking application, a chat/messaging application, an
e-commerce application, a financial application, a news application, a calendar
13
application, an ATM, an information/blog application, is installed/configured/presented.
The issuer 102 can be operatively coupled, through the computing device 104 or any
other device/means, with an issuing bank/financial institution 108, wherein the issuer 102
has a financial identity with the bank, wherein the financial identity can include, but is
not limited to, account number, debit/credit card number, IFSC code, PIN, expir5 y
information, or any other information that enables the issuing bank/issuer to complete a
given transaction.
[0048] In another embodiment, the architecture 100 can include a financial institution
110 of the third-party application’s service provider, which can be configured to receive
10 the transaction details of the transactions initiated using the third party
application/interface. According to another embodiment, the architecture 100 can include
a beneficiary 112 that is operatively coupled with a beneficiary bank/financial institution
114 that the beneficiary 112 has an account with, wherein the beneficiary 112 also has a
financial identity with the bank 114.
15 [0049] According to one embodiment, an issuer 102 can, through the third party
application/interface 106, associate its financial identity with its unique identifier on the
third party application 106 or any other unique identifier. For instance, financial identity
of the issuer can be associated with Twitter/Facebook/Email id/phone number/social
security number of the issuer 102, post which the issuer can, on the third party
20 application 106 such as in an email, initiate a financial transaction indicate at least the
beneficiary’s financial identity/identifier, amount to be transferred, and a one-time PIN.
The one-time PIN, as also explained above and below with reference to FIGs. 2 and 3,
can be generated using the original PIN and a transformation key. Once such a financial
transaction is initiated, the details of the same can be formatted/parsed/processed and
25 then sent to the financial institution 110 of the third-party application’s service provider,
based on which the financial institution 110 sends requisite information to the issuer’s
financial institution 108 and beneficiary’s financial institution 112 for authentication of
the issuer 102 using the one-time PIN at the issuer’s financial institution 108, and transfer
of the amount from the issuer’s financial institution 108 to the beneficiary’s financial
30 institution 112.
[0050] FIG. 2 illustrates exemplary functional modules 200 of the proposed system in
accordance with an embodiment of the present disclosure. In an aspect, the system 200
14
can include a financial identity to unique identifier mapping module 202, tokenization
key retrieval module 204, PIN transformation module 206, third-party interface based
transaction initiation module 208, third-party listener based transaction processing
module 210, financial institution based transaction execution module 212, and a
transaction completion module 2145 .
[0051] According to one embodiment, unique identifier mapping module 202 can be
configured to enable a user/customer/transaction initiator to map his/her/its financial
identity including but not limited to account number, bank, branch code, IFSC code,
SWIFT code, among any other details of the bank account/issuing financial institution,
10 with a third party unique identifier such as social networking identifier/email
address/twitter handle/Social Security Identifier, or any other identifier of customer’s
convenience. In an aspect, such mapping can be performed at a user interface of say the
third party website/application itself, where the user enters his/her financial identity and
maps it with his/her unique/public/private identifier.
15 [0052] One should appreciate that user/customer of the present disclosure can include an
individual or even a company, and therefore all such stakeholders/entities that wish to
initiate a financial transactions are completely within the scope of the present disclosure.
[0053] It should also be appreciated that instead of one, multiple bank accounts/credit
card accounts/debit card accounts can be linked to a given third part identifier of the user.
20 [0054] According to one embodiment, tokenization key retrieval module 204 can be
configured to enable the user/customer to retrieve/fetch a one-time authentication
tokenization key for his/her financial identity. For instance, in case the user, through
module 202, had linked a debit card of a Bank B, module 204 can be configured to enable
the user to fetch, from Bank B, a one time tokenization key for financial identity/bank
25 account of the user. With reference to FIG. 3, a one time tokenization key 302 is being
shown, which can be received by a user through any means including but not limited to a
mobile application of the third party interface, bank interface, SMS, email, WhatsApp, or
any other means wherein the tokenization key 302 can be securely transmitted to the
user/customer. For instance, a special page can be created on Facebook of the user that
30 enables the user to, through module 202, associate the facebook identifier of the user with
one or more bank accounts, and then through module 204, receive a one time
tokenization key in real time upon request.
15
[0055] According to one embodiment, PIN transformation module 206 can be configured
to enable the user/customer to use his/her original/real secret PIN for the bank
account/debit/credit card that he/she has mapped with the third party identifier, and map
the original PIN with the tokenization key to generate a one time transformation PIN that
can be used to authenticate the user for a single transaction. As the issuing bank that i5 s
connected with the third party interface/identifier of the user has issued the tokenization
key, the bank is aware of the one time transformation PIN (TPIN) and can accordingly
authenticate the user. With reference to FIG. 3, in case the original PIN for the customer
for the selected source of funds is 2367, the tokenized authentication for that transaction
10 becomes 2956.
[0056] According to one embodiment, third-party interface based transaction initiation
module 208 can be configured to enable the user/customer to initiate the transaction on
the third part interface such as on a Twitter page, or a Facebook page, or a LinkedIn
Page, or on any other third party page such as even a blog/news page such as CNN
15 website/sports page/among others that has implemented/incorporated the proposed
system, wherein the user can send/issue a message in a defined format such as “Pay Rs.
100 to @Beneficiary #TPIN”. Such a format for transaction initiation may be kept fixed
for all third party interface, or can be implemented as being flexible/ configurable/
customizable for each third party interface. Such a message can be written in any
20 configured location on the third party interface such as in the message box/status update
box of the facebook page, or in an email subject of an email application, or in the
description of a calendar page. One should clearly appreciate that although the present
dislcosure is largely being explained with reference to social networking platforms,
aspects of the present disclosure can be implemented in any third party interface such as
25 in an email application, chat application, an ecommerce application or just any web/nonweb
enabled application that can communicatively be coupled with financial institutions
for authentication and transaction completion. As mentioned above, a message such as
“Pay Rs. 100 to @Beneficiary #TPIN” can be changed as regards its
format/content/configuration but should include at least the minimum beneficiary details
30 indicated in @Beneficiary such as bank account number/identifier/IFSC code or any
other details that may be required. In case the beneficiary has a unique identifier on the
third party interface and has coupled his/her financial bank information on the interface
16
with the unique/third party identifier (such as twitter/linkedin/email id), the
sender/user/customer can simply submit the unique/third party identifier of the
beneficiary (say beneficiary_234678) in the message. The message can also include the
one time transformation PIN (TPIN) that was generated by the user.
[0057] According to one embodiment, third-party listener based transaction processin5 g
module 210 can be configured to enable a listener /adapter that is configured in/for the
third party interface/application to continuously listen to such above mentioned mesasge
and identify if they indicate initiation of a transaction. For instance, the message can
include a unique term such as #pinTwin, which can uniquely indicate to the listener that a
10 financial transaction has been initiated by the user/customer that is currently logged into
the third party application. Listener can also use natural language processing to detect the
format of the message to conclude whether the message is indicative of a new financial
transaction. Once a new transaction is detected, the listener can be operatively coupled
with a financial identity tokenization service that is configured to check the financial
15 details/identity of both the @customer_1 that has initiated the transaction (detected as the
transaction was initiated from his/her account) and @customer_2 who is the intended
beneficiary of the transaction and whose financial identity details are present in the
message sent by customer_1.
[0058] According to one embodiment, the financial institution based transaction
20 execution module 212 can be configured to send the transaction details, once financial
identity details of both the issuing as well the beneficiary customers have been retrieved,
to the financial institution of the service provider such as Email application service
provider (Gmail for instance), chat/messaging application service provider (Whatsapp for
instance), social networking application service provider (Facebook, for instance).
25 According to one embodiment, such transaction details can, before being sent to the
financial institution of the service provider, can be processed to determine if the
transaction should/could/can be processed, based on message format, history of the
user/customer, product/service being purchased, among any other aspect/parameter. In
another aspect, before the transaction details are sent to the financial institution of the
30 service provider, transaction can also be translated to a defined format required by the
financial institution of the service provider, wherein such translation can be performed,
for instance, by necessary de-tokenization of the identities and the authentication.
17
[0059] According to one embodiment, transaction completion module 214 can be
configured to enable the financial institution of the service provider to receive the
transaction details and send the necessary/configured details to both the issuing as well as
the beneficiary’s banks to enable the issuing bank to authenticate the user/customer based
on TPIN and then transfer the amount to the beneficiary’s bank. Based the successfu5 l
completion of the transaction, the proposed system/application configured in the third
party interface can issue/present a confirmation message such as “Money sent to
@customer_2”.
[0060] FIG. 4 illustrates another set of exemplary modules 400 of the proposed financial
10 transaction execution system in accordance with an embodiment of the present
disclosure. In an exemplary aspect, the system can include a financial institution/card
token provider interface 402, a customer user interface 404, a third party adapter/listener
406, a response message dispatcher 408, a financial identity tokenizing service 410, an
authentication tokenization service 412, and a business logic 414.
15 [0061] In an aspect, the customer user interface 404 is the third-party application
interface on which the originator/sender/user/customer of the transaction maps his/her
unique third-party identifier with his/her financial identify. It is the customer user
interface 404 on which the sender/user initiates the transactions and even receives a
confirmation that the transaction is successful and that the amount has been transferred.
20 [0062] According to one embodiment, the third party adapter/listener 406 is configured
to listen to a defined pattern of a message that is indicative of a transaction initiation and
can further be configured to intercept the message and process the same for execution of
the transaction. Such a listener 406 can be implemented differently by each third-party
application service provider. According to one embodiment, the financial financial
25 identity tokenizing service 410 can be configured to check/retrieve the financial identities
of both the initiating customer as well as the beneficiary customer. In another aspect, the
business logic 414 can be configured to determine if the initiated transaction can even be
processed based on multiple parameters such as bank account status of the issuer/user,
user profile, format of the transaction message, among other like parameters. Upon
30 completion of the transaction, response message dispatcher 408 can be configured to send
a message back to the third party interface confirming that the money has been
transferred from the issuer to the beneficiary.
18
[0063] According to one embodiment, the authentication tokenization service 412 can be
configured to retrieve a one-time tokenization key and enable the user to create a onetime
transaction PIN based on the original PIN and the one-time tokenization key.
[0064] FIG. 5 illustrates another exemplary architecture layout 500 of the proposed
financial transaction execution system in accordance with an embodiment of the presen5 t
disclosure. The layout 500 shows three domains, issuer domain 502, solution domain
504, and the third-party domain 506, wherein the issuer 502 comprises a source of funds
508 that is indicative of the financial institution/issuers bank that enables association of a
financial identity of the issuer with a unique identifier 512 (at the third party domain 506)
10 such as email address 512-1, social networking identifier 512-2, blogging identifier 512-
3, application login identifier 512-4, social security number, or any other unique user
number. The financial institution can further be configured to issue a
transformation/tokenization key to the issuer/user to enable the user to use the key along
with his/her original PIN to generate a one-time PIN for the instant transaction.
15 [0065] In an aspect, in the embodiment of the third-party ATM based transaction, a
user/customer can map his/her financial identity (debit/credit card number/details thereof)
through a user interface, based on which the customer can receive a special tokenized
card (having a different number) generated and dispatched by the server but mapped at
the solution server to the same original card. Such a service can be provided at the
20 issuer’s domain through a card token service provider 510.
[0066] A customer can then fetch and use a one-time authentication tokenization key for
his/her financial identity to tokenize his/her original ATM PIN using a financial identity
tokenizing service 514. The customer can then approach a networked ATM and use the
tokenized card along with the tokenized PIN to execute a financial transaction and
25 withdraw the desired amount. Further details of this third-party ATM embodiment would
be explained with reference to FIG. 8.
[0067] FIGs. 6A to 6B illustrate exemplary representations showing execution of a
financial transaction using a third party application/interface in accordance with an
embodiment of the present disclosure. Representation 602 of FIG. 6(a) shows a user
30 interface of a email calender or a standalone calender application that enables a user to
put one or more reminders/events that he wishes to be reminded of. In an aspect of the
present invention, a user can put an event for rent payment that not only allows the user
19
to be reminded of payment of rent but also enables the user to actual pay the rent using
the calender as the third party application. As shown in 604 of FIG. 6(b), the user can
double click on the rent payment event, and generate on the same or on another interface,
a one-time pin based on a transaction/tokenization key and the user’s original PIN,
wherein the one-time PIN can then be used along with the beneficiary’5 s
identifier/financial identity and amount of rent to be paid (which can also be selected
from a default/fixed amoun, and hence the user may not be expected to pay the fees).
Based on such one-time PIN (twinpin), the user can therefore from the calender
application itself make a direct rent payment.
10 [0068] FIG. 7 illustrates an exemplary flow diagram 700 showing execution of a
financial transaction using a third party application/interface in accordance with an
embodiment of the present disclosure. At step 702, a customer maps his/her financial
identity with a unique identifier (such as social networking ID, emailID, among others).
At step 704, the customer fetches a tokenization key, and at 706, uses the tokenization
15 key along with the original PIN (for the financial identity) to generate a one-time
transaction/ temporary PIN. At step 708, the customer initiates a transaction through a
message indicating the beneficiary identifier/financial identity, amount to be transferred,
and the transaction/ temporary PIN or any other configured/desired detail.
[0069] At step 710, a third party listener detects/intercepts the transaction message based
20 on the format/keyword/processing the message. At step 712, a financial identity
tokenization service checks the financial identities of both the issuer/user as well as of the
beneficiary. At step 714, the transaction message is translated in a format required by
financial institutions by performing necessary de-tokenization of the identities and the
authentication. At step 716, configured transaction details are dispatched to the financial
25 institutions of the issuer and/or the beneficiary, and at step 718, the financial institution of
the issuer authenticates the issuer based on the temporary PIN and sends a transaction
response message to both the issuer as well as the beneficiary. At step 720, the service
provider of the third party application sends a message indicative of completion of the
transaction.
30 [0070] FIG. 8 illustrates another exemplary flow diagram 800 showing execution of a
financial transaction using a third party application/interface in accordance with an
embodiment of the present disclosure. At step 802, a customer maps his/her financial
20
identity through a user interface, and at step 804, receives a tokenized card (having a
different card number from the one submitted as part of the financial identity) that is
generated and/or dispatched by the server but mapped at the solution server to the same
original card.
[0071] At step 806, the customer can use his/her computing device to fetch a one-tim5 e
authentication tokenization key for his/her financial identity. At step 808, the customer
uses the authentication tokenization key to tokenize his/her ATM PIN in his/her mind for
the original card. At step 810, the customer can approach a networked ATM, select
withdrawal option, dips his/her tokenized card, provides an amount, and provides the
10 tokenized ATM PIN when asked. At step 812, the ATM passes the transaction to an
ATM switch, which routes the transaction to the solution server where the tokenized card
has been issued from, for authorization. At step 814, the server can then recreate the
transaction based on the original card (which itself may be tokenized) and the original
card PIN. At step 816, the transaction is dispatched to the financial institution /card token
15 service provider, wherein, at step 818, based on the response received, response message
dispatchers inform all the parties involved in the transaction appropriately. At step 820,
the ATM gets authorization message for withdrawal and the amount gets disbursed by the
ATM to the customer.