WO2017212339A1

WO2017212339A1 - System and method of communicating requests and responses using a communications network

Info

Publication number: WO2017212339A1
Application number: PCT/IB2017/000846
Authority: WO
Inventors: Julian Edward Forsyth LITTLE; Duncan Francis Christian LITTLE
Original assignee: International Consulting Services Fz Lle
Current assignee: International Consulting Services Fz Lle
Priority date: 2016-06-10
Filing date: 2017-06-12
Publication date: 2017-12-14
Anticipated expiration: 2018-12-10

Abstract

A request and response system including a payment request device operable to present a graphical user interface to a user and receive details of a payment request and subsequently generate and transmit a payment request message over a communications network, one or more authorisation devices operable to receive payment request messages and present a graphical user interface to an authoriser and receive either approval or rejection of payment requests and generate and transmit payment request response messages over the communications network, the one or more authorisation devices further operable to generate and transmit funds transfer messages over the communications network in the event the authorisation device receives an approval of the payment request, and a funds disbursal system operable to receive one or more funds transfer messages and further operable to transfer funds from a source account to a destination account in accordance with details contained within funds transfer messages, the destination account accessible by the users who caused the generation of payment requests corresponding to the funds transfer.

Description

SYSTEM AND METHOD OF COMMUNICATING REQUESTS AND RESPONSES USING A COMMUNICATIONS NETWORK

FIELD OF THE INVENTION

[0001] The present invention relates to a system and method that is useful for managing payment requests. The system and method of the present invention is particularly useful for managing payments requests that are commonly referred to as "short cycle payments", "ad hoc payments" or "petty cash" payments and where those payments are subject to the usual accounting and audit requirements for businesses. The system and method of the present invention has particular application in circumstances where funds are required in respect of unpredictable expenses and also in situations where the exact amount of an expenditure is unknown until the time of purchase but payment is required at the time of purchase. The present invention may also find use in situations where organisations have operational activities that are geographically isolated from their physical offices and these remote activities incur expenses in respect of which payment is required at the time of purchase and where the approval and transfer of funds under such circumstances is time-critical.

BACKGROUND OF THE INVENTION

[0002] Traditionally, organisations manage two different types of payments, pre- budgeted (or predictable) long payment cycle expenses and unpredictable (or unbudgeted) short payment cycle expenses and classify any unpredictable or unbudgeted expenses as "ad hoc payments" or "short cycle payments" where the approval and transfer of funds under such circumstances is time-critical. Organisations tend to settle such expenses with cash disbursements or "petty cash" or manage a process to approve the payment outside of standardised long cycle end of month payment terms. Petty cash is typically a small amount of discretionary cash funds that are used to settle disbursements and/or expenditures in instances where it is impractical or infeasible to settle disbursements and/or expenditures by cheque or electronic funds transfer, primarily due to the inconvenience associated with obtaining the required authorisation before effecting cheque payments and electronic funds transfers.

[0003] Ad hoc payments, as compared with pre-agreed or contracted payments, are disbursements that are usually, but not always, smaller in amount and require immediate, or near immediate, payment. Ad hoc payments are often incurred in relation to operational and project activities associated with an organisation. Typical examples of ad hoc payments include, but are not limited to, employee travel expenses, catering expenses, expenses relating to purchase of stationery and utilities, conference/seminar registrations, event planning, promotional and marketing expenses, maintenance and/or repair expenses and moving expenses.

[0004] Ad hoc payments also include requests from employees or contract workers for an advance on their salary. Advance salary requests are inherently difficult to manage and track due to the unpredictability in the timing and amount of the advance salary request.

[0005] Whilst "cash disbursement" and ""petty cash" payment transactions may often be small in amount, the frequency of such transactions within an organisation can be high and so it will be appreciated that "petty cash" transactions may accumulate and significantly contribute to the overall expenditure of a business. Accordingly, it is important for an organisation to accurately and efficiently track and account for each and every ad hoc payment transaction and ensure that proper internal controls are followed at all stages of the request / approval / payment cycle.

[0006] Typically, organisations adopt the same or similar authorisation process for ad hoc payments as is used for pre-agreed or contracted payments. Such authorisation processes usually require one or more authorised persons to approve, or "sign-off," a purchase request in order to satisfy organisational guidelines, financial control and audit requirements. Sometimes, depending on the request amount or the organisation guidelines, such authorisation processes involve multiple sequential authorisation steps that need to be completed in order for an ad hoc payment to be approved.

[0007] Frequently ad hoc cash or petty cash transactions inherently involve the retrospective submission of invoices as evidence of any transaction for which an ad hoc payment amount has been requested, approved and spent by an employee of an organisation. This retrospective submission requirement often presents problems since invoices are sometimes not submitted, or when submitted, are difficult to enter into an organisation account to reconcile a particular invoice with a particular expenditure. [0008] In addition, payment through "cash disbursements" and "petty cash" become difficult to manage in any organisations having a number of remote operations in different parts of a city, country or the world, particularly when any discretionary funds set aside as "petty cash" are controlled by only one part of the organisation in one physical location i.e., a head office location and the geographically isolated operational activities are incurring company expenses where the approval and transfer of funds under such circumstances is time-critical and cannot be effectively managed. Many companies migrate to distributed teams using cash disbursements to meet such short cycle payments and internal controls are compromised as post-purchase approval of purchasing and / or expenses replaces pre-approval of purchases and / or expenses. The management of "cash disbursements", and other short cycle payments also becomes difficult in situations where the signatory is away from the office or travelling. Under such circumstances, pre-expenditure approval becomes difficult and the lack of an audit trail is problematic.

[0009] The operational and often unpredictable nature of ad hoc payments means that they are often time-critical and therefore the approval of a requested amount is often almost immediately required in order to meet a deadline and for the successful progression of a project or activity within an organisation. Current methods of processing ad hoc payment requests involve the requirement for an approval (often verbal or by email), and a signatory, and in many instances, multiple signatories (particularly for larger requested amounts) to "sign-off", or approve, the use of funds for an ad-hoc purchase. Whilst typical multi-signatory payment approval processes meet the financial control policies set by organisations, such processing methods often require sequential participation from the required signatories who are often extremely busy and/or traveling and/or have competing priorities and therefore find it difficult to attend to the approval of ad hoc payment requests in a timely manner. In some circumstances, the failure to approve ad hoc payment requests in a timely manner is problematic where projects may be delayed and their successful completion may even be compromised.

[0010] Accordingly, current methods of processing ad hoc payment requests are time consuming and typically impose additional requirements upon employees who are required to complete projects and ensure deadlines are met within short-timeframes for which ad hoc funds are required. The situation is further complicated when any of the required signatories are located in remotely located offices as compared with the location of the purchase, thereby further slowing down the approval process.

[0011] In addition, the unpredictable amount and timing of the requests relating to ad hoc payments often requires immediate approval and transfer of funds, which means that cash must be kept on the company premises thereby presenting a security risk and an increased risk of misappropriation of funds by individuals having direct access to any cash maintained on the premises.

[0012] In addition, with regard to isolated or remote workplaces and communities, for example, mining sites, movie sets at remote locations, shipping vessels or isolated refugee camps, "micro-economies" are often formed within the workforce or community, where commodities and other goods are provided, or services rendered, by individuals in exchange for an "I owe you" (IOU) that is typically physically recorded on paper or by a "word-of-mouth" agreement. The individual providing the commodities or goods, or that has rendered a service, will collect funds at a later date as agreed by the individual(s) forming part of the IOU agreement. As will be appreciated, such transactions are difficult to manage and track due to the ad hoc nature (in terms of timing and amount) of the IOU request, particularly in isolated workforces and communities having a large number of members and employees or contract workers.

[0013] A further consideration for many companies is the management of quotes or tender proposals by goods and service providers for the provision of various services and/or goods. Often, many tender proposals or quotes are received by companies from multiple goods and service providers and in respect of multiple goods and/or service requests, and hence, these are difficult to record and manage.

[0014] According to usual processes and procedures for arranging and approving payment requests, such as ad-hoc purchases, there is substantial communication between a person who is authorised to approve payment requests and the person seeking authorisation to make a payment. It is common for the communication to include phone calls, email messages, text messages and even messages posted on social media web-pages. In any event, the inefficiency of current expenditure approval processes results in inefficient use of time and data communications networks that have finite band width and, as skilled readers will appreciate, there is a cost associated with inefficient use of time and finite resources. [0015] The system and method of the present invention seeks to address at least some of the above mentioned problems associated with current methods of managing payment requests and problems associated with companies making payment of these approved requests using "cash disbursement" or "petty cash".

SUMMARY OF THE INVENTION

[0016] A computer implemented system for managing payment requests, the system including: an authorisation component configured to accept a payment request from a requestor for authorisation of the transfer of a monetary amount, the component operable to accept the entry of one or more details associated with payment requests, an interface that displays the requested monetary amount and any details thereof for viewing by an authoriser having authority to disburse funds from a source account containing funds, wherein the authoriser by operation of the interface, either authorises or declines the payment request, a transfer component that transfers funds, upon receipt of authorisation of a payment request, in respect of the requested monetary amount from the source account containing funds to a destination account accessible by the requestor.

[0017] In an embodiment, the destination account is accessible with one or more transaction payment devices.

[0018] In an embodiment, the one or more transaction payment devices are debit cards. It will be appreciated that a debit card, in contrast to a credit card, is a card on which funds are able to be loaded in any desired amount. Accordingly, user associated with a particular debit card is not required to be credit worthy and does not have to undergo any credit checks to be issued a card.

[0019] It will be appreciated that in most instances, funds are required to be transferred from the source account to the destination account before good(s) and/or service(s) is/are able to be provided to the person that has submitted the payment request.

[0020] Accordingly, in an embodiment, the funds are transferred prior to the provision of at least one good and/or service and upon authorisation of the transfer of the monetary amount by the authoriser thereby providing the necessary funds for the payment request. [0021] However, the system and method of the invention also contemplates the situation in which good(s) and/or service(s) is/are provided to an individual prior to the transfer of funds.

[0022] In another aspect, the present invention provides a computer implemented system for managing payment requests, the system including: an authorisation request component configured to accept a payment request for authorisation of the transfer of a monetary amount in respect of the provision of at least one good and/or service, the component further configured to accept the entry of one or more details associated with the payment request, an interface that displays the requested monetary amount and any details thereof for viewing by an authoriser, wherein the authoriser, by use of the interface, either declines the payment request or allocates funds in respect of the requested monetary amount for settlement of the payment request upon satisfaction of one or more conditions, and a transfer component that transfers the allocated funds from a source account to a destination account upon receiving notification of the satisfaction of the one or more conditions.

[0023] In an embodiment, the individual that provides the at least one good and/or service initiates the payment request.

[0024] In an embodiment, the individual that receives the at least one good and/or service initiates the payment request.

[0025] In an embodiment, the individual that provides the at least one good and/or service receives the payment request.

[0026] In an embodiment, the individual that receives the at least one good and/or service receives the payment request.

[0027] In an embodiment, the individual that provides at least one good and/or service authorises the payment request.

[0028] In an embodiment, the individual that receives the at least one good and/or service authorises the payment request. [0029] It will be appreciated that the pre-determined monetary amount managed by the system and method according to an embodiment of the present invention is effectively a "digital IOU" wherein the details of the pre-determined agreed monetary amount and the details of the proposed goods and/or services exchange are able to be recorded, managed and tracked using the system and method of the invention. Such details may include the specification of an agreed time-frame after the completion of a service or delivery of good(s) for effecting the funds transfer, such that the transfer is automatically effected once the specified time elapses in accordance with the terms of the digital IOU.

[0030] Alternatively, the system may allow the specification of an event, the occurrence of which triggers the automatic transfer of funds in accordance with the terms of the digital IOU. An event, for example, may include the date of the next pay cycle of the individual who owes the funds such that funds are transferred from the source account (of the individual who owes funds) to the destination account (of the individual of is owed funds).

[0031] In an embodiment, the payment request is in respect of a proposed expenditure relating to the purchase of goods. As an example, the proposed expenditure may be in respect of the supply of office stationery requested by an Office Manager. In another example, the proposed expenditure is in respect of flight and accommodation purchases requested by an employee as part of their work-related travel.

[0032] It will be appreciated that the term "purchase" may be broadly interpreted within the context of the invention and encompasses any acquisition occurring as a result of a funds transfer (i.e., payment). Purchases may include goods and/or services and may even include employees purchasing "annual leave" that is additional to the standard annual leave entitlements of each employee.

[0033] In an embodiment, the payment request is in respect of a proposed expenditure relating to a service. For example, a Maintenance Officer within a company may request the transfer of a monetary amount to cover costs associated with the maintenance and/or repair of a heating / cooling system located in the company premises. [0034] In an embodiment, the payment request is in respect of a salary advance and so does not have to be associated with a specific proposed expenditure. For example, a crew member on a shipping vessel may request an advance on their salary from the shipping vessel Master (authoriser).

[0035] In an embodiment, the payment request associated with a salary advance may be submitted by a user that receives the salary advance. Alternatively, in an embodiment, the payment request associated with a salary advance may be submitted by a user that authorises the payment request.

[0036] In an embodiment, the management of funds involves managing the workflow of (i) a payment request, (ii) authorisation of the payment request, (iii) transfer of funds from the source account to the destination account associated with one more transaction payment devices, and (iv) the reconciliation of the transfer of funds between the source account and the destination account after the purchase.

[0037] The term "proposed expenditure" within the context of the invention may refer to an amount of funds required to settle the purchase of a product or service relating to a specific task or event where the payment terms are on receipt, or prior to delivery, of the product or service. A "proposed expenditure" may also refer to situations where the actual purchase of the product or service is unplanned and the payment is time critical, or where the exact value of the product or service is unknown and the payment is time critical. Typically these types of purchases are smaller in amount compared to an amount that is in respect of a product or service associated with a pre-agreed contract payment. Traditionally, cash has been used to settle such payments and when the size of the payments is small the process is known as "petty cash".

[0038] A "proposed expenditure" may also be in respect of larger amounts, for example, financial aid that is required to be paid, typically on an urgent basis, to various members of a community during for example, the occurrence of a natural disaster.

[0039] An organisation may include or impose a limit for any proposed expenditure, andaccordingly, the system and method according to an embodiment of the invention also provides a means for entry of a specified expenditure (or spend limit) by an administrator. Any requests for funds above such a specified spend limit may require extraordinary approval measures (for example, approval by more than one authorizer, for example an administrator and a Department Head, and any requests that are below the specified spend limit may receive automatic approval. Accordingly, in an embodiment, the system is able to automatically process and approve a request for a proposed expenditure, when the requested proposed expenditure is below a specified spend limit entered into the system by the system administrator.

[0040] A proposed expenditure may be in respect of disbursements incurred as part of the management of, or due to the operational activities within, an organisation and may include, but are not limited to, travel expenses, repairs and maintenance of fixed assets, purchasing provisions or catering, event management, seminar/conference registration fees, purchases of sundries, utility expenses and any costs that are unable to be specifically pre-budgeted by an organisation due to the unpredictable nature of such expenditures and may also be where the payment terms for purchases are on receipt or prior to delivery of the product or service.

[0041] The term "managing payment requests" may encompass actions including, but not necessarily limited to, using an application (App) or website to manage receiving requests for specific expenditures with the entry of key decision data relevant to the expenditure in a request form; reviewing requests for specific expenditures; approving requests for specific expenditures; processing requests for specific expenditures including authorising a request for a transfer of funds from a source account (wallet) to a destination account (wallet) or declining a request for transfer of funds from a source account (wallet) to a destination account (wallet); transfer of funds from a source account (wallet) to a destination account (wallet), and substantiating through a reconciliation process, any funds transfers.

[0042] The term "managing payment requests" may further include a user or holder of the destination account (wallet) using a transaction payment device that may further be a network branded transaction payment device (for example a Visa or a MasterCard device) to make a payment for a purchase using the funds in the destination account; the user or holder of the destination account (i.e., secondary wallet) linking the approved request to the record of the purchase transaction and imaging a substantiating document such as an invoice or receipt into the record of the purchase transaction; the authoriser being able to view the record of the purchase transaction with the details of the linked approved request and the imaged substantiating document such as an invoice or receipt; the authoriser being able to transfer back into the source account (i.e., primary wallet) the balance of any monies that are in the destination account in excess of the actual purchase; and for the system to produce a data export of all data associated with the approved request and any further data entered after the transactions (including images of any substantiating document such an invoice of receipt) in a format that is suitable for an organisation to import into their accounting systems in order to reconcile and audit the purchase activity managed by the system and meet corporate internal control procedures.

[0043] It will be appreciated that in various embodiments, the term "destination account" is directed to any account linked, or otherwise associated with, a transaction payment device, whether the transaction payment device is a card, such as a credit or debit card, and whether the card is a physical card, an electronic card, a virtual card or a token. In embodiments, the transaction payment device may be a mobile (smart) phone application, a watch, a bracelet, an iPad or tablet or any software layer associated with an account, such that the device may be used to make financial transactions. Such transactions may include transactions via a standard branded payment network such as MasterCard, Visa, China Union Pay, Amex etc., and/or transfer and receive funds via payment networks such as, for example, Automated Clearing House (ACH), Swift or a wallet system such as PayPal or We-Chat Pay, Blockchain technologies or a crypto- currency based system or network.

[0044] In an embodiment, the transaction payment device is a branded payment network device. It will be appreciated that the term "branded payment network device" encompasses any device (as previously defined) that is linked, or otherwise associated, with a branded credit facility such as Visa or MasterCard.

[0045] In an embodiment, the transaction payment device is a debit card which is loaded with funds and not linked to any branded credit facility.

[0046] Having a destination account that is associated with one or more payment transaction devices may allow for more efficient processing of funds transfer requests to be realised. That is, in embodiments, the system of the invention may enable an authoriser to review and make an approval, have that approved value transferred in an efficient and direct (or straight-through) process from a source account controlled by the authoriser to a destination account associated with one or more payment transaction devices.

[0047] The transfer of the approved value to a destination account that is linked to, or otherwise associated with, one or more payment transaction devices enables an automated and real-time straight-through-process that may lead to the realisation of multiple benefits including, but not limited to any one or more of the following:

1. Elimination of manual activities, that would otherwise exist when using a destination account that is not connected to one or more transaction payment devices, between approval of a funds transfer request in the value of a proposed expenditure and using the requested funds transferred to the destination to make a payment;

2. Elimination of any manual paper-based work that tends to increase the accuracy, speed and efficiency of the payment process,

3. Elimination of time delays between when an authoriser who approves the transfer of value (and the value is transferred to a destination account) and the user who controls the destination account in order to use the value transferred to effect (make) a payment. In this regard, it will be appreciated that the real-time nature of the straight- through-processing of the system means the authoriser may approve a request and the system transfers the value relatively instantaneously to the destination account so that the user may immediately use the value transferred to effect a payment using the transaction payment device associated with the destination account. It will be appreciated that this process is possible whether the authoriser and user are in the same or different locations;

4. Elimination of time delays, errors and costs associated with the post- transaction reconciliation process since a user may be able to readily view any data associated with a transaction (purchase) that is completed with a payment transaction device that is linked to a destination account. Accordingly, through the use of a transaction payment device linked to a destination account to effect a purchase, a user may instantaneously view the details of the transaction by using, for example, a mobile App. In addition, as the user is able to view the details of any transaction (purchase) relatively instantaneously, the user may also link (or otherwise associate) the approved request for a proposed expenditure to a particular payment transaction as soon as the purchase has been effected by the use of, for example, a mobile App.

5. The ability to automate the process tends to have a lower error rate and thereby reduce audit and compliance risk;

6. The ability to achieve straight-through processing as a result of using a destination account that is associated with one or more payment transaction devices eliminates possible delay due to information regarding a particular transaction being transmitted slowly or inefficiently.

7. Elimination of the need to maintain physical cash on the company premises by permitting electronic transfer of funds thereby reducing the security risk associated with handling and storing physical cash at a location. It will be appreciated that eliminating the need to handle physical cash also means that funds may be transferred from a source account to a destination account in different currencies and typically USD or Euro. It will also be appreciated that the ability to transfer funds in USD or Euro is particularly desirable in companies having multinational locations and employees residing in different parts of the world. The ability to transfer funds in USD or Euro is also particularly desirable in the shipping industry, where shipping vessels employ crew members of different nationalities having primary residences in different countries.

[0048] Authorisers may be created by users known as administrators. The term "administrator" encompasses any person having authorisation to configure the system for a company. In an embodiment, the administrator may also be an authoriser who has the authority to approve or decline a proposed expenditure request.

[0049] An authoriser may include a single person such as a Credit Controller of a company authorised to configure the system and also approve and decline funds requests, or one or more Directors or designated officers or Department Heads of a company that have been configured by an administrator with sufficient authority to approve and decline funds requests.

[0050] In an embodiment, the Master of a shipping vessel may be an authoriser as well as an individual that makes requests. [0051] In an embodiment, the request for authorisation for the transfer of a monetary amount and any details associated with the requested transfer include the uploading of an image of a document such as a quotation or pro-forma invoice that can substantiate the proposed purchase, expenditure or salary advance request and that may be viewed by the authoriser as part of the request approval review process.

[0052] In an embodiment, the request for authorisation of the transfer of a monetary amount and any details associated with the requested proposed purchase or expenditure are entered by a user other than the authoriser. In this embodiment, the user may be any employee of an organisation. In an alternative embodiment, the funds request process may be operated by an external contractor of an organisation.

[0053] It will be appreciated that the term "user" encompasses any one or more persons that have access to, and are therefore able to use the system of the invention. In an embodiment, users may be restricted through the user setup configuration to be able to only make a request for a transfer of funds for a proposed expenditure that is authorised by the administrator.

[0054] Alternatively, a user may be configured as a "Department Head" and enabled through the user setup configuration to authorize requests from users for a transfer of funds in respect of a payment request where such users are associated in the user setup configuration as belonging to the respective Department. In the embodiment where a user is configured as a Department Head, the user is associated with a secondary account configured as an electronic department wallet that acts as a source account for funding the request for a transfer of funds that are approved by the Department Head.

[0055] In some embodiments, the system administrator is able to initiate a funds transfer in the absence of a request by a user (e.g., an employee of an organisation). Under these circumstances, the administrator enters details of a monetary amount to be transferred from the source account containing funds, selects the destination account for the transfer, and approves the transfer such that the nominated funds are transferred from the source account to the selected destination account.

[0056] In a further embodiment, the secondary account associated with a user may be a payroll account in which a salary or payroll is paid into the secondary account by an organisation. In this embodiment, the administrator may initiate a funds transfer to the user in the absence of a funds transfer request by a user. Where there are a plurality of secondary accounts being used for payroll, the system may allow the administrator to upload a file, for example, a spreadsheet or csv file, into the system with all the details of the relevant secondary accounts and the value of the payroll to be credited to each account. Following the upload of the file, the system may then process the file and debit the source account in the total consolidated value of the payroll file and credit each specified secondary account with the value of the payroll specified in the file to be credited to each account.

[0057] In an alternative embodiment, the system may be used to pay bonus payments to the staff within an organisation. In this embodiment, a Department Head may submit a request for a transfer of funds in an amount of the bonus payment to the authoriser controlling the source account (primary electronic wallet) for a transfer of value to an electronic department wallet controlled by the Department Head. The Department Head may then initiate a funds transfer to the user(s) in the absence of any funds transfer request by a user(s) so that funds (bonus payments and salary advance payments) are transferred from the electronic department wallet to the one or more user destination accounts.

[0058] In a further embodiment where the secondary account is used for payroll purposes, the system may block the ability for the Department Head or the administrator/authoriser to view the transaction spending/purchase/withdrawal history of the respective secondary accounts and associated transaction payment devices that are configured for payroll.

[0059] In an embodiment, the request for authorisation of a payment request is achieved by the completion of an electronic request form. In one embodiment, the electronic request form includes data fields that are presented in a single screen, where the user may view all fields that require completion and may enter data or select menu items as required or prompted for each of the respective fields.

[0060] In an alternative embodiment the format of the Request Form may display a series of sequential data fields that the user is prompted to complete by either entering data or selecting menu items for each of the respective fields such that the complete form is not displayed in one screen at any time. [0061] In an alternative embodiment, the request form with data fields for a request for authorisation of a payment request are generated within a third party platform (for example, Enterprise Resource Planning (ERP) management software) associated with the system. In this embodiment, the details in the request form are imported into the system, via an agreed data exchange method, such that the system uses the imported data to create a request in the system for authorisation by the authoriser or for automatic approval through the use of any configured constraints. In this embodiment, the data in the imported request would need to include the details of the source account to be debited and the secondary (or destination) account to be credited. Approval of the request may trigger the debiting of the primary (or source) account and the crediting of value to the secondary (or destination) account.

[0062] In an embodiment, approval of a funds transfer request may be achieved through the use of an external (or third party) system such as Enterprise resource planning (ERP) management software associated with the system of the invention. Accordingly, in this embodiment, a request for authorisation of a proposed expenditure may be created by a user in the system and then exported to another system (for example, an organisation's ERP or workflow management system) for authorisation / approval and then the original request and the approval result is imported back into the system. Importing the approval of the request from the third party system triggers the debiting of the source account and the crediting of value to the secondary / destination account and the associated transaction payment device (for example, a user payment card).

[0063] In some embodiments, the request for authorisation of a payment request is controlled by constraints created by a system administrator. Accordingly, in an embodiment, the system further includes defined constraints that support various types of "approval" parameters to manage a range of scenarios including, but not limited to, automatic approval where the request for authorisation meets pre-set "approval" parameters, requirement that a department head can approve a request through to requirements for dual authorisation of a request for authorisation of a proposed expenditure.

[0064] The secondary or destination account(s) may have a plurality of multicurrency sub-accounts associated with each destination account. Such multi-currency destination accounts may be linked to multi-currency branded payment networks such as Visa, MasterCard, China Union Pay or the like.

[0065] Accordingly, in an embodiment, a user may select the type of currency of the nominated funds in the payment request. This may be achieved through selection of the desired currency from a drop down list of currencies available in the request form as configured by the administrator during the setup of the system. When the payment request (and any associated details) are displayed for viewing by an authoriser, the system may display the requested funds value in the currency originally requested by the user and this funds value is converted, at the current exchange rate, to the specified currency of the source account (with any additional margins). According to this embodiment, upon authorisation of expenditure payment request, it is the monetary value of the request in the source account currency that will be debited from the source account once the authoriser approves the payment request.

[0066] In a further embodiment, the system may request a current exchange rate for the conversion between the request currency and the source account currency and may further add a customer specific margin and use this consolidated rate to convert the currency of the requested proposed expenditure amount and the source account currency amount.

[0067] Alternatively, the system allows various sub-accounts to be created within an account, for example a source account, where each sub-account deals in funds transfers of a certain currency. Such sub-accounts with different currencies are termed "currency wallets" throughout the specification.

[0068] Accordingly, in an embodiment, the system includes a plurality of currency wallets associated with a source account and the Company Administrator and / or Finance Department are able to transfer funds between currency wallets associated with a source account so that they can manage that there is always a sufficient balance in each currency specific wallet to fund the approval of currency specific requests. In a further embodiment, the system may request a current exchange rate and may further add a customer specific margin and use this consolidated rate to convert the value being transferred between the different currency wallets within the source accounts. [0069] Accordingly, in an embodiment, the system includes a plurality of currency wallets associated with a source account and/or a destination account. The system may also have a number of source accounts and/or destination accounts each dealing in funds transfers of specific currencies. Accordingly, funds are able to be transferred between source and destination accounts dealing in the same currency, thereby avoiding delays associated with currency conversions. As such, funds transfers between a source account and a destination account are able to be effected substantially immediately.

[0070] It will be appreciated that as currency exchange rates are constantly changing, in a further embodiment, the system may hold the specific exchange rate for a period of time (for example, 90 seconds) and advise the authoriser in the request authorisation screen of the period remaining at which the rate is being held. At the end of the holding period, the system requests a current exchange rate and re-converts the requested monetary amount to the source account wallet currency using the new rate. The new amount is then updated and is displayed for viewing by the authoriser in the request authorisation screen. Upon authorisation of the payment request by the authoriser, the system debits the requested monetary amount from the source account in the specified currency and transfers the equivalent converted monetary amount to the destination account in the currency requested by the user.

[0071] In a further embodiment, the system may also use foreign currency forward exchange rates which may be specified for a variable future period and displayed to the authoriser.

[0072] In a further embodiment, when an authoriser reviews a request for approval of a payment request and there is insufficient funds in the source account to meet the monetary amount of the request, the authoriser may approve the request for auto approval processing once the funds in the source account are increased to an amount that is greater than the requested funds amount.

[0073] Once the payment request has been approved and the relevant funds have been transferred from the source account to the destination account and the funds have been used to make a purchase (i.e., an actual expenditure), the system may provide a means of substantiating the purchase. Accordingly, in an embodiment, the system further includes a component configured to enable linking the details of the actual purchase transaction expenditure to the approved request associated with a payment request. In an embodiment, further details of the actual expenditure are entered by the user that entered the payment request.

[0074] In an embodiment, the actual expenditure details include the uploading of an image of a document that can substantiate the actual expenditure. The image may include, but is not limited to, any one or more of an invoice, receipt, quotation, price tag or any other form of documentary evidence that may be used to indicate, or substantiate, the value of the actual expenditure made.

[0075] In an embodiment, the processing device of the system transfers funds between the source account and the destination account such that the destination account is debit based.

[0076] In an embodiment, the source and the destination accounts may be one or more electronic wallets wherein the source account is one or more primary electronic wallet(s) and the destination account is one or more secondary electronic wallet(s).

[0077] In an embodiment, the funds in the primary electronic wallet are pre-funded and the primary electronic wallet is therefore also debit based. Accordingly, this obviates the need for either the system administrator or any user to be "credit worthy", that is, there is no need for any of the administrators or users, or any entities with which the administrators or users are associated, to meet any required bank credit approval processes. It will be appreciated that this would be especially desirable in situations where it is difficult to obtain the necessary approvals associated with credit based products, for example, in developing markets.

[0078] Accordingly, it will be appreciated that the system of the invention may support financial inclusion of businesses in developing markets that may use the system of the invention to more effectively manage the approval of remote payment requests and associated actual payment transactions and thereby attain greater control and efficiency in their business operations.

[0079] In embodiments, the primary electronic wallet (or source account) may be funded by funds transfers from an organisation's bank account. Such funds transfers may be "push transfers" where the administrator of the organisation's bank account creates an instruction in the organisation's bank account system to debit the bank account and transfer the funds to the bank account holding the funds of the primary electronic wallet(s) (referred to as the "float account"). Alternatively, such funds transfers may be "pull transfers" initiated by the primary electronic wallet system where the administrator of the primary electronic wallet creates an instruction in the primary electronic wallet system to debit the bank account (often referred to as a direct debit or Automatic Clearing House (ACH) debit) and transfer the funds to the float account.

[0080] In a further embodiment, the system may be configured to manage automatic transfer of funds such that when the balance of funds in the primary electronic wallet falls to a pre-set minimum level then this triggers a business rule to automatically request a new transfer of funds from the organisations bank account (whose bank account details are associated with the primary electronic wallet) to the primary electronic wallet (often referred to as a direct debit where the amount that may vary with each instruction) and this transfers/credits the funds to the float account.

[0081] In a further embodiment, the system may generate a unique reference number (URN) that may be used to identify funds transfers from an organisation's bank account to the primary electronic wallet(s) of the organisation. The URN generated by the primary electronic wallet system may be unique to the organisation and the primary electronic wallet or the URN may be unique to a specific funds transfer to the organisation's primary electronic wallet.

[0082] In an embodiment, operationally the managers of the system (i.e., those persons, groups or organisations that manage, run and license (or otherwise distribute for use), the system to users such as, but not limited to organisations and / or financial institutions are able to review the statement(s) of the bank account(s) (i.e., float account(s)) and identify each transfer successfully credited to the float account(s) and credit these values to the respective organisation's primary electronic wallet.

[0083] In a further embodiment, where the managers of the system have authority to import the bank statement of the float account electronically into the system of the invention, the generated URNs may be used to ensure correct automated matching and allocation of values credited to the float account and values credited to the respective organisation's primary electronic wallet. [0084] It will be appreciated that the transfer funds in one currency in a source account to a destination account in a different currency is permitted, subject to such funds transfers incorporating a foreign exchange conversion rate that includes a margin.

[0085] In an embodiment, the system allows funds of a selected currency to be transferred from a currency wallet associated with source account to a currency wallet associated with a destination account, wherein the currency wallets associated with the source and destination accounts deal in the same currency.

[0086] It will be appreciated the transfer of funds in a source account in one currency to a destination account in another currency typically involves delays associated with the currency conversion process. For example, if funds in the source account are in USD and the approval of a request requires that funds are to be transferred from a source account in USD to a destination account in Japanese YEN, the actual settlement of the YEN, and the funding of the request in YEN, may be delayed until the end of the business day or even the next morning.

[0087] Accordingly, it will be appreciated that by the use of various currency wallets within the source and/or destination account, the delay associated with transferring funds and managing the conversion between different currencies between accounts may be avoided.

[0088] Alternatively, in embodiments, the funds in the primary electronic wallet may be a line of credit extended by a financial institution (such as a bank, building society, credit union or any other type of financial institution), to an entity of which a user is associated, for example, an organisation of which the user is an employee. Accordingly, the primary electronic wallet may be credit based and funds may desirably be dynamically and efficiently transferred from the primary electronic wallet to one or more secondary electronic wallets within an entity (organisation) as required. In such an embodiment the secondary electronic wallets or destination account may be credit based or debit based.

[0089] In an embodiment, the secondary electronic wallet is linked, or otherwise associated with a payment transaction device interoperable with a standard branded payment network. Such standard branded payment networks may include, but are not limited to, credit, debit and/or pre-paid cards. In an embodiment, the branded payment networks include Visa, MasterCard, China Union Pay or the like. In a further embodiment the secondary electronic wallet may be a physical card or an electronic card accessible through a mobile application (App), a watch, payment bracelet, a one-time virtual payment network card account number usable for a single online transaction for the approved value, or any electronic means of accessing electronic cards.

[0090] In an embodiment, the secondary electronic wallet may include a plurality of individually managed branded payment networks. For example, an organisation administrator may distribute a number of transaction payment devices, for example, cards (whether credit, debit or pre-paid) to a number of employees (users) within an organisation and manage the transfer of those funds from a primary (or central) electronic wallet to any one or more of the issued cards. In an embodiment these multiple issued cards may belong to multiple branded payment networks such as Visa, MasterCard, China Union Pay or the like.

[0091] In an embodiment, one or more secondary wallets may be configured as one or more electronic department wallets. These department wallets may be funded by transfers from a primary (or central) electronic wallet to the secondary wallet that is configured as a department wallet. Such department wallets may be the source account for any funds requests that are approved by, for example, the manager of the department (Department Head). Transfers from a primary (or central) electronic wallet to the secondary (department) wallet may be either initiated by the Department Head as a request for a transfer of value to the department wallet that is then received and approved by the administrator or the administrator may initiate a transfer of value to the department wallet without a prior request from the department head.

[0092] In embodiments, all of the Company funds are maintained in a primary electronic wallet (source account) wherein the Company Administrator or Finance Department sets the available currencies in the system setup and allocates a budget (the allocated budget) for each Department and for each available currency, for a specified period. The allocated budget represents funds allocated to a Department that may be used by that Department to manage and approve payment requests. Accordingly, the allocated budget is the currency specific budget for the Department for a period, and the period may be 7 days, 14 days or a calendar month as selected by the Company Administrator or Finance Department in the system setup. [0093] In an embodiment, the system and method monitors the allocated budget for each Department and the available budget for each Department wherein each payment request, upon authorisation, is debited from the available budget for that currency associated with the Department. Accordingly, as the period progresses and additional requests are approved by the Department, the available balance (the net balance) remaining for that period reduces.

[0094] Further, as payment requests are approved by the Department, the net balance of the currency wallet matching the currency of the request is reduced as the value of each approved request is debited from the relevant currency wallet in the primary electronic wallet and the value is transferred to a destination account associated with the user making the request.

[0095] In an embodiment, the system and method may additionally require that multiple conditions be satisfied for an authorisation to proceed and successfully debit from the relevant currency wallet in the primary electronic wallet. These conditions include: i) that the value of the request is less than or equal to the remaining available budget for the department for the currency of the request, and ii) that the value of the request is less than or equal to the remaining balance of the currency wallet matching the currency of the request.

[0096] Where a Department cannot approve a payment request as the value of the request is greater than the remaining available budget for the department for the currency of the request, then the system escalates the request for approval by the Company Administrator or Finance Department. In this situation, the Company Administrator or Finance Department can approve the escalated request provided that the value of the request is less than or equal to the remaining balance of the currency wallet matching the currency of the request.

[0097] In a further embodiment, the Company Administrator or Finance Department may select a different condition to apply to selected Departments and their associated users in the system set up such that these users can approve requests where i) the value of the request is greater than the remaining available budget for the department for the currency of the request, and ii) the value of the request is less than or equal to the remaining balance of the currency wallet matching the currency of the request. [0098] Where the value of the payment request is greater than the remaining balance of the currency wallet matching the currency of the request, then the user that is making the approval has the option to escalate the request to the Company Administrator or Finance Department and the Company Administrator or Finance Department must transfer additional funds to the relevant currency wallet in order to approve the request.

[0099] For example, an organisation administrator may configure a number of secondary electronic wallets for, and within, the different departments residing within the organisation, and set up users within a Department with associated constraints so that any requests made by such users is forwarded to the Department Head for manual approval. Accordingly, users associated with different departments may enter requests for approval of specific expenditures, and such requests are forwarded to the Department Head for manual approval. Any approved expenditures may be transferred from the respective associated department (secondary) electronic wallet to the destination account (and associated transaction payment device) of the user making the request. In this embodiment, any funds requests are approved by the manager of the department (Department Head) according to the constraints defined by the administrator in the system setup process.

[0100] The system is a computer-implemented system that administrators and users may access via a data communications network such as the internet or the system may be an application associated with a particular device.

[0101] The system may include separate or stand-alone segments of computer instruction code that provide functional features or elements of the system, or alternatively, the system may include embedded computer processes having computer instruction code therein within one or more external (third party) systems which may offer additional functionality to an external (third party) application. Typical third party applications that are envisaged as being particularly suited for use in or with the system of the present invention include corporate ERP systems, core bank systems, card management systems, customer relationship management systems, foreign exchange management systems and data extraction applications.

[0102] Alternatively, in embodiments where a bank or financial institution supplies the system to existing corporate customers, then the company / organisational details of the primary electronic wallet (company name, company address, administrator details) may be entered into the system via a data import process and / or an application programming interface (API) from a third party system such as a core bank system, card management system or customer relationship management system as used by banks and financial institutions. In such embodiments, the funds in the primary electronic wallet may be a line of credit extended by such a bank or financial institution and the value of the line of credit associated with the primary electronic wallet may be determined through an API between the systems managing the primary electronic wallet and the core bank system as used by the respective bank or financial institution.

[0103] In an embodiment, the system enables the submission of requests for one or more quotations. In such embodiments, the system includes a component configured to accept and store the details of one or more goods and/or service providers; the system further including a component configured to enable an authoriser to enter details of any required goods and/or services and make such details available to any selected goods and/or service providers from which a quotation request would be accepted; the system further including a component configured to enable at least one quotation from any of the selected goods and/or service providers to be accepted and stored within the system, wherein the authoriser either authorises or declines the one or more quotations wherein, upon authorisation of any quotation, the system automatically transfers funds in the amount quoted from the source account containing funds to a destination account.

[0104] In an embodiment, the destination account is associated with the user that submitted the quotation request.

[0105] In an embodiment, the destination account is associated of the goods and/or service provider whose quotation has been authorised.

[0106] In an embodiment, the system is configured to accept details of one or more goods and/or service providers and required goods and/or services using data having a pre-defined (i.e., standardised) format that is selectable by the user.

[0107] In an embodiment, the data is stored according to location (for example the location of a shipping Port) and categories of type of goods / services required and is selectable from a finite list of available options within each category.

[0108] In an embodiment, the details of any payment or tender request or any request associated with required goods and/or services are made available to any selected goods and/or service providers by electronic mail correspondence. However, it will be appreciated that other forms of electronic communication may be used, for example, short message service (sms).

[0109] The system of the invention according to any embodiment may be a single application or alternatively, may be a distributed application. In an embodiment, the system is publicly accessible operating on a secure third party cloud provider platform. However, in other embodiments, the system may be a private application operating on a private cloud or organisation specific data center with restricted user access where the system is accessible to a client such as a bank or financial institution.

[0110] The system interface may be any conventional interface system that operates on a number of devices including, but not limited to, a personal computer, laptop, mobile (smart) phone, iPad or tablet and one that allows an administrator or user to interact with and use the system of the invention. The system interface may also allow authentication of an administrator or user's credentials by requiring the administrator or user to enter, for example, a unique username and password in order to access the system. The system may additionally, or in the alternative, adopt a method using a hardware based randomly generated PIN verification.

[0111] In another aspect, the present invention provides a request and response system including: a payment request device operable to present a graphical user interface to a user and receive details of a payment request and subsequently generate and transmit a payment request message over a communications network; one or more authorisation devices operable to receive payment request messages and present a graphical user interface to an authoriser and receive either approval or rejection of payment requests and generate and transmit payment request response messages over the communications network; the one or more authorisation devices further operable to generate and transmit funds transfer messages over the communications network in the event the authorisation device receives an approval of the payment request; and a funds disbursal system operable to receive one or more funds transfer messages and further operable to transfer funds from a source account to a destination account in accordance with details contained within funds transfer messages, the destination account accessible by the users who caused the generation of payment requests corresponding to the funds transfer.

[0112] In another aspect, the present invention provides a method of requesting authorisation of a payment request, the method including: a user accessing a system through a system interface and entering a payment request for authorisation for the transfer of a monetary amount including one or more details associated with the payment request; the user receiving either an approval or rejection of the payment request, the approval or rejection being displayed on the system interface; and in the event the payment request is approved, transferring funds in an amount corresponding to the monetary amount between a source account containing funds and a destination account accessible by the user.

[0113] In an embodiment, the source account is one or more primary electronic wallets and the destination account is one or more secondary electronic wallets. In a further embodiment the source account is one or more department wallets and the destination account is one or more secondary electronic wallets.

[0114] In an embodiment, the user is able to assign a priority level (for example, low, medium or high) to the payment request. Accordingly, if funds are urgently required, the user may allocate, by the use of an available option on the system interface, a "high" priority to the request. In embodiments, the system may also send a notification to an electronic communications device associated with the one or more authorisers, that a payment request is pending and awaiting authorisation. The one or more authorisers will understand that any payment request allocated a "high" priority is to be immediately reviewed and, if appropriate, authorised.

[0115] In embodiments, the system and method of the invention may also enable a payment request to be allocated a specified time period within which a payment request is to be authorised or declined. In embodiments, the specified time period may be associated with, or automatically allocated on the basis of, the allocated priority level of the request, wherein, for example, payment requests allocated a "high" priority have a shorter time period within which they must be reviewed by an authoriser compared to payment requests allocated a "medium" or "low" priority.

[0116] In embodiments, the system and method of the invention may also automatically send a notification to one or more further authorisers in the event a payment request is not authorised or declined within a specified time period. Such one or more further authorisers may be identified in a list of authorisers entered into the system. For example, the initial notification may be sent to a Department Head for authorisation within a specified time period, for example, three hours. In the event the Department Head does not authorise or decline the payment request within three hours, the system escalates the payment request and automatically sends a notification to the next authoriser higher in the list (for example, the Financial Controller of the Company) with an associated specified time period for authorisation of the payment request, for example, two hours. In the event the Financial Controller does not authorise or decline the payment request within two hours, the system escalates the payment request and automatically sends a further notification to the next authoriser higher in the list, for example, the Company Executive Officer.

[0117] In an embodiment, the system and method of the invention may also predict, as a result of prior payment requests, the one or more authorisers to which the notification of a pending payment request, and subsequent notifications in the event a payment request is not authorised within a specified time period, should be sent to. The system and method of the invention may also be able to predict the priority associated with the request and also the time period within a payment request is to be authorised or declined. Accordingly, in embodiments, there is no need for a user (or system administrator) to specify a priority level, a time period for review, or to whom the payment request should be sent for approval, as the system is able to predict these parameters, on the basis of previous payment requests.

[0118] In an embodiment, an authoriser is able to specify, by the use of the system interface, their availability to authorise a payment request. For example, an authoriser is able to set their availability as "in a meeting" or "not available" in situations where the authoriser is in a meeting, or travelling and hence is in a different time zone, and is therefore unavailable to authorise or decline a payment request. When an authoriser is occupied or otherwise unavailable, the system automatically sends a notification to another authoriser, for example, the next person on a structured (or pre-defined) list of authorisers (or another authoriser as automatically selected by the system on the basis of prior payment requests of similar parameters).

[0119] As an alternative to the use of a specified time period within which a payment request is to be reviewed or the specification of the availability of an authoriser in order to ensure payment requests are promptly reviewed and attended to, the system is able to monitor an associated electronic communications device of an authoriser and is capable of sensing when the communications device is idle or motionless, thereby indicating that an authoriser is either unavailable or unable to attend to a review of a payment request. In such situations, the system automatically sends a notification of the pending request to another authoriser identified in a dynamic list of authorisers, wherein the dynamic list of authorisers is continually and automatically updated by the system on the basis of data collected over time in respect of prior payment requests.

[0120] For example, the system, in an embodiment, is able to sense or detect when an electronic communications device (e.g., a smartphone) is motionless for specified period of time (say one hour) thereby indicating that the authoriser is either not in possession of their smartphone or that the authoriser is otherwise occupied and not using (viewing) their smartphone. In the event the system detects that the authoriser's smartphone is motionless for more than an hour, the system automatically sends a notification of the pending payment request for review and approval to the next authoriser on the dynamic list of authorisers maintained and updated by the system.

[0121] In embodiments, the system accumulates data associated with prior payment requests and is able to predict the time period required for review of a payment request, depending on, the source of the payment request, the time of day, and the monetary amount associated with the payment request. The system is also able to predict, on the basis of accumulated data, the authorisers that have the fastest response times and uses such data to generate a dynamic list of authorisers which the system continually maintains and updates. Accordingly, the system is able to generate a dynamic list of authorisers on the basis of any combination of day/time/location/record of movement of the authorisers' smartphone and route a request for approval to the next authoriser on the dynamic list in a sequential manner.

[0122] In another aspect, the present invention provides a method of authorising a payment request, the method including: an authoriser accessing a system through a system interface and viewing a payment request for the transfer of a monetary amount including one or more details associated with the payment request; the authoriser either approving or declining the payment request, and; in the event the payment request is approved, transferring funds in an amount corresponding to the monetary amount between a source account containing funds and a destination account

[0123] In a further embodiment, the system and method of the invention may be applicable for, general consumer usage. For example, the system may be licensed to a bank or financial institution which can then offer the system as a product to consumers as a way to manage their finances. In this embodiment, it is envisaged that the funds transfer request will be from children or other dependents (the requesters) and the approval process is completed by the parent(s) (as the authoriser). It is further envisaged that the parent(s) would also be able use the "push transfer" function (where there is no request from a requester) in order to transfer funds to destination (secondary) accounts held by children or dependents. This embodiment is envisaged to be useful in managing, for example, a child's allowance (sometimes referred to as pocket money) or for payments made to domestic staff such as housekeeping.

[0124] It will be appreciated that the system and method of the invention desirably allows for faster processing of ad hoc time critical payment authorisation requests and allows for the efficient distribution and tracking of such funds transfers to destination accounts associated with one or more payment transaction devices. This desirably leads to greater financial control and efficiency, higher productivity and reduced pressure, particularly in situations where the transfer of funds between one or more source or primary (central) electronic wallets and one or more destination or secondary electronic wallets (destination account) of an organisation is time-critical to making a payment using a transaction payment device such as a branded network payment transaction device (for example a Visa Card or a MasterCard) linked to the destination account. [0125] In another aspect, the present invention provides a method of requesting authorisation of a payment request, the method including: a user accessing a system through a system interface and entering a payment request for authorisation for the receipt of one or more goods and/or services of interest; the user sending a request for a quotation to at least one goods and/or services provider in respect of the provision of the one or more goods and/or services of interest; receiving one or more quotations including a monetary value from at least one goods and/or services provider in respect of the provision of one or more goods and/or services of interest; the user receiving either an approval or rejection of the payment request, the approval or rejection being displayed on the system interface; and in the event the payment request is approved, transferring funds in an amount corresponding to the monetary value between a source account containing funds and a destination account accessible by the user.

[0126] In an embodiment, the user conducts a search of a database containing records of available goods and/or services providers and their associated goods and/or services, wherein the database includes fields that permit categorisation of goods and/or services according to categories, wherein the categories are defined using standardised text and wherein one or more categories are selectable by the user for use in the generation of the payment request.

[0127] In an embodiment, the system generates a standard electronic mail template for use by the user to submit details of the payment request.

[0128] In an embodiment, the electronic mail includes a URL link that the one or more goods and/or services providers use to enter the quotation.

[0129] In another aspect, the present invention provides a method of managing a payment request for the provision of one or more goods and/or services, the method including: a user accessing a system through a system interface and entering a request for authorisation for the transfer of a monetary amount and one or more details associated with the payment request; the user receiving either an approval or rejection of the payment request, the approval or rejection being displayed on the system interface; and in the event the payment request is approved, allocating funds in an amount corresponding to the monetary amount. [0130] In an embodiment, the user is an individual that provides the at least one good and/or service.

[0131] In an embodiment, the user is an individual that receives the at least one good and/or service.

[0132] In an embodiment, the payment request is received by the user that provides the at least one good and/or service.

[0133] In an embodiment, the payment request is received by the user that receives the at least one good and/or service.

[0134] In an embodiment, the payment request is authorised by the user that provides the at least one good and/or service.

[0135] In an embodiment, the payment request is authorised by the user that receives the at least one good and/or service.

[0136] In an embodiment, the allocated funds are transferred from a source account to a destination account after the provision of the at least one or more goods and/or services and upon the satisfaction of the one or more conditions.

[0137] In an embodiment, the one or more conditions includes transferring the allocated funds upon reaching an agreed date.

[0138] In an embodiment, the one or more conditions includes transferring funds upon the occurrence of a pre-defined event.

[0139] In an embodiment, the transfer of the allocated funds occurs automatically and substantially immediately upon satisfaction of the one or more conditions. [0140] In another aspect, the present invention provides a method of generating a payment request including: a user generating a payment request using a payment request device accessible through a graphical user interface and entering details of the payment request; the user receiving a payment request response message over a communications network including either an approval or rejection of the payment request; and in the event the payment request is approved, the user accessing a destination account containing funds transferred from a source account to a destination account in accordance with details contained within funds transfer message.

[0141] In another aspect, the present invention provides a method of receiving and authorising a payment request including: an authoriser receiving details of a payment request in a payment request message over a communications network; and the authoriser either approving or rejecting the payment request using a graphical user interface on one or more authorisation devices operable to receive payment request messages and generate and transmit payment request response messages over the communications network.

[0142] In another aspect, the present invention provides a method of disbursing funds including: generating a payment request using a payment request device operable to present a graphical user interface to a user and receive details of a payment request and subsequently generate and transmit a payment request message over a communications network; receiving details of the payment request on one or more authorisation devices operable to receive payment request messages and present a graphical user interface to an authoriser who either approves or rejects the payment request, generating a payment request message response wherein the one or more authorisation devices are further operable to generate and transmit payment request response messages over the communications network; and in the event a payment request is approved, generating and transmitting a funds transfer message wherein the one or more authorisation devices are further operable to generate and transmit funds transfer messages over the communications network; and disbursing funds using a funds disbursal system operable to receive one or more funds transfer messages and further operable to transfer funds from a source account to a destination account in accordance with details contained within the funds transfer message.

BRIEF DESCRIPTION OF THE FIGURES

[0143] Embodiments of the invention will now be described in further detail with reference to the accompanying figures in which:

[0144] Figure 1 is a functional flow diagram that shows how an organisation sets up an account for use with the system and method in accordance with an embodiment of the invention.

[0145] Figure 2 is a functional flow diagram directed to various available options associated with a funds transfer request, authorisation process, purchase or ATM withdrawal, reconciliation process and data export in accordance with an embodiment of the invention.

[0146] Figures 3a and 3b are two parts of a functional flow diagram that shows how a user submits a request for an approval of a transfer of funds and how an administrator processes the request to either approve or decline the request in accordance with an embodiment of the invention.

[0147] Figures 4a and 4b are two parts of a functional flow diagram that shows how an administrator authorises a funds transfer from a source account to a destination account in the absence of a user (cardholder) request in accordance with an embodiment of the invention.

[0148] Figures 5a, 5b and 5c are three parts of afunctional flow diagram that shows how a branded network payment transaction device linked to the destination (secondary) account (User Card) is used to make a transaction, how the User subsequently links the transaction to an approved funds transfer request and images a substantiating document such as an invoice or receipt into the record of the purchase transaction and the process of reconciliation of the transaction in accordance with an embodiment of the invention.

[0149] Figures 6a and 6b are two parts of a functional flow diagram that shows how data is extracted from a document image for use during reconciliation of a transaction and also shows how the system automatically performs a cross-check between the initial request value, the actual expenditure amount and the extracted value from the invoice in accordance with an embodiment of the invention.

[0150] Figure 7 is a functional flow diagram directed to a specific embodiment of the present invention showing how the system and method of the present invention can be applied to manage advance salary funds transfers to crew members of a shipping vessel.

[0151] Figure 8 is a functional flow diagram directed to another specific embodiment of the present invention showing how the system and method of the present invention can be applied to manage funds for making port purchases by a Master of a shipping vessel.

[0152] Figures 9a and 9b are two parts of a functional flow diagram directed to another specific embodiment of the present invention showing how the system and method of the present invention can be applied to manage "digital IOU" requests from shipping vessel crew members and personnel.

[0153] Figures 9c and 9d are two parts of a functional flow diagram that is directed to the embodiment of Figures 9a and 9b, however the digital IOU in this embodiment is managed with a QR code.

[0154] Figure 10 is a functional flow diagram that is directed to another specific embodiment of the present invention showing how the system and method of the present invention can accommodate and manage vendor quotations with specific reference to the shipping industry.

DETAILED DESCRIPTION OF THE EMBODIMENT(S) OF THE INVENTION

[0155] For convenience, the invention will be described with respect to a particular embodiment, however it will be appreciated by those skilled in the art that the invention is not limited to this particular embodiment.

Account Creation within an Organisation

[0156] In an embodiment, the system and method of the invention supports a Small Business configuration with a single administrator source account (or primary electronic wallet) with one or more destination (Cardholder) / secondary accounts. The system and method of the invention according to an embodiment also supports an Enterprise configuration with one or more administrator source accounts (or primary electronic wallets) and a plurality of Department level destination accounts (which in this embodiment act as source accounts for funding the request for transfer of funds for proposed expenditure transfers that are approved by the Department Head) in addition to a plurality of User (Cardholder) accounts.

[0157] With reference to Figure 1 , in order to register an Organisation and create an account, a system administrator in step 101 navigates to the system website using the internet, a smartphone or an Application or, alternatively, the Organisation may upload the relevant system files in order to create various user (e.g., employee) profiles.

[0158] With further reference to Figure 1 , the registration process includes the following steps:

• Creation of an administrator username and password (refer to step 103)

• Entry of corporate (company) details including corporate name, address/telephone number, Website URL) (refer to step 103)

• Registration of administrator details including first name, surname, title, email address and mobile telephone number (refer to step 105)

• Upload company documents to meet "Know Your Customer" requirements and administrator ID (refer to step 107) • Validation through generation and receipt by administrator a one-time PIN (OTP) to mobile which must be entered by the administrator in order to complete the validation step (refer to step 109).

[0159] In step 1 11 , the administrator requests payment devices (cards) for all Users. This will require the administrator to select the number of secondary accounts with the linked payment transaction devices (credit or debit cards) required, and to enter the employee (User) details including the employee's first name, surname, title, email address and mobile telephone number. Where the secondary account of the user and/or the linked debit or branded (e.g., Visa/MasterCard) network payment device is being used to manage expenditures mainly in association with a specific company asset or company project, then the administrator may enter an Asset or Project Name and an Asset or Project Code to the record of the User in the system and this Asset or Project Name and Asset or Project Code is displayed at various times in the system including when the Authoriser views the Approve Request screen to make it clearer that the proposed expenditure is in association with a specific company asset or company project. The administrator will also have to enter a government issued Identification (ID) numbers for all Users. This creates secondary accounts in the system. Once the user registration step is complete, the system will notify the administrator (by email) and confirm the following information: Organisation name, administrator name, quantity of secondary accounts (cards) ordered and the names of the individual Users (Cardholders)

[0160] In step 1 13, the administrator sets up user account profiles and constraints associated with the account at the organisation, department and user account levels. Users may be set up either as Standard Users having limited access and little or no privileges or Department Head Users wherein broader access and approval privileges may apply.

[0161] The administrator may also set up a Department (wallet) account(s) where authorisation of any transfers from the Department wallets to destination (Cardholder) accounts (where the destination user account is setup as a Department User) is controlled by a Department head. [0162] During the account set up, an administrator may configure the system to recognise Users as either Direct Users (wherein any User requests are submitted to the administrator for authorisation) or Department Users (wherein Users are under the Hierarchy of the Department Head and any funds transfer requests are submitted to the Department Head for authorisation). Subject to the configuration of any constraints set up within the system, the request may be authorised by the Department Head only or require secondary authorisation from the administrator. When the request is authorised, the funds are transferred from the department wallet to the secondary account belonging to the user making the request.

[0163] An administrator may also configure various constraints during the account set up to support automatic authorisation of funds transfer requests as required. These constraints may be configured to apply at different levels within the Organisation, for example, at the User level, the Department level or the Organisation level.

[0164] Examples of constraints include "forward to administrator for manual approval", "forward to Department Head for manual approval" or "dual authorisation (e.g., administrator and Department Head) required for approval" or "auto-approve request based on a pre-set approval limit". Typical "approval" parameters include, but are not limited to:

• Count - number of funds transfer requests;

• Amount - "trigger" funds amount above which manual approval is required

• Period - Daily, Weekly or Calendar Month.

[0165] Any approval parameters that are set may be saved as a template and applied to other or subsequent User set ups.

[0166] An administrator may also configure currency wallets available as subaccounts on each secondary user account by selecting the list of currency wallets available on cards from a pre-set system master list of available currencies.

[0167] In an embodiment, the system includes one or more source accounts associated with a plurality of currency wallets wherein the Company administrator manages the conversion of funds from a base currency (e.g., USD or Euro) to other currency wallets within the primary electronic wallet (or source account). In such embodiments, it is the Company's responsibility to maintain sufficient balances in each currency wallet to meet requests in these currencies substantially instantaneously (as the funds are already converted prior to the request being made).

[0168] Further in step 113, the system may also include "usage type check" parameters on the type of card usage permitted, where the administrator may set parameters that manage restrictions on individual users (cardholders) and what POS purchase, ATM withdrawal and/or online purchase activity is permitted and will be successfully authorised. Such "usage type check" parameters are managed via communication interfaces between the system and the external transaction processor that authorises payment transactions completed with payment transaction devices linked to the destination account and/or platforms to manage POS / ATM Internet "usage type check" parameters provided by the relevant payment network system (e.g. Visa/MasterCard etc).

[0169] In step 1 17, the administrator may also configure some of the data fields of the Request Form and configure the menu items available in various data fields in the Request Form (Menu Item Configuration). This may be achieved through defining labels for available user definable fields in the Request Form and defining menu items to populate drop down menus in available user definable menu items. Included in this process the Administrator may enter or upload a set of Chart of Accounts codes used by the organisation (in the organisation's general ledger accounting system) to enable expenditure items processed through the system to be classified correctly to the relevant Chart of Account code in the transaction reconciliation process. The system will export the Chart of Account Codes selected in transaction reconciliation process, together with other transaction details, in various formats for the organisation to import into their accounting or ERP systems for reconciliation and audit purposes and use to match up expenditure items processed through the system to the correct Chart of Account Codes in the organisation's general ledger accounting or ERP systems. The above steps trigger the population of the Data Field Label & Menu Item system configuration.

[0170] The system also allows any constraints defined within the system and User accounts to be updated and amended during, or at any time after the initial set-up of the system account and registration. Changes to defined constraints or other configuration settings affecting user accounts or the system in general, trigger audit log events and these trigger App notifications via email or the App to the Administrator

[0171] In step 119, the system also has a process to manage Know Your Customer (KYC) where any information and documents uploaded may be manually reviewed and / or processed against records of the Office of Foreign Assets Control (OFAC). The system also forwards customer data and document images to a third party system for automated validation against known third party databases in order to manage the Know Your Customer requirements.

[0172] In step 121 , the administrator manages a push transfer process from the organisation's bank account where the administrator of the organisation's bank account creates an instruction in the organisation's bank account system to debit the bank account and transfer the funds to the bank account holding the funds of the combined primary electronic wallet balances (referred to as the "float account"). The administrator uses a system generated unique reference number (URN) to populate a field in the instruction submitted to the bank that appears in the record of the transfer in the statement of the float account.

[0173] In step 123, the managers of the system review the statement(s) of the float account(s) and using the URNs that are identified on the statement of the float account then identify each transfer successfully credited to the float account(s) and credit these values to the respective company's primary electronic wallet.

[0174] Once the Organisation account has been created and all Users have been registered, embodiments of the system and method of the invention provide a system administrator with a number of options by which funds may be requested and transferred from a source account (electronic wallet) to a destination (Cardholder) account. Various embodiments of the system and method of the invention also provide functionality that imparts additional security and allows for more efficient processing of requests for approval of proposed expenditures, approvals of such requests, effecting the payment using a linked payment transaction device and the associated reconciliation of these business payment transactions. The system and method according to an embodiment of the invention will now be described with reference to Figures 2 to 6b.

[0175] Embodiments of the invention also enable funds transfers in different currencies to be handled. In this regard, the system allows various sub-accounts to be created within an account, for example a source account, where each sub-account deals in funds transfers of a certain currency. Such sub-accounts with different currencies are termed "currency wallets" throughout the specification.

[0176] Accordingly, in an embodiment, the system allows funds of a selected currency to be transferred from a currency wallet associated with source account to a currency wallet associated with a destination account, wherein the currency wallets associated with the source and destination accounts deal in the same currency.

[0177] Accordingly, when a user submits a request for approval of a payment, the user may select the desired currency of the request in the request form. As part of this process, the system identifies within the request form the currency wallets available at the source level. When an authoriser reviews the request, the authoriser is able to view the value of the request, the desired currency and the balance in the currency wallet in the source account that matches the currency of the request. When the request is approved, the debit is to the currency wallet in the source account and the credit is to a matching currency wallet associated with the destination/secondary account. By the use of currency wallets to transfer funds, delays associated with currency conversions are avoided, and substantially automatic transfer of funds between accounts is able to be achieved.

Cardholder Request and Authorisation Process, Administrator Value Credit Transfer Process (without Cardholder Request), Purchase, Full Cycle Reconciliation, Activity History and Data Export

[0178] Figure 2 shows a high level summary of the end to end process from creation of a request through to completion of reconciliation process and data export.

[0179] At step 201 , a user (for example a company employee) submits a payment request for the manual approval of a funds transfer by Department Head 203, and/or an administrator 205 and/or by automatic approval according to the constraints (funds transfer limit) set by an administrator 207.

[0180] Instead of a payment request in respect of a proposed expenditure being initiated by a user such as, for example, an employee, a payment request may be initiated by the authoriser (for example, a Department Head or administrator) in the absence of an employee request. This is known as a "push transfer". Steps 210 - 216 show a push transfer that is described in further detail in Figure 4.

[0181] Following either i) the approval of a request for transfer by a user or ii) the initiation of a "PUSH" Transfer with no request for transfer by a user, then step 218 shows the process of debiting the value of the proposed expenditure from the Primary Electronic Wallet (Source Account) and crediting to the Secondary (Destination) Account (Card).

[0182] Prior to using the card for a purchase or ATM withdrawal, the user must unlock the card in step 220. The user unlocks card using the Mobile App or by logging into the website, to change the status of the card (or payment device) linked to the secondary account from locked to unlocked. The system does this by either i) sending a message to the external transaction processor that authorises branded payment network transactions completed with the payment card (payment device) via communication interfaces between the system and this platform (where this external transaction processor may belong to the issuing bank or a third party) and/or ii) platforms to manage POS/ATM Internet "status type check" parameters provided by the relevant branded payment network (e.g. Visa / MasterCard etc.).

[0183] Having unlocked the card, then the user (Cardholder) is able to use the transaction payment device (Card) associated with the destination account in step 222 to make a purchase at a Point of Sale (POS), Automatic Teller Machine (ATM) or an internet (online) purchase.

[0184] Once a purchase has been made, the system includes the security feature of automatically locking card by changing its status from "unlocked} to "locked" in step 224 so that any authorisation request will be declined when the card is in a locked status. In order to change the status of the card from "unlocked" to "locked", the system detects the data transaction in a data feed from the external transaction processor to the system and when the system detects a purchase transaction/ATM withdrawal in the data feed, then the system generates a message to change status from unlocked to locked and sends this message to either i) the external transaction processor that authorises branded payment network transactions completed with a payment device via communication interfaces between the system and the platform (where this external transaction processor may belong to the issuing bank or a third party) and/or ii) platforms to manage POS/ATM Internet "status type check" parameters provided by the relevant branded payment networks (e.g. Visa / MasterCard, etc.).

[0185] The system in an embodiment also includes additional process stages in the user linking the details of a completed transaction to the approved request and displaying all of the data for the transaction and the linked approval on the transaction statement for the secondary wallet. These additional process stages are shown in greater detail in Figure 5.

[0186] Step 232 relates to the use of an Activity History function by a user in order to access previous activity in the system. The Activity History or Activity Reporting function is a menu item that lists all events in time order for the user. This function is also available to the administrator/authoriser to see global transaction activity relevant to each user's secondary account. The Activity Reporting information can be searched or re- filtered by the user (using a "Show related" icon) to display all the events related to a single transaction e.g. the request for approval of the proposed expenditure, the imaged quotation, the approval by the authoriser, any chat comments (if applicable), the purchase transaction or ATM withdrawal, the linking by the user of the relevant approval to the transaction, and then the imaging of the document e.g. the invoice to the transaction record.

[0187] In step 240 all activity, data, and documents imaged are available for export from the system to the organisation's ERP / accounting systems for reconciliation / audit.

Request for transfer of a funds amount by a User (Cardholder) and Request Approval Process [0188] With reference to Figures 3a and 3b, the request for funds transfer may be completed in step 301 by an application existing on, for example, a user's smartphone, iPad or tablet, or a user may submit the funds transfer request through a website.

[0189] In order to submit a funds transfer request, a user completes an electronic Request Form in step 303 and enters data according to, but not limited to, the following fields:

• Currency (preferred currency is selected from a drop down menu where the preferred currency may be set as a default). The list of currencies is as configured by the administrator in the setup of the system;

• Amount;

• Purpose;

• Purchase Order Number (PO);

• Priority Level (may be selected from "Urgent" or "Normal" where "Normal" is the default);

• Location (Port etc.,) from drop down menu. The list of ports is as configured by the administrator in the system setup where the administrator selects the relevant ports to the operations of the Company from a global list of ports pre-supplied with the system.

• Project (from drop down menu set by Administrator)

• Category (from drop down menu of categories of types of goods / services). The list of categories of types of goods / services is as configured by the administrator in the system setup where the administrator selects the relevant categories of types of goods / services that are relevant to the operations of the Company from a global list of categories of types of goods / services pre-supplied with the system.

• Type of transaction (Purchase, ATM, Online, or ALL),

• Transaction Count - Single / Multiple (number of transactions a user expects to incur for value requested where a user would specify "single" where the requested value is for a single transaction purchase and "multiple" where the requested value is for multiple transaction purchases such as a business trip).

• Attached Document Image (optional) of Quotation, Pro-Forma Invoice or Invoice to be paid (enable camera & defined image capture process) • Document Description from drop down (select invoice, Quotation, Receipt, Add own description), (Option is greyed out until document attached).

• Add Document Number (i.e., Quotation Number etc.)

• Select Chart of Account Code to classify proposed requested expenditure

• Payment Date (payment required by date)

• Vendor

• Select Department from drop down menu of Departments. The list of Departments is as configured by the administrator in the setup of the system.

[0190] In embodiments, the system allows payment requests to be submitted by Users that are not associated with and / or setup within a specific company department. For example, an employee in the Engineering department of the company is able to submit a payment request from the Maintenance Department and / or an employee of the company such as the shipping vessel Master is able to submit a payment request and route that payment request to the department relevant to the payment request for approval. Accordingly, in an embodiment, the system interface permits the selection of a department from a drop down menu of all available departments. The system may be configured so that the selection of a department in the request is mandatory. Once a department has been selected and the payment request is submitted, the request is forwarded to the selected department for approval.

[0191] In embodiments, the system is able to accommodate the setting and management of constraints by which an administrator or Department Head may set spend limits and any other business requirements including the type of approval that must be sought and obtained in order to effect a transfer of funds from a source account to a destination account. In an embodiment, any defined constraints may be set at a user level. With reference to step 305, various constraints that are contemplated within the scope of the present invention include, but are not limited to:

• Forward to administrator for Manual Approval,

• Forward to Department Head for Manual Approval

• Auto approval based on pre-set approval limits (examples of approval limit parameters are Count and/or Amount; time period (e.g., Daily/Weekly, Sunday to Saturday week, or Calendar Month). The values of these limit parameters are set by the Administrator in step 1 13 (see Figure 1 ) is the Account Creation Process. In embodiments, various sets of configured limits may be saved as a template and applied to other Users for use in subsequent funds transfers.

• Requirement for dual authorisation where system forwards request to Department Head for Authorisation and then forwards that Authorisation to administrator for secondary Authorisation.

[0192] Accordingly, a system administrator may create pre-configured requirements so that any requests are forwarded to an administrator for manual approval. Once a request is forwarded by the system to the relevant Authoriser (either the Administrator and/or the Department Head according to defined constraints), the request triggers the system to generate a notification to the relevant Authoriser according to step 307. The notification may be sent to the Authoriser in an application on the Authoriser's smartphone, or may appear as a notification on a website associated with the system or may even send a text message by Short Messaging Service (SMS) or an email to the Authoriser and the requesting user. In this embodiment, the notification appears on a website that that the Authoriser accesses on their computer. The App Notification generated by the system has summary details of the request that is now pending approval so that the Authoriser may quickly understand who the request is from and the priority of the request. Simultaneously in step 310, a counter in the Approvals Menu item on the Authoriser's home screen shows an incremental pending request queued for approval by Authoriser and a counter in the Request Menu item on the requesting user's system mobile app home screen shows an incremental pending request queued for approval by Authoriser.

[0193] In step 309 the Authoriser may select the App Notification on their smartphone and this automatically loads the relevant request and presents the Approve Request screen for approval of the request by Authoriser. Alternatively in step 312 the Authoriser may select the Approvals Menu item on the mobile app home screen on the Authoriser's smartphone. When the Authoriser selects the Approvals Menu item the system mobile app (or website) in step 314 displays the Select Approval screen which displays a listing of all pending requests for approval with summary details (Request Date, Priority, Currency, Amount, Purpose, & Project) of each request. [0194] During the approval process in step 316 (refer to Figure 3b), the system displays a request approval (authorisation) screen to the administrator or Department Head for manual approval of the funds transfer request. The request approval (authorisation) screen may display the following fields:

• The available balance in the source account currency wallet and destination account (user or cardholder account); and

• All Request fields as entered by the user (card holder) during the creation of the funds request in step 303. The request fields may include, but are not limited to the funds request amount (with currency displayed), the intended purpose of the requested funds, the priority level of the request and, optionally, any supporting documentation such as an image of a quotation or an invoice to be paid.

[0195] The authoriser can view or enlarge the document image in the Request form (Quotation, Pro Forma Invoice/Invoice) and the system also displays i) the value of the request in the currency requested by user in step 303 and ii) the value of the request (from (i) above) converted to the value of the request in the currency of the primary electronic wallet which is the source account containing funds that are controlled by the Authoriser.

[0196] Where the secondary account (destination account) has multiple different currency sub-accounts then, as a preparatory process to step 316, the system requests a current foreign exchange cross rate for the conversion between the request currency and the source account primary wallet currency and adds a customer specific margin and uses this consolidated rate to convert the currency values. The request for the current foreign exchange cross rate is managed through a request process from the system to a third party foreign exchange management platform that responds and supplies current foreign exchange cross rates to the system.

[0197] As exchange rates are constantly changing, the system manages a holding the rate for a period of time (for example 90 seconds) and advises the authoriser of the period remaining of this period when the rate is being held. This advice of the period remaining is displayed within the authorisation screen. At the end of this period the system requests a new / current exchange rate and re-converts the requested value to the source account wallet currency using the new rate. The new value is then updated and is displayed for viewing by the authoriser in the request authorisation screen.

[0198] In steps 318 and 319 of Figure 3b, the Authoriser (e.g., administrator or Department Head) makes a selection regarding the approval (or otherwise) of the funds transfer request. In an embodiment, the Authoriser may make one of the following selections:

• Approve Request (with no change) - select blue Approve button with a tick icon,

• Approve Request (with change) - Authoriser manually edits value of request so it is less than the wallet balance and approves by blue Approve button with a tick icon,

• Suspend request and set a reminder to remind the Authoriser of a pending authorisation of this request (reminder is managed within the system),

• Decline Request - select Decline button/icon (with optional field to complete a reason regarding the reason for declining the request). This field may be retained for audit purposes and may be communicated via App Notification to the user (cardholder) that made the request),

• Open Chat - the Authoriser opens chat process to ask questions about the request for authorisation of proposed expenditure. The chat process in the system manages the Authoriser directing questions to the user making the request and also the responses from the requesting user. This chat process is linked to the specific request.

[0199] Where the request for funds transfer is declined, then the user (cardholder) may change details of the request by entering further or amended data into the request form data fields and select "Resubmit" to resend the amended request to the Authoriser.

[0200] If the value of requested funds is greater than the available funds in the source account, then in step 319 the administrator is unable to make a selection to approve the funds request. In an embodiment, this is achieved by disabling an approval button with a tick icon (used for confirmation of the approval) and the system displays a message "Request Value [currency and amount inserted at this point within the message] is greater than the available source account balance - re-load source account". In the message the symbol ">" may be used instead of the words "is greater than". The system provides the administrator authorising the request with the ability to suspend the approval (using a suspend function) until further funds have been credited to the primary electronic wallet which is the source account as per step 123 (refer to Figure 1 ).

[0201] On completion of the review process, the system forwards a notification to a User (Cardholder) in step 320 of the outcome (Approval, Decline, or Request Changed) of any review performed by an Authoriser (administrator or Department Head).

[0202] In the instance where a request has been approved, then the system in step 322 debits the requested (and approved) value from the source account (wallet) and credits the destination account (card) with this value. When the requested proposed expenditure is in a currency that is different to the currency of the source account then the system debits the value of the requested expenditure from the source account in the currency of the source account and credits / transfers the converted value to the respective matching currency specific sub-account of the destination account of the user thereby providing the necessary funds for the purchase in the currency requested. As per step 316 the conversion of the value of the requested expenditure in the currency of the request to the currency of the source account is managed using the current foreign exchange cross rate obtained by the system (from the specialist foreign exchange third party platform service) plus a system applied customer specific margin and the system uses this consolidated rate to convert the currency values.

[0203] Whilst not shown in Figure 3b, an additional step may follow from step 322 where the system manages the conversion of values of proposed expenditures that are in a currency that is different to the currency of the source account, and the Authoriser approves such a request, then the system sends a message to the third party foreign exchange management platform to execute a trade buying the value of the requested proposed expenditure in the currency of the requested proposed expenditure and selling the value of the requested expenditure in the currency of the source account. The conversion between these two values is done at the spot foreign exchange cross rate supplied to the system (from the specialist foreign exchange third party platform service) plus a system applied customer specific margin and the system uses this consolidated rate to convert the currency values. [0204] The user (cardholder) is notified of the credit value transferred to the destination account (card) (by App/SMS/email) and may also include information/data from the original request including the amount requested, the intended purpose of the funds, the transaction count and details of any variance to original requested value.

[0205] According to step 324 of Figure 3b, a User may amend a funds request and select "Re-submit". As an example, the user (cardholder) may recall any prior request from the Activity History function and modify and select as appropriate and then elect to resend the request to the Authoriser by selecting the "Re-submit" button.

Funds PUSH by an Authoriser (e.g. administrator or Department Head)

[0206] The system and method of the invention according to an embodiment also contemplates the ability of an Authoriser, such as an administrator or Department Head, to initiate a funds transfer in the absence of a user (Cardholder) request (refer to step 401 in Figure 4a). This process is known as a "PUSH" of funds in which an Authoriser proactively creates a transfer instruction in the form of a Transfer Form and transfers credit value from a source account to a destination account such as a user card or department wallet.

[0207] As outlined in step 210 of Figure 2, in order to "PUSH" an amount of funds the Authoriser selects a destination account (e.g., a user card account) to which an amount of funds is to be transferred from the source account to the destination account.

[0208] With reference to Figure 4, in step 403, the Authoriser selects a Secondary / Destination Account (Cardholder) by entering the Cardholder's full or partial first name and/or surname or Asset / Project Name or Asset / Project Code into a search field. The system will conduct a search of all Secondary / Destination Accounts (Cardholders) maintained in a database and the system will display the full name and title of the matched Cardholder name and any associated Asset / Project Name or Asset / Project Code of the selected Secondary / Destination Account.

[0209] The available balance on the source account and destination (Cardholder's) account is displayed to the Authoriser (refer to step 405). [0210] In step 409, the Authoriser completes a Request Form and enters the amount of funds to be transferred from the source account to the destination (Cardholder's) account. The Authoriser must also enter any required information including the intended purpose and any associated project of the requested funds any supporting documentation such as an image of a quotation or an invoice to be paid. The system in an embodiment further includes:

o Purchase Order Field wherein the Authoriser may enter details of a purchase order invoice number

o Type Field (Purchase, ATM, Online, or ALL),

o Transaction Count Field: Single / Multiple (transaction number user expects to perform for value requested),

o Attach Document Image Field (optional) of Invoice to be paid,

o Document Description Field (ability select Invoice, Quotation, Receipt from drop down list),

o Document Number Field,

o Account Code Field.

All of the above information is visible to the user when the user lists approvals (including the above push transfer instructions) described in step 509 in Figure 5a and allows the user to link the approved request transactions or push transfer transactions to the spend transaction.

[0211] The system also supports in embodiments multiple approved request transactions or push transfer transactions processed to the user's destination account and a specific approved request transaction or push transfer transaction needs to be selected and linked to a specific purchase transaction.

[0212] In an embodiment, the system also provides additional security for any funds transfer requests above a certain transfer value (i.e., a "trigger" value) wherein the system is configured to generate and forward a "One Time Password" (OTP) by an SMS/email/App Notification to the Authoriser (refer to step 409 of Figure 4b). The trigger value may be set at a user or organisation level and before any funds transfer requests above the trigger amount are able to be processed, the Authoriser will need to confirm the transaction by entering the OTP into the system. [0213] With reference to Figure 2, once the OTP has been correctly entered and/or the funds transfer is approved by a Department Head 212 (where such approval optionally undergoes and passes an additional automatic approval process as set by the administrator 216) or approved by an administrator 214, then the source account is debited in an amount of funds that have been requested and the destination (Cardholder) account is credited in this amount in step 218. See also step 41 1 in Figure 4b. As set out in step 41 1 , where the Destination Account has multi-currency sub-accounts and the transfer value is in a currency different to the Source Account, then the currency exchange processes outlined in the description of the steps in Figures 3a and 3b apply to the process. The system then automatically forwards an email, SMS or App Notification to both the Authoriser of the Request and the Cardholder that received the funds (see step 413 in Figure 4b).

Secondary Account (Card) Usage, Post-Purchase Linkage & Full Cycle Reconciliation

[0214] With reference to Figures 5a, 5b and 5c, once the destination (Cardholder) account has been credited with value (refer to step 501 ), and the user has unlocked the card as per step 220 of Figure 2, then the user (Cardholder) is able to use the account (Card) in step 503 to make a purchase at a Point of Sale (POS), Automatic Teller Machine (ATM) or an internet (online) purchase (Refer also to step 222 of Figure 2).

[0215] The system may have additional "usage type check" functionality to manage the types of transactions permitted with an account card, for example, whether an ATM transaction is permitted with the card. Refer to step 1 15 of Figure 1 where the administrator can set "usage type check" parameters on card usage that manage restrictions on individual users (cardholders) and what POS purchase, ATM withdrawal and / or Online Purchase activity is permitted and will be successfully authorised. Accordingly, once the intended usage of the user (Cardholder) passes a "usage type check" in step 503 and the user completes the transaction, the next step involves the reconciliation of the transaction with the original request.

[0216] Still referring to Figure 5a, once a purchase transaction has been completed, the system in step 505 sends a transaction alert (by an App Notification, email or by SMS) to both the Cardholder who completed the transaction and also the Authoriser who authorised the funds transfer request.

[0217] The system, according to an embodiment, also allows an administrator to set up alerts to be automatically forwarded to the Authoriser/administrator as a reminder to ensure the reconciliation process of the purchase is completed. Such alerts will continue to be sent to the Authoriser/administrator until all the stages of the reconciliation process of all purchase transactions relating to a particular authorised expenditure have been completed.

[0218] Referring to step 507, the system will also send a reminder to the Cardholder (by App Notification, SMS or email) to Link Approval (link the purchase transaction just completed by the user to the Approved Request that transferred the funds, used in the purchase transaction, from the source account to the destination account and upload image(s) of any documentation associated with the purchase, for example, a receipt or invoice from the transaction. In this regard, any number of images may be uploaded by the user in support of the transaction where the first image may be a quote and the second image may be the actual receipt or invoice.

[0219] In order to complete the reconciliation, the User (Cardholder) in step 509 of Figure 5a, uses the system to link the transaction (e.g. the purchase transaction or ATM withdrawal) to the original approved funds transfer request or administrator PUSH transfer.

[0220] With further reference to step 509 in Figure 5a (refer also to step 228 of Figure 2), the user (Cardholder) navigates to the Statement section of the system and finds (and selects) the relevant purchase transaction. In order to assist with the navigation of the Statement section of the system, the Statement is able to be searched according to various filter inputs including, but not limited to time (date), accounts (wallets or currency specific wallets on multicurrency cards), and status (e.g., "All status", "Pending Link Approval", "Pending Image Document").

[0221] Upon selection of the relevant purchase transaction with reference to step 509 of Figure 5a, the following information may be displayed: • The financial transaction details;

• Transaction location and time: (ATM name; date and time captured in the system according to any desired time-zone depending on organisation/user/customer preference; country code of country in which transaction occurred; Merchant category code, ID and/or name.

• Transaction response type i.e., Approved or Declined

• Local Transaction Time; and

• Mobile Location at time of purchase / ATM transaction.

[0222] A "Link" icon will also be displayed for selection by a User in order to link (or otherwise associate) a specific purchase transaction with an approved funds amount as will now be further described.

[0223] Once the user selects the "Link" icon in step 509, the screen displays a list of funds transfer requests that have been approved. Included in this list of approvals are all of the approved "Request for Transfers" and "PUSH Credit Transfers" where each approval has a status of either i) Unmatched and Open (where a Link Approval has not been completed to link the approved request transaction or push transfer transaction to a purchase transaction and where Transaction Count = Single) or ii) Matched and Open (where one or more Link Approvals have been completed to link the approved request transaction or push transfer transaction to one or more purchase transactions and where Transaction Count = Multiple). The user selects the relevant "Approved Request" or "Push Transfer" and this displays all data from the Approved Request or Push Transfer. The user then confirms the selection and this links the selected "Approved Request" or "Push Transfer" to the Purchase Transaction previously selected above.

[0224] A final process in step 509 is where the system displays a menu function to allow the user to "close" the approved request transaction or push transfer transaction where the approved request transaction or push transfer transaction that has just been linked has a "Transaction count" field value of "Multiple", and the user has already linked a purchase transaction or ATM withdrawal to this approved request transaction or push transfer transaction. This is relevant where an approved request transaction or push transfer transaction has a "Transaction count" field value of "Multiple" and for these types of approved request transactions or push transfer transactions then the user will progressively link the same approved request transaction or push transfer transaction to multiple purchase transactions / ATM withdrawals.

[0225] When the user has completed the reconciliation process for all of the purchase transactions that are to be linked to the relevant approved request transaction or push transfer transaction ("Transaction count" field value of "Multiple"), then the user selects the menu function to "close" the approved request transaction or push transfer transaction. By selecting the menu item to "close" the approved request transaction or push transfer transaction, the user is informing the Authoriser that there are no more purchase transactions to link to the approved request transaction or push transfer transaction. Thus where an approved request transaction or push transfer transaction is for, for example, a business trip that will involve multiple purchase transactions and / or multiple ATM withdrawals then, when the user has completed linking all the purchase transactions and/or ATM withdrawals that were completed on the business trip, the user selects the menu item to "close" the approved request transaction or push transfer transaction. Prior to the user selecting to "close" the approved request transaction or push transfer transaction, and where the relevant approved request transaction or push transfer transaction has a Transaction count" field value of "Multiple", then the status of this approved request transaction or push transfer transaction will be "open". When the User selects "Link Approval" and the screen then displays all "Approved Requests" and "Push Transfers", the system will not list approved request transactions or push transfer transactions with a Transaction count" field value of "Multiple" or "Single" and a status of "closed". Further, where a user has already linked a purchase transaction or ATM withdrawal to an approved request transaction or push transfer transaction with a Transaction count" field value of "Single" then the system automatically sets the status on the approved request transaction or push transfer transaction to "closed".

[0226] According to step 51 1 of Figure 5a, the details of the purchase transaction/ATM withdrawal and the original Request Form/Transfer Form (as applicable) is displayed with all the data fields populated as originally entered by the Cardholder (or administrator in the case of a push transfer request) and which have already received approval and therefore, may not be edited/updated or otherwise amended by the User. [0227] Additional fields will also be displayed including, but not limited to, the actual value of the purchase transaction/ATM withdrawal which is auto-populated from the Statement.

[0228] Once a Cardholder's approved request (or push transfer) has been linked to a purchase transaction (or ATM withdrawal), the User is then returned to the Statement section of the system in step 513 of Figure 5b (also refer to step 230 of Figure 2) where the relevant purchase transaction record will now display a linked approval (identified in embodiment with a Green tick icon).

[0229] Following the user successfully completing the Link Approval process, the system Statement will now display a prompt (i.e., an "Image Document" prompt) on the relevant transaction record for the user to upload any supporting documentation of the purchase with an image of, for example, an invoice or receipt (refer to step 515).

[0230] With reference to step 515 of Figure 5b (also refer to step 232 of Figure 2), the User (Cardholder) selects the "Image Document" prompt and the system activates a camera in the Cardholder's device, for example a smartphone, iPad or tablet, that enables the capture of one or more images of any supporting document(s) (e.g. receipt, invoice) which is/are attached to a transaction record located within the system. The system also prompts the User (Cardholder) to select a description (refer to step 517 of Figure 5b) of the document image(s) uploaded to the system in response to which the user may select, from a drop down menu of available options, an appropriate description including, but not limited to, "Receipt" or "Invoice". It will be appreciated that the menu items in the screen interface shown in step 517 may be standard descriptions and may also include any customised descriptions created by the Organisation administrator. The user may also enter a document number (i.e., an invoice number) in the document number field. Once a description of the uploaded documents is complete, the user is returned to the Statement/History screen (i.e., "Transaction History") in step 521 and the relevant purchase transaction record now displays a status "Document Imaged" (identified in the embodiment shown in step 521 with icons of a tick and image beside the relevant purchase). [0231] Where a user either i) fails or forgets to link an approval or ii) having successfully completed the link approval process then fails or forgets to complete the process of imaging a document (invoice or receipt) into the relevant transaction record, then the system will generate reminders to prompt the user to complete the above required steps (link approval and/or image document) and will send these reminders to the user via App notifications/SMS/emails. These reminders of the actions required by the user will also be sent to the Authoriser and populate exception reporting to facilitate follow up by management to ensure that the user complies with the requirements of the system.

[0232] Alternatively, organisations may also configure their systems to allow data to be extracted from any image uploaded (refer to step 519 of Figure 5b). It will be appreciated that this may avoid the need to manually enter a description of a transaction document (e.g., receipt or invoice) and the document number as is described with reference to step 517. Alternatively the process to extract data from document images is managed as an additional step to the manual entry of a description of a transaction document (e.g., receipt or invoice) and the document number.

[0233] Steps 525, 527 and 529 as shown in Figure 5c describe the process where, following a purchase transaction (or at any time), an Authoriser can move a remaining (unrequired) balance from a destination account back to the source account (primary wallet). In step 525 the system sends a Wallet Value Retrieval Alert (via App notification / SMS / email) after a purchase transaction to the Authoriser. The alert displays the "Balance on Destination Account (Users Card)" after a purchase transaction. The system will typically send this Wallet Value Retrieval Alert to the Authoriser where a purchase transaction has just been completed and the status of the approved request transaction or push transfer transaction is "closed".

[0234] In step 527, where the transaction currency is the same as the card Wallet currency (the specific currency sub-account of the destination account) then the system allows the Authoriser to retrieve the total of the balance on the card Wallet. In step 529, where the Transaction currency is different to the card Wallet currency (the specific currency sub-account of the destination account) then the system adds a surcharge percentage to the original transaction value (to cover changes in settlement value from foreign exchange conversion fluctuations) and allows the Authoriser to retrieve the balance of the card Wallet less the surcharge value to the Wallet.

[0235] Where an Authoriser transfers a remaining balance from a destination account / sub-account that is in a currency that is different to the currency of the source account, and when the Authoriser initiates such an instruction, then i) the system requests a current foreign exchange cross rate for the conversion between the currency of the destination account / sub-account and the source account primary wallet currency, ii) adds a system applied customer specific margin, iii) the system uses this consolidated rate to convert the currency values, and iv) sends a message to the third party foreign exchange management platform to execute a trade selling the value of the requested transfer in the currency of the destination account / sub-account and buying the value of the requested transfer in the currency of the source account. The system then debits the value of the balance remaining on the destination account / sub-account and this value is converted into the currency of the source account and credited to the source account (primary electronic wallet).

Document Data Extraction, Updating Request and Transaction Record, and Automatic Cross Check of Request Value to Transaction to Extracted Total Value of Invoice

[0236] With reference to Figures 6a and 6b, step 601 shows either a user (Cardholder) or an administrator (step 604) (PUSH transfer) submitting a request to have an amount of funds transferred from a source account (primary wallet) to a destination account (secondary wallet). With respect to either the user (Cardholder) or administrator, each will have to complete a Request Form (steps 603 and 605) in which various information has to be entered as shown in step 607. Optionally, image(s) of any supporting documentation for the proposed transaction (e.g., a quote) may also be transferred to a Document Extraction Service in step 609 (refer to Figure 6b) for data extraction.

[0237] With reference to Figure 6b, once the user (Cardholder) receives approval and the funds are transferred to the User's card, the user is able to use the card as shown in step 61 1 to make a purchase at a Point of Sale (POS), Automatic Teller Machine (ATM) or online. The user then links the purchase with the approved funds request in step 613 (using the same procedure as previously described with reference to an alternative embodiment described in Figures 5a, 5b and 5c) and then selects the "Image Document" icon in step 615 to attach an image of any further documentation that evidences the details of the actual purchase/transaction (e.g., a receipt).

[0238] With further reference to Figure 6b, as the system in this embodiment is configured to handle data extraction, the system transfers the imaged documents through a Document Extraction Service (refer to step 234 in Figure 2 or step 617 in Figure 6b) where the system automatically extracts and captures the following fields:

• Gross Total - Total value of purchase

• Vendor,

• Sales Tax,

• Currency,

• Date,

• Invoice Number,

• Tax Number.

[0239] The system also creates and displays a new form (based on the template of the existing Request Form) and populates this new form with any extracted data. An image of the uploaded document is displayed in a Document Image Window on the screen which allows a user to directly compare the uploaded image and any data extracted/captured in the form and correct (if necessary). To simplify this step, a User may highlight and select any of the extracted/captured data on the form which the User desires to edit. Any highlighted section will cause the system to focus on the position coordinates in the image that correspond to the extracted data value so that section of the image is displayed in the Document Image Window.

[0240] Once the data extraction is complete, the User is returned to the Statement section of the system as shown in step 236 of Figure 2. All activity, data and documents imaged are available to the User (Cardholder) and the administrator and Department Head. [0241] With further reference to Figure 6b, the system and method of the invention according to an embodiment also contemplates an automatic "cross-check" step wherein the system in step 619 performs a cross-check between the amount of the initial approved funds request, the amount of funds debited to the destination (Cardholder) account for the purchase transaction and the invoice/receipt amount of the corresponding transaction. On completion of the automatic cross-check, the system sends an App/SMS/email notification to the Authoriser (administrator or Department Head) with a "Match" or "No match" result. If the result is a "Match" the reconciliation process is completed for that particular transaction. If the result is a "No match" further reconciliation will be required and alerts/reminders will continue to be forwarded to the system administrator and the Cardholder.

[0242] It will be appreciated that the system and method of the invention also allow a user to select any particular transaction at any time in the Statement/Transaction History Screen of the system and view the Transaction Details screen which displays i) financial transaction details (as detailed above), ii) all data fields from the linked "Approved Requests" or the "Push Transfers", iii) a link to view the imaged document(s) attached in the Request process (i.e., a quotation), and iv) a link to view the imaged document attached in the post transaction post-link process (i.e., an invoice).

Use of system and method of the invention in an embodiment relating specifically to the shipping industry

[0243] A shipping vessel is a unique environment which has the following characteristics:

• The "workplace" is not at a fixed location;

• Shipping crew members are of different nationalities and have primary residences spanning the world and therefore prefer to receive their salary on a payment card in USD or Euro that is globally accepted;

• Due to the lack of any fixed location and the isolated environment whilst the ship it at sea, access to external commodities and services is limited;

• The isolated environment of a shipping vessel lends itself to the formation of an on-board "micro-economy"; • Due to the isolated environment, shipping vessels tend to carry large sums of physical cash for port purchases

[0244] It will also be appreciated that when a shipping vessel is docked at any particular location, the availability of funds is subject to the local banks and currency at that particular location and delays are often encountered. In addition, the time spent by a shipping vessel in port is limited, and as there is usually a lead time of 1 to 3 days before the Master of the shipping vessel is able to access funds, timing of any funds transfers is critical so as to ensure enough funds are secured to pay for ad-hoc purchases in port. Other issues include restrictions such as transaction limits imposed by the local banks and once a transaction occurs, there is usually an agent fee of up to 5-10% of the cash delivered that is payable.

[0245] The lack of visibility and traceability of physical cash transactions is also a problem, particularly on shipping vessels that can accommodate hundreds of employees and contractors at any given time.

[0246] A further consideration is that once the Master of a shipping vessel secures funds and attends to any ad-hoc purchases in port, the balance of cash is stored by the Master on the shipping vessel which is a security risk and also increases the risk of misappropriation of the cash by individuals due to the lack of traceability of physical cash.

[0247] As a result of the above identified characteristics and associated problems that are specific to a shipping vessel, the ability to seamlessly manage and track electronic funds transactions is highly desirable in the shipping industry.

Crew Salary Advance Process

[0248] Figure 7 is a functional flow diagram that illustrates how the system and method according to an embodiment of the invention can be used to manage and transfer salary advance funds to crew members on shipping vessels.

[0249] Head Office 710 in which the financial department of a shipping company is located maintains and manages central virtual wallet 722 (i.e., a source account) from which funds are transferred to destination accounts controlled by Ship Masters of the various shipping vessels. As part of the management process, the financial department initially sets a budget for each department by wallet currency to allocate funds 760 for each department within the company which are maintained in central virtual wallet 722. Located within the financial department of Head Office 710 is Authoriser 712 who uses interface 724 to access computer system 720 that is used to manage and control various company processes, including payment requests and electronic funds transfers from central virtual wallet 722 to destination accounts controlled by the Ship Masters of the various shipping vessels. Authoriser 712 in this embodiment is the Chief Financial Officer of the shipping company, or optionally the Head of a department or a user within a department authorised to approve requests, who has the authority to either decline or authorise payment requests submitted by the Ship Masters of the various shipping vessels for funds required to cover advance salary requests from one or more crew members.

[0250] With reference to shipping vessel 730, Ship Master 732 submits one or more payment requests 713 nominating a monetary amount 768 for salary advance requirements for the entire crew, using an application on device 726 (for example, a tablet or smart phone). Upon authorisation, the nominated monetary amount 768 is transferred from virtual wallet 722 to debit card 740 associated with the destination account of shipping vessel 730 controlled by Ship Master 732.

[0251] Upon transfer of funds to debit card 740, Ship Master 732 is able to decline or authorise a transfer of funds in accordance with one or more payment requests from crew members 732. It will be understood that debit card account 740 is now a "source account" and Ship Master 732 now adopts the capacity of an "authoriser". Upon authorisation by Ship Master 732 of one or more payment requests submitted by crew members 734 for an advance on their salary, funds 770 are transferred from debit account 740 to personal debit card accounts 742, 744 and 746 of crew members 734. Once funds have been transferred to one or more personal debit card accounts 742, 744 and 746, crew members are notified 772 by short message service of the approval of their payment request and the transfer of funds to their personal account and they are free to use funds 774 loaded on their personal debit card to purchase goods at merchant terminals 750 or withdraw cash at automatic teller machines 752. [0252] Accordingly, the Head Office of the shipping company has fully visibility and control over funds transfers globally in which any distribution of funds to crew members is able to be recorded, tracked and validated, therefore reducing the risk of misappropriation of funds during transfer of funds from the shipping company virtual wallet to the account/debit card controlled by Ship Master and subsequent distribution of funds from the Ship Master account/debit card to various crew member destination accounts.

[0253] In addition, the system and method of the invention also accommodates multi-currency transactions and is capable of facilitating substantially immediate transfer of funds from a source account to a destination account.

[0254] In an alternative embodiment, the salary advance transfer process may be managed by the Ship Master submitting a payment request in a monetary value that equates to the total estimated value of the entire monthly crew salary advance requirement. Upon authorisation of the payment request, funds in the requested monetary amount are transferred from the central virtual wallet (source account) to a destination account managed by the Ship Master. In the event a crew member requests an advance on their salary, the Ship Master can submit a Crew Payment PUSH transfer (if the crew member has made a verbal request) or the Ship Master can authorise a funds transfer (if the crew member has submitted an electronic request). Once the payment request is authorised, the funds are transferred from the Ship Master's account (now the source account) to the destination account belonging to the crew member which is associated with one or more payment transaction devices (for example, a branded payment card or debit card or a wallet system such as PayPal or We-Chat Pay).

Port-purchase Process

[0255] Figure 8 is a functional flow diagram that illustrates how the system and method according to an embodiment of the invention can be used to manage funds transfers for purchases when shipping vessels are in port.

[0256] As described in respect to the embodiment illustrated in Figure 7, Figure 8 similarly shows Head Office 810 in which the financial department of a shipping company is located maintains and manages central virtual wallet 822 (i.e., a source account) from which funds are transferred to destination accounts of various shipping vessels. As part of the management process, the financial department initially sets, and then supervises the on-going adequacy of, a budget by wallet currency for each department to allocate funds 860 for each department within the company. These funds are maintained in central virtual wallet 822. Located within the finance department of Head Office 810 is Authoriser 812 who uses interface 824 to access computer system 820 that is used to manage and control various company processes, including payment requests and electronic funds transfers from central virtual wallet 822 to destination accounts of the Ship Masters of the various shipping vessels. Authoriser 812 in this embodiment is the Chief Financial Officer of the shipping company who has the authority to either decline or authorise 813 payment requests submitted by the Ship Masters of the various shipping vessels for funds required to make Port purchases.

[0257] With reference to shipping vessel 830, Ship Master 832 submits one or more payment requests 864 nominating a Department and a monetary amount using an application on device 826 (for example, a tablet or smart phone) in respect of one or more purchases made in Port. The Request is routed to the users associated with the Department selected in the Request, and upon authorisation, nominated monetary amount 868 is transferred from virtual wallet 822 to debit card 840 associated with the destination account of shipping vessel 830 controlled by Ship Master 832.

[0258] Upon transfer of funds to debit card 840, Ship Master 832 is able to use funds loaded onto debit card 840 to purchase goods in Port using merchant terminals 850 or cash withdrawn at automatic teller machines 852. Any purchases made undergo a validation process where Ship Master 832 uploads a digital image 872 of one or more invoices 854 associated with any purchases made in Port using device 826 (for example, a tablet or smartphone).

Digital IOU Process

[0259] Figures 9a, 9b, 9c and 9d is a four part functional flow diagram that illustrates how the system and method of the present invention can be used in an embodiment to manage predetermined monetary agreements or "I owe you" (IOU) agreements between shipping vessel personnel in exchange for goods and/or services.

[0260] As discussed above, due to the isolated workplace environment on shipping vessels, on board "micro-economies" tend to form in which goods and/or services are exchanged between shipping vessel personnel on the basis of an exchange of funds.

[0261] Figures 9a and 9b illustrate an embodiment where crew member 914 of shipping vessel 910 purchases goods from shipping vessel Master 912.

[0262] In order to initiate a payment request and with reference to Figure 9a, Master 912 accesses the system application in step 920 using device 916 which can be a smartphone, tablet or computer, and selects the "Sales" function. Master 912 then proceeds to select in step 922 the crew member of interest (i.e., the purchaser of the goods) whose details are stored on the system and displays in step 924 past sales associated with the crew member of interest and any sales that the crew member is yet to authorise (or finalise). In step 926, Master 912 enters the sale date and a description of the goods, the amount (value) of the goods and the currency in which the transaction is to be effected and selects "OK". As shown in step 928, this creates a digital IOU against the record of the crew member of interest and is stored in the company system records 929.

[0263] In order to finalise the payment request and with reference to Figure 9b, crew member 914 of shipping vessel 910 that is purchasing the goods from the Master may access the system application or website using device 917 that can be a smartphone, tablet or computer. Crew member 914 logs into the system in step 930 and selects, in step 932, "Payments" which displays a list of pending digital lOUs awaiting authorisation. Crew member selects the "Approve" function 934 to authorise the payment request and once authorisation is complete, the system automatically allocates funds in accordance with the recorded monetary amount for subsequent transfer in step 936 to the Master's 912 account once the goods have been exchanged and in accordance with the agreed and recorded sale date (i.e., the date upon which the funds are to be transferred from the Crew member's 914 account to the Ship Master's 912 account). [0264] In an alternative embodiment, the system may also accommodate the use of a QR code to identify individual crew members against which one or more payment requests may be recorded.

[0265] Figures 9c and 9d illustrate an embodiment where crew member 914 of shipping vessel 910 purchases goods from shipping vessel Master 912, wherein crew member 914 is identified by the use of a personal QR code that is unique to that individual crew member.

[0266] In order to initiate a payment request, crew member 914 that is purchasing goods from a Ship Master may access the system application using device 918 that can be a smartphone, tablet or computer. Upon accessing the system as shown in step 950, crew member 914 selects the "Payments" function which causes crew member's QR code to be displayed on device 918 as shown in step 952.

[0267] In order to authorise a payment request, Ship Master 912 accesses the system application in step 958 using device 919 which may be a smartphone, tablet or computer and selects, in step 960, the "Sales" function which causes QR codes of individual crew members with pending payment requests to be displayed as shown in step 962. The specific QR code of crew member 914 is displayed which, upon being read in step 964, takes Ship Master 912 to another display screen for entry of information including the proposed "Sale date", a description of the goods, an amount (value) of the goods and the currency in which the funds transfer is to be effected. As shown in step 966, once Ship Master 912 selects "OK" after entering all of the required information, the system automatically creates a digital IOU and stores this in company system records 968 against the record of crew member 914. As shown in step 970, details of the payment request is displayed on crew member's 914 device 918 and once crew member 914 authorises the payment request by selecting "OK", the system automatically allocates funds in accordance with the recorded monetary amount for transfer in step 972 to the Master's 912 account once the goods have been exchanged and in accordance with the agreed and recorded sale date (i.e., the date upon which the funds are to be transferred from the Crew member's 914 account to the Ship Master's 912 account). [0268] Whilst the above embodiment is described with reference to predetermined monetary agreements made between shipping vessel personnel, it will be appreciated that this embodiment is not necessarily restricted to a shipping vessel environment and can be applied in any situation where the provision of one or more goods and/or services occurs prior to the transfer of funds according to an established "IOU" agreement.

System and Method including integrated Vendor/Supplier Quotation Process

[0269] Figure 10 is a functional flow diagram that illustrates how the system and method of the present invention, according to an embodiment, may be utlilised in the management of payment requests that incorporate vendor/supplier quotations relating to the supply of stock (goods) and maintenance services on a shipping vessel.

[0270] In this embodiment, two types of requests can be considered:

(i) a "Payment Request" that includes details of the proposed Port purchase and also includes the anticipated monetary amount and currency required to effect the Port purchase that can be either authorised or declined by an Authoriser; and

(ii) a "Requirements Request" that includes details of the proposed Port purchase but is in the absence of any anticipated monetary amount and currency and requires the submission of one or more vendor quotations in order to effect a funds transfer. Once the vendor quotation is submitted and uploaded to the system, the "Requirements Request" effectively becomes a "Payment Request" that can be either authorised or declined by an Authoriser.

[0271] The process of managing a "Requirements Request" is described with reference to Figure 10. Computer system 1010 located within a shipping company's head office, is used to manage "Requirements Requests" received from a shipping vessel Master (or Purchase Officers). Since "Requirements Requests" do not include a monetary amount, such requests also require the collection and submission of one or more vendor quotations from vendors/suppliers 1020, 1022 and 1024 of various goods and services. Computer system 1010 is also used to control the shipping company's Enterprise Resource Planning (ERP) that is used to create, maintain and manage a list of vendor records 1026 that includes details of available vendors/suppliers. Alternatively, vendor records 1026 may be created and managed within a third party system connected to computer system 1010. Vendor records 1026 also include a description of the goods and services offered by each vendor/supplier and any information relating to previous purchases from any of the vendors/suppliers listed in the system.

[0272] In order to facilitate the identification of suitable/appropriate vendors/suppliers, vendor records 1026 are categorised using "Port" and "Category" fields. The Port field enables the selection of a particular port of interest from a drop down list of available Ports. In an embodiment, when a particular Port is selected the currency is also automatically nominated to be the currency of the country within which the Port is located.

[0273] The Category field enables the selection of a particular good and service of interest from a drop down list of available categories. Examples of available categories include, but are not limited to, Laundry, Chemical Supplies, Fresh Water and Technical Spares.

[0274] The system also includes standardised text in relation to the Port and Category fields for selection by users. In an embodiment such text is able to be modified to suit the purpose of the customer (shipping company). The use of standardised text increases the speed at which the Ship Master (or Purchase Officer) can create requests and provides the shipping company with more standardised/structured data for creating reports during tracking and validation processes.

[0275] It is also envisaged that any number of Ports and Categories can be incorporated into the system which can be expanded to include further Ports, Categories and other fields as required.

[0276] Referring once again to Figure 10, in order to initiate a Requirements Request, Ship Master 1027 of shipping vessel 1015 uses interface 1030 to enter details of the "Requirements Request". The request requires the selection of a Port and Category and includes details of the type and amount of goods/services required and the timeframe within which the goods/services are required. [0277] In order to obtain one or more vendor quotations for submission with the "Requirements Request", Ship Master 1027 uses interface 1030 to select one or more vendors meeting the entered Port and Category selection criteria and generates one or more electronic mails (emails) 1032 to be sent to selected vendors. Email(s) 1032 include a system generated standard template that are completed by the individual submitting a "Requirements Request" (in this embodiment a Ship Master) and also include a URL link that is selected by the Vendor(s) to open web page 1036 in which a quotation value is entered, and quotation image is uploaded, by the vendor.

[0278] Ship Master 1027 reviews quotes and selects one or more successful quotes and enters this information in the system using interface 1042. Details of the successful quote are then recorded and sent to the shipping company Head Office using one of two options, first option 1044 including a Purchase Order, vendor details, quotation value and image and second option 1046 including quotation value and image.

[0279] Upon receipt of the Requirements Request and vendor quotation (which together define a payment request), the request is reviewed by the shipping company Head Office personnel who have the authority to either decline or authorise the transfer of a monetary amount corresponding to the value of vendor quotation. Upon approval of the payment request by the shipping company Head Office, funds 1050 corresponding to the value of the vendor quotation are transferred from a central virtual wallet ("source account") of the company to debit card 1052 ("destination account") controlled by Ship Master 1027, which can be used to purchase goods and services in Port. Whilst not shown Figure 10, the system also accommodates an image of one or more invoices associated with the purchases in Port to be uploaded to the system by the Ship Master as a means of verifying the payment request and goods/services purchased in Port.

[0280] Whilst the above example is with reference to the shipping industry, it will be appreciated that the system and method of the present invention may be used in any industry in which payment requests and funds transfers of an ad-hoc nature are common. However, due to the ability to efficiently effect funds transfers that can be easily managed, tracked and verified (validated) within the one system, the system and method of the present invention generally finds particular application in companies that attract a large workforce, have offices in multiple locations or have workplaces that are isolated (for example mining sites at remote locations or shipping vessels).

[0281] Throughout this specification and the claims which follow, unless the context requires otherwise, the word "comprise", and variations such as "comprises" and "comprising", will be understood to mean the inclusion of a stated integer or step, or group of integers or steps, but not the exclusion of any other integer or step or group of integers or steps.

[0282] The reference to any prior art in this specification is not, and should not be taken as, an acknowledgement or any form or suggestion, that the prior art forms part of the common general knowledge.

Claims

Claims:

1 . A computer implemented system for managing payment requests, the system including:

an authorisation component configured to accept a payment request from a requestor for authorisation of the transfer of a monetary amount, the component operable to accept the entry of one or more details associated with payment requests,

an interface that displays the requested monetary amount and any details thereof for viewing by an authoriser having authority to disburse funds from a source account containing funds, wherein the authoriser by operation of the interface, either authorises or declines the payment request,

a transfer component that transfers funds, upon receipt of authorisation of a payment request, in respect of the requested monetary amount from the source account containing funds to a destination account accessible by the requestor.

2. A computer implemented system according to claim 1 wherein the system further includes an image component configured to receive and store an image of a document associated with the payment request.

3. A computer implemented system according to either claim 1 or claim 2 wherein the document is any one or more of: a quotation, an invoice or a salary advance request.

4. A computer implemented system according to any one of the preceding claims wherein the destination account also services as a source account in subsequent funds transfers to one or more additional destination accounts.

5. A computer implemented system according to any one of the preceding claims, wherein the source account has a plurality of associated sub-accounts wherein funds held in each sub-account are of different currencies.

6. A computer implemented system according to any one of the preceding claims, wherein the destination account has a plurality of associated sub-accounts, wherein funds held in each sub-account are of different currencies.

7. A computer implemented system according to either one of claim 5 or claim 6, wherein the transfer component transfers funds from a source sub-account associated with the source account to a destination sub-account associated with the destination account, wherein funds held in the source sub-account and destination sub-account are of the same currency.

8. A computer implemented system according to any one of the preceding claims wherein the destination account is accessible by use of one or more transaction payment devices.

9. A computer implemented system according to claim 8 wherein the transaction payment device is a debit card.

10. A computer implemented system according to any one of the preceding claims wherein the funds are transferred prior to the provision of at least one good and/or service and substantially upon authorisation of the payment request by the authoriser.

1 1 . A computer implemented system according to any one of claims 1 to 9 wherein the funds are transferred after the provision of at least one good and/or service and substantially upon an agreed date of transfer.

12. A computer implemented system according to any one of the preceding claims wherein the system further includes a request submission component configured to submit a request for a quotation from one or more goods and/or service providers;

the system further including a quotation component configured to receive details of a quotation from one or more goods and/or service providers.

13. A computer implemented system according to claim 12 wherein the details of the quotation include a monetary value of the quotation and/or an image of the quotation document.

14. A computer implemented system according to either one of claim 12 or claim 13 wherein the system further includes a database for storing details of one or more goods and/or service providers and a description of their associated goods and/or services.

15. A computer implemented system according to any one of the preceding claims wherein the payment request is in respect of a proposed expenditure.

16. A computer implemented system according to any one of the preceding claims wherein the payment request is in respect of an advance on salary.

17. A computer implemented system for managing payment requests, the system including:

an authorisation request component configured to accept a payment request for authorisation of the transfer of a monetary amount in respect of the provision of at least one good and/or service, the component further configured to accept the entry of one or more details associated with the payment request,

an interface that displays the requested monetary amount and any details thereof for viewing by an authoriser, wherein the authoriser, by use of the interface, either declines the payment request or allocates funds in respect of the requested monetary amount for settlement of the payment request upon satisfaction of one or more conditions, and

a transfer component that transfers the allocated funds from a source account to a destination account upon receiving notification of the satisfaction of the one or more conditions.

18. A method of requesting authorisation of a payment request, the method including: a user accessing a system through a system interface and entering a payment request for authorisation for the transfer of a monetary amount including one or more details associated with the payment request;

the user receiving either an approval or rejection of the payment request, the approval or rejection being displayed on the system interface; and

in the event the payment request is authorised, transferring funds in an amount corresponding to the monetary amount between a source account containing funds and a destination account accessible by the user.

19. A method according to claim 18, wherein following the transfer of funds from the source account to the destination account, the user receives one or more payment requests from one or more additional users, wherein the user becomes an authoriser of the one or more payment requests received from the one or more additional users, and the destination account becomes a source account from which funds are transferred in respect of the one or more payment requests received from the one or more additional users.

20. A method according to either one of claims 18 or 19, wherein funds held in the source account are managed in a plurality of associated sub-accounts wherein funds held in each source sub-accounts are of different currencies.

21 . A method according to either one of claims 18 or 19, wherein funds held in the destination account are managed in a plurality of associated sub-accounts, wherein funds held in each destination sub-account are of different currencies.

22. A method according to any one of claims 18 to 21 , wherein funds transferred from a source sub-account associated with the source account of a certain currency are transferred to a destination sub-account associated with the destination account of the same currency.

23. A method according to any one of claims 18 to 22, wherein the payment request is in respect of a proposed expenditure or a salary advance.

24. A method according to any one of claims 18 to 23 further including the step of uploading an image of a document.

25. A method according to claim 24 wherein the document is any one or more of a quotation, invoice or a salary advance request.

26. A method of authorising a payment request, the method including: an authoriser accessing a system through a system interface and viewing a payment request for the transfer of a monetary amount including one or more details associated with the payment request;

the authoriser either authorising or declining the payment request, and;

in the event the payment request is authorised, transferring funds in an amount corresponding to the monetary amount between a source account containing funds and a destination account.

27. A method according to any one of claims 18 to 26 wherein the payment request is submitted by the authoriser.

28. A method according to any one of claims 18 to 27 wherein a payment request is automatically authorised upon the application of one or more pre-configured requirements created by a system administrator.

29. A method according to any one of claims 18 to 28 further including automatic generation of a unique reference number (URN) associated with the payment request to identify funds transfers from a source account to a destination account.

30. A method of requesting authorisation of a payment request, the method including: a user accessing a system through a system interface and entering a payment request for authorisation for the receipt of one or more goods and/or services of interest; the user sending a request for a quotation to at least one goods and/or services provider in respect of the provision of the one or more goods and/or services of interest; receiving one or more quotations including a monetary value from at least one goods and/or services provider in respect of the provision of one or more goods and/or services of interest;

in the event the payment request is approved, transferring funds in an amount corresponding to the monetary value between a source account containing funds and a destination account accessible by the user.

31 . A method according to claim 30 wherein the user conducts a search of a database containing records of available goods and/or services providers and their associated goods and/or services, wherein the database includes fields that permit categorisation of goods and/or services according to categories, wherein the categories are defined using standardised text and wherein one or more categories are selectable by the user for use in the generation of the payment request.

32. A method according to either one of claim 30 or claim 31 wherein the system generates a standard electronic mail template for use by the user to submit details of the payment request.

33. A method according to claim 32 wherein the electronic mail includes a URL link that the one or more goods and/or services providers use to enter the quotation.

34. A method of managing a payment request for the provision of one or more goods and/or services, the method including:

a user accessing a system through a system interface and entering a payment request for authorisation for the transfer of a monetary amount and one or more details associated with the payment request;

in the event the payment request is approved, allocating funds in an amount corresponding to the monetary amount.

35. A method according to claim 34 wherein the user is an individual that provides the at least one good and/or service.

36. A method according to claim 34 wherein the user is an individual that receives the at least one good and/or service.

37. A method according to claim 34 wherein the payment request is received by the user that provides the at least one good and/or service.

38. A method according to claim 34 wherein the payment request is received by the user that receives the at least one good and/or service.

39. A method according to claim 34 wherein the payment request is authorised by the user that provides the at least one good and/or service.

40. A method according to claim 34 wherein the payment request is authorised by the user that receives the at least one good and/or service.

41 . A method according to any one of claims 34 to 40 wherein the allocated funds are transferred from a source account to a destination account after the provision of the at least one or more goods and/or services and upon the satisfaction of the one or more conditions.

42. A method according to any one of claims 34 to 41 wherein the allocated funds are automatically transferred on an agreed date.

43. A method according to any one of claims 34 to 42 wherein the allocated funds are automatically transferred upon the occurrence of a pre-defined event.

44. A request and response system including: a payment request device operable to present a graphical user interface to a user and receive details of a payment request and subsequently generate and transmit a payment request message over a communications network; one or more authorisation devices operable to receive payment request messages and present a graphical user interface to an authoriser and receive either approval or rejection of payment requests and generate and transmit payment request response messages over the communications network; the one or more authorisation devices further operable to generate and transmit funds transfer messages over the communications network in the event the authorisation device receives an approval of the payment request; and a funds disbursal system operable to receive one or more funds transfer messages and further operable to transfer funds from a source account to a destination account in accordance with details contained within funds transfer messages, the destination account accessible by the users who caused the generation of payment requests corresponding to the funds transfer.

45. A method of generating a payment request including: a user generating a payment request using a payment request device accessible through a graphical user interface and entering details of the payment request; the user receiving a payment request response message over a communications network including either an approval or rejection of the payment request; and in the event the payment request is approved, the user accessing a destination account containing funds transferred from a source account to a destination account in accordance with details contained within funds transfer message.

46. A method according to any one of claims 18 to 45 wherein a priority level is able to be allocated to the payment request.

47. A method according to any one of claims 18 to 46 wherein a specified time period within which the payment request is to be authorised or declined is able to be allocated to the payment request.

48. A method according to claim 47 wherein the specified time period is automatically allocated on the basis of the allocated priority level of the request

49. A method according to either one of claims 47 or 48, wherein a notification to one or more further authorisers is automatically generated in the event a payment request is not authorised or declined by the authoriser within the specified time period, or if the authoriser is not available, or if an electronics communications device associated with the authoriser sensed to be motionless for a specified period of time.

50. A method according to claim 49, wherein the one or more further authorisers are automatically selected in a sequential and escalating manner from a list of available authorisers.

51 . A method according to claim 50, wherein the list of available authorisers is a dynamic list of authorisers and is automatically generated and updated on the basis of a combination of any one or more of: the average response time of each authoriser, the source of the payment request, the day of submission of the payment request, the time of submission of the payment request, the location of the one or more authorisers, the availability of the one or more authorisers and the sensed motion or monitored use of an electronics communications device associated with, and used by, each authoriser to either authorise or decline a payment request.

52. A method according to either one of claims 50 or 51 , wherein the list of available authorisers is a dynamic list that is automatically and continuously updated on the basis of data collected from previous payment requests.