WO2014207615A1

WO2014207615A1 - Financial account with group authorization

Info

Publication number: WO2014207615A1
Application number: PCT/IB2014/062333
Authority: WO
Inventors: Owen David MEREDITH
Original assignee: Visa Cape Town (Pty) Ltd
Priority date: 2013-06-26
Filing date: 2014-06-18
Publication date: 2014-12-31
Also published as: ZA201509101B; AP2015008886A0

Abstract

A method and system for enabling a group of members to transact with funds stored in a value store is provided. An authorization server receives a proposal for a transaction to use funds stored in the value store from an electronic device of a member of the group. The authorization server transmits the proposal to electronic devices of a plurality of members of the group, and receives responses indicating agreement or disagreement with the proposal from at least some of the members of the group. In response to receiving a predetermined number of responses indicating agreement with the proposal, the transaction is authorized and at least one of the members of the group is provided with transaction details required to fulfil the transaction. In response to a failure to receive a predetermined number of responses indicating agreement with the proposal, the transaction is denied.

Description

CROSS-REFERENCES TO RELATED APPLICATIONS

[0001] This application claims priority to South African provisional patent application number 2013/04772 entitled "Financial Account with Group Authorization", filed on 26 June 2013, which is incorporated by reference herein.

BACKGROUND

[0002] Various systems and methods have been developed for providing and controlling access to shared sources of funds. Examples of shared sources of funds range from physical sources such as conventional safes or community savings boxes used in developing countries, to electronic sources such as community savings accounts, group accounts for charity organizations or other non-profit organizations, shared business accounts and household accounts, and the like.

[0003] Deposits or withdrawals in respect of shared physical sources of funds may be a time-consuming and cumbersome process. For example, in the case of a community savings box, many or all of the parties involved may be required to physically authorize a deposit or withdrawal by each unlocking a lock on the savings box to which only that party possesses the key.

[0004] Withdrawals or transfers from shared electronic sources of funds may present security risks. For example, a fraudulent party with access to a shared financial account may be able to withdraw or transfer funds from the account without approval from one or more other parties associated with the account. In some implementations, a "parent-child" relationship may exist between parties in which only parent parties are able to propose and/or authorize a transaction against the shared financial account. However, in such cases, it may be difficult or impossible for a child party to propose and obtain approval for a transaction when a parent party is unreachable or unresponsive to such a proposal. [0005] The present invention aims to alleviate these and other problems, at least to some extent. BRIEF SUMMARY

[0006] According to the present invention there is provided a method of enabling a group of members to transact with funds stored in a value store, comprising: receiving, from an electronic device of a member of the group, a proposal for a transaction to use funds stored in the value store; transmitting the proposal to electronic devices of a plurality of members of the group: receiving responses indicating agreement or disagreement with the proposal from at least some of the members of the group; determining whether a predetermined number of responses indicating agreement with the proposal have been received; and in response to receiving a predetermined number of responses indicating agreement with the proposal, authorizing the transaction and providing at least one of the members of the group with transaction details required to fulfil the transaction; or in response to a failure to receive a predetermined number of responses indicating agreement with the proposal, denying the transaction.

[0007] Further features provide for a sub-set of the group to be designated as authorized proposers, wherein a proposal for a transaction is received only from one of the authorized proposers; for a sub-set of the group to be designated as authorized approvers, wherein the proposal is transmitted only to the authorized approvers; and for a sub-set of the group to be designated as authorized fulfillers, wherein the transaction details required to fulfil the transaction are provided only to the authorized fulfillers,

[0008] Yet further features provide for the authorized approvers to be the same subset of the group as the authorized proposers; alternatively, for the authorized approvers to be a different sub-set of the group than the authorized proposers.

[0009] Still further features provide for any member of the group to be capable of fulfilling the transaction once the transaction is authorized; for the transaction details required to fulfil the transaction to be specific to the proposed transaction and valid only for fulfilling the proposed transaction; and for the transaction details to have a limited lifespan.

[0010] The transaction details required to fulfil the transaction may include one or more of: a transaction identifier, additional transaction details, a transaction token, a primary account number (PAN), a single-use PAN, a card expiry date, a card verification value (CVV), a password, and a personal identification number (P!N).

[0011] Further features provide for the electronic device to be a mobile phone; for the value store to be a mobile wallet account held at a mobile banking system; for the mobile wallet account to be a single shared account of the group of members; for each of the members of the group to be identified using at least a mobile phone identifier; and for the mobile phone identifier to be a Mobile Station international Subscriber Directory Number (MSISDN),

[0012] The transaction may be a cash-out transaction in which credit in the account is converted to cash available for withdrawal at a mobile banking agent, a withdrawal transaction, or a transfer of funds to a different financial account,

[0013] Further features provide for the predetermined number of responses to be selected from the group consisting of: a majority of the sub-set of authorized approvers, a predetermined percentage of the sub-set of authorized approvers, all of the authorized approvers, and a predetermined percentage of the members of the group; for an authorized manager to be capable of configuring an approval rule for proposed transactions; and for thresholds to be applied to limit the value or number of transactions that can be proposed and/or fulfilled by a particular member of the group. [0014] A further feature provides for the method to further include the steps of: reserving funds upon receiving a proposal for a transaction; and removing the reservation of those funds if the transaction is denied; or debiting the reserved funds upon the transaction being approved and fulfilled.

[0015] Yet further features provide for the method to also include the step of notifying at least some of the members of the group that the proposed transaction has been authorized or denied, whatever the case may be; and for the notifications to be transmitted by way of Short Message System (SMS) messages.

[0016] In one embodiment, the step of transmitting the proposal to electronic devices of a plurality of members of the group includes transmitting the proposal only to electronic devices of other members of the group and not to the electronic device of the member of the group from which the proposal was received. [0017] According to the present invention there is provided a system for enabling a group of members to transact with funds stored in a value store, the system including an authorization server comprising: a proposal receiving component for receiving, from an electronic device of a member of the group, a proposal for a transaction to use funds stored in the value store: a proposal transmitting component for transmitting the proposal to electronic devices of a plurality of members of the group; a response receiving component for receiving responses indicating agreement or disagreement with the proposal from at least some of the members of the group; an approval determining component for determining whether a predetermined number of responses indicating agreement with the proposal have been received; and an authorization component for, in response to receiving a predetermined number of responses indicating agreement with the proposal, authorizing the transaction and providing at least one of the members of the group with transaction details required to fulfil the transaction, or, in response to a failure to receive a predetermined number of responses indicating agreement with the proposal, denying the transaction,

[0018] Further features provide for the system to further include a plurality of electronic devices in communication with the authorization server, each electronic device associated with a member of the group; for the electronic devices to be mobile phones; for the value store to be a mobile wallet account held at a mobile banking system; and for the mobile wallet account to be a single shared account of the group of members.

[0019] Still further features provide for at least one of the electronic devices to include a proposal component for transmitting the proposal for a transaction to use funds stored in the value store to the authorization server; for at least one of the electronic devices to include an authorization component for transmitting a response to the authorization server indicating agreement or disagreement with the proposal; and for at least one of the electronic devices to include a fulfilling component for receiving the transaction details required to fulfil the transaction. [0020] According to the present invention there is provided a computer program product for enabling a group of members to transact with funds stored in a value store, the computer program product comprising a computer-readable medium having stored computer-readable program code for performing the steps of: receiving, from an electronic device of a member of the group, a proposal for a transaction to use funds stored in the value store; transmitting the proposal to electronic devices of a plurality of members of the group; receiving responses indicating agreement or disagreement with the proposal from at least some of the members of the group; determining whether a predetermined number of responses indicating agreement with the proposal have been received; and in response to receiving a predetermined number of responses indicating agreement with the proposal, authorizing the transaction and providing at least one of the members of the group with transaction details required to fulfil the transaction; or in response to a failure to receive a predetermined number of responses indicating agreement with the proposal, denying the transaction.

[0021] The computer-readable medium may be a non-transitory computer-readable medium, and the computer-readable program code may be executable by a processing circuit.

[0022] In order for the invention to be more fully understood, implementations thereof will now be described with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0023] FIG. 1A is a schematic diagram illustrating an embodiment of a system for enabling a group of members to transact with funds stored in a value store according to the invention;

[0024] FIG. 1 B is a block diagram illustrating components of an embodiment of an authorization server according to the invention; [0025] FIG. 1 C is a block diagram illustrating components of an embodiment of an electronic device of a member of a group according to the invention;

[0026] FIG. 2 is a flow diagram illustrating an embodiment of a method of enabling a group of members to transact with funds stored in a value store according to the invention; [0027] FIG. 3 is a swim lane flow diagram illustrating an embodiment of a method of enabling a group of members to transact with funds stored in a value store according to the invention;

[0028] FIG. 4 is a flow diagram illustrating a series of steps wherein an authorized manager requests to configure an approval rule for transaction proposals according to the Invention;

[0029] FIG. 5 is a table illustrating details of members of an exemplary group according to the invention;

[0030] FIG. 6 is a schematic diagram Illustrating steps conducted by a group of members in an exemplary implementation of the invention;

[0031] FIG. 7 is a block diagram of a computing device in which various aspects of the invention may be implemented; and

[0032] FIG. 8 is a block diagram of a communication device that can be used in various embodiments of the invention.

DETAILED DESCRIPTION WITH REFERENCE TO THE DRAWINGS

[0033] A system and method for enabling a group of members to transact with funds stored in a value store is provided. The system allows a member of the group to transmit a proposal for a transaction to use funds stored in the value store to an authorization server. The authorization server transmits the proposal to electronic devices of a plurality of members of the group, and receives responses indicating agreement or disagreement with the proposal from at least some of the members of the group, where after the transaction is either approved or denied, depending at least in part on the responses received by the authorization server. [0034] FIG. 1 illustrates a system (100) for enabling a group (1 10) of members (120) to transact with funds stored in a value store according to described embodiments. In the system (100) depicted in FIG. 1 , the value store is a mobile wallet account held at a mobile banking system. The mobile wallet account is a single, shared account of the group (1 10). [0035] The system (100) comprises an authorization server (130), which is a mobile banking server in this embodiment, and a plurality of member electronic devices (140), each member electronic device (140) being associated with one of the members (120) In the group ( 10). The system (100) may further include an agent (150), which is a mobile money agent in this embodiment. The agent (150) has an agent electronic device (160), in this embodiment a mobile phone of the agent (150), which it uses to communicate with the authorization server (130),

[0036] The group (1 10) of members (120) hold a shared financial account at the authorization server (130), details of which are typically stored in a server database (131 ) of the authorization server (130). Both the members (120) and the agent (150) are in communication with the authorization server (130) over a communications network (170), in this embodiment a mobile communications network.

[0037] The details stored in the server database (131 ) may include one or more of an account number for the shared financial account, a member identifier for each member (120), electronic device identifiers associated with each member, and a member status of each member (120) in the group (1 10). The member status of each member (120) may include whether or not the specific member (120) is an authorized proposer, an authorized approver, an authorized fulfiller, and/or authorized to modify approval rules for the group. These features are described in greater detail below.

[0038] In embodiments of the invention where the member electronic device (140) is a mobile phone, the member identifier may be an electronic device identifier. The electronic device identifier may be a mobile phone identifier such as a Mobile Station International Subscriber Directory Number (MSISDN) identifying a "mobile phone number" of the account holder. In this embodiment, the mobile phone number is used as an identifier in relation to the each user of the mobile banking system, as is commonly the case in mobile banking or "mobile money" deployments in developing countries. The authorization server (130) is, in this embodiment, capable of identifying each of the members (120) of the group (1 10) using the mobile phone identifier.

[0039] In this embodiment, and as depicted in FIG. 1 A, the authorization server (130) is associated with an issuing bank (180). The authorization server (130) may be controlled or managed by a mobile network operator that offers subscribers a mobile money program which can be accessed over the communications network (170) via their electronic devices. In such a case, the issuing bank (180) acts with the mobile network operator to hold funds for users and perform a variety of transactions.

[0040] Embodiments of the authorization server (130) may include a proposal receiving component (132), a proposal transmitting component (133), a response receiving component (134), an approval determining component (135) and an authorization component (136). The authorization component (136) may further include a transaction details component (137) and a transaction denial component (138). These components are illustrated in FIG. 1 B.

[0041] Embodiments of the member electronic device (140) may include a receiving component (142), a transmitting component (144), and a mobile wallet application (146) which may include one or more of a proposal component (147), an authorization component (148) and a fulfilling component (149). These components are illustrated in FIG. 1 C.

[0042] It should be noted that, throughout this specification, the terms "member electronic device" and "electronic device of a member" / "electronic device of the member" are used interchangeably and should be interpreted so as to carry a similar meaning, unless the context dictates otherwise.

[0043] FIG. 2 is a flow diagram (200) illustrating a method of enabling the group (1 10) of members (120) to transact using the shared financial account, conducted at the authorization server (130), according to described embodiments.

[0044] At a first stage (202), the authorization server (130) receives a proposal for a transaction to use the funds stored in the shared account. The proposal may be received at the proposal receiving component (132). The proposal originates from the member electronic device (140) of one of the members (120) of the group (1 10). In a typical scenario, the proposal is a proposal for a cash-out transaction in which credit in the shared financial account is to be converted to cash available for withdrawal. Alternatively, the proposal may be a withdrawal transaction proposal or a proposal to transfer funds from the shared account to a different financial account. [0045] The authorization server (130), at a next stage (204), transmits the proposal to the electronic devices (140) of other members (120) in the group (1 10), requesting the other members (120) to respond to the proposal by indicating either agreement or disagreement with the proposal. The proposal may be transmitted using the proposal transmitting component (133). in some embodiments, the proposal is transmitted only to electronic devices (140) of other members (120) of the group (1 10) and not to the electronic device (140) of the member (120) of the group (1 10) from which the proposal was received. The member (120) proposing the transaction may thus in some cases not be requested to approve or deny the transaction, as the proposal itself may indicate approval. In other implementations of the invention, the member (120) may be requested to approve or deny the transaction similarly to other members (120) of the group (1 10). The proposal may be received at the member electronic device (140) using the receiving component (142).

[0046] At least some of the members (120) then use the transmitting component (144) of their member electronic device (140) to transmit a response to the authorization server (130). At a next stage (206), the authorization server (130) receives, at its response receiving component (134), responses from at least some of the members (120) to which the proposal was transmitted. The authorization server (130) then, at a further stage (208), uses the approval determining component (135) to determine whether a predetermined number of responses indicating agreement with the proposal were received.

[0047] If a predetermined number of agreement responses, or possibly a number of agreement responses greater than the predetermined number, were received, the authorization server (130), at a next stage (210), authorizes the transaction, notifies the group (1 10) that the transaction has been authorized, and allows at least one of the members (120) in the group (1 10) to fulfil the transaction at a final stage (212).

[0048] in order to allow at least one of the members (120) to fulfil or complete the actual transaction, the one or more member is provided with transaction details required to fulfil the transaction. [0049] Contrastingly, in response to a failure to receive the predetermined number of responses indicating agreement with the proposal, at an alternative final stage (214), the authorization server (130) denies the transaction and notifies the group (1 10) that the transaction has been denied. A denial notification may be transmitted to at least some of the members of the group by way of, for example, a Short Message Service (SMS) message.

[0050] The authorization component (136) may be used to carry out either authorization or denial of the proposed transaction. The transaction details component (137) may be used to generate and/or transmit the details required to fulfil the transaction, while the transaction denial component (138) may be used to notify members that the proposed transaction was denied.

[0051] In some embodiments, a sub-set of the group of members may be designated as authorized proposers such that a proposal for a transaction is received only from one of the authorized proposers. Furthermore, a sub-set of the group may be designated as authorized approvers such that proposals are transmitted only to the authorized approvers by the authorization server. Also, in some embodiments, a sub-set of the group may be designated as authorized fulfillers such that the transaction details required to fulfil the transaction are provided only to the authorized fulfillers.

[0052] In some embodiments, any member of the group may be capable of fulfilling the transaction once the transaction is authorized. To enhance transaction security, the transaction details required to fulfil the transaction may be chosen so as to be specific to the proposed transaction and valid only for fulfilling the proposed transaction. The transaction details may also have a limited lifespan.

[0053] The sub-sets described above may be selected at the time of creating the shared financial account, or may be changed or created after the account has been generated. For example, all of the members (120) in the group (1 10) can, by default, be authorized approvers. In other cases, only selected members (120) are authorized approvers in that they are authorized to approve or deny a transaction proposal. Authorized proposers and/or authorized fulfillers may be managed in a similar manner.

[0054] The authorized proposers may be the same sub-set or a different sub-set to the authorized approvers. In cases where authorized approvers have been specified or selected by default, transaction proposals are only sent to the authorized approvers. Similarly, in cases where authorized proposers have been specified or selected by default, the authorization server (130) only receives proposals for transactions from one of those authorized proposers or deems proposals received from members not designated as authorized proposers, as invalid .

[0055] The sub-set of authorized fulfillers may be exclusively authorized to ultimately, after the authorization server (130) has authorized the transaction, fulfil the transaction. In the case of, for example, a cash-out transaction to be performed at the mobile money agent (1 50) of the system (100) of FIG. 1 , one or only some of the members (120) may be authorized to provide the agent (150) with transaction details and physically collect the cash associated with the cash-out transaction from the agent (150). The authorization server (130) may store a member status for each member (120) in the database, which may include information on whether each member is an authorization approver, authorized proposer and/or authorized fulfiller.

[0056] In some embodiments, the member electronic devices (140) of at least one of the members (120) may be equipped with a mobile wallet application (146). The mobile wallet application (146) may include one or more of: a proposal component (147) for transmitting the proposal for a transaction to use funds stored in the value store to the authorization server (130), an authorization component (148) for transmitting a response to the authorization server (130) indicating agreement or disagreement with the proposal, and a fulfilling component (149) for receiving the transaction details required to fulfil the transaction. In some cases, for example where a member (120) uses a feature mobile phone not capable of having such an application installed thereon, the method and system of the present invention may be implemented without making use of such a software application.

[0057] The transaction process according to embodiments of the invention will now be described in greater detail with reference to FIG. 3, which is a swim lane flow diagram (300), illustrating the roles of the authorization server (130), member electronic devices (140), and a mobile banking agent (150) in such a transaction process. A cash-out transaction is used as transaction type primarily for exemplary purposes and use thereof should not be interpreted so as to limit the scope to a specific transaction type.

[0058] In this embodiment, only one member (120) in the group (1 10) is authorized to fulfil the cash-out transaction and is thus an authorized fulfiller. A plurality of members are designated as authorized proposers and a plurality of members are designated as authorized approvers.

[0059] At a first stage (302), one of the authorized proposers, using his or her member electronic device (140), transmits a transaction proposal to the authorization server (130). !n this example, the transaction proposal is a cash-out proposal, in other words, a transaction in which credit in the mobile money account is to be withdrawn as cash. It is foreseen that thresholds may be applied which limit the value and/or number of transactions that can be proposed by any particular authorized proposer in the group (1 10). A transaction proposal may include one or more of a transaction type, such as "cash-out", an amount, a proposed date, a merchant or beneficiary, and details of the account against which the transaction is to be conducted.

[0060] The authorization server (130) then receives this proposal at a next stage (304), typically by way of an Unstructured Supplementary Service Data (USSD) communication session message, a Short Message System (SMS) message, by way of communication between a mobile software application resident on the member electronic device (140) and the authorization server (130), or the like, it should be appreciated that any suitable method and/or devices may be employed to effect communication between the member electronic devices and the authorization server and between the agent electronic device and the authorization server.

[0061] In cases where a plurality of transaction proposals are pending simultaneously, to ensure that pending proposals do not interfere with each other so as to cause available funds in the shared account to become depleted before all pending transactions are either authorized or rejected, the authorization server (130) may reserve funds upon receiving a specific proposal for a transaction. In other words, the proposed transaction amount is subtracted from the available funds in the account. Then, if the transaction is eventually denied, the reservation on those funds is removed and the available amount increases, and if the transaction is eventually authorized, the reserved funds are debited against the shared account upon the transaction being authorized and/or fulfilled.

[0062] The authorization server (130) looks up the member status of each member (120) in the group (1 10) from the database (132) in order to determine which members (120) are authorized to propose, authorize, and/or fulfil a transaction. At a next stage (306), the authorization server (130) transmits the transaction proposal to each of the authorized approvers in the group (1 10). Typically, this does not include the member from which the proposal originated, even if that member is an authorized approver. The transaction proposal may be transmitted using any suitable communications protocol, for example, by means of SMS messages to the member electronic device (140) of each authorized approver or as a push notification presented to the member (120) by a mobile software application installed on the member electronic device (140) of each authorized approver. [0063] The authorized approvers receive the transaction proposal at a next stage (308). The proposal includes information which prompts the authorized approver to respond to the proposal indicating either agreement or disagreement therewith. At least some of the authorized approvers, at a next stage (310), proceed to respond with an appropriate agreement or disagreement message to the authorization server (130).

[0064] It is foreseen that, in cases where an authorized approver does not respond to a proposal within a predefined timeframe, the authorization server (130) may deem that particular authorized approver as having denied the proposed transaction.

[0065] In order for the transaction to be approved by the authorization server (130), a specific, predefined approval rule must be satisfied, in other words, depending on the rule and the number of members (120) in the group (1 10), a certain number of agreement responses must be received before the authorization server (130) authorizes the transaction proposed by the authorized proposer.

[0066] Various approval rules may be employed to establish a transaction approval or denial. For example, the majority of the group of members may be required to provide an agreement response, or a majority of the authorized approvers, which is a sub-set of the group, may be required to provide an agreement response to the proposal. A predetermined percentage of the authorized approvers or the group of the members may be required, all of the authorized approvers may be required to provide an agreement response, or the entire group of members may be required to provide an agreement response before a transaction is authorized by the authorization server. It should be appreciated that these rules relating to the predetermined number of responses indicating agreement with the proposal that are required, are primarily listed for exemplary purposes, and any other suitable approval rule or similar decision logic may, of course, be used.

[0067] At a next stage (312), the authorization server (130) determines whether or not the predetermined number of agreement responses, or a number greater than the predetermined number, has been received. If it is the case that the approval rule cannot be satisfied due to the number of disagreement responses received from the authorized approvers, or if the predetermined number of agreement responses are not received within a specified timeframe, the authorization server (130), at a next stage (314), denies the proposed transaction. The members (120), typically, at a final stage (316), receives a notification from the authorization server (130) stating that the proposed transaction has not been approved.

[0068] Alternatively, if the approval rule is satisfied, the authorization server (130), at a next stage (320), authorizes the transaction and notifies one or more members (120) in the group (1 10) that the proposed transaction has been authorized. Once again, the authorization server (130) may typically notify at least some of the members of the group that the proposed transaction has been authorized or denied, whatever the case may be. Authorization or denial notifications may be transmitted using any suitable communications protocol or platform, typically Short Message System (SMS) messages.

[0069] At a next stage (322), the members (120) receive the authorization notification from the authorization server (130). The member (120) in the group (1 10) authorized to fulfil the cash-out transaction, in other words the authorized fulfiller or fulfillers, may typically, at a next stage (324), receive additional information. The authorized fulfillers receive transaction details required to complete the transaction. The transaction details may include, for example, a transaction identifier (ID), additional transaction details, a transaction token, a primary account number (PAN), a single-use PAN, a card expiry date, a card verification value (CVV), a password, and a personal identification number (PIN). [0070] One of the authorized fulfillers can then complete the cash-out transaction by presenting the necessary transaction details to the agent (150), at a next stage (326). The authorized fulfiller may, for example, present a single-use PAN and a passcode to the agent (150). The agent (150), at a next stage (328), uses the transaction details, as will be appreciated by those skilled in the art, to effect a conventional mobile money cash-out transaction. At a final stage (330), the member ( 20) receives the cash associated with the authorized transaction. Funds reserved for the specific transaction, if applicable, are debited at this point in time.

[0071] It is envisaged that all members (120) may receive a transaction identifier (ID) uniquely associated with the transaction as part of the authorization notification from the authorization server (130). In cases where any member (120) may fulfil the transaction, the transaction ID may then be used to complete the transaction at the agent (150). Alternatively, only an authorized fulfiller may receive a transaction ID and this ID may be required to complete the transaction. The transaction ID may have a limited life-span. In such a case, after authorization, the transaction must be fulfilled within a certain timeframe, for example one day.

[0072] Similarly to authorized proposers, it is envisaged that thresholds may applied to limit the value or number of transactions that can be fulfilled by a particular member of the group.

[0073] An authorized manager of the value store may be able to create, configure or change an approval rule for subsequent transaction proposals. The authorized manager, who may generally one of the members in the group or alternatively a party external to the group, may, for example, be able to change the predetermined number of total responses or agreement responses required for a transaction to be authorized. In some embodiments, the authorized manager may create, configure or change an approval rule only if the proposed change is accepted by the majority of the group. It should, of course, be appreciated that any other suitable approval rule or logic may be employed in this regard. Furthermore, a plurality of authorized managers may be selected for a single shared financial account.

[0074] One example of a process wherein an authorized manager requests to configure an approval rule for transaction proposals is illustrated by the flow diagram (400) of FIG. 4. [0075] At a first stage (402), an authorized managers requests, via his or her member electronic device, to configure an existing approval rule. The authorization server receives the request and may then, at a next stage (404), present a set of approval rule options to the authorized manager. For example, the authorized manager may choose a democratic-type approval rule, a rule requiring a minimum number of authorized approvers to approve a proposed transaction, or an approval rule wherein all authorized approvers are required to approve a proposed transaction before it is authorized by the authorization server,

[0076] At a next stage (406), the authorized manager selects a desired approval rule. The authorization server then, at a next stage (408), transmits approval requests to other members in the group. In one embodiment, these members are the set of authorized approvers for the group. The authorized approvers, in such a case, respond to the approval request by either transmitting an agreement response or a disagreement response to the authorization server.

[0077] The authorization server determines whether an adequate number of agreement responses have been received at a next stage (410), and if this is the case, the authorization server modifies the approval rule for subsequent transactions accordingly, and may also notify the members in the group of the new approval rule at a final stage (412). If an adequate number of agreement responses are not received, at an alternative final stage (414), the authorization server does not allow the approval rule to be modified and optionally notifies the members in the group that a request to configure the approval rule was received and subsequently denied. [0078] It is foreseen that a similar process may be used to initially create an approval rule when the shared financial account is generated. When the account is generated, identifiers of all of the members in the group who are one or more of an authorized proposer, an authorized approver, an authorized fulfiller and an authorized manager, are provided. This identifier will, in a preferred embodiment, be a mobile phone identifier such as a SISDN of the member. This enables the authorization server to communicate specifically with the authorized proposers, authorized approvers, authorized managers and authorized fuifi!lers during subsequent transaction proposals or account configuration activities.

[0079] The table (500) of FIG. 5 illustrates details of members of an exemplary group according to the invention. The table may (500) may, for example, be included in the database (131 ) of FIG. 1 A. The authorization server has access to the database and is capable of configuring various fields therein, as will be described below. [0080] In this example, members of a shared financial account are shown. The account has five members. The table (500) indicates an account number (501 ) identifying the account, and which is associated with each of the members. Each individual member is uniquely identified using a MSISDN (502), as described above. The table (500) further includes a name (503) of each member.

[0081] In this example, each member has a member status. The member status includes whether or not the member is an authorized proposer (504), an authorized approver (505), or an authorized fu!fi!Ier (506) in relation to transactions conducted against the shared account. The table (500) further indicates whether or not each member is an authorized manager (507) capable of configuring an approval rule for the account. The authorized manager (507) may also be capable of configuring which members are authorized proposers, approvers and fulfillers, and of setting limits with regard to proposals and/or fulfillment.

[0082] In this example, and as shown in FIG. 5, two of the members are designated as authorized proposers (504), and only these members may propose transactions. All five of the members are designated as authorized approvers (505), while three of the members of the group are authorized fulfillers (506). Furthermore, only one member of the group is designated as an authorized manager (507).

[0083] The table (500) may also include information relating to account activity. In this embodiment, the table includes a data on the number of transaction proposed (508) by each member during a specific month and on the number of transactions fulfilled (509) for the month. Any suitable timeframe may, of course, be used in other embodiments.

[0084] In this example, one of the authorized proposers has proposed one out of a possible five transactions for the month, while the other authorized proposer has proposed three out of a possible ten transactions for the month. Two of the authorized fulfillers have each completed two of the authorized transactions, while the third authorized fulfiller has not completed a transaction. These limits may typically be set up during creation of the shared account, and may in some embodiments be configured by an authorized manager.

[0085] Finally, the table (500) includes the approval rule (510) used for the group. Approval rule "3", as depicted in FIG. 5, may, for example, refer to a rule wherein the majority of the authorized approvers are required to approve a proposed transaction before it is authorized,

[0086] it is foreseen that different approval rules may be used for different members, depending on the member proposing the transaction. In such a case, upon receiving a transaction proposal, the authorization server checks the database (131 ) to estabiish the rule to be employed for the particular member proposing the transaction.

[0087] The schematic diagram (600) of FIG. 6 illustrates steps conducted by a group of members in a further exemplary implementation of the invention. In this example, an automated teller machine (ATM) withdrawal type transaction is conducted wherein an authorized fulfiller is provided with transaction details required for withdrawing funds at an ATM against the shared account.

[0088] FIG. 6 depicts an authorized proposer (602) having a member electronic device (603), an authorized approver (604) having a member electronic device (605), and an authorized fulfiller (606) having a member electronic device (607).

[0089] At a first stage (610), the authorized proposer (602) uses its electronic device (603) to initiate a USSD session with the authorization server (not shown), and accesses a group account menu. The authorized proposer (602) wishes to propose an ATM withdrawal transaction, and selects the appropriate option (612). [0090] In this exemplary scenario, the authorized proposer proposes a transaction for the amount of 5000 RWF (Rwandan franc). The currency RWF is only used for descriptive purposes in order to highlight exemplary features of systems and methods according to the invention, and the invention is in no way limited to a single nationality, currency or method of payment.

[0091] At a further stage (620), once the authorized proposer (602) has entered an amount for the transaction, the proposal is confirmed. The authorization server then receives this proposal and transmits it to the authorized approver (604). Typically, the proposal will be transmitted to a number of authorized approvers (604).

[0092] At a next stage (630), the authorized approver (604) receives the proposal as an SMS message at its electronic device (605). The authorized approver (604) is instructed to reply to the SMS message with "YES" or "NO" so as to approve or deny the proposed transaction. The authorization server receives these responses from a plurality of members and determines whether or not the particular approval rule is satisfied.

[0093] In this example, upon determining that the approval rule is satisfied, the authorization server transmits transaction details required to fulfill the transaction to the authorized fulfiller (606). At a final stage (640), the authorized fu .filler (808) receives an SMS message with these details at its electronic device (607). The SMS message includes an account identifier, the transaction amount, a transaction ID to be entered at an ATM, and a period of validity for the transaction ID. The authorized fulfiller (606) may be required to perform further authentication steps when completing the transaction, such as providing identification documentation or entering a passcode at the ATM.

[0094] It is envisaged that the "group authorization" method as described with reference to the embodiments and examples above may only be applied to certain transactions against the shared financial account. For example, group approval may only be required for withdrawal transactions or transfers to other financial accounts, or for withdrawal or transfer transactions above a specific amount. In other cases, group approval may only be required if a transaction is proposed by a specific member in the group. Furthermore, different approval rules may apply to different transaction types, for example, all authorized approvers may be required to authorize a withdrawal above a certain amount, while a democratic principle may be employed for smaller withdrawals.

[0095] Additionally, it may be possible for a group to have an "open" membership. For example, any person may deposit funds into the shared account, without requiring formal account membership. These deposits may, in some cases, be donations from external parties or funds owed to the group by external parties. Furthermore, deposits greater than a certain amount may be required for a person to become a member of the group.

[0096] In other embodiments, agreement or disagreement responses transmitted to the authorization server may have different weights associated thereto. For example, the more a person or group member has deposited into the shared financial account, the greater the weight of his or her "vote" in the authorization decision. In an even further embodiment, it would be possible for a person or group member to obtain authorized approver status, authorized proposer status, or any other membership status as described, by depositing an amount above a predefined threshold into the shared account, For example, a relatively large deposit may be required for a group member to acquire the ability to fulfil an authorized transaction.

[0097] The functionality provided by the described methods and systems may be particularly useful in developing countries, where communally-shared products and community savings methods are often used. Access to and control of a value store that is shared between two or more individuals can, using the authorization process according to the embodiments described, be more effectively provided and more efficiently managed than using, for example, physical savings systems such as savings boxes and safes to which multiple parties hold different keys.

[0098] It should be appreciated that the described methods and systems are not limited to a specific transaction type. Although in this specification the transactions proposed and authorized are described with reference to mobile banking implementations, the system and method disclosed may equally be implemented for authorization of other transaction types, for example, e-comrnerce transactions.

[0099] Once the transaction is authorized and the transaction details have been transmitted to one or more members of the group, the transaction itself may be carried out and processed using any suitable process. The transaction details may be provided by an issuing bank or a payment processing network. The transaction details may include a token or proxy account number which serves as a reference to actual account information to avoid transmitting sensitive account information "in the clear". [0100] The value store in respect of which transaction are proposed and authorized is not limited to a bank account. The value store may, for example, be a store of airtime associated with a mobile network operator, a loyalty account having a balance of credit, "Air Miles", or the like.

[0101] The described methods and systems allow a plurality of members of a group to be able to propose, authorize and/or fulfill a proposed transaction. This may make transactions against a shared account less cumbersome, since urgent transactions may still be approved and carried out even when one or more parties are unreachable or unresponsive to such a proposal.

[0102] The method may be implemented as a computer program product for enabling a group of members to transact with funds stored in a value store. The computer program product may comprise a computer-readable medium having stored computer-readable program code for performing the steps of: receiving, from an electronic device of a member of the group, a proposal for a transaction to use funds stored in the value store; transmitting the proposal to electronic devices of a plurality of members of the group; receiving responses indicating agreement or disagreement with the proposal from at least some of the members of the group; determining whether a predetermined number of responses indicating agreement with the proposal have been received; and in response to receiving a predetermined number of responses indicating agreement with the proposal, authorizing the transaction and providing at least one of the members of the group with transaction details required to fulfil the transaction; or in response to a failure to receive a predetermined number of responses indicating agreement with the proposai, denying the transaction.

[0103] The computer-readable medium may be a non-transitory computer-readable medium, and the computer-readable program code may be executable by a processing circuit.

[0104] FIG. 7 illustrates an example of a computing device (700) in which various aspects of the disclosure may be implemented. The computing device (700) may be suitable for storing and executing computer program code. The various participants and elements in the previously described system diagrams may use any suitable number of subsystems or components of the computing device (700) to facilitate the functions described herein.

[0105] The computing device (700) may include subsystems or components interconnected via a communication infrastructure (705) (for example, a communications bus, a cross-over bar device, or a network). The computing device (700) may include at least one central processor (710) and at least one memory component in the form of computer-readable media. [0106] The memory components may include system memory (715), which may include read only memory (ROM) and random access memory (RAM). A basic input/output system (BIOS) may be stored in ROM. System software may be stored in the system memory (715) including operating system software. [0107] The memory components may also include secondary memory (720). The secondary memory (720) may include a fixed disk (721 ), such as a hard disk drive, and, optionally, one or more removable-storage interfaces (722) for removable- storage components (723).

[0108] The removable-storage interfaces (722) may be in the form of removable- storage drives (for example, magnetic tape drives, optical disk drives, floppy disk drives, etc.) for corresponding removable storage-components (for example, a magnetic tape, an optical disk, a floppy disk, etc.), which may be written to and read by the removable-storage drive.

[0109] The removable-storage interfaces (722) may also be in the form of ports or sockets for interfacing with other forms of removable-storage components (723) such as a flash memory drive, external hard drive, or removable memory chip, etc.

[0110] The computing device (700) may include an external communications interface (730) for operation of the computing device (700) in a networked environment enabling transfer of data between multiple computing devices (700). Data transferred via the external communications interface (730) may be in the form of signals, which may be electronic, electromagnetic, optical, radio, or other types of signal.

[0111] The external communications interface (730) may enable communication of data between the computing device (700) and other computing devices including servers and external storage facilities. Web services may be accessible by the computing device (700) via the communications interface (730).

[0112] The external communications interface (730) may also enable other forms of communication to and from the computing device (700) including, voice communication, near field communication, Bluetooth, etc. [0113] The computer-readable media in the form of the various memory components may provide storage of computer-executable instructions, data structures, program modules, and other data. A computer program product may be provided by a computer-readable medium having stored computer-readable program code executable by the central processor (710).

[0114] A computer program product may be provided by a non-transient computer- readable medium, or may be provided via a signal or other transient means via the communications interface (730).

[0115] Interconnection via the communication infrastructure (705) allows a central processor (710) to communicate with each subsystem or component and to control the execution of instructions from the memory components, as well as the exchange of information between subsystems or components.

[0116] Peripherals (such as printers, scanners, cameras, or the like) and input/output (I/O) devices (such as a mouse, touchpad, keyboard, microphone, joystick, or the like) may couple to the computing device (700) either directly or via an I/O controller (735). These components may be connected to the computing device (700) by any number of means known in the art, such as a serial port.

[0117] One or more monitors (745) may be coupled via a display or video adapter (740) to the computing device (700).

[0118] FIG. 8 shows a block diagram of a communication device (800) that may be used in embodiments of the disclosure. The communication device (800) may be a cell phone, a feature phone, a smart phone, a satellite phone, or a computing device having a phone capability.

[0119] The communication device (800) may include a processor (805) (e.g., a microprocessor) for processing the functions of the communication device (800) and a display (820) to allow a user to see the phone numbers and other information and messages. The communication device (800) may further include an input element (825) to allow a user to input information into the device (e.g., input buttons, touch screen, etc.), a speaker (830) to allow the user to hear voice communication, music, etc., and a microphone (835) to allow the user to transmit his or her voice through the communication device (800). [0120] The processor (805) of the communication device (800) may connect to a memory (815), The memory (815) may be in the form of a computer-readable medium that stores data and, optionally, computer-executable instructions.

[0121] The communication device (800) may also include a communication element (840) for connection to communication channels (e.g., a cellular telephone network, data transmission network, Wi-Fi network, satellite-phone network, Internet network, Satellite internet Network, etc.). The communication element (840) may include an associated wireless transfer element, such as an antenna.

[0122] The communication element (840) may include a subscriber identity module (SIM) in the form of an integrated circuit that stores an international mobile subscriber identity and the related key used to identify and authenticate a subscriber using the communication device (800). One or more subscriber identity modules may be removable from the communication device (800) or embedded in the communication device (800). [0123] The communication device (800) may further include a contactless element (850), which is typically implemented in the form of a semiconductor chip (or other data storage element) with an associated wireless transfer element, such as an antenna. The contactless element (850) may be associated with (e.g., embedded within) the communication device (800) and data or control instructions transmitted via a cellular network may be applied to the contactless element (850) by means of a contactless element interface (not shown). The contactless element interface may function to permit the exchange of data and/or control instructions between mobile device circuitry (and hence the cellular network) and the contactless element (850).

[0124] The contactless element (850) may be capable of transferring and receiving data using a near field communications (NFC) capability (or near field communications medium) typically in accordance with a standardized protocol or data transfer mechanism (e.g., ISO 14443/NFC). Near field communications capability is a short-range communications capability, such as radio-frequency identification (RFID), Bluetooth, infra-red, or other data transfer capability that can be used to exchange data between the communication device (800) and an interrogation device. Thus, the communication device (800) may be capable of communicating and transferring data and/or control instructions via both a cellular network and near field communications capability.

[0125] The data stored in the memory (815) may include: operation data relating to the operation of the communication device (800), personal data (e.g., name, date of birth, identification number, etc.), financial data (e.g., bank account information, a bank identification number (BIN), credit or debit card number information, account balance information, expiration date, Ioyalty provider account numbers, etc.), transit information (e.g., as in a subway or train pass), access information (e.g., as in access badges), etc. A user may transmit this data from the communication device (800) to selected receivers.

[0126] The communication device (800) may be, amongst other things, a notification device that can receive alert messages and access reports, a portable merchant device that can be used to transmit control data identifying a discount to be applied, as well as a portable consumer device that can be used to make payments. [0127] The foregoing description of the embodiments of the invention has been presented for the purpose of illustration; it is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Persons skilled in the relevant art can appreciate that many modifications and variations are possible in light of the above disclosure. [0128] Some portions of this description describe the embodiments of the invention in terms of algorithms and symbolic representations of operations on information. These algorithmic descriptions and representations are commonly used by those skilled in the data processing arts to convey the substance of their work effectively to others skilled in the art. These operations, while described functionally, computationally, or logically, are understood to be implemented by computer programs or equivalent electrical circuits, microcode, or the like. The described operations may be embodied in software, firmware, hardware, or any combinations thereof,

[0129] The software components or functions described in this application may be implemented as software code to be executed by one or more processors using any suitable computer language such as, for example, Java, C++, or Perl using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions, or commands on a non-transitory computer- readable medium, such as a random access memory (RAM), a read-only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD-ROM. Any such computer-readable medium may also reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network,

[0130] Any of the steps, operations, or processes described herein may be performed or implemented with one or more hardware or software modules, alone or in combination with other devices, in one embodiment, a software module is implemented with a computer program product comprising a non-transient computer- readable medium containing computer program code, which can be executed by a computer processor for performing any or all of the steps, operations, or processes described.

[0131] Finally, the language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the invention be limited not by this detailed description, but rather by any claims that issue on an application based hereon. Accordingly, the disclosure of the embodiments of the invention is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.

Claims

WHAT IS CLAIMED IS:

1 . A method of enabling a group of members to transact with funds stored in a value store, comprising:

receiving, from an electronic device of a member of the group, a proposal for a transaction to use funds stored in the value store;

transmitting the proposal to electronic devices of a plurality of members of the group;

receiving responses indicating agreement or disagreement with the proposal from at least some of the members of the group;

determining whether a predetermined number of responses indicating agreement with the proposal have been received; and

in response to receiving a predetermined number of responses indicating agreement with the proposal, authorizing the transaction and providing at least one of the members of the group with transaction details required to fulfil the transaction; or

in response to a failure to receive a predetermined number of responses indicating agreement with the proposal, denying the transaction.

2. A method as claimed in claim 1 , wherein a sub-set of the group are designated as authorized proposers, and wherein a proposal for a transaction is received only from one of the authorized proposers,

3. A method as claimed in claim 1 or claim 2, wherein a sub-set of the group are designated as authorized approvers, and wherein the proposal is transmitted only to the authorized approvers.

4. A method as claimed in any one of the preceding claims, wherein a sub-set of the group are designated as authorized fuifi!lers, and wherein the transaction details required to fulfil the transaction are provided only to the authorized fulfillers.

5. A method as claimed in any one of claims 1 to 3, wherein any member of the group is capable of fulfilling the transaction once the transaction is authorized. 8. A method as claimed in any one of the preceding claims, wherein the transaction details required to fulfil the transaction are specific to the proposed transaction and valid only for fulfilling the proposed transaction.

7. A method as claimed in any one of the preceding claims, wherein the transaction details required to fulfil the transaction includes one or more of: a transaction identifier, additional transaction details, a transaction token, a primary account number (PAN), a single-use PAN, a card expiry date, a card verification value (CW), a password, a passcode, and a personal identification number (PIN), 8. A method as claimed in any one of the preceding claims, wherein the electronic device is a mobile phone and the value store is a mobile wallet account held at a mobile banking system, and wherein the mobile wallet account is a single shared account of the group of members. 9. A method as claimed in claim 8, wherein each of the members of the group are identified using at least a mobile phone identifier.

10. A method as claimed in claim 9, wherein the mobile phone identifier is a Mobile Station International Subscriber Directory Number (MSISDN).

1 1 . A method as claimed in any one of the preceding claims, wherein the transaction is selected from the group consisting of: a cash-out transaction in which credit in the account is converted to cash available for withdrawal at a mobile banking agent, a withdrawal transaction, and a transfer of funds to a different financial account.

12. A method as claimed in claim 3 or in any one of claims 4 to 1 1 when dependent on claim 3, wherein the predetermined number of responses is selected from the group consisting of: a majority of the sub-set of authorized approvers, a predetermined percentage of the sub-set of authorized approvers, all of the authorized approvers, and a predetermined percentage of the members of the group.

13. A method as claimed in any one of the preceding claims, wherein an authorized manager is capable of configuring an approval rule for proposed transactions.

14. A method as claimed in any one of the preceding claims, wherein thresholds are applied to limit the value or number of transactions that can be proposed and/or fulfilled by a particular member of the group.

15. A method as claimed in any one of the preceding claims, wherein the step of transmitting the proposal to electronic devices of a plurality of members of the group includes transmitting the proposal only to electronic devices of other members of the group and not to the electronic device of the member of the group from which the proposal was received.

16. A method as claimed in any one of the preceding claims, which further includes the steps of:

reserving funds upon receiving a proposal for a transaction; and removing the reservation of those funds if the transaction is denied: or debiting the reserved funds upon the transaction being approved and fulfilled. 17. A system for enabling a group of members to transact with funds stored in a value store, the system including an authorization server comprising:

a proposal receiving component for receiving, from an electronic device of a member of the group, a proposal for a transaction to use funds stored in the value store;

a proposal transmitting component for transmitting the proposal to electronic devices of a plurality of members of the group;

a response receiving component for receiving responses indicating agreement or disagreement with the proposal from at least some of the members of the group; an approval determining component for determining whether a predetermined number of responses indicating agreement with the proposal have been received; and

an authorization component for, in response to receiving a predetermined number of responses indicating agreement with the proposal, authorizing the transaction and providing at least one of the members of the group with transaction details required to fulfil the transaction, or, in response to a failure to receive a predetermined number of responses indicating agreement with the proposal, denying the transaction,

18. A system as claimed in claim 17, further including a plurality of electronic devices in communication with the authorization server, each electronic device associated with a member of the group, and wherein:

at least one of the electronic devices includes a proposal component for transmitting the proposal for a transaction to use funds stored in the value store to the authorization server;

at least one of the electronic devices includes an authorization component for transmitting a response to the authorization server indicating agreement or disagreement with the proposal; and

at least one of the electronic devices includes a fulfilling component for receiving the transaction details required to fulfil the transaction.

19. A system as claimed in claim 18, wherein the electronic devices are mobile phones and the value store is a mobile wallet account held at a mobile banking system, and wherein the mobile wallet account is a single shared account of the group of members.

20. A computer program product for enabling a group of members to transact with funds stored in a value store, the computer program product comprising a computer-readable medium having stored computer-readable program code for performing the steps of:

receiving, from an electronic device of a member of the group, a proposal for a transaction to use funds stored in the value store; transmitting the proposal to electronic devices of a plurality of members of the group;