WO2015172193A1

WO2015172193A1 - Computer-implemented methods and management systems for managing membership of a group

Info

Publication number: WO2015172193A1
Application number: PCT/AU2015/050235
Authority: WO
Inventors: David Knox; Shane TUOHY; Paul SHALLUE
Original assignee: Mercer Australia Pty Ltd
Current assignee: Mercer Australia Pty Ltd
Priority date: 2014-05-15
Filing date: 2015-05-12
Publication date: 2015-11-19
Anticipated expiration: 2016-11-15
Also published as: AU2015258771A1; AU2016101535A4

Abstract

A management system for managing membership of a group associated with a plurality of clients, wherein each member of a client is assigned a member account and has a valid membership of the group at a beginning of a period, the management system being arranged to communicate with at least one server across a communications network. The management system comprises a manager module arranged to determine at least one member of a client associated with the group having an invalid membership after the beginning of the period, and an account module arranged to determine for each member of a client having an invalid membership after the beginning of the period, a risk value associated with the member at the beginning of the period. The management system further comprises a calculations module arranged to determine, at the end of the period, a bonus amount, wherein the bonus amount is a function of a sum of the risk values of all members determined to have an invalid membership and a transfer module arranged to facilitate distribution of a portion of the bonus amount for each member of a client having a valid membership at the end of the period across the communications network to a respective client account associated with an account module of the at least one server. In response to the calculations module determining that a member of a client having an invalid membership after the beginning of the period has complied with a benefit condition, the transfer module is arranged to facilitate transfer of a benefit amount for across the communications network to an account of the client with the member having the invalid membership associated with the account module of the at least one server.

Description

Title: Computer-implemented methods and management systems for managing membership of a group

Technical Field

[0001] Some embodiments relate generally to computer-implemented methods and management systems for managing membership of a group associated with a plurality of clients. For example, the group may be associated with assets, for example, trusts or funds, such as longevity funds or superannuation/pension related funds.

Background

[0002] Superannuation or pensions are arrangements which assist people in accumulating funds for retirement. However, it is difficult to gauge how much income will be sufficient to ensure a comfortable living for retirement, and in some cases, where retirees outlive their retirement expectations, traditional superannuation or pension arrangements have been found to be inadequate.

[0003] It is desired to address or ameliorate one or more shortcomings of prior art or to at least provide a useful alternative thereto.

[0004] Throughout this specification the word "comprise", or variations such as "comprises" or "comprising", will be understood to imply the inclusion of a stated element, integer or step, or group of elements, integers or steps, but not the exclusion of any other element, integer or step, or group of elements, integers or steps.

[0005] Any discussion of documents, acts, materials, devices, articles or the like which has been included in the present specification is not to be taken as an admission that any or all of these matters form part of the prior art base or were common general knowledge in the field relevant to the present disclosure as it existed before the priority date of each claim of this application. Summary

[0006] Some embodiments relate to a computer management system for managing membership of a group associated with a plurality of clients, wherein each member of a client is assigned a member account and has a valid membership of the group at a beginning of a period, the management system being arranged to communicate with at least one server across a communications network, the management system comprising: a manager module arranged to determine at least one member of a client associated with the group that has an invalid membership after the beginning of the period; an account module arranged to determine for each member of a client having an invalid membership after the beginning of the period, a risk value associated with the member at the beginning of the period; a calculations module arranged to determine, at the end of the period, a bonus amount, wherein the bonus amount is a function of a sum of the risk values of all members determined to have an invalid membership; a transfer module arranged to facilitate distribution of a portion of the bonus amount for each member having a valid membership at the end of the period to a respective client account associated with an account module of the at least one server; and wherein, in response to the calculations module determining that a member, having an invalid membership after the beginning of the period, has complied with a benefit condition, the transfer module being arranged to facilitate transfer of a benefit amount to an account of the client for the member having the invalid membership associated with the account module of the at least one server. [0007] For example, the risk value may be based on an initial investment to the member account and at least one risk parameter.

[0008] In some embodiments, the manager module may be arranged to receive a request from the manager module of the at least one server across the communications network to exit a designated member of a client from the group and, in response to the request, to update a member record associated with the client to indicate that the designated member has an invalid membership.

[0009] In some embodiments, the manager module may be arranged to receive, during the period, a request from the manager module of the second server across the communications network to withdraw funds from a client account on behalf of a member associated with the group, and cause the transfer module to facilitate transfer of funds associated with the member to the account associated with the account module of the second server, subject to the account module determining that a balance of the member's account exceeds a threshold amount. For example, the calculations module may comprise a transfer tool arranged to determine funds to be distributed.

[0010] In some embodiments, during the period, the manager module may be arranged to receive a request to associate a new member of a client with the group from a manager module of the at least one server across the communications network and, in response to the request, to create a member record for the new member and assign a member account to the new member. The manager module may be further arranged to record, in the member record, the new member of a client as having an invalid membership of the group at the beginning of the period, and a valid membership of the group at the end of the period. In some embodiments, during the period, the manager module may be arranged to receive a request to associate a new client with the group from a manager module of the at least one server across the communications network and, in response to the request, to create a client record for the new client and assign a client account to the new client. Once the client record is created, the manager module may then associate one or more member accounts with the client record of the new client. [0011] In some embodiments, the manager module may be arranged to determine that the at least one member of a client has an invalid membership at the end of the period by determining from the member record associated with the client that the member has an invalid membership at the end of the period.

[0012] The calculations module may be arranged to determine investment earnings at the end of the period, wherein the investment earnings is determined as a function of an investment sum derived from an investment.

[0013] In some embodiments, the management system may further comprise a transfer module arranged to facilitate transfer of an investment amount across the communications network to an investment server, and facilitate receipt of an indication of the investment sum associated with the group.

[0014] In some embodiments, the manager module may be arranged to determine whether the member of a client has complied with the benefit condition by determining whether an amount less than a threshold amount over a term of the member's membership of the group was transferred to the client account for the member. The benefit condition may be dependent on at least one of receipt of a withdrawal instruction or notification from a client, notification that a member has died, a determination of whether and how many previous withdrawal requests have been received and actioned, amount of payments determined to have been received during term of membership, a recorded age of the member, a determined duration of membership of the member and a surviving partner benefit election of the member.

[0015] The risk parameters may include at least one of: i) investment switches including investment income, bonus amount payments, and capital return payments , ii) partial exits and shortfall withdrawals made during the nominated period; iii) personal information associated with the member; iv) previous penalties imposed in accordance with rules of the group; v) previous indexation and/or adjustments to the value of the member account balance due to undistributed positive or negative investment earnings in previous nominated periods and vi) a surviving partner benefit election of the member. The risk value for each member of a client associated with the group may depend on a mortality rate for the member.

[0016] The bonus amount for each member of a client may be determined as a total bonus pool value multiplied by a weighted risk value for the member, and divided by a sum of the weighted risk values for all members having a valid membership at the end of the time period.

[0017] The management system may further comprise a reconciliation engine to validate and reconcile transfers into and withdrawals from the member account of each member of the group. Each such transfer into and withdrawal from the member account may be processed at least in part via another server (148) that is not associated with the at least one server or the management system. Each member of a client may be permitted to join the group by initiating an initial transfer into a new member account and for each initial transfer into the member account, the reconciliation engine generates and allocates a member identification number to the member account.

[0018] In validating and reconciling transfers into or withdrawals from the member account of each member of a client of the group, the reconciliation engine may be arranged to receive and compare at least two transaction reports from at least two different sources over the communication network. For transaction reports that pass validation by the reconciliation engine, the reconciliation engine may store each of the at least two transaction reports into at least one data store with a pending status, wherein if the comparison of the transaction reports indicates a data match for transfers or withdrawals to be reconciled, then the stored transaction reports are updated to a confirmed status.

[0019] If validation by the reconciliation engine of one of the transaction reports is determined by the reconciliation engine to have failed, then the reconciliation engine may generate and transmit a failure notification to a server source from which the non- validated transaction report was received. [0020] Some embodiments relate to a computer implemented method of managing membership of a group associated with a plurality of clients, wherein each member of a client is assigned a member account and has a valid membership of the group at a beginning of a period, the method operable on a first server arranged to communicate with at least one second server across a communications network, the method comprising: determining, by a manager module of the first server, at least one member of a client associated with the group having an invalid membership after the beginning of the period; for each member of a client having an invalid membership after the beginning of the period, determining, by an account module of the first server, a risk value associated with the member at the beginning of the period; determining, by a calculations module of the first server, at the end of the period, a bonus amount, wherein the bonus amount is a function of a sum of the risk values of all members determined to have an invalid membership; facilitating, by a transfer module of the first server, distribution of a portion of the bonus amount for each member of a client having a valid membership at the end of the period to a respective member account associated with an account module of the at least one second server; and in response to determining by the calculations module that a member of a client having an invalid membership after the beginning of the period has complied with a benefit condition, facilitating by the transfer module transfer of a benefit amount to an account of the client for the member having the invalid membership associated with the account module of the at least one second server. [0021] For example, the risk value may be based on an initial investment to the member account and at least one risk parameter.

[0022] In some embodiments, in response to receiving a request from the manager module of the second server across the communications network to withdraw the designated member of a client from the group, the method may further comprise updating, by the manager module, a member record associated with the designated client to indicate that the designated member has an invalid membership.

[0023] In some embodiments, the method may further comprise, in response to receiving by the manager module, during the period, a request from the manager module of the second server across the communications network to withdraw funds from a client account on behalf of a member associated with the group, facilitating transfer of funds by the transfer module of the first server to the account associated with the account module of the second server, wherein the facilitating may be subject to determining by the account module that a balance of the member's account exceeds a threshold amount. For example, the method may further comprise determining, by a transfer tool of the calculations module, the funds to be distributed.

[0024] In some embodiments, in response to receiving by the manager module of the first server, during the period, a request from a manager module of the second server across the communications network, to associate a new member of a client with the group, the method may comprise creating, by the manager module of the first server, a member record for the new member and assigning a member account to the new member. The method may further comprise recording, by the manager module, in the member record, the new member as having an invalid membership of the group at the beginning of the period, and a valid membership of the group at the end of the period. In some embodiments, in response to receiving during the period a request from the manager module of the first server to associate a new client with the group from a manager module of the second server across the communications network the method may comprise creating, by the manager module of the first server, a client record for the new client and assigning a client account to the new client. Once the client record is created, the manager module may then associate one or more member accounts with the client record of the new client.

[0025] In some embodiments, determining that the at least one member of a client has an invalid membership after the beginning of the period may comprise determining, by a manager module, from the member record associated with the client whether the member has an invalid membership at the end of the period.

[0026] The method may further comprise determining, by the calculations module of the first server, at the end of the period, investment earnings, wherein the investment earnings is determined as a function of an investment sum derived from an investment.

[0027] In some embodiments, the method may further comprise facilitating the transfer of the investment sum by a transfer module of the first server across the communications network to an investment server and facilitating receipt of an indication of the investment sum associated with the group.

[0028] In some embodiments, determining whether the member of a client has complied with the benefit condition may comprise determining whether an amount less than a threshold amount over a term of the member's membership of the group was transferred to the client for the member. The benefit condition may be dependent on at least one of receipt of a withdrawal instruction from a client, notification that a member of a client has died, a determination of whether and how many previous withdrawal requests have been received and actioned, amount of payments determined to have been received during term of membership, a recorded age of the member, a determined duration of membership of the member and a surviving partner benefit election of the member.

[0029] The risk parameters may include at least one of: i) investment switches including investment income, bonus amount payments, and capital return payments, ii) partial exits and shortfall withdrawals made during the nominated period; iii) personal information associated with the member; iv) previous penalties imposed in accordance with rules of the group; v) previous indexation and/or adjustments to the value of the member account balance due to undistributed positive or negative investment earnings in previous nominated periods; vi) a surviving partner benefit election of the member; and vii) time since the member became a member. The risk value for each member of a client associated with the group may depend on a mortality rate for the member.

[0030] The bonus amount for each member of a client may be determined as a total bonus pool amount multiplied by a weighted risk value for the member, and divided by a sum of the weighted risk values for all members having a valid membership at the end of the time period.

[0031] The method may further comprise validating and reconciling, using a reconciliation engine executing on the second server, transfers into and withdrawals from the member account of each member of a client of the group. Each such transfer into and withdrawal from the member account may be processed at least in part via another server (148) that is not associated with the first server or the at least one second server. Each member of a client may be permitted to join the group by initiating an initial transfer into a new member account and for each initial transfer into the client account for a member, the reconciliation engine may generate and allocate a member identification number to the member account.

[0032] The validating and reconciling transfers into or withdrawals from the member account of each member of a client of the group by the reconciliation engine may comprise comparing by the reconciliation engine at least two transaction reports from at least two different sources over the communication network. For transaction reports that pass validation by the reconciliation engine, the method may comprise storing by the reconciliation engine each of the at least two transaction reports into at least one data store with a pending status, wherein if the comparison of the transaction reports indicates a data match for transfers or withdrawals to be reconciled, then the stored transaction reports are updated by the reconciliation engine to a confirmed status. [0033] If validation by the reconciliation engine of one of the transaction reports is determined by the reconciliation engine to have failed, the method may further comprise the reconciliation engine generating and transmitting a failure notification to a server source from which the non-validated transaction report was received.

[0034] Some embodiments relate to a computer program product comprising a computer readable medium encoded with computer executable instructions, which when executed in a computer system, is effective to cause the computer system to carry out the methods described above. For example, the computer readable medium may be a non-transitory computer readable medium.

Brief Description of Drawings

[0035] Embodiments are described in further detail below, by way of example, with reference to the accompanying drawings, in which:

[0036] Figure 1 is a schematic block diagram of a communications system comprising a first server arranged to communicate with a second server across a communications network;

[0037] Figure 2 is a schematic block diagram of a framework of a modified superannuation or pension fund according to some embodiments;

[0038] Figure 3 is a flow diagram of a method of managing a request to associate a client with a group managed at the second server of Figure 1, according to some embodiments;

[0039] Figure 4 is an example of a member record maintained by the second server of Figure 1 ;

[0040] Figure 5 is a flow diagram of a method of managing a group at the second server of Figure 1, according to some embodiments; [0041] Figure 6 is a flow diagram of a method of managing a withdrawal from a member account associated with a member of a client of the group managed at the second server of Figure 1, according to some embodiments;

[0042] Figure 7 is a flow diagram of a method of managing a transfer of funds for clients associated with the group from the second server across the communications network to the first server of Figure 1, according to some embodiments;

[0043] Figure 8 is a flow diagram of a method of determining at the second server of Figure 1, a bonus amount for members of clients having valid membership of the group, according to some embodiments; and

[0044] Figure 9 is a database schema illustrating data structures employed in the system of Figure 1 ;

[0045] Figure 10 is a flow diagram of a method of reconciling transaction records for a transfer into a client account for at least one member of a client;

[0046] Figure 11 is a flow diagram of a method of reconciling transaction records for a withdrawal of at least one member from a client account; and

[0047] Figure 12 is a flow diagram of a method of automatic data transfer and electronic notification generation.

Description of Embodiments

[0048] Some embodiments relate generally to computer-implemented methods and management systems for managing membership of a group associated with a plurality of clients and/or members. For example, the group may be associated with assets, for example, trusts or funds, such as longevity funds or superannuation/pension related funds. [0049] The present disclosure may provide for an effective management of membership of the group enabling members of superannuation or pension funds (e.g. clients) to enhance or supplement their funds by availing of an investment option catering to needs of members of clients who live longer than expected. In the context of this description, clients may represent or manage account-based pension (ABP) funds or other organised and regulated retirement investment funds. Members are people who invest in funds offered by such clients.

[0050] Referring to Figure 1, there is illustrated a communications system, generally indicated at 100, comprising a first server 102 arranged to communicate with a second server 104, such as a group management server, across a communications network 106, such as a local area network, a wireless data network, an intranet or the Internet or combinations of such networks.

[0051] The first server 102 and the second server 104 may each comprise a single physical server or multiple physical servers arranged to operate as a distributed system. In some embodiments, the first server 102 and/or second server 104 may be virtual servers having distributed functions. For example, the first server 102 and/or second server 104 may comprise a set of virtualised servers configured to adapt dynamically to demand and may be effectively provided as on-demand computing services. In some embodiments, the first server 102 and/or the second server 104 may be isolated from direct client device interaction. The first server 102 and/or the second server 104 may comprise virtual servers.

[0052] In some embodiments, the first server 102 and/or the second server 104 may interact with one or more client computing devices 147 over the network 106. For example, suitable authorised client computing devices 147 may execute stored program code for at least one software application 149, which may comprise a suitable browser application or a purpose-built application (an "app"), to interact with servers 102 and/or 104 and extract data therefrom for display on a display (not shown) of the client computing device 147. For example, the application 149 may provide a user interface to extract generalised and/or aggregated member data from database 144. Thus, a user of client computing device 147 may provide user input to the application 149 that, according to the code executed by the application, triggers the transmission of a data request to the server 102 and/or 104. In response, the server 102 and/or 104 may authenticate the data request to ensure that the client computing device 147 is at least temporarily authorised to receive the requested data and then, assuming it is suitably authorised, the server 102 and/or 104 serves code and/or data to the client computing device 147 in a form executable by at least one computer processor (not shown) of the client computing device 147 to cause the application display the requested data or information based thereon. For example, the client computing device 147 may be used to request data for modelling or simulation processes in order to demonstrate to prospective members past fund performance and project or estimate possible future fund performance based on data (sanitised to omit personally identifying information) that is generalised and aggregated by the server 102 or 104 over a number of member accounts of past or existing members of a client.

[0053] The first server 102 may comprise one or a plurality of computer processors 108 (referred to for convenience as "processor 108") connected to or at least in communication with a program memory 110, a data memory 112, and a communications port 114. The one or more computer processors 108 may comprise one or more virtual machines. The program memory 110 may comprise a non- transitory computer readable medium, such as a hard drive, a solid state disk or CD- ROM and/or a virtualised data storage system, for example. Software, that is executable instructions or program code, such as program code grouped into code modules, may be stored on program memory 110, and may, when executed by the processor 108, cause the server 102 to perform functions for applications, such as applications for managing a fund as discussed in more detail with reference to Figure 2 below.

[0054] In some embodiments, the program memory 110 may include a manager module 116 and an account module 118, the functions of which may be typically implemented by appropriate software elements forming part of an overall fund management application hosted on the first server 102. In some embodiments, the manager module 116 may comprise a core or central program or code for performing the management application and includes function calls for invoking functions to be performed by the other tools and modules of the program memory 110.

[0055] The processor 108 may retrieve information from and/or store data in the data memory 112, such as information pertaining to clients of the fund and rules for managing the fund. The processor 108 may employ the communications port 114 to facilitate receiving and transmitting of information to and from the server 102.

[0056] As depicted, the second server 104 may comprise one or a plurality of computer processors 120 (referred to for convenience as "processor 120") connected to or at least in communication with a program memory 122, a data memory 124, and a communications port 126. The one or more computer processors 120 may comprise one or more virtual machines. The program memory 122 may be or include a non-transitory computer readable medium, such as a hard drive, a solid state disk or CD-ROM and/or a virtualised data storage system, for example. Software, that is executable instructions or program code, such as program code grouped into code modules, may be stored in program memory 122 and may, when executed by the processor 120, cause the processor to perform functions for applications such as applications for managing membership of a group, as discussed in more detail below with reference to Figure 2.

[0057] In some embodiments, the program memory 122 may include a manager module 128, an account module 130, and a calculations module 132. The manager module 128 may include a reconciliation engine 129. The reconciliation engine 129 may comprise a file transfer tool 159, the functions of both of which are described in further detail below with reference to Figures 10 to 12. The account module 130 may include a balance module 134 and/or a transfer module 136. The calculations module 132 may include an investment tool 138, a bonus tool 140, and/or a transfer tool 142. The functions of each of the manager module 128 (including the reconciliation engine 129 and the file transfer tool 159), the account module 130, including the balance module 134 and/or a transfer module 136 and the calculations module 132 including the investment tool 138, bonus tool 140, and/or transfer tool 142, may be typically implemented by appropriate software elements forming part of an overall group management application, as will be explained in more detail below.

[0058] In some embodiments, the manager module 128 comprises a core or central program or code for performing the management application and includes function calls for invoking functions to be performed by the other tools and modules of the program memory 122. In particular, the manager module 128 is responsible for reconciling transaction records received from server 102 with transaction records received from a fund custodian server, for example such as a bank system server 148. For this purpose, the manager module includes the reconciliation engine 129 to validate and reconcile the transaction records before transfers into or withdrawals from members of client accounts are confirmed. As part of the reconciliation process, automated electronic transfer of the transaction records is required and this is effected by file transfer tool 159 within reconciliation engine 129.

[0059] The processor 120 may retrieve information from and/or store data in the data memory 124, such as information pertaining to clients of the group and rules for managing the group. The processor 120 may employ the communications port 126 to facilitate receiving and transmitting of information to and from the management server 104.

[0060] The modules and tools of the program memory 110 and 122 may be software components comprising executable code or instructions, which when executed by a computer, such as processor 108 and 120 of servers 102 and 104, respectively, are arranged to perform functions associated with the modules and tools. Furthermore, the modules and tools are interoperable with one another and are capable of transferring data between one another and may include function calls to one another to cause the invoking of other modules and/or tools as required for the associated functions of the module or tool to be performed in accordance with described embodiments.

[0061] The servers 102 and 104 may communicate with a database 144, an investment server 146 and a bank system server 148 across communications network 106 to perform various functions in accordance with described embodiments. Database 144 may comprise multiple separate distributed or co-located data stores that may be logically and/or physically separated. Database 144 may be accessed through a database interface application, such as Microsoft Access™, for example.

[0062] Figure 2 illustrates a schematic block diagram or framework of a modified pension/superannuation fund application, generally indicated at 200, according to some embodiments. The modified pension/superannuation fund application 200 may be hosted or implemented in part on the first server 102 and in part on the second server 104 such that the first and second servers interoperate to perform functions of the modified pension/superannuation fund application. However, embodiments are primarily directed to software and/or hardware functions of, or associated with, the second server 104.

[0063] The modified pension/superannuation fund application 200 may include an account-based pension (ABP) fund 202 (which is an example of a client) having an account 214 associated with a member of a client. The account 214 associated with the member may be held or maintained by the server 102 or may be held or maintained by the bank system server 148. For example, the ABP fund 202 may comprise or represent a retirement benefit of the member of a client. As depicted, a bundle of investment options 204 may be available in which the member may invest a portion or percentage of the (ABP) fund 202. In some embodiments, the processor 108 may be arranged to execute code to invoke the manager module 116 and the account module 118 to perform functions to manage the bundle of investment options 204.

[0064] In some embodiments, the bundle of investment options 204 may include a growth option 206, designed to cater for members of clients willing to invest in a potentially volatile growth orientated investment, a cash option 208, designed to cater for members of clients unwilling to reduce a capital value of their portion of the fund, and a default option 210, which is designed to determine a suitable investment strategy for a member of a client based on parameters associated with the member, such as the age and risk profile of the member. In some embodiments, further investment options 204 are envisaged.

[0065] As depicted, the bundle of investment options 204 may include a group membership option 212. The group membership option 212 may be designed to cater for members of clients willing to invest in an investment option configured to potentially provide an additional source of income to that provided by their superannuation or pension arrangement in the event that the member lives longer than anticipated or planned for. In some embodiments, an application for management of the group membership option 212 is hosted on the second server 104 and implemented by the processor 120. For example, the processor 120 may be arranged to execute code to invoke the manager module 128, the account module 130 and the calculations module 132 to perform functions to manage the group membership option 212.

[0066] In some embodiments, the group membership option 212 involves contributing to or investing in a group fund which may provide income to the member of a client based on at least one of income derived from investment earnings, bonus amount payments and capital return payments.

[0067] In one embodiment, payments of income derived from the group membership option 212 may be distributed from the second server 104 to the first server 102, directly to the client, or indirectly to the member of a client, for example, by distributing the group membership income to at least one of the other investment options 206, 208, 210, of the investment options 204 and thereby providing payment to an account or facility 214 associated with the member. Payments to the member account or facility 214 may be made directly or indirectly and may be made periodically or irregularly.

[0068] Figure 3 is a flow diagram of a method 300 of managing a request to join a group or associate a member of a client with a group managed at the second server 104. The method 300 may be implemented by the processor 120 deployed on the server 104. [0069] As exemplified in Figure 3, the manager module 128 may receive 302 a request on behalf of a member of a client to associate the member with a group managed by the server 104. For example, the request may be transmitted by the manager module 116 of the first server, for example, via the communications port 114, across the communications network 206 and may be received by the manager module 128 of the server 204 for example, via communications port 126.

[0070] In some embodiments, the request is assessed 304 to ascertain whether or not the request and/or the client complies with requirements of the group. Requirements of the group may include the request being received from an authorised source, the request conforming with a specified protocol, the client having adhered to relevant financial controls in regard to the secure transfer of money equivalent to the amount of investment requested. In some embodiments, the requirements of the group may be recorded as rules, and may be stored locally on the server 104, for example, in data memory 124 or may be stored in a database independent of and/or separate to the server 104, such as the database 144, local to or remote from server 104 and accessible via communications network 106.

[0071] In other embodiments, compliance with requirements may include determining whether the request has been received from a pre-approved source, such as the server 102. For example, the first server 102 may conduct compliance testing of a client prior to submitting a request to the server 104 on behalf of the client. In some embodiments, including those described below in relation to Figures 10, 11 and 12, a reconciliation process is performed by the reconciliation engine 129 of the manager module 128 as part of validating and reconciling fund transfers incoming to and outgoing from accounts associated with members of the investment group.

[0072] Subject to the request and/or the client satisfying the requirements of the group, the manager module 128 may create 306 a member record 400 for the client, an example of which is depicted in Figure 4. This act may include the reconciliation engine 129 generating and associating with the member record 400 a member identifier for initial inward transfers for membership of the group. [0073] The member record 400 may include a unique member identification 402 for the member, personal member details 404 such as their name, age (date of birth), income tax level, gender, marital status, and/or the date of joining the group membership option, membership status 406, account details 408 pertaining to the group and the ABP fund, and/or rules or permissions 410 associated with the member. Optionally, the member record may include beneficiary data, such as data identifying a partner or other beneficiary of the member.

[0074] The member record 400 may be implemented as a software object and may be stored locally on the server 104, for example, in data memory 124 or may be stored in a database independent of and/or separate to the server 104, such as a database 144, local to or remote from server 104 and accessible via communications network 106.

[0075] The manager module 128 may cause or prompt the account module 130 to create 308 a member account for the client associated with the group and associated with the member record.

[0076] The manager module 128 may determine 310 that a deposit associated with the client has been transferred to the client account associated with the group. In some embodiments, the manager module 128 may receive a notification from the account module 130 that a deposit associated with a client has been transferred to the client account. In some embodiments, the manager module 128 may query the account module 130 to determine whether a deposit associated with a client has been transferred to the client account or to pre-warn or notify the account module 130 to expect a deposit associated with a client to be transferred to the client account and request an indication from the account module 130 to signify that the deposit was received. In determining whether a deposit has been transferred to the client account, the account module 130 may employ the balance module 134 and/or the transfer module 136. The balance module 134 may be arranged to monitor and query a balance of all client accounts associated with the group and provide notifications to the account module 130, the manager module 128 and/or the calculations module 132, periodically, or in response to requests for specific information. [0077] The transfer module 136 may be arranged to monitor, record and facilitate the movement of deposits and payments to and from accounts associated with the group, optionally in cooperation with the reconciliation engine 129. The transfer module 136 may provide notifications to the account module 130, the manager module 128 and/or the calculations module 132, periodically, or in response to requests for specific information. The balance module 134 and the transfer module 136 may also communicate with one another to share information pertaining to the efficient and effective functioning of the management application.

[0078] In some embodiments, the client account and/or group account is held and maintained at the bank system server 148 and the transfer module 136 may be employed to facilitate transfers of funds to and from the client account and/or group account. For example, the account module 130 may invoke the transfer module 136 to query the bank system server 148 to ascertain whether a deposit associated with a client has been transferred to the client account or to pre-warn or notify the bank system server 148 to expect a deposit associated with a client to be transferred to the client account. The bank system server 148 may execute an automatic or semiautomatic notification routine that automatically or semi-automatically generates and issues an electronic notification, for example in the form of a transaction record detailing one or more transfer transactions that the bank system server 148 has been instructed to be made, to the transfer module 136 via the communications network 106. This electronic notification is to indicate whether a deposit was received or whether a transfer or a series of transfers is scheduled, for example, within a specified period, and if so, the amount of the deposit. The transfer module 136 may then communicate the amount of the deposit, transfer or series if transfers and/or account balances to the balance module 134, for example by notifying the balance module 134 of the receipt of the transaction record.

[0079] In some embodiments, the electronic notifications to and from the bank system server 148 may be in the form of emails and may require user input. For example, to generate notifications, the transfer module 136 may invoke an email client (not shown) to automatically populate an email template or attach one or more documents with relevant information and transmit the email to the bank system server 148 for processing. In some embodiments, the transfer module 136 may seek user input to generate, populate and transmit an email to the bank system server 148 for processing. For example, a user may be prompted by displaying a message box on a display screen of a computing device associated with the server 104, wherein the message box includes instructions for the user to generate and transmit and email to the bank server system 148. In one embodiment, the transmission of notifications may be semi-automatic. For example, the email client (not shown) may generate and display on the display screen an email for completion by a user and/or requiring user input to activate a user-selectable option to transmit the email; or a link, which when activated is configured to transmit a populated email. In alternative embodiments, another form of automatic electronic notification can be employed, such as automatically parseable messages or possibly a data transfer protocol (e.g. FTP).

[0080] Subject to the determination by the manager module 128 that a deposit associated with the client has been transferred to the client account, the member of the client may be accepted as a member of the group and the member record 400 may be updated accordingly to reflect the member of the client as having a valid membership of the group and as having an account balance based on the deposit received, i.e., the initial investment.

[0081] In some embodiments, steps 302 to 310 of method 300 may be conducted in a different order than that depicted in Figure 3. For example, in some embodiments, the determining 308 a transfer of a deposit associated with the member of a client may be conducted before the creating 306 of a member record 400.

[0082] Figure 5 is a flow diagram of a method 500 of managing a group according to some embodiments. The method 500 may be implemented by the processor 120 deployed on the server 104 and executing computer program code embodied as code modules or tools described herein. [0083] In some embodiments, the method 500 of managing the group is performed over a nominated period of time, having a commencement time CD(t) and an end time ED(t). For example, the period of time may be days, a month or months, or a year or years. In one embodiment, the period is a quarter of a year.

[0084] At the commencement time, the account module 130 may determine 502 a net value associated with the group. The net value associated with the group may be a sum of a total value of each of the member account balances B(t) at the commencement time CD(t).

[0085] The account module 130 may interact with the transfer module 136 to cause the transfer module 136 to invest 504 at least a portion of the net value associated with the group. For example, the transfer module 136 may engage with or communicate with the bank system server 148 for example, via communications port 126, across communications network 106 to direct the bank system server 148 to facilitate the investing of funds associated with the group, for example, by engaging with the investment server 146. The bank system server 148 may perform automatic or semiautomatic verification and/or authentication processes before transferring or investing funds. In some embodiments, the electronic communications to and from the bank system server 148 may be in the form of emails or other electronic data transfer or messaging and may require user input, as discussed above.

[0086] At or after the end time ED(t) of the period, the account module 130 may determine 506 a net value associated with the group. In some embodiments, the net value associated with the group at the end of the period may be expressed as the net value associated with the group at the start of the period plus any income or earnings derived from investments minus any fees, taxes or penalties payable and minus any withdrawals from member accounts associated with the group. The manner in which the group management application may handle withdrawals is discussed in more detail below with reference to Figure 6. [0087] The account module 130 may determine 508 payments to be made to each member of a client. In some embodiments, the transfer module 136 may be arranged to cause the bank system server 148 to transfer the payments for each client to an account associated with the server 102 across communications network 106 and the processor 108 of the server 102 may manage the electronic distribution of the payments to other investment options 106, 108, 110 associated with the client to thereby provide payment to an account or facility 114 associated with the client. The bank system server 148 may perform verification and/or authentication processes before transferring payments. In some embodiments, the notifications to and from the bank system server 148 may be in the form of emails or other electronic data transfer or messaging and may require user input. The manner in which the group management application may determine payment for the clients is discussed in more detail below with reference to Figure 7.

[0088] The account module 130 may determine 510 the member account balance B(t) for each member of a client. In some embodiments, the member account balance B(t) for each member of a client having a valid membership status 406 at or after the end time ED(t) may be calculated as:

[0089] B(t) = I - (P3(t) + P4(t) - P5(t) + P6(t) + E(t) + T(t)), where:

I is the initial investment made by the member;

P3(t) is a sum of previous investment switches made from the member's account at commencement time CD(t), for example, to another account associated with the member, such as the member's ABP account, and may include investment income, bonus amount payments, capital return payments and transfers, such as withdrawals and/or commutations;

P4(t) is a sum of previous penalties imposed in accordance with rules of the fund at commencement time CD(t); P5(t) is a sum of previous indexation and/or adjustments to the value of the member account balance due to undistributed positive investment earnings in previous nominated periods at commencement time CD(t);

P6(t) is a sum of previous indexation and/or adjustments to the value of the member account balance due to negative investment earnings in previous nominated periods at commencement time CD(t);

E(t) is a sum of previous expenses paid from the member account in accordance with rules of the group at commencement time CD(t); and

T(t) is a sum of previous taxes paid from the member account at commencement time CD(t).

[0090] In some embodiments, steps 502 to 510 of method 500 may be conducted in a different order than that depicted in Figure 5. For example, the member account balance may be determined 510 before payments are made 508 to the clients.

[0091] Figure 6 is a flow diagram of a method 600 of managing a withdrawal or transfer of funds from the member account associated with the group according to some embodiments. The method 600 may be implemented by the processor 120 deployed on the server 104 and executing computer program code embodied as code modules or tools described herein.

[0092] A withdrawal from a member account associated with the group may arise as a result of a shortfall withdrawal request made by the client, for example to enable the client to make a required payment from the ABP for the member, a partial exit of a member from the group, for example, to allow a member to reduce the amount of capital in their member account, or a complete or full exit, for example, as may arise as a result of the death of a member of a client. In some embodiments, a shortfall withdrawal, a partial exit and a full exit causes a change or modification to the member record 400 associated with the client.

[0093] In some embodiments, a withdrawal may be processed by the management application at any time, for example, before, during or after a nominated period. [0094] As exemplified in Figure 6, the manager module 128 may electronically receive 602 a notification on behalf of or associated with a member of a client that the client has arranged to withdraw funds from the client account associated with the group managed by the server 104. For example, the notification may be received by the server 104 from the server 102 across the communications network 106.

[0095] The manager module 128 may determine 604 whether the request relates to a shortfall withdrawal, a partial withdrawal or a full withdrawal. A shortfall withdrawal is a withdrawal made at the request of a client (as opposed to a member) for an amount to be paid from the member account managed/governed by server 104 in order for the client to meet a mandated payment on behalf of the member. For example, the client may be required to pay a pension payment to the member but funds are required from the account governed by the server 104 in order to meet the amount of funds required for such a payment. In some embodiments, the request may include a flag to indicate that the request relates to a full, partial or shortfall request. In some embodiments, the manager module 128 may determine 604 whether the request relates to a shortfall withdrawal, a partial withdrawal or a full withdrawal by comparing a withdrawal amount indicated in the request with an account balance for the member.

[0096] Subject to determining whether the withdrawal is a shortfall withdrawal, a partial withdrawal or a full withdrawal, the manager module 128 may determine 606 a set of conditions associated with the shortfall withdrawal, partial withdrawal or a full withdrawal with which the request is to comply in order for the request to be authorised. For example, the set of conditions may be based on the member's current age, the member's age at entry to the group, the member's gender, the member's term of investment, minimum payments required by legislation, legislative requirements, a minimum accumulated balance required to be remaining in the member accounts associated with the group and/or the member's account, the member's health, the member's financial circumstances, the member's personal circumstances, any previous withdrawals from the group, and any previous negative or positive returns affecting the member's account balance associated with the group, any tax or fees, the member's level of income tax and a surviving partner benefit election of the member. The set of conditions may be stored locally in the data memory 124, or may be retrieved from a remote location, such as from database 144.

[0097] Subject to determining 608 that the request complies with the set of conditions, the manager module 128 may invoke the account module 130 and/or the calculations module 132 to determine 610 a withdrawal payment, if any, to be made in accordance with the request.

[0098] In some embodiments, the determination of whether a withdrawal payment is payable depends on compliance of the member of a client with a benefit condition. For example, if the member has received, over a term of their membership of the group, funds in excess of the original investment, the manager module 128 may determine that no withdrawal payments are payable. In some embodiments, if the member is older than a threshold benefit age and/or has received funds below a threshold benefit amount, the manager module 128 may determine that a withdrawal payment is payable. Other benefit conditions may depend on at least one of receipt of a withdrawal instruction from a client, notification that a member of a client has died, a determination of whether and how many previous withdrawal requests have been received and actioned, amount of payments determined to have been received during term of membership, a recorded age of the client and a determined duration of membership, any tax or fees, the member's level of income tax and a surviving partner benefit election of the member.

[0099] In some embodiments, the transfer tool 142 is employed to determine any withdrawal payments payable to the member of a client as discussed in more detail with reference to step 706 of Figure 7.

[0100] In some embodiments, if the request relates to a partial exit, the calculations module 132 may determine the withdrawal payment based on instructions received from the client on behalf of the member selecting a partial withdrawal, or a client requesting a shortfall withdrawal as required to satisfy any ABP withdrawal provisions. [0101] If the request relates to a full exit, the calculations module 132 may determine the withdrawal payment based on a value of the member account balance associated with the group at the time of the request, B(t), a total sum of investment earnings paid to the client for the member at the time of the request, Pl(t), a total sum of bonuses paid or capital returns paid to the client at the time of the request P2(t), and/or any expense or fee associated with the full exit, Ex.

[0102] In some embodiments, the calculations module 132 may further determine the withdrawal payment based on factors such as the member's age at entry to the group, the member's gender, the member's age at the time of the request, any previous withdrawals from the group and any previous negative or positive returns affecting the member's account balance of the group, any tax or fees, the member's level of income tax and a surviving partner benefit election of the member.

[0103] For example, in one embodiment, the calculations module 132 may calculate the withdrawal payment for a full exit at a time t, or between a time t and time t+1, as being the higher of:

[0104] {Ki*B(t) - (K₂*Pl(t) + K₃*P2(t) + Ex)} and zero, where Ki, ¾ and ¾ are constants which may depend on the factors set out above.

[0105] The manager module 128 may authorise 612 the withdrawal. This may involve further checks with compliance requirements and the manager module 128 may update the member record 400 to record details of the withdrawal. For example, the manager module 128 may alter the membership status 406 of the member record 400 to indicate that the membership has become invalid where a full withdrawal occurs.

[0106] Subject to the withdrawal being authorised by the manager module 128, the manager module 128 may notify the transfer module 136 to instigate the transfer of the withdrawal payment and the transfer module 136 may effect 614 the transfer. For example, the transfer module 136 may cause the withdrawal payment to be transferred to an account associated with the server 102 and the processor 108 of the server 102 may manage the electronic distribution of the payment to other investment options 206, 208, 210 associated with the client. In some embodiments, the transfer module 136 may communicate with the bank system server 148 across communications network 106 to prompt the bank system server 148 to make the withdrawal payment to an account associated with the server 102, such as a pension/superannuation fund. The bank system server 148 may perform automatic or semi-automatic verification and/or authentication processes before transferring payments. In some embodiments, the electronic notifications to and from the bank system server 148 may be in the form of emails or other electronic data transfer or messaging and may require user input as described above.

[0107] The balance module 134 may update 616 the member account balance associated with the group once the funds transfer has been effected.

[0108] In some embodiments, steps 602 to 616 of method 600 may be conducted in a different order than that depicted in Figure 6. For example, authorisation of the withdrawal may be performed before calculating the withdrawal payment, or the member account balance may be updated before the withdrawal payment is transferred.

[0109] Figure 7 is a flow diagram of a method 700 of managing a transfer of funds for clients associated with the group according to some embodiments. The method 700 may be implemented by the processor 120 deployed on the server 104.

[0110] As discussed with reference to Figure 5, the account module 130 may determine 508 payments to be made to each member. To this end, the account module 130 may interact or communicate with the calculations module 132. In some embodiments, the payments may be derived from investment earnings, a bonus, and/or a capital return. [0111] The calculations module 132 may invoke the investments tool 138 to determine 702 investment earnings for each client. In some embodiments, the investments tool 138 may determine the investment earnings for each member of a client having a valid membership of the group at the end of a nominated period. For example, investment earnings may be derived from earnings received by the transfer module 136 as a result of an investment made by investment server 146.

[0112] In some embodiments, the investment earnings for each member of a client associated with the group may be determined from at least some of the total amount of investment earnings associated with the group, the duration (i.e. how long since the money was invested) of investment of each member of a client in the period, the value of the member account balance, B(t) at the commencement time CD(t), the value of any new investments received during the nominated period, i.e. at or after CD(t), and a level of indexation, if applicable, applied to each member's account balance for that nominated period.

[0113] In the event that the investments tool 138 determines that net investment earnings are negative in the nominated period, the calculations module 132 may determine that no investment earnings are to be paid to the clients associated with the group. In some embodiments, the account module 130 may reduce each member account balance by an amount. For example, the member account balance may be reduced by an amount proportional to the member account balance at the commencement time CD(t) and/or the term duration (i.e. how long since the money was invested) of the investment in the period. In some embodiments, the account module 130 may reduce each member account balance by an amount such that the sum of the reduction amounts of all member account balances equals or substantially equals the negative net investment earnings.

[0114] The calculations module 132 may invoke the bonus tool 140 to determine 704 the account bonus amount for each member of a client associated with a valid membership status of the group at the end of a nominated period, as discussed in more detail with reference to Figure 8. [0115] The calculations module 132 may invoke the transfer tool 142 to determine 706 a repayment of capital to a member of a client during or at the end of a nominated period. For example, in some embodiments, determination of whether a capital transfer is to be made to a client for a member may depend on: an initial investment I of the member, which may or may not be reduced to take into consideration any negative returns, the account balance of the member at the beginning of the period, B(t), the age of the member, the gender of the member, whether or when a repayment term is to be completed, or a risk assessment value associated with the member.

[0116] In some embodiments, the transfer tool 142 is invoked to determine an amount of funds to be transferred from a client account as a result of receipt by the manager module 128 of a request by a client on behalf of a member for a full or partial withdrawal or shortfall withdrawal of funds and/or a modification of the membership status, as discussed above with reference to Figure 6.

[0117] In some embodiments, where the manager module 128 receives a request to exit a member of a client from the group, for example, as a result of the death of the member, during or after the nominated period, the transfer tool 142 may be invoked to determine an amount of funds or benefit amount to be transferred from the client account to the server 102. For example, the benefit amount may depend on a benefit condition as described above, such as the initial investment by the member and a determined amount at risk value A(t) associated with the member.

[0118] Authorisation of repayment of capital to a member of a client associated with the group may be determined by the manager module 128 and may be assessed in accordance with a set of conditions associated with the account. For example, the set of conditions associated with authorisation of repayment of capital may be stored at a location accessible to server 104, such as in the data memory 124, or may be stored at a remote location, such as at database 144 or on the server 102.

[0119] The calculations module 132 may communicate with the account module 130 to cause the transfer module 136 to direct the bank system server 148 to transfer or distribute 708 the payments to the server 102. In some embodiments, the bank system server 148 may be arranged to transfer the payments of each client to an account associated with the server 102 and the processor 108 of the server 102 may be arranged to manage the electronic distribution of the payments to other investment options 206, 208, 210, of the investment options 204 associated with the client to thereby provide payment to an account or facility associated with the member of a client 214. The bank system server 148 may perform automatic or semi-automatic verification and/or authentication processes before transferring payments. In some embodiments, electronic notifications to and from the bank system server 148 may be in the form of emails or other electronic data transfer or messaging and may require user input.

[0120] The account module 130 may then invoke the balance module 134 to update 710 the account balance accordingly once the transfer or distribution has been conducted.

[0121] In some embodiments, steps 702 to 710 of method 700 may be conducted in a different order than that depicted in Figure 7.

[0122] Referring to Figure 8, there is depicted a flow diagram of a method 704 for determining a bonus amount for each member of a client having a valid membership of the group at the end of a nominated period, according to some embodiments. The method 704 may be implemented by the processor 120, and in some embodiments may be primarily implemented by execution of the calculations module 132, deployed on the server 104.

[0123] In some embodiments, the method 704 of determining a bonus amount is performed over a nominated period of time, having a commencement time CD(t) and an end time ED(t). For example, in one embodiment, the method 704 of determining the bonus amount is conducted at or after the end time ED(t) of the nominated period of time. [0124] The calculations module 132 may invoke the bonus tool 140 to determine 802 a total bonus pool amount $X at end time ED(t).

[0125] In some embodiments, the total bonus pool amount $X at end time ED(t) may be calculated as:

$X = NAV - BB(t+l) - IE(t+l) - C(t+1) - NI(t), where NAV is a net value associated with the group at end time ED(t), and may exclude any new investments at or after end time ED(t), i.e. at time t+1 , and before making payments derived from investment earnings and/or a capital transfer to clients associated with the group; BB(t) is a sum of the member account balances B(t) at the commencement time CD(t) for all members of clients having a valid membership of the group at the end time ED(t) and BB(t+l) is BB(t) minus any indexation of B(t) at the end of the period ED(t), and/or negative returns at ED(t) and/or any investment switching and/or capital transfer paid during the period; IE(t+l) is a sum of all payments related to investment earnings to be paid to members of clients in respect of the nominated period; C(t+1) is a sum of all payments related to capital transfers to be paid to members of clients in respect of the nominated period; and NI(t) is a sum of new investments received from new or existing members of clients during the nominated period.

[0126] In the case that a transfer is determined to be payable to members of clients associated with the group, the total sum of the transfer may be subtracted from the net value NAV to determine the total bonus pool amount $X.

[0127] In some embodiments, the total bonus pool amount $X at end time ED(t) may be calculated as a function of the sum of an amount at risk value A(t) for each member of a client having a valid membership at commencement time CD(t) and an invalid membership status at end date ED(t). [0128] In some embodiments, the bonus tool 140 may determine 804 an amount at risk value A(t) for each member of a client having a valid membership status at end date ED(t). The amount at risk value A(t) may depend on a range of factors or risk parameters, which may be defined as rules of the group. For example, the factors may include any of: I, B(t), Pl(t), P2(t), P3(t), and P4(t), all as previously defined, total of previous investment earnings, bonus, capital returns, investment switches, shortfall withdrawals and partial exit, any partial exits and shortfall withdrawals made during the nominated period, and any personal information associated with the member.

[0129] In some embodiments, for each member of a client having a valid membership status, i.e. a surviving member, at end time ED(t), characteristics of those members at commencement time CD(t), such as age, period of investment, gender, election of a surviving partner benefit and the amount at risk value A(t) may be employed to determine a share of bonus amount payable to a surviving member. Mortality rates, as may be determined from government or quasi-governmental authority, such as the Australian Government Actuary (Australian Life Tables), or a similar authority or publication, may be employed to calculate a mortality rate at each age for the members associated with the share of bonus amount. In some embodiments, a unisex mortality rate at each age may be calculated for each member in determining the amount at risk value A(t).

[0130] The bonus tool 140 may apply 806 a weighting to the time invested calculated as ED(t)-CD(t) and a weighting to the mortality rate for each surviving member calculated for each surviving member at end date ED(t). In some embodiments, the weighting applied may ensure that older members receive a higher bonus amount than younger members, for the same balance at risk, in order to reflect their higher risk of dying and forfeiting that balance.

[0131] In some embodiments, the amount at risk value A(t) for each member may be multiplied by a weighting factor. The weighting factor may be determined by multiplying time t after firstly multiplying t by and/or raising t to the power of a constant K_7. A(t) may then be multiplied by the member's mortality rate after firstly multiplying the mortality rate by and/or raising the mortality rate to the power of a constant Kg. For example, K₇ and Kg may be constants recommended by an actuary or similarly qualified person and may vary depending on age and/or gender. In some embodiments, if K₇ and Kg are determined to be zero, they are ignored.

[0132] The bonus tool 140 may sum 808 the weighting factors for each member having a valid membership Y to determine a total weighting factor Z_A.

[0133] The bonus tool 140 may determine a bonus percentage for each member having a valid membership as the total bonus pool amount $X multiplied by the member's weighting factor and divided by the total weighting factor Z_A.

[0134] The bonus tool 140 may calculate the bonus for each member as their bonus percentage multiplied by the total bonus pool value $X. The bonus tool 140 may verify the calculated bonus amount for each member having a valid membership by summing the total of calculated bonus amounts for each such member and determining whether the total is equal to or substantially equal to the total bonus pool amount $X.

[0135] In some embodiments, steps 802 to 812 of method 704 may be conducted in a different order than that depicted in Figure 8 and furthermore, that not all of the steps are required to perform the method. For example, in some embodiments, step 806 of applying a weighting to the risk values may be selectively omitted or eliminated.

[0136] In the event that the group is to be wound up or closed, a payment may be made from group to the ABP account of the members of clients associated with the group, which may equate to or be proportional to the value of the member account balance B(t) plus any net investment earnings and bonus amount payments and minus any allowance for wind up expenses, as may be defined in the rules of the group, and which may be calculated at the date of wind up. In some embodiments, a supplementary payment may be distributed as a result of earnings from sale of assets of the group. [0137] Figure 9 shows an example database schema 900 illustrating data structures employed in the management system 100 of Figure 1. Database schema 900 represents an example relational database, such as may be constructed using a database management system (DBMS) such as Microsoft Access, for example. Schema 900 is an example of a database schema that may be employed by the server 104 in managing the data received and/or generated and managing operations performed by the manager module 128, the account module 130 and the calculations module 132. Tables of schema 900 may include tables relating to individual investment transactions, overall fund transactions for the member group, members, investment fund policies for individual members, fund balances for member policies, policy transactions conducted under certain policies, transaction types, fund performance and bank transactions, for example. Example data fields for each of such tables are listed in the respective tables in schema 900.

[0138] Referring now to Figure 10, a flow diagram of a method 1000 of reconciling transaction records for a transfer into a client account is described in further detail. At 1005, server 102 periodically (for example once or multiple times daily) transmits an investment request to server 104, where the investment request forms part of a transaction file having multiple such investment requests. At 1010, the server 104 receives the transaction file. Act 1010 is described in further detail below with reference to Figure 12. At 1012, the reconciliation engine 129 performs a validation check of the transaction file to determine whether it can be processed and loaded to the database 144. This validation check may include checking the format of the data, checking that the file is not a null (empty) file, that the file has the correct header information (such as correct date, correct sender and addressee), that the file is properly encrypted and can be decrypted and that the file relates to funds and member groups that the server 104 is authorised to manage, for example.

[0139] If the transaction file fails the validation process, then at 1015, the reconciliation engine attempts to identify the reason for the failure, and generates and sends a notification message at 1017 to the server 102 describing the identified reasons for the failure. At 1020, the non-validated transaction file is stored in a directory of the database 144 for failed transaction files.

[0140] If the transaction file passes the validation process, then at 1022, the transaction file is stored into the database 144 and given a "pending" status. The transaction file is also moved into a "pending" directory in the database 144. At 1025, the reconciliation engine 129 or the manager module 128 generates a member identification code for any transfers that are initial (first) transfers for that member. This member identification code is added into the stored transaction file against the appropriate transfer.

[0141] The investment request sent by the server 102 at 1005 is also periodically (for example once or multiple times daily) provided by server 102 to an investment custodian server, such as the bank server system 148, which generates and sends a custodian transaction report to the server 104. The custodian transaction report received at 1030 from the custodian server includes multiple transactions for a period such as a day, listed by funds and including funds for group membership option 212 as well as funds for other investment options, such as 206, 208 and 210. For the custodian transaction report received at 1030, the reconciliation engine 129 performs a validation check at 1032 to determine whether it can be processed and loaded to the database 144. This validation check may include checking the format of the data, checking that the file is not a null (empty) file, that the file has the correct header information (such as correct date, correct sender and addressee), that the file is properly encrypted and can be decrypted and that the file relates to funds and member groups that the server 104 is authorised to manage, for example.

[0142] If the custodian transaction file fails the validation process, then at 1035, the reconciliation engine 129 attempts to identify the reason for the failure, and generates and sends a notification message at 1037 to the server 102 describing the identified reasons for the failure. At 1040, the non-validated transaction file is stored in a directory of the database 144 for failed transaction files. [0143] If the custodian transaction file passes the validation process, then at 1042, the transaction file is stored by the reconciliation engine 129 into the database 144 and given a "pending" status. The transaction file is also moved by the reconciliation engine 129 into a "pending" directory in the database 144. At 1045, a reconciliation process is performed by the reconciliation engine 129 in relation to the at least two transaction files stored (in separate directories) in the database 144 as pending. This reconciliation process is performed periodically, for example once, twice or three times daily or at certain times referenced to Greenwich mean time. The reconciliation includes comparing at 1047 the details of each of the transfers itemised in the two transaction files, such as date, fund identifier and transfer amount. The contents of the transaction files do not need to be the same, but for transfers appearing in the transaction file received by the server 104 at 1010, it is expected that there will be a matching transfer in the file received by the server 104 at 1030. If the comparison indicates that there is an imperfect match of the details for one or more of the fund transfers, then an exception handling routine is performed at 1050 to identify the nature of the mismatch. A notification of the mismatch is automatically generated at 1052, describing the nature of the mismatch and the reason for the failure of the reconciliation. Transaction files stored in database 144 as pending remain with the pending status until the reconciliation failure can be rectified, for example by intervention from an administrative user, or one or both of the transaction files received at 1010 and 1030 is corrected and re-loaded.

[0144] If the details of the transfers are determined at 1047 to match, then at 1055, the reconciliation engine 129 instructs the status of the transaction file that was loaded to database 144 at 1022 to be updated to "confirmed" and the transfers detailed in that file are executed to create new fund balances based on those transfers. At 1060, the reconciliation engine 129 moves the custodian transaction file (loaded at 1042) and the transaction file (loaded at 1022) to respective separate "confirmed" directories, where they are indexed for later reference, if required. At 1065, the reconciliation engine 129 generates, stores in database 144 and sends to the investment custodian server (bank system server 148) a transaction confirmation file that includes details of the confirmed transfers, and includes member identification codes that were allocated at 1025 or at an earlier point when the same client initiated its first transfer via server 102 and 104 to become a member of the group.

[0145] The reconciliation engine 129 notifies server 102 of the confirmation of the successful reconciliation by generation of an automatic message, such as an email or another electronic data transfer and by transmission of the transaction confirmation file generated at 1065. In response, the server 102 checks at 1070 the details of the confirmed transactions against the original investment instructions that the investment requests sent at 1005 were based upon. If any errors or inconsistencies are noted by this check, the server 102 performs at 1075 an exception handling process to resolve them. Otherwise, the transaction confirmation file is loaded into a database associated with, and accessible to, server 102 (which may be database 144) as having been confirmed.

[0146] Referring now to Figure 11, a flow diagram of a method 1100 of reconciling transaction records for a withdrawal from a member account is described in further detail. At 1105, server 102 periodically (for example once or multiple times daily) transmits a withdrawal request to server 104, where the investment request forms part of a transaction file having multiple such withdrawal requests. At 1110, the server 104 receives the transaction file from server 102. Act 1110 is described in further detail below with reference to Figure 12. At 1112, the reconciliation engine 129 performs a validation check of the transaction file to determine whether it can be processed and loaded to the database 144. This validation check may include checking the format of the data, checking that the file is not a null (empty) file, that the file has the correct header information (such as correct date, correct sender and addressee), that the file is properly encrypted and can be decrypted and that the file relates to funds and member groups that the server 104 is authorised to manage, for example.

[0147] If the transaction file fails the validation process, then at 1115, the reconciliation engine attempts to identify the reason for the failure, and generates and sends a notification message at 1117 to the server 102 describing the identified reasons for the failure. At 1120, the non-validated transaction file is stored in a directory of the database 144 for failed transaction files. [0148] If the transaction file passes the validation process, then at 1122, the transaction file is stored into the database 144 and given a "pending" status. The transaction file is also moved into a "pending" directory ion the database 144.

[0149] The withdrawal request sent by the server 102 at 1105 is also periodically (for example once or multiple times daily) provided by server 102 to an investment custodian server, such as the bank server system 148, which generates and sends a custodian transaction report to the server 104. The custodian transaction report received at 1130 from the custodian server includes multiple transactions for a period such as a day, listed by funds and including funds for group membership option 212 as well as funds for other investment options, such as 206, 208 and 210. For the custodian transaction report received at 1130, the reconciliation engine 129 performs a validation check at 1132 to determine whether it can be processed and loaded to the database 144. This validation check may include checking the format of the data, checking that the file is not a null (empty) file, that the file has the correct header information (such as correct date, correct sender and addressee), that the file is properly encrypted and can be decrypted and that the file relates to funds and member groups that the server 104 is authorised to manage, for example.

[0150] If the custodian transaction file fails the validation process, then at 1135, the reconciliation engine 129 attempts to identify the reason for the failure, and generates and sends a notification message at 1137 to the server 102 describing the identified reasons for the failure. At 1140, the non-validated transaction file is stored in a directory of the database 144 for failed transaction files.

[0151] If the custodian transaction file passes the validation process, then at 1142, the transaction file is stored by the reconciliation engine 129 into the database 144 and given a "pending" status. The transaction file is also moved by the reconciliation engine 129 into a "pending" directory in the database 144. At 1145, the reconciliation engine 129 checks whether the withdrawn assets have been received in the client account to which they were to be directed according to the transfer instructions. If this check does not confirm that the withdrawn assets have been received in the correct client account, then an exception handling routine is performed at 1147 to identify the error, if possible, and to automatically notify an administrative user of server 102 and/or server 104.

[0152] At 1150, a reconciliation process is performed by the reconciliation engine 129 in relation to the two transaction files stored (in separate directories) in the database 144 as pending. This reconciliation process is performed periodically, for example once, twice or three times daily or at certain times referenced to Greenwich mean time. The reconciliation includes comparing at 1152 the details of each of the transfers itemised in the two transaction files, such as date, fund identifier and transfer amount. The contents of the transaction files do not need to be the same, but for withdrawals appearing in the transaction file received by the server 104 at 1110, it is expected that there will be a matching withdrawal in the file received by the server 104 at 1130. If the comparison indicates that there is an imperfect match of the details for one or more of the fund transfers, then an exception handling routine is performed at 1155 to identify the nature of the mismatch. A notification of the mismatch is automatically generated at 1157, describing the nature of the mismatch and the reason for the failure of the reconciliation. Transaction files stored in database 144 as pending remain with the pending status until the reconciliation failure can be rectified, for example by intervention from an administrative user, or one or both of the transaction files received at 1110 and 1130 is corrected and re-loaded.

[0153] If the details of the transfers are determined at 1152 to match, then at 1160, the reconciliation engine 129 instructs the status of the transaction file that was loaded to database 144 at 1122 to be updated to "confirmed" and the withdrawals detailed in that file are executed to create new fund balances based on those withdrawals. At 1162, the reconciliation engine 129 moves the custodian transaction file (loaded at 1142) and the transaction file (loaded at 1122) to respective separate "confirmed" directories, where they are indexed for later reference, if required. At 1165, the reconciliation engine 129 generates, stores in database 144 and sends to the investment custodian server (bank system server 148) a transaction confirmation file that includes details of the confirmed withdrawals, and includes member identification codes for each of the withdrawal transactions.

[0154] The reconciliation engine 129 notifies server 102 of the confirmation of the successful reconciliation by generation of an automatic message, such as an email or another electronic data transfer, and by transmission of the transaction confirmation file generated at 1165. In response, the server 102 checks at 1170 the details of the confirmed transactions against the original investment instructions that the investment requests sent at 1005 were based upon. If any errors or inconsistencies are noted by this check, the server 102 performs an exception handling process at 1175 to resolve them. Otherwise, the transaction confirmation file is loaded into a database associated with, and accessible to, server 102 (which may be database 144 or another data store) as having been confirmed.

[0155] Figure 12 illustrates a method 1200 of automatic data transfer and electronic notification generation performed by the reconciliation engine 129 and in particular by the file transfer tool 159. Method 1200 is performed as part of act 1010 of method 1000 and act 1110 of method 1100 in order to transfer a transaction file from server 102 to server 104 to effect either a deposit (1010) or a withdrawal (1110). At 1210, the transaction file generated at 1005 or 1105 is stored in a designated location on server 102 or at a secure storage location local to or controlled by server 102. At 1220, the file transfer tool 159 periodically checks the designated storage location to determine whether a file is present in that location. At 1230, the file transfer tool 159 generates and sends an electronic notification or message, such as an email, to a first list of designated recipients when the file transfer tool 159 finds a file in the designated storage location of server 102. This alerts the designated recipients that a transaction file has been made available for transfer. At 1240, the file transfer tool copies the transaction file found at the designated location and transfers it to s designated storage location on server 104 or at a secure storage location accessible to and controlled by server 104. At 1250, the file transfer tool 159 automatically generates and sends an electronic notification or message, such as an email, to a second list of designated recipients (which may have different recipients from the first list) to confirm receipt of the transaction file a the second server 104. The generation of the second electronic notification at 1250 serves to confirm that the file transfer of the transaction file was successful. Thus, system administrators for server 104 can have suitable checks on the file transfer process. The transaction file is thus an output of method 1200 to feed in to the validation check of act 1012 of Figure 10 or to act 1112 of Figure 11.

[0156] Table I and Table II below depict simplified working examples of the determination of a bonus amount for each member of a client having a valid membership of the group at the end of a nominated period.

[0157] The examples of both Table I and Table II relate to a group associated with 10 members, each of which have a valid membership of the group at the beginning of a nominated period.

[0158] For each member, Tables I and II depict the age, gender, and initial investment made by the member, a gross amount payable to the member as a result of a withdrawal from the group, i.e., "death benefit", Bonus payments, investment earnings, capital return payments, postcode, the value at risk, a probability of death during the nominated period, whether or not the member survived to the end of the nominated period, funds to be distributed to surviving members (continuing members) at the end of the nominated period, i.e., members having a valid membership at the end of the nominated period, the weighting factor, the bonus percentage and the bonus amount to be distributed.

[0159] As depicted in the example shown in Table I, at the beginning of the nominated period, the total sum of the balances of the member accounts is $1,150,000. Member number 5 was determined not to have a valid membership of the group at the end of the nominated period and at least a portion of the "death benefit" of $25,000 was calculated as being payable to an account associated with the member, the bonus pool amount or total "living bonus" was calculated as being $75,000, and the total sum of the balances of the member accounts associated with the group at the end of the nominated period was calculated as $1,050,000. At the end of the nominated period, nine members having a valid membership were associated with the group.

[0160] As depicted in the example shown in Table II, at the beginning of the nominated period, the total sum of the balances of the member accounts is $1,150,000. Member numbers 1 and 7 were determined not to have a valid membership of the group at the end of the nominated period. At least a portion of the "death benefit" of $95,000 was calculated as being payable to an account associated with member number 1 and at least a portion of the "death benefit" of $105,000 was calculated as being payable to an account associated with member number 7. The bonus pool amount or total "living bonus" was calculated as being $25,000, and the total sum of the balances of the member accounts associated with the group at the end of the nominated period was calculated as $925,000. At the end of the nominated period, eight members having a valid membership were associated with the group.

[0161] It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the above-described embodiments, without departing from the broad general scope of the present disclosure. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.

Table I

Table II

Claims

CLAIMS:

1. A computer management system for managing membership of a group associated with a plurality of clients, wherein each member of a client is assigned a member account and has a valid membership of the group at a beginning of a period, the management system being arranged to communicate with at least one server across a communications network, the management system comprising:

a manager module arranged to determine at least one member of a client associated with the group that has an invalid membership after the beginning of the period;

an account module arranged to determine for each member of a client having an invalid membership after the beginning of the period, a risk value associated with the member at the beginning of the period;

a calculations module arranged to determine, at the end of the period, a bonus amount, wherein the bonus amount is determined as a function of a sum of the risk values of all members determined to have an invalid membership;

a transfer module arranged to facilitate distribution of a portion of the bonus amount for each member having a valid membership at the end of the period to a respective client account associated with an account module of the at least one server; and

wherein, in response to the calculations module determining that a member having an invalid membership after the beginning of the period has complied with a benefit condition, the transfer module being arranged to facilitate transfer of a benefit amount to an account of the client for the member having the invalid membership associated with the account module of the at least one server.

2. The management system of claim 1, wherein the risk value is based on an initial investment to the member account and at least one risk parameter.

3. The management system of claim 1 or 2, wherein the manager module is arranged to receive a request from a manager module of the at least one server across the communications network to exit a designated member of a client from the group and, in response to the request, to update a member record associated with the client to indicate that the designated member has an invalid membership.

4. The management system of any preceding claim, wherein the manager module is arranged to receive, during the period, a request from the manager module of the second server across the communications network to withdraw funds from a client account on behalf of a member associated with the group, and cause the transfer module to facilitate transfer of funds associated with the member to the account associated with the account module of the second server, subject to the account module determining that a balance of the member's account exceeds a threshold amount.

5. The management system of any preceding claim, wherein the calculations module further comprises a transfer tool arranged to determine funds to be distributed.

6. The management system of any preceding claim, wherein the manager module is arranged to receive a request to associate a new member of a client with the group during the period from a manager module of the at least one server across the communications network and, in response to the request, to create a member record for the new member and assign a member account to the new member.

7. The management system of claim 6, wherein the manager module is further arranged to record, in the member record, the new member as having an invalid membership of the group at the beginning of the period, and a valid membership of the group at the end of the period.

8. The management system of any preceding claim, wherein the manager module is arranged to determine that the at least one member of a client has an invalid membership at the end of the period by determining from the member record associated with the client that the member has an invalid membership at the end of the period.

9. The management system of any preceding claim, wherein the calculations module is arranged to determine investment earnings at the end of the period, wherein the investment earnings is determined as a function of an investment sum derived from an investment.

10. The management system of claim 9, further comprising a transfer module arranged to facilitate transfer of an investment amount across the communications network to an investment server, and facilitate receipt of an indication of the investment sum associated with the group.

11. The management system of any preceding claim, wherein the manager module is arranged to determine whether the member of a client has complied with the benefit condition by determining whether an amount less than a threshold amount over a term of the member's membership of the group was transferred to the client account for the member.

12. The management system of any preceding claim, wherein the benefit condition is dependent on at least one of receipt of a withdrawal notification from a client, notification that a member has died, a determination of whether and how many previous withdrawal requests have been received and actioned, amount of payments determined to have been received during term of membership, a recorded age of the member, a determined duration of membership of the member and a surviving partner benefit election of the member.

13. The management system of any preceding claim, wherein the risk parameters include at least one of: i) investment switches including investment income, bonus payments, and capital return payments, ii) partial exits and shortfall withdrawals made during the nominated period; iii) personal information associated with the member; iv) previous penalties imposed in accordance with rules of the group; v) previous indexation and/or adjustments to the value of the member account balance due to undistributed positive or negative investment earnings in previous nominated periods; and vi) a surviving partner benefit election of the member.

14. The management system of any preceding claim, wherein the risk value for each member of a client associated with the group depends on a mortality rate for the member.

15. The management system of any preceding claim, wherein the bonus amount for each member of a client is determined as a total bonus pool amount multiplied by a weighted risk value for the member, and divided by a sum of the weighted risk values for all members having a valid membership at the end of the time period.

16. A computer implemented method of managing membership of a group associated with a plurality of clients, wherein each member of a client is assigned a member account and has a valid membership of the group at a beginning of a period, the method operable on a first server (104) arranged to communicate with at least one second server (102) across a communications network, the method comprising:

determining, by a manager module of the first server (104), at least one member of a client associated with the group having an invalid membership after the beginning of the period;

for each member of a client having an invalid membership after the beginning of the period, determining, by an account module of the first server (104), a risk value associated with the member at the beginning of the period;

determining, by a calculations module of the first server (104), at the end of the period, a bonus amount, wherein the bonus amount is determined as function of a sum of the risk values of all members determined to have an invalid membership; facilitating by a transfer module of the first server (104), distribution of a portion of the bonus amount for each member of a client having a valid membership at the end of the period to a respective member account associated with an account module of the at least one second server (102); and in response to determining by the calculations module that a member of a client having an invalid membership after the beginning of the period has complied with a benefit condition, facilitating by the transfer module transfer of a benefit amount to an account of the client for the member having the invalid membership associated with the account module of the at least one second server (102).

17. The method of claim 16, wherein the risk value is based on an initial investment to the member account and at least one risk parameter.

18. The method of claim 16 or claim 17, further comprising, in response to receiving a request from the manager module of the second server across the communications network to withdraw a designated member of a client from the group, updating, by the manager module, a member record associated with the client to indicate that the designated member has an invalid membership.

19. The method of claim 18, further comprising, in response to receiving by the manager module, during the period, a request from the manager module of the second server across the communications network to withdraw funds from a member account on behalf of a member associated with the group, facilitating transfer of funds by the transfer module of the first server to the client account associated with the account module of the second server, wherein the facilitating is subject to determining by the account module that a balance of the member's account exceeds a threshold amount.

20. The method of claim 19, further comprising determining, by a transfer tool of the calculations module, the funds to be distributed.

21. The method of any one of claims 16 to 20, wherein, in response to receiving by the manager module of the first server, during the period, a request from a manager module of the second server across the communications network, to associate a new member of a client with the group, creating, by the manager module of the first server, a member record for the new member and assigning a member account to the new member.

22. The method of claim 21, further comprising recording, by the manager module, in the member record, the new member as having an invalid membership of the group at the beginning of the period, and a valid membership of the group at the end of the period.

23. The method of any one of claims 16 to 22, further comprising determining, by the manager module, from a member record associated with the client whether the member has an invalid membership at the end of the period.

24. The method of any one of claims 16 to 23, further comprising determining, by the calculations module of the first server, at the end of the period, investment earnings, wherein the investment earnings is determined as a function of an investment sum derived from an investment.

25. The method of claim 24, further comprising facilitating transfer of the investment sum by a transfer module of the first server across the communications network to an investment server, and facilitating receipt of an indication of the investment sum associated with the group.

26. The method of any one of claims 16 to 25, wherein determining whether the member of a client has complied with the benefit condition comprises determining whether an amount less than a threshold amount over a term of the member's membership of the group was transferred to the client for the member.

27. The method of any one of claims 16 to 26, wherein the benefit condition is dependent on at least one of receipt of a withdrawal instruction from a client, notification that a member has died, a determination of whether and how many previous withdrawal requests have been received and actioned, amount of payments determined to have been received during term of membership, a recorded age of the member, a determined duration of membership of the member and a surviving partner benefit election of the member.

28. The method of one of claims 16 to 27, wherein the risk parameters include at least one of: i) investment switches including investment income, bonus amount payments, and capital return payments, ii) partial exits and shortfall withdrawals made during the nominated period; iii) personal information associated with the member; iv) previous penalties imposed in accordance with rules of the group; v) previous indexation and/or adjustments to the value of the member account balance due to undistributed positive or negative investment earnings in previous nominated periods; vi) a surviving partner benefit election of the member; and vii) time since the member's investment began.

29. The method of any one of claims 16 to 28, wherein the risk value for each member of a client associated with the group depends on a mortality rate for the member.

30. The method of any one of claims 16 to 29, wherein the bonus amount for each member of a client is determined as a total bonus pool amount multiplied by a weighted risk value for the member, and divided by a sum of the weighted risk values for all members having a valid membership at the end of the time period.

31. The method of any one of claims 16 to 30, further comprising validating and reconciling, using a reconciliation engine executing on the second server, transfers into and withdrawals from the member account of each member of a client of the group.

32. The method of claim 31 , wherein each such transfer into and withdrawal from the member account is processed at least in part via another server (148) that is not associated with the first server or the at least one second server.

33. The method of claim 31 or claim 32, wherein each member of a client is permitted to join the group by initiating an initial transfer into a new member account and for each initial transfer into the member account, the reconciliation engine generates and allocates a member identification number to the member account.

34. The method of any one of claims 31 to 33, wherein the validating and reconciling transfers into or withdrawals from the member account of each member of a client of the group by the reconciliation engine comprises comparing by the reconciliation engine at least two transaction reports from at least two different sources over the communication network.

35. The method of claim 34, wherein, for transaction reports that pass validation by the reconciliation engine, storing by the reconciliation engine each of the at least two transaction reports into at least one data store with a pending status, wherein if the comparison of the transaction reports indicates a data match for transfers or withdrawals to be reconciled, then the stored transaction reports are updated by the reconciliation engine to a confirmed status.

36. The method of claim 35, wherein if validation by the reconciliation engine of one of the transaction reports is determined by the reconciliation engine to have failed, the method further comprises the reconciliation engine generating and transmitting a failure notification to a server source from which the non-validated transaction report was received.

37. A computer program product comprising a computer readable medium encoded with computer executable instructions, which when executed in a computer system, is effective to cause the computer system to carry out the method of any one of claims 16 to 36.

38. The computer program product of claim 37, wherein the computer readable medium is a non-transitory computer readable medium.

39. The management system of any one of claims 1 to 15, further comprising a reconciliation engine to validate and reconcile transfers into and withdrawals from the member account of each member of the group.

40. The management system of claim 39, wherein each such transfer into and withdrawal from the client account is processed at least in part via another server (148) that is not associated with the at least one server or the management system.

41. The management system of claim 39 or claim 40, wherein each member of a client is permitted to join the group by initiating an initial transfer into a new member account and for each initial transfer into the member account, the reconciliation engine generates and allocates a member identification number to the member account.

42. The management system of any one of claims 39 to 41, wherein, in validating and reconciling transfers into or withdrawals from the member account of each member of a client of the group, the reconciliation engine is arranged to receive and compare at least two transaction reports from at least two different sources over the communication network.

43. The management system of claim 42, wherein, for transaction reports that pass validation by the reconciliation engine, the reconciliation engine stores each of the at least two transaction reports into at least one data store with a pending status, wherein if the comparison of the transaction reports indicates a data match for transfers or withdrawals to be reconciled, then the stored transaction reports are updated to a confirmed status.

44. The management system claim 43, wherein if validation by the reconciliation engine of one of the transaction reports is determined by the reconciliation engine to have failed, then the reconciliation engine generates and transmits a failure notification to a server source from which the non-validated transaction report was received.

45. The management system of any one of claims 39 to 44, wherein the reconciliation engine comprises a file transfer tool to transfer a transaction file from the at least one server to the management system, wherein the transaction file specifies transfers into and withdrawals from the member account of each member of the group.

46. The method of any one of claims 31 to 36, further comprising executing a file transfer tool on the first server to transfer a transaction file from the second server to the first server, wherein the transaction file specifies transfers into and withdrawals from the member account of each member of the group.