AU2014201752A1 - Method and system for secure electronic funds transfer - Google Patents

Method and system for secure electronic funds transfer Download PDF

Info

Publication number
AU2014201752A1
AU2014201752A1 AU2014201752A AU2014201752A AU2014201752A1 AU 2014201752 A1 AU2014201752 A1 AU 2014201752A1 AU 2014201752 A AU2014201752 A AU 2014201752A AU 2014201752 A AU2014201752 A AU 2014201752A AU 2014201752 A1 AU2014201752 A1 AU 2014201752A1
Authority
AU
Australia
Prior art keywords
record
donor
financial institution
recipient
funds
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
AU2014201752A
Inventor
Peter Dakouris
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from AU2013901422A external-priority patent/AU2013901422A0/en
Application filed by Individual filed Critical Individual
Priority to AU2014201752A priority Critical patent/AU2014201752A1/en
Publication of AU2014201752A1 publication Critical patent/AU2014201752A1/en
Abandoned legal-status Critical Current

Links

Landscapes

  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Abstract A method of electronically transferring funds between a donor and a recipient, the method including: (a) generating and storing an electronic funds record at a donor financial institution server, the electronic funds record including at least a record identifier and data indicative of a cash value of the electronic funds record; (b) transmitting at least the record identifier to an electronic device associated with a donor in data communication with the donor financial institution server; (c) receiving at least the record identifier at the donor financial institution server from a recipient financial institution server, whereby the recipient financial institution server obtained the record identifier via the donor electronic device; (d) processing the record identifier at the donor financial institution server to ensure that the record identifier is valid and to determine a funds amount to be transferred; and (e) electronically transferring funds corresponding to the cash value of the electronic funds record to the recipient financial institution server. Generate Electronic 305 Funds Record Transmit Record 31 0 Identifier Receive Record 31 5 Identifier 320 Process Record ERROR Identifier Verified N30 325 ? 335 Transfer Fungs Archive Electronic 340 Funds Record Figure 3

Description

METHOD AND SYSTEM FOR SECURE ELECTRONIC FUNDS TRANSFER Technical Field [0001] The present invention relates to a method and system for transferring electronic funds in a secure manner. Background [0002] Electronic funds transfer (credit card, direct debit, prepaid card etc.) generally requires information (usually account details) to be passed from the donor to the recipient in order to complete the transaction. This is especially true when the donor is a customer and the recipient is a merchant. A problem with traditional electronic funds transfer such as this is that it is inherently unsafe. Account details (whether it is a credit card number, a pin number date of birth or name) are artefacts which may persist across transactions. [0003] Each time this information is passed there is an opportunity for it to be stolen and possibly misused. For example, instances of reported credit card data thefts from various online sales based organisations are common place. So too are scams run by crime gangs whose objective is to steal credit card information from POS terminals and ATMs using skimming devices. [0004] It would therefore be desirable to provide a system and method which alleviates or at least ameliorates the above problems. [0005] A reference in this specification to any prior publication (or information derived from it), or to any matter which is known, is not, and should not be taken as an acknowledgement or admission or any form of suggestion that the prior publication (or information derived from it) or known matter forms part of the common general knowledge in the field of endeavour to which this specification relates. Disclosure of the Invention [0006] The present invention provides a system and method in which the data for a funds transfer is transient. That is, the data for the transaction can be used only once, and then is invalid. Further the transient data is data which bears no relationship whatsoever to any artefacts which can be related back to the donor. 1 [0007] The present invention provides a method of electronically transferring funds between a donor and a recipient. The donor may be an individual as may be the recipient. Preferably, the donor is an individual and the recipient is a merchant. The method includes generating and storing an electronic funds record at a donor financial institution server. The electronic funds record includes at least a record identifier and data indicative of a cash value of the electronic funds record. The record identifier is transmitted to an electronic device associated with the donor in data communication with the donor financial institution server. Advantageously, the record identifier does not contain any sensitive information which if found could lead to fraud. The record identifier is then received at the donor financial institution server from a recipient financial institution server - the recipient financial institution server obtaining the record identifier via the donor electronic device. The record identifier is then processed at the donor financial institution server to ensure that the record identifier is valid and to determine a funds amount to be transferred; and funds are electronically transferred corresponding to the cash value of the electronic funds record to the recipient financial institution server. [0008] Preferably, the recipient financial institution server obtains the record identifier from a recipient server via the donor electronic device. The method may further include providing a recipient identifier together with the record identifier. [0009] In an alternative, the method may include providing a financial institution identifier together with the record identifier. [0010] Preferably, the method further includes the step of archiving the electronic funds record in at the donor financial institution server, once the funds transfer has been completed. [0011] Preferably, the method further includes the step of validating the electronic funds record at the donor financial institution server based on at least one predetermined criteria. The predetermined criteria may include an expiry time associated with the electronic funds record or a password associated with the electronic funds record. Advantageously, this provides an added level of security to the transaction. 2 [0012] In an alternative, the electronic funds record may further include an owner of the electronic funds record and/or the currency type. [0013] Preferably, the method further includes the step of encrypting the record identifier prior to being received at the recipient financial institution server. The record identifier may be a 128 bit number or a graphically represented by a QR code for example. [0014] Preferably, the recipient financial institution server obtains the record identifier from the donor electronic device via near field communication. [0015] Preferably, the donor is a customer and the recipient is a vendor and the recipient financial institution server obtains the record identifier from the customer electronic device for purchase of goods or services. [0016] Preferably, funds are electronically transferred corresponding to the cash value of the goods or services purchased by the customer from the cash value of the electronic funds record to the recipient financial institution server to complete the purchase of the goods or services. [0017] According to a further aspect, the present invention provides a system for electronic transfer of funds between a donor and a recipient, the system including: a donor financial institution server for generating and storing an electronic funds record, the electronic funds record including a record identifier and data indicative of a cash value of the electronic funds record; the donor financial institution server being adapted to transmit at least a record identifier to an electronic device associated with a donor in data communication with the donor financial institution server; and a recipient financial institution server in data communication with the donor financial institution server for receiving at least the record identifier from a donor electronic device; wherein the donor financial institution server being in data communication with the recipient financial institution server electronically to transfer funds corresponding to the cash value of the electronic funds record to the recipient financial institution server. [0018] Embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings. It is to be understood 3 that the particularity of the drawings does not supersede the generality of the preceding description of the invention. Brief Description of the Drawings [0019] Figure 1 is a schematic diagram of an example network that can be utilised to give effect to a method according to an embodiment of the invention. [0020] Figure 2 is a functional block diagram of an example processing system that can be connected to the network. [0021] Figure 3 is a flow chart of a method for transferring electronic funds in a secure manner according to an embodiment of the invention. [0022] Figure 4 is a method for transferring electronic funds in a secure manner according to another embodiment of the invention. [0023] Figure 5 is a method for transferring electronic funds in a secure manner according to a further embodiment of the invention. Detailed Description [0024] The following description refers in more detail to the various features and steps of the present invention. To facilitate and understanding of the invention, reference is made in the description to the accompanying drawings where the invention is illustrated in a preferred embodiment. It is to be understood however that the invention is not limited to the preferred embodiment illustrated in the drawings. Example of a Network [0025] The system and method of the present invention can be realised over a network 115, an example of which is shown in Figure 1. [0026] The system 100 of the present invention may run on a network 115 which includes one or more donor electronic devices and one or more server processing systems. In this example, the donor electronic devices include one or more mobile communication devices 105 and one or more personal computers (PCs) 110. The server processing systems include a recipient server 120, donor bank server 125 and recipient bank server 130. The donor electronic device 105, personal computer 110 and recipient server 120 are connected via a network 115 such as the internet. The 4 donor bank server 125 and recipient bank server 130 may be interconnected between each other directly or via a network 115 such as the internet. [0027] The transfer of information and/or data over the network can be achieved using wired communications means or wireless communications means. It will be appreciated that embodiments of the invention may be realised over different networks, such as a MAN (metropolitan area network), WAN (wide area network) or LAN (local area network). Also, embodiments need not take place over a network, and the method steps could occur entirely on a client or server processing system. Example of a Processing System [0028] The mobile communication device 105, personal computer 110, donor bank server 125, recipient bank server 130 and recipient server 120 may include a processing system 200 shown in Figure 2. [0029] The processing system 200 includes a processor 202 (or processing unit), a memory 204, at least one input device 206, at least one output device 208 and a communications port 222. As is shown, the processor 202, memory 204, input device 206, output device 208 and communications port 222 are typically coupled together via a bus or group of buses 210. In certain embodiments, input device 206 and output device 208 may be the same device such as in the case of, for example, a computer graphics display or handheld device such as an tablet or mobile communication device that incorporates a touch-screen. [0030] An interface 212 can also be provided for coupling the processing system 100 to one or more peripheral devices. For example interface 212 may include a PCI card or PC card. At least one storage device 214 which houses at least one database 216 can also be provided. [0031] The memory 204 may include any suitable memory device and including, for example, volatile or non-volatile memory, solid state storage devices, magnetic devices, etc. The memory 204 may typically store an operating system that provides functionality to the processing system 200. A file system and files are also typically stored on the storage device 214 and/or the memory 204. The memory 204 may also include one or more software applications or program data. 5 [0032] The applications running in memory 204 may include a web browser or application suitable application for displaying electronic documents for reading or reviewing and accessing the internet 115 to carry out the method and system of the present invention. [0033] The processor 202 may include more than one processing device, for example to handle different functions within the processing system 200. Input device 206 receives input data 218 and may include, for example, a keyboard, a pointer device such as a pen-like device or a mouse, a touch-screen, audio receiving device for voice controlled activation, such as a microphone, data receiver or antenna such as a modem or wireless data adaptor, data acquisition card, camera, etc. The input device 208 may be operable by a user to enter input data 218, or it may receive data from another input data source (such as a QR code). Thus, the input data 218 may be provided by different input devices 206. For example, in an embodiment the input data 218 may include keyboard or mouse instructions entered by a user, in conjunction with data received via a network or a QR code. Preferably, the input device 208 includes a touch screen associated with an electronic communication device. [0034] Output device 208 produces or generates output data 220. In one embodiment, the output device 208 includes a display device (such as a computer graphics display) for providing output data 220 in a visual form. In another embodiment, the output device 208 includes a display device or monitor together with a set of audio speakers in which case the output data 220 may be provided in an audio-visual form. [0035] It will be appreciated that other types of output devices 208 may also be used, such as, a port (for example a USB port), a peripheral component adaptor, a data transmitter or antenna such as a modem or wireless network adaptor, etc. [0036] It will also be appreciated that the output data 220 could be output from a variety of different output devices 208 such as, for example, a visual display on a monitor in conjunction with data transmitted to a network. In such an embodiment a user may view data output, or an interpretation of the data output, on, for example, a monitor or using a printer. 6 [0037] The storage device 214 can include any form of data or information storage means, for example, volatile or non-volatile memory, solid state storage devices, magnetic devices, etc. [0038] The communications port 222 allows the processing system 200 to communicate with other devices via a hard wired or wireless network, such as network 115 in Figure 1. [0039] In use, the processing system 200 can be adapted to allow data or information to be stored in and/or retrieved from, via wired or wireless communication means, the at least one database 216. The interface 212 may allow wired and/or wireless communication between the processing unit 202 and peripheral components that may serve a specialized purpose. The processor 202 may receive instructions as input data 218 via input device 206 and can display processed results or other output to a user by utilising output device 208. Multiple input devices 206 and/or output devices 208 can be provided. [0040] It should be appreciated that the processing system 200 may be any form of terminal, server processing system, specialised hardware, computer, computer system or computerised device, personal computer (PC), mobile or cellular telephone, mobile data terminal, portable computer, Personal Digital Assistant (PDA), pager or any other similar type of device. [0041] Figure 3 is a flow chart of a method 300 for secure electronic funds transfer according to an embodiment of the invention. The method 300 may be carried out on the system 100 described with reference to Figure 1. At step 305, in response to user input from a donor electronic device 105 or 110, for example, the donor bank server 125 generates and stores an electronic funds record at the donor bank server 125. The electronic funds record includes a unique record identifier together with data indicative of a cash value of the electronic funds record. Effectively, this record represents an amount of cash purchased by the customer from a financial institution associated with the donor bank server 125. It may include the following attributes: a unique numerical identifier which can be used to represent the record across information systems including other financial institutions, the value of the cash amount the record represents, the currency type (usually the default currency of the 7 jurisdiction in which the bank resides unless specified otherwise). The electronic funds record may further include owner information (i.e. the account identification number or customer identification number of the donor. This information may be included in the event that the electronic funds record needs to be cancelled and/or refunded before it is used by the donor (for example before it is used to purchase goods or if the customer decides not to purchase goods). [0042] In addition, the electronic funds record may include an expiry window; that is, a time for which the electronic funds records is valid. This may be a very short time period since the electronic funds record in practice will be used and cashed in real time. In the event the expiry time is past the electronic funds records is no longer valid as will be described further below. [0043] Further, the electronic funds record may include a pass phrase and may employ extra security in certain circumstances. A pass phrase may be provided such that the donor (i.e. owner of the funds record) elects to print out the record identifier via associated QR code for use at a point of sale. The donor may elect to do this in the event their smartphone app was not functioning for example. Upon creation of the electronic funds record, the donor includes a pass phrase (which should be committed to memory) but is stored on the donor bank server. Upon presentation of the record identifier in the form of printed QR code for scanning at point of sale, the donor advises the recipient (in this case a vendor) of the pass phrase and the recipient may input the pass phrase into their application via a keyboard, together with scanning the QR code, for processing. In the event the printed version of the record identifier is lost prior to use by the donor, it cannot be cashed even if the dollar value of the record identifier is known since a pass phrase is also required. [0044] The electronic funds record may logically reside in an Electronic Cash Records Table (ECRT) of the bank or financial institution which issued it and therefore stored on, for example donor bank server 125 until the electronic funds record is used at which point it is archived once a recipient has been credited. Advantageously, the electronic funds record does not require the passing of account related data to a recipient; rather the account related data remains in the context of a trusted relationship between the donor and his or her financial institution (donor bank server 125). 8 [0045] Once generated, the electronic funds record is stored on the donor bank server 125 and control moves to step 310 where a record identifier is transmitted to an electronic device associated with the donor 105, 110, the electronic device being in data communication with the donor bank server 125. This step allows the donor to provide the record identifier (which relates to the electronic funds record) to a third party such as a recipient. The recipient may include a vendor or an individual either in an online environment or in person (such as for example at an EFTPOS or ATM terminal). In addition to the record identifier, other information may be transmitted such as the value associated with the electronic funds record and/or the donor bank information or a pass phrase as described above. [0046] Control then moves to step 315 where the record identifier which has been provided to a recipient is received at the donor bank server 125 from a recipient bank server 130. The recipient bank server 130 will have received the record identifier from the donor electronic device 105, 110 or indirectly through the donor electronic device 105, 110 via a recipient server 120. It will be appreciated that the donor electronic device 105, 110 need not be the same donor electronic device that requested the electronic funds record. Rather the donor electronic device 105, 110 may be a recipient device in which the donor associated with the donor electronic device has invited the record identifier to the recipient in order to arrange payment. [0047] Control then moves to step 320 in which the record identifier is processed at the donor server 125 to ensure that the record identifier is valid and to determine a funds amount to be transferred. At step 325 a check is made to determine whether or not the electronic funds record is valid by looking up the Electronic Cash Records Table on the donor bank server 125 ensuring that, for example a time period has not expired or a pass phrase is not incorrect. In the event there is a problem or an error control moves to step 330 which is an error state. The transaction fails and an interface (at the donor bank server, recipient bank server and/or donor electronic device) return an error response to the calling application (in this case, the recipient bank server) which may be, for example, a non-zero error code and an error message which identifies the nature of the error. Preferably, this should be captured and displayed back to the entity trying to process the record. Errors include incorrect 9 pass phrase (if one is associated with the electronic funds record) or if the incorrect transaction amount is entered. [0048] In the event electronic funds record is valid, control moves to step 335 in which the funds in the amount of the electronic funds records is electronically transferred between the donor bank server 125 and the recipient bank server 130. [0049] Control then moves to step 340 in which the electronic funds record may be archived at the donor bank server 125. [0050] Donor bank server 125 and recipient bank server 130 hold the donor and recipient bank accounts respectively. Logically, these two entities can reside in separate banks since it is possible to operate across financial institutions providing that they have a way of transferring funds from one to another in real time (i.e. SWIFT) or the banks may be one and the same. Preferably the donor bank server 125 and recipient bank server 130 provide an interface to the donor and/or recipient (for example online banking or a downloaded application for a mobile communication device) whereby the donor/recipient can create/purchase/revoke or redeem electronic cash records and in the case of a donor retrieve the record identifier of the electronics funds record for use in an online environment or at a retail point of sale. [0051] Preferably the recipient bank server 130 includes an interface to recipients of electronic funds records (who are existing customers of that institution) whereby the recipient can directly send a record identifier (provided by a donor) for payment of goods and/or services together with the recipients account details for processing it for fulfilment of the payment into the recipients account. Preferably this interface is a SOAP/XML/HTTPS interface (but need not be limited to this) to ensure compatibility with common internet platforms. It will be appreciated that this solution is not limited to a particular internet suite of protocols. The recipient may then post this interface in its own website associated with a recipient server 120 (or other presence, such as an application on a mobile communication device) or connected to a customised point of sale software in a physical store for example. Preferably the interface receives one or more of the following parameters to process the record identifier associated with the electronic funds record: 10 * Target bank address (e.g. DNS name) for which the record identifier belongs to * The cash record identifier provided by the donor in order to validate the electronic funds record. * A pass phrase for the electronics funds record (if one has been associated with the electronics funds records). * The amount of the transaction (which should correspond to the value of the electronics funds record) * Currency type * Target for the funds to be paid to (i.e. the bank details of the recipient for processing on recipient bank server 130). * Password for target customer (.i.e. the password the recipient uses to identify themselves when logging into the recipient bank server). [0052] Upon entering this information and receiving this request, the recipient bank server 130 validates whether the address is its own or that of another bank (for example donor bank server 125). In the event that the address is that of another bank, the recipients banking institution can then forward the transaction by calling an interface as follows: [0053] The following interface is for other financial institutions for receiving requests that contain electronic funds records. The funds can then be electronically transferred from the banks cash records holding account to the appropriate BSB/account number. The interface would accept the following parameters for example: * Target bank (i.e. DNS name) address for which the record identifier belongs * Record identifier * Pass phrase for the record (if one has been created) * Amount of the transaction * Currency type * BSB/account number of the target account for the funds to be transferred to * Account name of the target account-for validation purposes * Bank security authentication mechanism (depending on the protocol being used for example HTTPS could use SSL certificates) 11 * Transfer methods (i.e. SWIFT etc.) * Transfer code (the code by which the calling bank where the receivers account is located identified in the transfer method) [0054] In receiving this request the financial institution would validate whether the address is its own or that of another bank. If it is the address of another bank, the institution can respond with an error message. If the Address is in fact its own address it can perform the following * validate the cash record identifier (identifier may be encrypted for security or authentication purposes) * find the matching cash record and validate it's amount against the amount required, as well as the rest of the record parameters. * If the amounts match, the funds are transferred into the target account and the cash record is deleted/archived. This could be performed using standard interbank software, such as SWIFT. A success message is sent back to the calling financial institution, as well as a transaction reference which relates back to the interbank transaction which completed the transfer. * If there is a failure somewhere in the process, an error is sent back to the calling entity. [0055] In the event the transfer completes successfully, the recipients financial institution (recipient bank server 130 for example) can validate the transaction identifier sent back by the other bank as part of a success message, and confirm that the funds are in the recipients account. A success message may in addition be sent back to the donor, along with a transaction reference number which may double as a receipt. [0056] In the event the banks address is its own address, that is the donor bank server 125 and the recipient bank server 130 are the same financial institution the following can be carried out: * Validate the record identifier (the identifier may be encrypted for security or authentication purposes). The donor bank server may encrypt the record identifier so as to provide an authentication mechanism to ensure that the donor bank was the originator of the record identifier. 12 * Find the matching cash record and validate its amount against the amount required as well as any other parameters (if required). * In the event the amounts match, the funds may be transferred into the recipients default account and the electronic funds record is deleted or may be archived. A success message may be sent back to the donor along with a transaction reference number which can double as a receipt. * If there is a failure somewhere in the process, an error message may be sent to the donor. [0057] The donor banks server 130 may expose an interface to recipients who are not customers of the institution, for receiving requests that contain electronic funds records provided by a donor. The funds can then be electronically transferred from the donor bank cash record holding account to an appropriate BSB/account number. The interface will accept the following parameters: * Target bank DNS address for which the record identifier belongs to * Record identifier * Pass phrase for the record (in the event one has been created) * The amount of the transaction * Currency type * BSB/account number of the target account for the funds to be transferred to. This is the default account set by the recipient for processing payments, and may be carried out by a banking application/software described below * The account name of the target account for validation purposes which may be set using internet banking application /software described below * A user password which may be set by internet banking applications/software describes below * Transfer method (i.e. SWIFT) * Transfer code (i.e. the code identifying the bank where the recipients account is located using the transfer method). [0058] In receiving a request such as this the financial institution (donor bank server 125) will validate whether the address is its own or that of another bank. If it is the address of another bank the institution can respond with an appropriate error message otherwise the donor bank server 125 may perform the following: 13 * Validate the record identifier (the identifier may be encrypted for security or authentication purposes) * Find the matching cash record and validate its amount against the amount required as well as any other record parameters * In the event the amounts match, the funds may be transferred to the recipients account and the cash record may be deleted or archived. This may be carried out using standard interbank software such as SWIFT. A success message may be sent back to the calling financial institution, as well as a transaction record which relates to the interbank transaction which completed the transfer. * In the event that there is a failure somehow in the process an error message may be sent back to the calling entity. Internet banking application and software [0059] Preferably, at step 305 a donor has requested an electronic cash record and the banks associated with donor bank server 125 includes internet banking software, delivered via a web browser or smart phone application enhanced to provide the electronic funds record functionality. Upon a request or purchase of an electronic funds record by a donor, the donor will be required to have the funds available in their account and the donor will be able to request an electronic funds record for any value provided it can be covered by the account. A fee may be charged by the bank to cover administrative costs. Effectively the electronic funds records is simply a unique reference identifier together with a cash amount and the funds themselves can be held wherever it is most convenient for the banking entity, such as its own cash transactions account (particularly useful in the event cash transactions are to take place between different financial institutions). Further, an electronic cash record may be made in another currency and an exchange may be performed at the going exchange rate. It will be appreciated that a pass phrase may be set on the electronic record for additional security to prevent unauthorised processing of the record. Preferably the pass phrase is provided separately to the electronic funds record if required. [0060] As noted above, an expiry time may be associated with the electronic funds record. Generally, due to the nature of these records (immediate or near 14 immediate use) a default expiry time may be 5 minutes, but a donor may deem it appropriate to set a longer expiry time. For example in the event the donor is purchasing tickets to a concert on a busy web portal they may wish to extend the expiry date of the record so as to ensure they have time to complete the transaction. Once the expiry time is reached, the electronic funds record is cancelled at the donor bank server 125 and the funds are returned to the donor account. [0061] Preferably the internet banking software provides a list of purchased and unused electronic funds records together with their currency types stored on the donor bank server 125. It is also possible to delete or refund a specific electronic funds record which results in returning the amount to a donor account. It will be appreciate that if a refund of an electronic funds record is in another currency the exchange is performed according to the going rate at that particular time. Preferably the internet banking software application includes a function for processing record identifiers for crediting to a recipients account which may be done in the following way: * Providing the donor with the ability to cut and paste or type via keyboard a record identifier into a text box in the application software (whether it is run on application or through a website) together with the value of the transaction and then submit this information using the bank interface described above * Alternately, the donor/recipient may scan an image of a record identifier (which may have been provided by a donor using a webcam or a mobile communication device which is controlled by application software) and after confirming the value of the transaction submitting it to the bank user interface described above. * The donor/recipient may acquire the record identifier by any other means for example Bluetooth, near field communication or any other means provided the necessary data is transferred and understood. [0062] A default bank account may be set for creating an electronic funds records (i.e. the account that the funds of the donor will come out of) and for processing received electronic funds records (i.e. the account to which the funds will be sent into 15 for the recipient) it may be useful if the donor/recipient has multiple accounts with the institution under the same customer identifier. [0063] Preferably in purchasing a service or product from a web site the donor can retrieve a string of characters which represents the record identifier of the electronics funds record. This information can be pasted into a dialog box on the target website purchasing page to complete the purchase. A target bank address may be attached to the string of characters denoting the donor financial institution which holds the cash record. [0064] In the event of a retail Point of Sale (POS) transaction, and where the donor has a downloaded banking application such as an application on their donor electronic device 105, the donor can provide a graphical representation of a selected electronic funds record in the form of a records identifier which is something that can be scanned (for example the record identifier could take the form of a QR code type image). In this instance the QR code may be scanned at the point of sale to in order to complete the purchase. Preferably the QR code includes an unencrypted address of the recipient financial institution. In an alternative the electronic funds records may also be represented as a file or string that may be transferrable from the donor electronic device 105 via Bluetooth, near field communication, or any other suitable method. [0065] In a further alternative the transaction may be carried out by the recipient scanning a QR code which has been printed out which may be used as defacto "paper cash". Preferably, in this arrangement, a pass phrase is provided such that the donor (i.e. owner of the funds record) includes a pass phrase upon creation of the electronic funds record, but is stored on the donor bank server. Upon presentation of the record identifier in the form of printed QR code for scanning at point of sale, the donor advises the recipient (in this case a vendor) of the pass phrase and the recipient must input the pass phrase together with scanning the QR code, for processing. Advantageously, in the event the printed version of the record identifier is lost prior to use by the donor, it cannot be cashed even if the dollar value of the record identifier is known since a pass phrase is also required. 16 [0066] It will be appreciated that an abridged version of the above features may be available to users who wish to use the facility of processing electronic funds records presented to them, but do not belong to a bank or institution which supports the process. In this case, the software may be available for download by an institution which issues electronic funds records (for example downloadable to a mobile communication device) and the user may download it and configure their account details with the application together with a password which can be stored on a table in the banks back end system. The application itself processes the electronic funds records in the same manner described earlier through the use of an exposed interface described above. Recipient Website [0067] Recipient websites associated with recipient servers 120 may implement the software via SOAP/XML including a payments processing interface which has been exposed to the bank information system as described above provided they have set up the facility using the available bank software. In this case the donor inputs a record identifier as described above and the identifier is then processed at the recipient bank server 130 and then sent to the donor bank server 125 (in the event the recipient bank server 130 and the donor bank 125 are not the same). Recipient's Point of Sale Retail [0068] In this case the recipient may use a customer POS terminal to swipe account details from a card belonging to a donor. In this situation, custom hardware may be eliminated and a recipient would simply require access to banking software via a computer or smart phone using the software described above or custom point of sale software in which an exposed interface to the bank is provide (described above) the recipient may receive or scan a record identifier provided by a donor which may be in the form of a barcode on a piece of paper or QR code or a smart phone screen) and subsequently provide this information (along with the recipients account details) to the recipient bank server 130 and in turn the donor bank server 125 to effect payment. [0069] Figure 4 illustrates the operation of the method and system of the present invention in the context of a donor (in this case a customer) browsing a website via the donor electronic device 110 such as a computer or possibly via donor electronic 17 device 105 such as a smart phone in which they are presented on a website with the ability to purchase goods or services. The donor via donor electronic device 105, 110 uses a web based banking application to create an electronic funds record 410 in the amount of $29.99 for the purchase of an item from a retail website 420. Upon creation of the electronic funds record, the user's account 405 with original balance of $109.00 is decremented to $79.01. The donor's bank server 125 creates an electronic funds record for $29.99. The electronic funds record is then ready for use. The electronic funds record 401 includes a record identifier in the form of a global unique identifier which may include a 128 bit number. The record identifier may also be linked back to the donor who created it such that in the event the donor does not wish to go through with a transaction, the funds may be to be returned to the donor account. [0070] The donor, via the web banking application associated with the donor electronic device 105 retrieves the record identifier which represents the unique identifier of the electronics funds record together with the DNS address of the bank which will process the record (i.e. generally the donor bank server 125 but it need not be). For example if the bank was the ANZ bank then the string may look like this: www.anz.com.au;335c4aa74dd88aaa76ddff 1 234ffcc99, for example. [0071] The string is provided to the donor and may be pasted into the payment details section of the real website 420 to submit for purchase. Once this happens, the recipient server 120 uses their financial institutions SOAP/HTPPS interface to send the details of the transaction together with details provided by the donor. Preferably the interface includes the recipient details associated with the retail site (i.e. customer id and password) so the funds are correctly transferred into the recipients account. [0072] The recipient bank server 130 may check the DNS address of the transaction and if the destination is another financial institution it may use an interbank interface to pass the transaction, along with the BSB/account number of the destination of the funds. The donor bank software processes the record identifier and the electronic funds record is deleted from the table in the donor bank server 125 and is archived. [0073] Figure 5 is an example of the system and method of the present invention in operation in the context of the donor or customer using a smart phone application 18 to purchase from a retail website (or point of sale). In this case the donor or customer uses a donor electronic device 105 such as a smart phone to create a cash record 410 for the purchase of goods or services from a retail website. The uses account 405 (with an original balance of $109.00) is decremented to $79.01 and the donor bank server 125 creates a cash record 410 in the amount of $29.99. At this point the electronic funds record is available for use and is indexed by a global unique identifier (i.e. by 128 bit number) to provide a record identifier. The record identifier may be linked back to the customer that created it such that in the event the donor does not wish to go through with a transaction, the funds may be to be returned to the donor account. [0074] In operation, the donor uses the application which resides on their smart phone to retrieve a QR code image for example. The image may include the encrypted string which represents the record identifier of the electronic funds record as well as the DNS of the bank which will process the record. For example if the bank is ANZ then the image data in the QR code may look like this: www.anz.com.au;335c4aa74dd88aa76ddff 1 234ffcc99, for example. [0075] The QR code image will be displayed temporarily on the screen of the donor electronic device 105 and the recipient has a corresponding smart phone application (which is connected to their bank account) which may scan the QR code image which is on the screen of the donor electronic device 105. The recipient's smart phone application may use their banks SOAP/HTTPS to send the details of the transaction to the recipient bank server 130. Together with the details provided by the donor (in the form of the QR code) the recipient interface will accept the details of the recipient (i.e. customer id and password) so the system knows where to transfer the donor funds to. [0076] Recipient bank server 130 checks the destination DNS address of the transaction. In the event the destination is another bank, it may use an interbank interface to pass the transaction on together with the BSB/account number of the destination of the funds. In the event the recipient bank server 130 and donor bank server 125 are the same institution the transfer may happen immediately. 19 [0077] The donor bank server 130 then processes the message and the funds are provided to the destination account and the electronic funds record is deleted from the donor bank server 125 and/or archived. [0078] Whilst the invention has been described in relation to banks, it will be appreciated that the invention is also applicable to other financial institution, such as credit unions, building societies and the like. [0079] Although these exemplary embodiments of the invention have been disclosed for illustrative purposes, those skilled in the art will appreciate that various modifications, additions and substitutions are possible without departing from the scope of the present invention. Therefore, the present invention is not limited to the above described embodiments but is defined by the following claims. 20

Claims (17)

1. A method of electronically transferring funds between a donor and a recipient, the method including: (a) generating and storing an electronic funds record at a donor financial institution server, the electronic funds record including at least a record identifier and data indicative of a cash value of the electronic funds record; (b) transmitting at least the record identifier to an electronic device associated with a donor in data communication with the donor financial institution server; (c) receiving at least the record identifier at the donor financial institution server from a recipient financial institution server, whereby the recipient financial institution server obtained the record identifier via the donor electronic device; (d) processing the record identifier at the donor financial institution server to ensure that the record identifier is valid and to determine a funds amount to be transferred; and (e) electronically transferring funds corresponding to the cash value of the electronic funds record to the recipient financial institution server.
2. The method of claim 1, wherein at step (c) the recipient financial institution server obtains the record identifier from a recipient server via the donor electronic device.
3. The method of claim 1 or 2, wherein at step (c), the method further includes providing a recipient identifier together with the record identifier.
4. The method of any one of the preceding claims, wherein at step (c), the method further includes providing a financial institution identifier together with the record identifier.
5. The method of any one of the preceding claims, further including the step of: (f) archiving the electronic funds record in at the donor financial institution server. 21
6. The method of any one of the preceding claims wherein at step (d) the method further includes the step of validating the electronic funds record at the donor financial institution server based on at least one predetermined criteria.
7. The method of claim 6, wherein the predetermined criteria includes an expiry time associated with the electronic funds record.
8. The method of claim 6, wherein the predetermined criteria includes a password associated with the electronic funds record.
9. The method of any one of the preceding claims, wherein the electronic funds record further includes an owner of the electronic funds record.
10. The method of any one of the preceding claims, wherein the electronic funds record further includes a currency type.
11. The method of any one of the preceding claims, wherein the method further includes the step of encrypting the record identifier prior to being received at the recipient financial institution server.
12. The method of any one of the preceding claims, wherein the record identifier is a 128 bit number.
13. The method of any one of the preceding claims, wherein the record identifier is graphically represented by a QR code.
14. The method of any one of the preceding claims, wherein at step (c), the recipient financial institution server obtains the record identifier from the donor electronic device via near field communication.
15. The method of any one of the preceding claims, wherein the donor is a customer and the recipient is a vendor and at step (c) the recipient financial institution 22 server obtains the record identifier from the customer electronic device for purchase of goods or services.
16. The method of any one of the preceding claims, wherein at step (e) funds are electronically transferred corresponding to the cash value of the goods or services purchased by the customer from the cash value of the electronic funds record to the recipient financial institution server to complete the purchase of the goods or services.
17. A system for electronic transfer of funds between a donor and a recipient, the system including: a donor financial institution server for generating and storing an electronic funds record, the electronic funds record including a record identifier and data indicative of a cash value of the electronic funds record; the donor financial institution server being adapted to transmit at least a record identifier to an electronic device associated with a donor in data communication with the donor financial institution server; and a recipient financial institution server in data communication with the donor financial institution server for receiving at least the record identifier from a donor electronic device; wherein the donor financial institution server is in data communication with the recipient financial institution server electronically to transfer funds corresponding to the cash value of the electronic funds record to the recipient financial institution server. 23
AU2014201752A 2013-04-23 2014-03-24 Method and system for secure electronic funds transfer Abandoned AU2014201752A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2014201752A AU2014201752A1 (en) 2013-04-23 2014-03-24 Method and system for secure electronic funds transfer

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
AU2013901422A AU2013901422A0 (en) 2013-04-23 Method and system for secure electronic funds transfer
AU2013901422 2013-04-23
AU2014201752A AU2014201752A1 (en) 2013-04-23 2014-03-24 Method and system for secure electronic funds transfer

Publications (1)

Publication Number Publication Date
AU2014201752A1 true AU2014201752A1 (en) 2014-11-06

Family

ID=51844425

Family Applications (1)

Application Number Title Priority Date Filing Date
AU2014201752A Abandoned AU2014201752A1 (en) 2013-04-23 2014-03-24 Method and system for secure electronic funds transfer

Country Status (1)

Country Link
AU (1) AU2014201752A1 (en)

Similar Documents

Publication Publication Date Title
US20230153791A1 (en) In-store card activation
US10229454B2 (en) Process of and apparatus for notification of financial documents and the like
US20180330342A1 (en) Digital asset account management
US11455682B2 (en) Instant bank account verification through debit card network
US8301500B2 (en) Ghosting payment account data in a mobile telephone payment transaction system
US20160012526A1 (en) Account security via an electronic token
US20170111493A1 (en) Automated user information provision using images
US20170270531A1 (en) Account notifications for required information to complete a financial transaction
US20140164228A1 (en) Methods and systems for value transfers using a reader device
JP2016536673A (en) Payment system and method mediated by intermediaries
US20140297517A1 (en) Mobile check book
US20120173436A1 (en) Method and system for authorizing, authenticating, implementing, brokering data transfers, and collecting fees for data transfers among distributed electronic devices and servers
US20120233021A1 (en) Online Transaction System
KR20110129735A (en) The internet loan system where the quick loan is possible
AU2014201752A1 (en) Method and system for secure electronic funds transfer
US11907801B2 (en) System for encoding resource access credential in barcode
KR100698398B1 (en) Method to handle guarantee process for electronic commerce
US20130173425A1 (en) Consumer-initiated financial transaction based on sales-side information
KR100876589B1 (en) Point processing method and system according to fund subscription and recording medium therefor
KR20090007537A (en) Method for managing affiliated store account
PH12018050140A1 (en) System for, method of, and computing apparatus for utilizing an electronic transaction account in a digital asset management environment
KR20090060009A (en) Transaction(or application) of addmission electronic documents, device for operating electronic documents
KR20090020975A (en) System for processing mobile gift certificate account and mobile terminal device, program recording medium
KR20080104084A (en) System and method for managing affiliated store account and program recording medium
KR20130110435A (en) Agent system for payment

Legal Events

Date Code Title Description
MK5 Application lapsed section 142(2)(e) - patent request and compl. specification not accepted