BACKGROUND OF THE INVENTION

THIS invention relates to a system and method for handling/attending to a payment instruction, as well as to a method for performing/facilitating a financial transaction.

Conventional bankcard transactions usually require a form of authentication, such as a signature or PIN code, and checks the client's/customer's account balance and limits during a transaction. The inventor however wishes to improve on these types of conventional transactions by adding an additional layer of control for clients.

SUMMARY OF THE INVENTION

In accordance with a first aspect of the invention there is provided a system for handling/attending to a payment request to pay a particular entity, wherein the system includes:

a communication module which is configured to receive a payment request from/on behalf of a client to pay the particular entity; and

a micro-service control arrangement which is configured to retrieve a client-customised computer program for the particular client and execute it.

The system may include a transaction module which is configured to send information on the payment request to the micro-service control arrangement. The micro-service control arrangement may be configured to retrieve the client-customised computer program for the particular client and execute it in an environment which is isolated from the transaction module.

The system may therefore be for handling/attending to a payment request to pay a particular entity, wherein the system includes:

a communication module which is configured to receive a payment request from/on behalf of a client to pay the particular entity;

a micro-service control arrangement; and

a transaction module which is configured to send information on the payment request to the micro-service control arrangement,

wherein the micro-service control arrangement is configured to retrieve a client-customised computer program for the particular client and execute it in an environment which is isolated from the transaction module.

In accordance with a second aspect of the invention there is provided a system for performing/facilitating a financial transaction, wherein the system includes:

a communication module which is configured to receive a payment request from/on behalf of a client to pay the particular entity; and

a micro-service control arrangement which is configured to retrieve a client-customised computer program for the particular client and execute it.

The system may include a transaction module which is configured to send information on the payment request to the micro-service control arrangement. The micro-service control arrangement may be configured to retrieve the client-customised computer program for the particular client and execute it in an environment which is isolated from the transaction module.

The system may therefore be for performing/facilitating a financial transaction, wherein the system includes: a communication module which is configured to receive a payment request from/on behalf of a client to pay a particular entity;

a micro-service control arrangement; and

a transaction module which is configured to send information on the payment request to the micro-service control arrangement,

wherein the micro-service control arrangement is configured to retrieve a client-customised computer program for the particular client and execute it in an environment which is isolated from the transaction module.

A "module", in the context of the specification, includes an identifiable portion of code, computational or executable instructions, or a computational object to achieve a particular function, operation, processing, or procedure. A module may be implemented in software, hardware or a combination of software and hardware. Furthermore, modules need not necessarily be consolidated into one device.

The features which are hereinafter described apply to the system in accordance with both the first and second aspects of the invention.

The micro-service control arrangement may be configured to retrieve the client-customised computer program for the particular client from a database. The database may form part of the system. A plurality of client- customised computer programs may be stored on the database. Each of the plurality of client-customised computer programs may refer to, or be associated with a specific client.

The micro-service control arrangement may be configured, by executing the client-customised computer program, to determine whether to accept or decline the payment request based on one or more custom rules which were created/added by the client, and send an indication of the decision to the transaction module. The transaction module may be configured to receive the indication to proceed or decline with the payment request from the micro-service control arrangement; and

either

decline the payment request, when the received indication is to decline the request, or

proceeding with the payment request, when the received indication is to proceed with the payment request, by transferring money from a first account which is associated with the client into a second account which is associated with the particular entity.

The micro-service control arrangement may include a controller. Each client-customised computer program may include one or more rules, preferably payment rules.

The communication module may be configured to receive the payment request via a communication network, preferably from a computing/payment terminal.

The first account may be the client's account. The first and/or second accounts may be bank accounts.

The payment request may be received from a bankcard terminal. In other words, the payment request may be a bankcard payment request. The system may therefore refer to a system for attending to a bankcard payment request.

The information on the payment request may include information on the client (e.g. a client identifier/identification code) and/or a payment amount.

The client-customised computer program may be provided in a secure sandbox environment. The micro-service control arrangement may be configured to provide a micro-service architecture within a secure sandbox environment. The micro-service control arrangement may be configured to allow a client to change/add rule(s) which is/are specifically relevant to an account which is associated with the client (i.e. his/her account, e.g. the first account), which is then incorporated into the client-customised computer program for the particular client.

The micro-service control arrangement may be configured to:

receive instructions from a client to change/add rule(s) which is/are specifically relevant to an account which is associated with the client, and

incorporate the changes/additions to the rule(s) into the client-customised computer program for the particular client.

The system may include a client interface via which a client can log into the system and change/add rule(s) which are specifically relevant to the account which is associated with the client (e.g. the first account), which is then incorporated into the client-customised computer program for the particular client (i.e. his/her specific computer program can be customised). The micro-service control arrangement may therefore be configured to incorporate the changes/additions to the rule(s), instructed via the client interface, into the client-customised computer program for the particular client.

The transaction module may be a transaction processing module.

In accordance with a third aspect of the invention there is provided a method of handling/attending to a payment request or performing/facilitating a financial transaction, wherein the method includes: receiving a payment request from, or on behalf of, a client to pay a particular entity;

send information on the payment request to a micro-service control arrangement;

retrieving a client-customised computer program for the particular client and executing it. The execution step may more specifically include executing the client- customised computer program in an isolated environment.

The method may include determining whether to accept or decline the payment request based on one or more custom rules provided/included in the client-customised computer program. The method may further include sending an indication of the decision to a transaction module/transaction facilitation module. The method may then include, at the transaction module, either

declining the payment request, when the received indication is to decline the request, or

proceeding with the payment request, when the received indication is to proceed with the payment request, by transferring money from a first account which is associated with the client into a second account which is associated with the particular entity.

The first account may be the client's account. The first and second accounts may be bank accounts.

The client-customised computer program may be executable by a processor/controller, preferably by a processor of the micro-service control arrangement.

The information on the payment request may include information on the client (e.g. a client identifier/identification code) and/or a payment amount.

The client-customised computer program may be provided in a secure sandbox environment. The micro-service control arrangement may be configured to provide a micro-service architecture within a secure sandbox environment. The micro-service control arrangement may be configured to allow a client to change/add rule(s) to his specific client-customised computer program. The method may include allowing a client to edit one or more rules which relate to payments from an account which is associated with the client (e.g. the first account), within a secure sandbox environment. More specifically, the method includes receiving instructions on one or more rules from a client for his specific client-customised computer program via a client portal.

In accordance with a fourth aspect of the invention there is provided a method of controlling/regulating at least part of a financial transaction, wherein the method includes:

receiving information on a payment request from a client; and within a micro-service(s) architecture, determining whether to accept or decline the payment request based on one or more custom rules which were created/added by the client.

In accordance with a fifth aspect of the invention there is provided a method of adapting/changing rules for financial transactions, wherein the method includes:

receiving login information from a client via a computing terminal; providing the client with a secure, isolated/sandboxed environment within which the client can add/change one or more rules which relate to financial transactions related to an account of the client (i.e. his/her account);

implementing the one or more rules when a payment instruction for the client is received.

In accordance with a sixth aspect of the invention there is provided a system for facilitating a financial transaction, wherein the system includes: a communication module which is configured to receive a payment request from a client to pay a particular entity;

an identification module which is configured to determine whether an amount of the payment, or at least part thereof, is sponsored by a third party, and is so transferring the payment amount, or at least part thereof, from an account of the third party to either an account of the client or the entity.

Preferably, the transfer should be made to the client, i.e. the client's account. The system may include a transaction module/transaction facilitation module which is configured, after the payment amount or part thereof has been transferred into the client's account, to proceed to pay the entity from the client's account.

In accordance with a seventh aspect of the invention there is provided a method for facilitating a financial transaction, wherein the method includes: receiving a payment request from a client to pay a particular entity; determining whether an amount of the payment, or at least part thereof, is sponsored by a third party, and if so transferring the payment amount, or at least part thereof, from an account of the third party to either an account of the client or the entity.

Preferably, the transfer should be made to the client, i.e. the client's account. The method may then include, after the payment amount or part thereof has been transferred into the client's account, proceeding with the payment to the entity from the client's account.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will now be described, by way of example, with reference to the accompanying diagrammatic drawings. In the drawings:

Figure 1 shows a schematic layout of a system in accordance with the invention; Figure 2 shows an illustrative example of when a client/customer uses the system of Figure 1 to inform him/her of his weekly expense on coffee purchases;

Figure 3 shows a simplified, schematic flow diagram of the operation of the system of Figure 1 ;

Figure 4 shows a flow diagram of the operation of the system of

Figure 1 ;

Figure 5 shows a schematic layout of a micro-service architecture which forms part of the system of Figure 1 ;

Figures 6 shows a screenshot of an interface with two custom solutions built by an end user/client; and

Figure 7 shows a flow diagram of the operation of the system, when a sponsor pays on behalf of a client.

DESCRIPTION OF PREFERRED EMBODIMENTS

The present invention generally relates to a system which allows a particular bankcard of a client (i.e. the bankcard holder) to be linked to a unique client-customised computer program which implements certain rules and behaviour/purchase-related actions. The term "bankcard" should be interpreted to include any payment card, whether it be a physical or virtual card, and includes debit cards, credit cards, cheque cards and gift cards. These client-customised computer programs are customised by the clients themselves and are executed during a financial transaction in a secure, isolated environment. In other words, the client-customised computer programs of the clients are executed in an environment which is isolated from a transaction/transaction processing module of a payment processing system of a bank or a card processor (e.g. stripe). In Figure 1 , reference numeral 10 refers generally to a system in accordance with the invention. The system 10 includes a central transaction server/processor 12 which is configured to facilitate the processing of financial transactions. In order to do so, the server 12 includes a transaction module. The server 12 is typically implemented by a bank or card transaction processor and includes a database 14 on which details of various clients/customers are saved. The details include, for example, the name, unique identity number/code and one or more bank account numbers which are associated with each customer/client. The balances of each bank account are also saved on the database 14. It should be appreciated that the system 10 can include various different banks which can communicate with each other over a communication network 105.

The system 10 further includes a secure sandbox architecture/environment 16 within which various custom-built/made computer programs can be executed for clients. More specifically, the sandbox environment includes a micro-service control arrangement/controller 18 and a database 20 on which a customised computer program for each client is stored. The system 10 is configured to allow clients 100 of the bank to log into the system 10 by using a computing terminal, such as computer 102 or smart device 104, via a communication network 105 (e.g. the Internet).

The system 10 typically allows each client 100 to create a customised computer program with rules and other activity/behaviour related instructions within the secure sandbox environment 16. For example, the rules may dictate that the transaction only be allowed to proceed in certain predetermined scenarios, which adds an extra layer of security for the clients' financial dealings. The rules can, for example, relate to a maximum expenditure on certain items or at certain stores (e.g. a maximum amount of coffee purchased on a monthly basis or the maximum amount of money spent in a specific store on a monthly basis). More specifically, the system 10 includes a portal 40 via which clients 100 can gain access to the system 10 and create their customised computer programs. The portal 40 typically includes a server/processor 42 which is configured to provide a user interface for each client 100 which can log into the system with suitable login information (e.g. by using a web browser).

The login process is typically similar to standard logging procedures (e.g. used in current banking systems) and will therefore not be described in greater detail. The user interface typically provides an integrated development environment (IDE) where source code from the programs can be created and edited. Reference is in this regard specifically made to Figure 6 which shows two customised solutions for a client wherein the one declines all fast-food transactions and the other sends a weekly spend summary after each transaction.

Each client-customised computer program is typically stored on the database 20. When a purchasing request is received from/via another party/entity, such as a merchant 200, then the server 12, before proceeding with the financial transaction, send details of the transaction to the micro- service control arrangement/controller 18. The details may include identification information of the specific client, transaction amount, the type of goods/services being purchased and the store at which it is being purchased. The micro-service control arrangement/controller 18 then identifies the client-customised computer program of the particular client (which was created by the client) and designates a specific micro-instance environment 120.1 -120.3 (hereinafter collectively referred to as 120) within which the client-customised computer program can be executed (see also Figure 5). This micro-instance environment 120.1 -120.3 is secure and isolated from the server 12.

Each micro-instance environment 120 typically includes a processor 130.1 - 130.3 which is configured to execute the client-customised computer program by utilising the transaction details received from the server 12. It will therefore be appreciated that the client-customised computer programs are executed in a sandboxed environment which helps for security purposes and to maintain fast execution time and scalability. In the example shown in Figure 3, a client/cardholder 100 can use his bankcard to pay for a specific product (or service) at a merchant 200 at a pay point/card terminal 101 . A card reader 103 at the terminal typically initiates the transaction by capturing details of the card, as well as a PIN code which is entered by the client 100 (see reference numeral 140). An authorisation request, which includes transaction details (e.g. product details, amount and store/merchant information), bankcard details and the PIN, is then sent to a bank 300 which is associated with the merchant 200 (also referred to as the "acquiring bank"). The bank 300 then forwards the request to a bank 400 which is associated with the particular client 100 (also referred to as the "issuing bank").

The server of the issuing bank then identifies the particular client 100 (e.g. based on details saved on a database) and checks the PIN (see block 142). If the PIN is invalid, then the transaction request is declined. If, however, the PIN is correct, then details of the authorisation request is sent to the micro-service control arrangement/controller 18 of the bank 400, which is provided within a secure sandbox environment 16. These details typically include identification information of the client 100, the payment amount, the merchant and the types of goods or services purchased. The controller 16 then retrieves an associated custom program of the client 100 (e.g. created by the client himself) and executes it in a secure micro- instance environment 120 (see block 144), e.g. by using a separate processor for the execution.

As mentioned, the custom program can typically include certain rules which need to be complied with before the transaction request is authorised. Alternatively, or in addition, the program may instruct certain purchase related behaviour to be captured (e.g. purchasing behaviour) and reported to the client on a regular basis (e.g. each time a particular purchase is made or on a weekly/monthly basis). For example, the program may indicate that each time when coffee is purchased, that an SMS message be sent to a cell phone of the client 100 in order to indicate his/her weekly coffee spend. In this regard, reference is made to the example shown in Figure 2.

If rules are included in the custom program, then that part of the computer program (also referred to as the "pre-transaction program") is typically executed before sending a response (e.g. approving or declining the transaction) back to issuing bank 400. If the rules are complied with, and when the transaction is completed by the custom program, an update on the completion of the transaction is sent to the card terminal (see block 146). If the rules are not complied with, then the decision to decline the transaction is also communicated to the card terminal.

If the custom program includes a part which indicates that certain purchase related behaviour should be communicated to the client 100, then that part of the programme (also referred to as the "after-transaction program") is executed after completion of the transaction (see block 148). For example, if a client purchased coffee and the custom program indicated that a summary of all coffee purchased during the last week should be communicated to the client 100, then the program will typically save updated information on the latest purchase on the database 20 and initiate a process by which an SMS is sent to the cell phone of the client 100 with the relevant details. The program may therefore, for example, be configured to record certain relevant purchases in order to provide an updated report to clients, e.g. by SMS or email).

This general operation of the system 10 is also illustrated in the flow diagram in Figure 4.

In one example, the system 10 can be configured to enable another entity (i.e. a so-called "sponsor") to pay for the particular financial transaction on behalf of the client 100. In other words, the system 10 can be used as a type of "sponsored-purchase system" which allows a cardholder's transaction to be sponsored by another party in real time. The program for implementing this aspect typically includes appropriate software for transferring the transaction amount or a portion/percentage thereof, from a bank account of the sponsoring party into the bank account of the cardholder, before a transaction is successfully completed.

In this regard, reference is specifically made to Figure 7. As shown, the cardholder 100 will typically insert his bankcard into a bankcard terminal (see block 500). The terminal then checks that the card is valid (see block 502) and requests a PIN from the cardholder 100 (see block 504). Once the PIN has been entered by the cardholder 100, then the validity of the pin is checked (see block 506). This may be done on the bankcard terminal itself or the details can be sent to the bank of the cardholder 100 for checking. If invalid, then the transaction is declined (see block 508).

If the PIN is valid then a designated program is executed in an isolated, secure environment 16, in order to check whether or not a sponsoring party should sponsor the purchase (see block 510). If not, then the transaction server of the bank checks whether or not the cardholder 100 has sufficient funds for the transaction (see block 516) and then either approves or declines the transaction (see blocks 508 and 518). If the program however determines that the purchase (or at least part thereof) should be paid by a sponsor, then the relevant funds are transferred from the bank account of the sponsor into the bank account of the cardholder 100 (see block 512). Once transferred, then the transaction server of the bank again checks whether or not there are sufficient funds in the account of the cardholder 100 and either decline or approve the transaction.

Once the transaction has been approved or declined, then an after transaction program can typically also be implemented in a similar manner as mentioned earlier (see block 520).

The Inventor believes that by allowing clients/customers to create/customise their own computer programs in a secure, isolated environment, which are executed during a financial transaction, it provides an extra layer of security (if certain purchase rules are added) and can provide a user with useful and up-to-date information on their own purchasing trends (e.g. the amount spent on coffee on a weekly basis). The system also allows third parties to sponsor certain payments on behalf of clients. This sponsored payment process is implemented in a secure and efficient manner. This can be particularly useful when, for example, someone wants to pay on behalf of a friend.