AU2014100959B4 - Transaction interface with translator - Google Patents

Abstract

TRANSACTION INTERFACE WITH TRANSLATOR Abstract Disclosed herein are a method for presenting a transaction interface in relation to a financial transaction, comprising the steps of: displaying a transaction interface to a user; receiving a numerical input value in a first field of said transaction interface; processing the numerical input value; and displaying the transaction interface to the user with a validation cue based on said processed numerical input value, wherein said validation cue includes a translated word amount corresponding to said numerical input value.

Description

AUSTRALIA Patents Act 1990 Innovation Patent Specification Title: TRANSACTION INTERFACE WITH TRANSLATOR Applicant(s): SMART GORILLA PTY LIMITED Inventor(s): Jake Edward Allan Alastair Hood Charles Morton Agent: © COTTERS Patent & Trade Mark Attorneys The following is a full description of the invention which sets forth the best method known to the applicant of performing it.

2 TRANSACTION INTERFACE WITH TRANSLATOR Related Application [0001] This application is related to Australian Provisional Patent Application No. 2014902082 entitled "A method for preventing computer errors", filed on 31 May 2014 in the name of MVP IP Pty Ltd, and Australian Provisional Patent Application No. 2014903100 entitled "A transaction interface", filed on 8 August 2014 in the name of MVP IP Pty Ltd, the entire content of each of which is incorporated herein by reference. Technical Field [0002] The present disclosure relates to a transaction interface and, in particular, to a transaction interface for use in financial transactions. Background [0003] It is increasingly common for people to access computing devices during financial transactions. Such computing devices may include, for example, personal computers, smartphones, or tablet devices running software applications ("apps') or displaying web browsers. The computing devices may also include automated teller machines (ATMs) for accessing bank accounts. [0004] The financial transactions may relate, for example, to managing bank accounts, such as through the transfer of funds from one account to another. This may include, for example, but is not limited to, transfer of funds between multiple accounts of a user, transfer of funds between different accounts within a single financial institution, transfer of funds between multiple financial institutions, and payments from a first account in a financial institution to a commercial trading entity. The financial transactions may also relate to online stock trading, management of superannuation funds, and the like. [0005] Electronic banking is now widespread, whereby a user uses a computing device to access and manage bank accounts. Further, a significant amount of commerce is now conducted in an online environment, such as via the Internet, whereby a user uses a computing device to access financial institutions or purchase a product from a website. Further electronic banking includes a user accessing an ATM to access a bank account. [0006] A common error in electronic banking is for a user to make an incorrect financial transaction, as a result of the user entering incorrect account or transaction details. Such 3 erroneous transactions may arise from incorrect account details or an incorrect amount being entered by the user. In such circumstances, it is common for the bank involved not to return money to the account holder in cases of incorrect financial transactions, even if a reversal of the incorrect financial transaction is possible. The liability is pushed onto the user. [0007] Thus, a need exists to provide an improved transaction interface. Summary [0008] The present disclosure relates to a transaction interface for use in financial transactions. [0009] In a first aspect, the present disclosure provides a method for presenting a transaction interface in relation to a financial transaction, comprising the steps of: displaying a transaction interface to a user; receiving a numerical input value in a first field of the transaction interface; processing the numerical input value; and displaying the transaction interface to the user with a validation cue based on the processed numerical input value, wherein the validation cue includes a translated word amount corresponding to the numerical input value. [0010] In one implementation, the transaction interface includes an audio activation device for playing an audio translation of the numerical input value. [0011] In another implementation, the method highlights a most significant value of the translated word amount. [0012] In a second aspect, the present disclosure provides a computer-implemented graphical user interface for use in relation to a financial transaction, comprising: a first field for receiving a numerical input value relating to the financial transaction; and a validation cue based on the numerical input value, wherein the validation cue includes a translated word amount corresponding to the numerical input value. [0013] In one implementation, a most significant value of the translated word amount is highlighted. [0014] According to another aspect, the present disclosure provides an apparatus for implementing any one of the aforementioned methods.

4 [0015] According to another aspect, the present disclosure provides a computer program product including a computer readable medium having recorded thereon a computer program for implementing any one of the methods described above. [0016] Other aspects of the present disclosure are also provided. Brief Description of the Drawings [0017] One or more embodiments of the present disclosure will now be described by way of specific example(s) with reference to the accompanying drawings, in which: [0018] Fig. la is a flow diagram illustrating a method of displaying a transaction interface with a validation cue; [0019] Fig. lb is a flow diagram illustrating a method of displaying a transaction interface with a visual validation cue; [0020] Figs 2a to 2c are schematic block diagram representations of embodiments of a transaction interface for translating an input numerical value to words; [0021] Fig. 3 is a schematic representation of a system on which one or more embodiments of the present disclosure may be practised; [0022] Fig. 4 is a schematic block diagram representation of a system that includes a general purpose computer on which one or more embodiments of the present disclosure may be practised; [0023] Fig. 5 is a schematic block diagram representation of a system that includes a general smartphone on which one or more embodiments of the present disclosure may be practised; [0024] Fig. 6 is a flow diagram illustrating a method of displaying a transaction interface with a validation cue; [0025] Figs 7a to 7c are schematic block diagram representations of embodiments of a transaction interface with a visual validation cue; [0026] Fig. 7d is a schematic representation of a Transaction Legend with a voice activation button; [0027] Fig. 7e is a schematic representation of a Transaction Legend; [0028] Fig. 7f is a schematic representation of a Transaction Legend, illustrating formatting of a transaction band corresponding to a numerical input value; 5 [0029] Fig. 7g is a schematic representation of a Transaction Legend, illustrating formatting of a numerical input value presented to a first field; [0030] Figs 8a to 8c are schematic block diagram representations of embodiments of a transaction interface with an audio validation cue; [0031] Fig. 9a is a schematic block diagram representation of a transaction interface with validation cues for account details and a numerical input value; [0032] Fig. 9b is an example of the first display region of the transaction interface of Fig. 9a; [0033] Figs 10a and 10b are schematic block diagram representations of a transaction interface; [0034] Fig. 10c is a schematic block diagram representation of an alternative interface that enables a user to customise a transaction interface; [0035] Fig. 11 is a schematic block diagram representation of a transaction interface with a validation cue for selecting a payee; [0036] Fig. 12 is a screenshot of a transaction interface; and [0037] Fig. 13 is a screenshot of a verification pages of a transaction interface. Detailed Description [0038] Method steps or features in the accompanying drawings that have the same reference numerals are to be considered to have the same function(s) or operation(s), unless the contrary intention is expressed or implied. [0039] The present disclosure provides a method and system for presenting a transaction interface for use in financial transactions. In the context of this application, a transaction interface refers to a user interface for receiving input from a user in relation to a financial transaction. The transaction interface may include one or more screens of a graphical user interface presented to a user from within a website or other online presence, such as a portal. In another arrangement, the transaction interface includes one or more screens presented on a display device of an ATM. In another arrangement, the transaction interface may be one or more screens displayed by a software application provided by a third party service provider for authorising payments, such as PayPal or the like. The transaction interface may be displayed on any display associated with a computing device, including, but not limited to, a personal computer, laptop computer, 6 smartphone, tablet device, smartwatch, Google Glass, ATM, Point of Sale (POS) machine, and the like. [0040] A financial transaction is any transaction involving consideration of some form and may include, but is not limited to: payment of funds in relation to a retail transaction; payment of a bill or invoice using BPay or other payment gateway; transfer of funds from one account to another; buying, selling, or trading shares or other property; gambling, including placement of bets or other wagers, and the purchase of lottery tickets and the like; and online banking transactions, either within a single account or between multiple accounts. [0041] A transaction engine is used to generate or display the transaction interface. In one arrangement, a transaction engine is part of a software application stored in a memory of a computing device and executing on one or more processors of the computing device. In one implementation, the software application is an "app" residing on a portable computing device, such as a smartphone or tablet device. In another implementation, the software application executes on a server and controls display of content, including the transaction interface, on a website. [0042] The transaction interface includes at least one field for receiving a numerical input value from a user relating to a financial transaction. The numerical input value may be, for example, but is not limited to, a value of an amount of money to be transferred or a value or number of shares to be bought, sold, or transferred. The method processes the numerical input value and displays the user interface with a validation cue (or prompt) based on the numerical input value. The validation cue acts as a prompt for the user to confirm that the numerical input value is correct before proceeding with the financial transaction. [0043] In an alternative arrangement, a transaction interface includes at least one field for receiving a textual input value from a user in relation to a financial transaction, wherein a textual input value is a quantity or value expressed in words. The method processes the textual input value and displays the transaction interface with a validation cue based on the textual input value. In one implementation, the validation cue is a translated numerical amount corresponding to the value of the textual input value. [0044] Fig. la is a flow diagram illustrating a method 100 of displaying a user interface for financial transactions. The method 100 begins at a Start step 105 and proceeds to step 110, which displays a user interface on a display device of a computing device 7 accessed by a user. The user interface includes a first field for receiving a numerical user input from the user in relation to a financial transaction. It will be appreciated by those skilled in the relevant art that the first field need not be the initial field presented in the user interface and may be presented in association with one or more other fields or input devices for receiving user input. Such other fields for receiving user input may relate, for example, to banking details of a party to which funds are to be transferred or a date on which the financial transaction is to be scheduled. Input devices may include text fields, calendars, drop-down boxes, and the like. [0045] In step 115, the method receives a numerical input value in the first field and step 120 processes the numerical input value. Step 125 displays the user interface with a validation cue based on the numerical input value. Control passes to step 130 and the method 100 terminates. [0046] People process information in different ways. The general population can be divided into having preferences for aural (or auditory), visual or kinaesthetic stimuli when processing information. When information is presented in a single way, such as only using numbers, a proportion of the population will not process the information intuitively. For example, some people, especially colour-blind individuals, like to see numbers presented as words, rather than numerals. Accordingly, the transaction interface of the present disclosure provides multiple stimuli for cognitive processing, in order to reduce human error. Information presented to a user in a first manner serves to reinforce the same information presented to the user in a second manner. Providing a transaction interface that presents a number in both numerical form and word form helps to engage an additional human sense to assist the individual confirm that the correct amount has been entered. [0047] In one arrangement, the transaction interface includes a field or display region that displays a word translation of a numerical input value as the numerical input value is entered by the user. For example, a final amount a user wants to transfer is $97,674.63. As the consumer types 97 into a first field of a transaction interface, a second field displays in words "Ninety-seven". As the user types the remaining digits 674.63 of the numerical input value into the first field, the content of the second field changes to reflect the additional funds proposed to be transferred; therefore, the second field displays "Ninety-seven Thousand Six Hundred and Seventy-four Dollars and Sixty Three Cents". In this example, the first letter of each word is capitalized to aid in readability. In an 8 alternative arrangement, the highest denomination is formatted to highlight the quantum of the amount. Such formatting may include, for example, displaying the highest denomination in bold font, a different colour, capital letters, underlined, in italics, or the like. [0048] Fig. lb is a flow diagram illustrating a method 150 embodying aspects of the present disclosure, in which the method of displaying a transaction interface uses a validation cue that is a translation of a received numerical input value into words. The method 150 begins at a Start step 155 and proceeds to step 160, in which the method 150 displays a transaction interface to a user in relation to a financial transaction. [0049] Control passes to step 165, which receives a numerical input value in a first field of the transaction interfaces. Step 170 processes the numerical input value by translating the numerical input value from numbers to words. For example, a received numerical input value of "$123.50" is translated into "One hundred and twenty-three dollars and fifty cents". The translation of the numbers to words may be performed using any one of many known translation devices. Alternatively, a built-in translator may be used. In one implementation, the translator uses a look-up table to match numbers to words and processes the number of digits to determine the respective quantities, from most significant amount to least significant amount. [0050] Control passes to step 175, which displays the translated words within the transaction interface. In one arrangement, the translated words are displayed in a region of the transaction interface adjacent to or beneath the first field in which the user provided the numerical input value. The translated words are a validation cue to the user that prompts the user to check that the input amount is correct. Control passes from step 175 to step 180 and the method 150 terminates. [0051] Figs 2a to 2c are schematic block diagram representations of embodiments of a transaction interface for translating an input numerical value to words. Fig. 2a shows a transaction interface 200 for receiving user input in relation to a financial transaction. The transaction interface 200 includes a first field 210 for receiving a numerical user input and a second field 215 for displaying a validation cue based on said numerical user input. The transaction interface 200 optionally includes other fields for displaying information relating to the financial transaction and other fields for receiving other user input. For the sake of clarity and succinctness, those other fields are not illustrated, but may include for 9 example, without being limited to, fields relating to account details, username, password, scheduled transaction date, reference number or identifier, and the like. [0052] In one implementation, the transaction interface 200 displays delimiting commas in a received numerical input value after every three digits, such that an input amount of 1000000 is displayed as 1,000,000. This provides a visual cue of the quantum being handled in that financial transaction. [0053] Fig. 2b shows the transaction interface 200 of Fig. 2a, wherein the user has provided a numerical input value of "1457" into the first field 210. The second field 215 displays a validation cue to the user in the form of a translated form of the numerical input value into words. In this example, the second field 215 displays "One Thousand Four Hundred and Fifty Seven", corresponding to "1457" entered into the first field 210. The validation cue prompts the user to confirm that numerical input value is correct. If the user intended to enter "14.57" into the first field 210, then the validation cue in the second field 215 presented to the user assists the user in identifying that the numerical input value is incorrect. [0054] It will be appreciated that many forms and locations of the second field 220 may be implemented without departing from the spirit and scope of the present disclosure. Fig. 2c shows an alternative implementation of a transaction interface 250, in which the second field 220 is presented without a delimiting box surrounding the second field 220. In this implementation, the most significant value of the numerical input value is highlighted by being presented in capitals in the translated word. Thus, the received numerical input value of "1457" is displayed in the second field 220 as "ONE THOUSAND four hundred and fifty seven". In different implementations, other formatting may equally be applied to distinguish the most significant value. Such formatting may include colours, fonts (e.g., bold, italics), underlining, highlighting, and the like. [0055] Fig. 3 is a schematic block diagram representation of a system 300 on which embodiments of the present disclosure may be practised. The system 300 includes a server 301 operated by or for a financial institution that provides online access to user accounts. The server 301 includes a processor and memory (not shown) for storing software for displaying a transaction interface. [0056] The server 301 also includes a processing module 310 for processing a received numerical input value. In one arrangement, the processing module 310 includes a translator for translating a received numerical input value into words. In a further 10 arrangement, the processing module 310 includes a translator for translating a received numerical input value into an audible validation cue, such as an audio representation of the numerical input value. In a further arrangement, the processing module 310 maps the received input value against a predefined scale of input values and determines a validation cue based on the mapping. In a further arrangement, the processing module 310 determines a validation cue based on the received input value and a transaction history associated with the user. [0057] The server 301 further includes a user interface module 312 for storing templates, graphics, and other information required to present the transaction interface to a display device of a computing device accessed by a user. [0058] The server 301 further includes a client database 314 for storing information associated with clients registered with the financial institution. In one arrangement, each registered client has an associated client profile stored in the client database 314, wherein the client profile includes client information. The client information may include, for example, the client name, contact details, account numbers, username, password, and other bibliographic information. The client information may also include transaction history of the client, relating to past financial transactions conducted by the client. [0059] The server 301 is coupled to a communications network 390, which may be implemented using one or more wired or wireless networks, including the Internet. [0060] The system 300 also includes a computing device 320 utilised by a first user to register with the server 301. In one implementation, a first user accesses the first computing device 320 to download a software application ("app") to the first computing device 320 from the server 301 via the communications network 390. The first computing device 320 may be, for example, a general purpose computing device, a mobile phone, a smartphone, or a tablet computing device. The first user accesses the app executing on a processor of the first computing device 320 to register with the server 301 and perform financial transactions relating to the financial institution administering the server 301. In such an implementation, the app includes a transaction engine for processing input presented by the first user and generating content and formatting to be displayed as a transaction interface to the first user. In an alternative arrangement, the first user uses the first computing device 320 to access a website hosted by the server 301, wherein the first user uses a browser to interact with the financial institution and perform financial transactions. In such an implementation, the 11 server 301 includes a transaction engine for processing input presented by the first user and generating content and formatting to be displayed as a transaction interface to the first user in the form of one or more webpages of the website. [0061] The system 300 also includes an ATM 340 that can be accessed by a user to view an account balance, withdraw funds, transfer funds, and deposit funds. In this example, the ATM 340 is coupled to the network 390 and is able to communicate with the server 301 via the network 390. In one implementation, the ATM includes a processor and computer software stored within memory of the ATM such that the software executing on the processor provides a transaction interface to a user of the ATM. In an alternative implementation, the server 301 provides the transaction interface to a display device of the ATM via the network 390. [0062] The system 300 also shows a second computing device 330 coupled to the network 390 and that can be accessed by a second user to communicate with the server 301. The system 300 further includes a Point of Sale (POS) terminal 350 that can be used to effect a financial transaction with a customer. Such a POS terminal 350 may be a standalone terminal, such as a kiosk, an external device coupled to a computer or cash register, or an integrated device forming part of another computing device. In the example of Fig. 3, the POS terminal 350 is coupled to the communication network 390. The system 300 also includes a retail computer 360 coupled to the network 390. The retail computer 360 represents an online retailer from which a user of the first computing device 320 can purchase goods or services. Such a retailer may be, but is not limited to, a traditional purveyor of goods and services, a bank or financial institution, stockbroker, gambling outlet, retail portal, and the like. [0063] The transaction interface of the present disclosure may be practised using a computing device, such as a general purpose computer or computer server. Fig. 4 is a schematic block diagram of a system 400 that includes a general purpose computer 410. The general purpose computer 410 includes a plurality of components, including: a processor 412, a memory 414, a storage medium 416, input/output (I/O) interfaces 420, and input/output (I/O) ports 422. Components of the general purpose computer 410 generally communicate using one or more buses 448. [0064] The memory 414 may be implemented using Random Access Memory (RAM), Read Only Memory (ROM), or a combination thereof. The storage medium 416 may be implemented as one or more of a hard disk drive, a solid state "flash" drive, an optical 12 disk drive, or other storage means. The storage medium 416 may be utilised to store one or more computer programs, including an operating system, software applications, and data. In one mode of operation, instructions from one or more computer programs stored in the storage medium 416 are loaded into the memory 414 via the bus 448. Instructions loaded into the memory 414 are then made available via the bus 448 or other means for execution by the processor 412 to effect a mode of operation in accordance with the executed instructions. [0065] One or more peripheral devices may be coupled to the general purpose computer 410 via the I/O ports 422. In the example of Fig. 4, the general purpose computer 410 is coupled to each of a speaker 424, a camera 426, a display device 430, an input device 432, a printer 434, and an external storage medium 436. The speaker 424 may be implemented using one or more speakers, such as in a stereo or surround sound system. In the example in which the general purpose computer 410 is utilised to implement the first or second computing devices 320, 330, one or more peripheral devices may relate to a monitor, a keyboard, a computer mouse or other input device connected to the I/O ports 422. [0066] The camera 426 may be a webcam, or other still or video digital camera, and may download and upload information to and from the general purpose computer 410 via the I/O ports 422, dependent upon the particular implementation. For example, images recorded by the camera 426 may be uploaded to the storage medium 416 of the general purpose computer 410. Similarly, images stored on the storage medium 416 may be downloaded to a memory or storage medium of the camera 426. The camera 426 may include a lens system, a sensor unit, and a recording medium. [0067] The display device 430 may be a computer monitor, such as a cathode ray tube screen, plasma screen, or liquid crystal display (LCD) screen. The display 430 may receive information from the computer 410 in a conventional manner, wherein the information is presented on the display device 430 for viewing by a user. The display device 430 may optionally be implemented using a touch screen to enable a user to provide input to the general purpose computer 410. The touch screen may be, for example, a capacitive touch screen, a resistive touchscreen, a surface acoustic wave touchscreen, or the like. [0068] The input device 432 may be a keyboard, a mouse, a stylus, drawing tablet, microphone, or any combination thereof, for receiving input from a user. The external 13 storage medium 436 may include an external hard disk drive (HDD), an optical drive, a floppy disk drive, a flash drive, or any combination thereof and may be implemented as a single instance or multiple instances of any one or more of those devices. For example, the external storage medium 436 may be implemented as an array of hard disk drives. [0069] The I/O interfaces 420 facilitate the exchange of information between the general purpose computing device 410 and other computing devices. The I/O interfaces may be implemented using an internal or external modem, an Ethernet connection, or the like, to enable coupling to a transmission medium. In the example of Fig. 4, the I/O interfaces 422 are coupled to a communications network 438 and directly to a computing device 442. The computing device 442 is shown as a personal computer, but may be equally be practised using a smartphone, laptop, or a tablet device. Direct communication between the general purpose computer 410 and the computing device 442 may be effected using a wireless or wired transmission link. [0070] The communications network 438 may be implemented using one or more wired or wireless transmission links and may include, for example, a dedicated communications link, a local area network (LAN), a wide area network (WAN), the Internet, a telecommunications network, or any combination thereof. A telecommunications network may include, but is not limited to, a telephony network, such as a Public Switch Telephony Network (PSTN), a mobile telephone cellular network, a short message service (SMS) network, or any combination thereof. The general purpose computer 410 is able to communicate via the communications network 438 to other computing devices connected to the communications network 438, such as the mobile telephone handset 444, the touchscreen smartphone 446, the personal computer 440, and the computing device 442. [0071] One or more instances of the general purpose computer 410 may be utilised to implement a server hosting a website to provide a transaction interface in accordance with the present disclosure or a computing device accessed by a user for displaying a transaction interface to enable the user to perform a financial transaction. In such an embodiment, the memory 414 and storage 416 are utilised to store data relating to a graphical user interface, translation data, and transaction data. Software for implementing the transaction interface is stored in one or both of the memory 414 and storage 416 for execution on the processor 412. The software includes computer program code for effecting method steps in accordance with the method of displaying a transaction interface described herein.

14 [0072] Fig. 5 is a schematic block diagram of a system 500 on which one or more aspects of a transaction interface for use in financial transactions may be practised. The system 500 includes a portable computing device in the form of a smartphone 510, which may be used by a registered user of the financial services system 301 in Fig. 3. The smartphone 510 includes a plurality of components, including: a processor 512, a memory 514, a storage medium 516, a battery 518, an antenna 520, a radio frequency (RF) transmitter and receiver 522, a subscriber identity module (SIM) card 524, a speaker 526, an input device 528, a camera 530, a display 532, and a wireless transmitter and receiver 534. Components of the smartphone 510 generally communicate using one or more bus connections 548 or other connections therebetween. The smartphone 510 also includes a wired connection 545 for coupling to a power outlet to recharge the battery 518 or for connection to a computing device, such as the general purpose computer 410 of Fig. 4. The wired connection 545 may include one or more connectors and may be adapted to enable uploading and downloading of content from and to the memory 514 and SIM card 524. [0073] The smartphone 510 may include many other functional components, such as an audio digital-to-analogue and analogue-to-digital converter and an amplifier, but those components are omitted for the purpose of clarity. However, such components would be readily known and understood by a person skilled in the relevant art. [0074] The memory 514 may include Random Access Memory (RAM), Read Only Memory (ROM), or a combination thereof. The storage medium 516 may be implemented as one or more of a solid state "flash" drive, a removable storage medium, such as a Secure Digital (SD) or microSD card, or other storage means. The storage medium 516 may be utilised to store one or more computer programs, including an operating system, software applications, and data. In one mode of operation, instructions from one or more computer programs stored in the storage medium 516 are loaded into the memory 514 via the bus 548. Instructions loaded into the memory 514 are then made available via the bus 548 or other means for execution by the processor 512 to effect a mode of operation in accordance with the executed instructions. [0075] The smartphone 510 also includes an application programming interface (API) module 536, which enables programmers to write software applications to execute on the processor 512. Such applications include a plurality of instructions that may be pre-installed in the memory 514 or downloaded to the memory 514 from an external 15 source, via the RF transmitter and receiver 522 operating in association with the antenna 520 or via the wired connection 545. [0076] The smartphone 510 further includes a Global Positioning System (GPS) location module 538. The GPS location module 538 is used to determine a geographical position of the smartphone 510, based on GPS satellites, cellular telephone tower triangulation, or a combination thereof. The determined geographical position may then be made available to one or more programs or applications running on the processor 512. [0077] The wireless transmitter and receiver 534 may be utilised to communicate wirelessly with external peripheral devices via Bluetooth, infrared, or other wireless protocol. In the example of Fig. 5, the smartphone 510 is coupled to each of a printer 540, an external storage medium 544, and a computing device 542. The computing device 542 may be implemented, for example, using the general purpose computer 410 of Fig. 4. [0078] The camera 530 may include one or more still or video digital cameras adapted to capture and record to the memory 514 or the SIM card 524 still images or video images, or a combination thereof. The camera 530 may include a lens system, a sensor unit, and a recording medium. A user of the smartphone 510 may upload the recorded images to another computer device or peripheral device using the wireless transmitter and receiver 534, the RF transmitter and receiver 522, or the wired connection 545. [0079] In one example, the display device 532 is implemented using a liquid crystal display (LCD) screen. The display 532 is used to display content to a user of the smartphone 510. The display 532 may optionally be implemented using a touch screen, such as a capacitive touch screen or resistive touchscreen, to enable a user to provide input to the smartphone 510. [0080] The input device 528 may be a keyboard, a stylus, or microphone, for example, for receiving input from a user. In the case in which the input device 528 is a keyboard, the keyboard may be implemented as an arrangement of physical keys located on the smartphone 510. Alternatively, the keyboard may be a virtual keyboard displayed on the display device 532. [0081] The SIM card 524 is utilised to store an International Mobile Subscriber Identity (IMSI) and a related key used to identify and authenticate the user on a cellular network to which the user has subscribed. The SIM card 524 is generally a removable card that 16 can be used interchangeably on different smartphone or cellular telephone devices. The SIM card 524 can be used to store contacts associated with the user, including names and telephone numbers. The SIM card 524 can also provide storage for pictures and videos. Alternatively, contacts can be stored on the memory 514. [0082] The RF transmitter and receiver 522, in association with the antenna 520, enable the exchange of information between the smartphone 510 and other computing devices via a communications network 590. In the example of Fig. 5, RF transmitter and receiver 522 enable the smartphone 510 to communicate via the communications network 590 with a cellular telephone handset 550, a smartphone or tablet device 552, a computing device 554 and the computing device 542. The computing devices 554 and 542 are shown as personal computers, but each may be equally be practised using a smartphone, laptop, or a tablet device. [0083] The communications network 590 may be implemented using one or more wired or wireless transmission links and may include, for example, a cellular telephony network, a dedicated communications link, a local area network (LAN), a wide area network (WAN), the Internet, a telecommunications network, or any combination thereof. A telecommunications network may include, but is not limited to, a telephony network, such as a Public Switch Telephony Network (PSTN), a cellular (mobile) telephone cellular network, a short message service (SMS) network, or any combination thereof. [0084] Fig. 6 is a flow diagram illustrating a method 600 of displaying a transaction interface with a validation cue based on a numerical input value. In this embodiment, the transaction interface formats a field based on a numerical input value provided by a user to that field. The method 600 begins at a Start step 605 and passes to step 610, which displays a transaction interface to a user. In a following step 615, the transaction interface receives a numerical input value from a user in a field of the transaction interface. [0085] Step 620 processes the numerical input value and step 625 formats a component of the transaction interface based on the numerical input value. The component may be, for example, a field of the transaction interface, a region of the transaction interface, an entry displayed within the transaction interface, or other content within the transaction interface. In one implementation, the component is the input field that receives and displays the numerical input value. In another implementation, the component is a field in which a translated word is displayed, corresponding to the numerical input value. In a 17 further implementation, the component is a region of the transaction interface, such as a portion of a display relating to the numerical input value. In a yet further arrangement, the component is the numerical value input. [0086] The formatting applied to the component may vary from one application to another and may include, for example, but is not limited to, colour, font, pattern, shading and the like of the relevant component. Depending on the implementation, different formatting corresponds to different levels of alert. [0087] One implementation colours the field that displays the numerical input value based on the size of the numerical input value relative to a predefined scale. In one example, amounts in the range of $0 - $99 are formatted using the colour green, amounts in the range $100 - $999 are coloured blue, amounts in the range $1,000 to $9,999 are coloured orange, and amounts above $10,000 are coloured red. Formatting the field in this way provides a visual cue to the user of the quantum of the amount that has been input. [0088] In an alternative implementation, the system processes the numerical input value relative to previous transactions made by the user. If the numerical input value falls within a predefined range of transactions previously made by that user, then the system formats the component accordingly, such as by using the colour green or a normal font. If the numerical input value falls beyond a predefined range of transactions previously made by that user, then the system formats the component accordingly, such as by using the colour red or by presenting the numerical input value in bold or a different colour from a standard font colour. [0089] In one implementation, for a financial transaction relating to the transfer of funds to a third party, such as payment of a bill, the system analyses previous transactions made between that user and the third party and formats the component based on whether the proposed current transaction falls within the bounds of previous transactions. For example, if the user has previously paid rent of $1,200.00 on a monthly basis to a real estate agent for the last 14 months and then provides a numerical input value of $120,000 for a proposed transfer to the real estate agent, as a result of omitting the decimal point, the system formats the component in a way to alert the user that the proposed transaction is anomalous. In such a case, the component may be, for example, a translated word amount that appears in red.

18 [0090] Step 630 displays the transaction interface with the formatted component. The method 600 terminates at an End step 635. [0091] Figs 7a to 7c are schematic block diagram representations of embodiments of a transaction interface with a visual validation cue. Fig. 7a shows a transaction interface 700 for receiving user input in relation to a financial transaction. The transaction interface 700 includes a first field 710 for receiving a numerical input value and a second field 715 for displaying a validation cue based on said numerical user input. The transaction interface 700 optionally includes other fields for displaying information relating to the financial transaction and other fields for receiving other user input. For the sake of clarity and succinctness, those other fields are not illustrated. [0092] In the example of Fig. 7a, the first field 710 receives a numerical input value of "1457", such as referring to the value of shares to be transferred. The system processes the numerical input value and displays a translated word "ONE THOUSAND Four Hundred and Fifty Seven" in a second field 715. In this example, the system formats the most significant amount of the translated word in bold font. [0093] In the example of Fig. 7b, the transaction interface formats the second field 715 based on a mapping of the numerical input value against a predefined scale. In this example, amounts in the range of $0 to $500 are identified using a thatched pattern 730, amounts in the range of $501 to $1,000 are identified using a left to right downward sloping diagonal pattern 732, amounts in the range of $1,001 to $10,000 are identified using a left to right upward sloping diagonal pattern 734, and amounts in the range of $10,000 + are identified using a horizontal pattern 736. As the received numerical input value in this example is "1457", the transaction interface formats the second field using the left to right upward sloping pattern, shown as a border 720 of the second field 715. In an alternative embodiment, shown in Fig. 7c, the entire second field is formatted using the left to right upward sloping pattern. In further embodiments, not illustrated, the transaction interface formats the first field 710 or another region of the transaction interface 700, alone or in combination with formatting of the second field 715. [0094] A further arrangement relates to a transaction interface with an audio validation cue. A numerical input value provided by a user to a first input field of a transaction interface is converted to an audio representation of that numerical input value. The transaction interface optionally includes an audio activation button that is able to be activated by the user in order to have the transaction interface play the audio 19 representation of the numerical input value to the user, via a loudspeaker. In one implementation, the audio representation is a simple echo of the numerical input value, so "1234" is played as "One Two Three Four". In another implementation, the audio representation accounts for the values associated with each digit, in which case "1234" is played as "One Thousand Two Hundred and Thirty Four". [0095] The audio activation button is optionally associated with a set of controls to modify the audio representation. Such controls may modify, for example, a volume at which the audio representation is played, a selection of male or female voice, bass and treble values, and the like. [0096] In one arrangement, a user uses the microphone 528 of the smartphone 510 to provide voice activated controls to the transaction interface. In such an arrangement, the transaction interface translates received audio content into a numerical input value to be displayed in a first field of the transaction interface. The transaction interface optionally translates the numerical input value into words to be displayed in a second field to provide a second validation cue to the user. [0097] For example, a user verbally speaks to into a microphone 432 of the computing device 410 to make a financial transaction. Fig. 7d is a schematic block diagram representation of a transaction interface 790 adapted for verbal input using a microphone activation button 795. In this example, the user wants to transfer $97,674.63 to another party via internet/mobile banking. It may be appreciated that the user may press a button to enable voice-activated commands, such as the button 795, or the user may optionally elect to have voice activation enabled. The user then speaks the words "Ninety-Seven Thousand Six-hundred and Seventy-Four Dollars, and Sixty-three cents". The number amount is received by the transaction interface, translated into a numerical input value and displayed in a first field of the transaction interface as "$97,674.63". [0098] One arrangement provides a colour-coded validation cue by formatting a first field for receiving a numerical value input based on a predefined scale of transaction amounts. In this example, the scale is referred to as a Transaction Legend. The letters of "PAY CHECK" form an acronym to match colours with transaction amounts. Each colour is divided into specific intervals. Fig. 7e is a schematic representation of one embodiment of a Transaction Legend. [0099] In another implementation, the application analyses the transaction history of a customer to divide the colours into amounts most regularly used by that customer, so 20 that the customer can see more clearly when they have made an error. In this way, for some people $10 dollar error increments are important. For others, $1,000 dollar error increments are important. [00100] Table 1 provides an example of how colours may be assigned to corresponding transaction amounts, making it easy for consumers to see how much they are sending. Colour Corresponding transaction amount ($) Purple 100,000,000-1,000,000,000 Aqua 10,000,000-99,999,999 Yellow 1,000,000-9,999,999 Crimson 100,000-999,999 Hollywood Blue 10,000-99,999 Emerald 1,000-9,999 Carrot 100-999 Khaki 0-99 Table 1 [00101] This feature ensures that the consumer sends the correct money transfer amounts. As the consumer types an amount they wish to transfer in a transaction amount field (the first field 710), the background colour or other parameter associated with that field changes to reflect the corresponding colour and transfer amount in the "Transaction Legend". Such parameters may include, for example, formatting, fonts, borders, shading, styles, and the like. For instance, the final amount the consumer wishes to transfer is $97,674.63. As the user types 97, the transaction field will glow/highlight in one colour (Khaki), then as the user types 674.63, the bar will automatically change colour to Hollywood Blue to reflect the additional funds proposed to be transferred and the transaction legend. [00102] In a further implementation, when the transaction amount field is formatted in a particular colour, the transaction interface formats the corresponding row in the Transaction Legend. This provides a further validation cue to help the users more noticeably see in which transaction increment the user intends to send money. Formatting may include, for example, enlarging the relevant row or drawing a box around the relevant row of the Transaction Legend. If a box already exists around the row in the Transaction Legend, then a further line in the form of a box may be implemented. It will be appreciated that the colour of the line may take the colour form of the associated 21 colour. In a further implementation, the box and the associated number amount are highlighted in bold font. Furthermore, formatting may include an arrow or other indicia to point to the transaction increment in the Transaction Legend to further highlight the proposed transaction increment to the user. [00103] In another implementation, the transaction interface optionally provides a collapsed or condensed view of the Transaction Legend, such that only a row of the Transaction Legend corresponding to an input amount is displayed. This condensed view provides a cleaner interface and may be better adapted for a smaller display. In one arrangement, the transaction interface collapses the Transaction Legend after the user stops typing for a predefined period of time, for example 2 seconds. The predefined period of time and option to collapse the Transaction Legend are optionally configurable by the user or by the organisation or financial institution, via profile settings. If the user wants to change the number entered in the input field, the Transaction Legend expands for ease of use and greater visibility so that the user can view the highlighted row corresponding to the present input value relative to other rows in the Transaction Legend. In an alternative implementation, the full Transaction Legend is shown on the transaction details page, however the transaction interface only displays a collapsed view of the Transaction Legend in a verification page. [00104] Fig. 7f is a schematic representation of a Transaction Legend, illustrating formatting of a transaction band corresponding to a numerical input value. In this example, the transaction band H corresponding to a transaction amount of $10,000 to $99,999 is displayed with a surrounding box and an arrow. Fig. 7g is a schematic representation of a Transaction Legend, illustrating formatting of a numerical input value presented to a first field 710 and a corresponding translated word presented in a second field 715. [00105] In one arrangement, the financial institution defines the amounts and increments in the Transaction Legend. In another arrangement, the Transaction Legend is customisable by a user. While this example uses 8 bands in the Transaction Legend, it will be appreciated that any number of bands may equally be practised without departing from the spirit and scope of the present disclosure. [00106] Figs 8a to 8c are schematic block diagram representations of embodiments of a transaction interface with an audio validation cue. Fig. 8a shows a transaction interface 800 for receiving user input in relation to a financial transaction. The 22 transaction interface 800 includes a first field 810 for receiving a numerical input value and an audio activation device 820 for providing an audio translation of the numerical input value. The transaction interface 800 optionally includes other fields for displaying information relating to the financial transaction and other fields for receiving other user input. For the sake of clarity and succinctness, those other fields are not illustrated. [00107] In the example of Fig. 8b, the first field 810 receives a numerical input value of "$821.15". The system processes the numerical input value and, in this example, displays a translated word "Eight Hundred and Twenty-one dollars and Fifteen Cents" in a second field 815. If the user activates the audio activation device 820, such as by using a computer mouse to click on the audio activation device 820 or by pressing on a screen displaying the audio activation device on a computing device equipped with a touchscreen, the transaction interface translates the numerical input value and plays an audio translation of the numerical input value to a loudspeaker associated with a computing device displaying the transaction interface. [00108] Fig. 8c is a further example showing the transaction interface 800 with a first field 810 for receiving a numerical input value, a second field 815 for displaying a translated word version of the numerical input value, and an audio activation device 820 that enables a user to play an audio translation of the numerical input value. In this example, the transaction system formats the second field 815 based on the numerical input value, as described above with reference to Fig. 6 and Figs 7a to 7g. In another arrangement, the audio activation device 820 is adapted to play an audio translation of one or more fields on the transaction interface 800. Such fields may include, for example, the first field 810, as shown, as well as fields relating to account details, not shown. In one example, the audio activation device 820 is adapted to play an audio translation of an account number, account name, BSB code, BPAY Electronic Funds Transfer (EFT) code, or the like. In one implementation, the transaction interface highlights a portion of a field of the transaction interface 800 as an audio translation of the content of that field is played to a loudspeaker of a computing device. Thus, in one example the first field 810 receives a numerical input value of "1234". The user presses the audio activation device 820 and the transaction engine translates the numerical input value to an audio output to be played through a loudspeaker. As the audio output is played, the corresponding portion of the numerical input value "1234" is highlighted, such as being presented in bold font. Thus, as the audio translation announces "one thousand", the "1" in "1234" is presented 23 in bold font or a different colour relative to the other portions of the numerical input value. [00109] In one arrangement, a user is able to modify settings associated with a user profile of the financial institution associated with the server 301. Such settings may include, for example, whether to play an audio translation of a numerical input value automatically or only in response to activation of the audio activation device 820. Such settings may also include the ability to customise formatting applied to one or more components of the transaction interface, based on a received numerical input value, and the components to which the formatting is applied. In one implementation, the user is able to customise one or more ranges that are associated with different formatting, thus enabling the user to create a user-defined scale against which a numerical input value is mapped. In another arrangement, settings associated with a user profile are able to be changed by the financial institution. This allows the financial institution to implement a common user experience across a set or group of customers. [00110] Fig. 9a is a schematic block diagram representation of a transaction interface 900 with validation cues for account details and a numerical input value. The transaction interface 900 includes a first display region 901 for receiving inputs relating to an account to which funds are to be transferred. In this example, the first display region 901 includes an account number field 902 for receiving an account number, a BSB field 904 for receiving a Bank State Branch (BSB) number, and an account name field 906 for receiving an account name. It will be appreciated that the first display region 901 may include any number of different fields for receiving information relating to an intended recipient of a financial transaction and that the present disclosure is not limited to the Australian bank account details described in this example. For example, the first display region 901 optionally includes a field for receiving an identifier or other reference number to identify or authenticate a payer, payee, account, biller, invoice number, or the like. Further, the identifier may optionally relate to a username to authenticate a party in the financial transaction via an intermediary portal, such as a social media website (e.g., Facebook, Twitter), payment gateway (e.g., PayPal), mobile telephone number, or email address. [00111] In one arrangement, the server 301 contains or is coupled to a database of all valid accounts. As a user provides inputs to the fields 902, 904, 906, the server 301 determines whether the inputs are valid. In one implementation, the fields 902, 904, 906 24 are presented in a default colour, such as grey. If valid inputs are presented by the user to the fields 902, 904, 906, the fields 902, 904, 906 are formatted in a colour, such as green, to indicate that the inputs are valid. In an alternative implementation, the fields 902, 904, 906 remain in the default colour to indicate that the inputs are valid. If the server determines that one or more of the inputs provided to fields 902, 904, 906 are either invalid or are invalid as a combination, the server formats the relevant fields in a different colour, such as red, to provide a validation cue to the user indicating that one or more of the inputs is incorrect. [00112] In a further implementation, the fields 902, 904, 906 are associated with a token 908 that provides a validation cue as to whether or not the inputs provided to fields 902, 904, 906 are valid. In this example, the token 908 resembles a padlock, which is shown in an open condition when the inputs to fields 902, 904, 906 are valid and in a closed condition when one or more of those inputs or a combination of those inputs is invalid. [00113] In the example of Fig. 9a, the transaction interface 900 includes a second display region 905 that includes a first field 910 for receiving a numerical input value and a second field 915 for displaying a translation of that numerical input value into words. [00114] In a further arrangement, the transaction interface 900 includes a verification check. A user is able to click a button (not shown) to request that the server 301 verifies information provided to fields 902, 904, 906. When a user activates the check, the server 301 uses information input to fields 902, 904, 906 to verify the recipient information. In one implementation, the server 301 sends a query to a database of registered businesses, such as the Australian Securities & Investments Commission (ASIC) to check business name details, or a database of valid accounts. In another implementation, the server 301 sends a query to a database of registered accounts, such as a database maintained by or on behalf of BPAY, PayPal, or other payment gateway or collective financial group, including any other infrastructure or overlay service relating to any real time payment platforms. [00115] In a further arrangement, the user provides inputs to the account number field 902 and the BSB field 904, or other identifier as described above. The transaction engine receives the inputs from the fields 902, 904 and sends a query to a relevant database to confirm the validity of the account number and BSB pairing entered by the user. If the pairing is valid, the transaction engine retrieves the associated account name 25 from the relevant database and populates the account name field 906 with the retrieved account name. [00116] Fig. 9b is a screenshot illustrating an example of the first display region 901. In this example, the account number field 902 receives an account number "Account B", the BSB field 904 receives a Bank State Branch (BSB) number "023456", and the account name field 906 receives the account number "12345678". The server authenticates each entry and the combination of entries and, in this case, determines that the entries and the combination of entries is valid. Accordingly, each field 902, 904, 906 is formatted to present a validation cue to the user that correct account details have been entered. In one implementation, the fields 902, 904, 906 are formatted green to indicate that valid inputs have been received and red to indicate that one or more invalid inputs have been received. As described above, alternative implementations of the first display region 901 may include one or more other fields for receiving an identifier or other reference number to identify and/or authenticate a party in the financial transaction, an account, an invoice number, or the like. In another arrangement, verification of the account details in fields 902, 904, 906 is shown using the token 908. In one example, the token 908 is a padlock that changes colour to red to indicate an invalid combination of account details entered in fields 902, 904, 906 and changes colour to green to indicate a valid combination of account details entered in fields 902, 904, 906. [00117] Fig. 10a is a schematic block diagram representation of a transaction interface 1000. The transaction interface 1000 includes a first field 1010 for receiving a numerical input value and a second field 1015 for displaying a translated word corresponding to the numerical input value. The transaction interface 1000 also includes an account name field 1002, a BSB field 1004, and an account number field 1006. In this example, the transaction interface 1000 includes a token 1008 indicating whether inputs provided to the account name field 1002, BSB field 1004, and account number field 1006 are valid. In an alternative implementation, the transaction interface 1000 includes one or more other fields for receiving an identifier or reference number, as described above, to identify and/or authenticate a party in the transaction, an account, an invoice number, or the like. [00118] The example of Fig. 10a also includes an audio activation device 1020 that a user can activate to have the transaction interface 1000 play an audio translation of the numerical input value presented to first field 1010. The transaction interface 1000 further 26 includes a Transaction Legend 1050 that provides a visual cue to the user of the quantum involved in the financial transaction. In this example, the numerical input value of "$97,674.63" maps to band H in the Transaction Legend 1050 and thus band H is formatted to provide a further validation cue to the user. In this particular example, a box and arrow 1055 are associated with band H in the Transaction Legend 1050. [00119] Fig. 10b is a schematic block diagram representation of a transaction interface 1000, illustrating functionality to enable a user to enable or disable various features. As a user hovers an input device over a component of the transaction interface 1000, the transaction interface optionally displays a "-" sign associated with that component. Pressing the "-" sign deactivates that component. In an alternative arrangement, pressing the "-" sign deactivates and hides that component. This allows a user to customise the transaction interface. Fig. 10c is a schematic block diagram representation of an alternative interface 1090 that enables a user to customise the transaction interface. [00120] Fig. 11 is a schematic block diagram representation of a transaction interface 1100 with a validation cue for selecting a payee. As noted with reference to Fig. 3, the server 301 includes a client database 314 that optionally stores a transaction history for each client. The transaction interface analyses previous payments and provides a visual cue as to whether a selected or intended payee corresponds to the transaction history. [00121] In the example of Fig. 11, a user wants to pay "James Smith". In the transaction history stored in the client database 314, there are two contacts labelled "James Smith". One James Smith is a plumber and to whom the user pays on average $100 per transaction. The other James Smith is a business associate to whom the consumer pays on average $10,000. In this example, the transaction interface 1100 provides a drop down list of contacts 1110 from which the user can select a payee. The transaction interface formats each contact according to an average amount paid to that contact over a predefined past time period. [00122] In the example of Fig. 11, the contacts entry for James Smith (plumber) is formatted in colour Carrot, corresponding to band C of the Transaction Legend and the contact entry for James Smith (Business Associate) is formatted in colour Emerald, corresponding to band E of the Transaction Legend.

27 [00123] In one implementation, the user (payor) can type the name of the payee. As the user types the name of the payee, the transaction interface autosuggests contacts from the payees in the transaction history of the payor. The user can optionally ignore the suggested contacts and type the name of the intended payee. In an alternative implementation, the user populates the name of the payee via voice activation. The user may then select a payee from the list of suggested contacts. If there are two people of the same name, the application will ask the user whether they mean for instance the plumber or business associate. In one implementation, each contact is automatically associated with a colour from the Transaction Legend depending upon the average transaction size sent to user. In another implementation, the Transaction Legend colour, which glows behind the name of the contact only lasts for when the user is selecting a contact, after which time the name returns to a default user interface text/font etc. (e.g., black text). In a further implementation, the Transaction Legend colour is used when the users hover over each contact with a computer mouse, or clicks on it on smart device, but only for that time period or a predefined time period. The predefined time period may be set by the user or alternatively the organisation or financial institution. [00124] Fig. 12 is a screenshot of a transaction interface 1200 relating to a payment made using BPAY. The transaction interface 1200 includes a Biller Code field 1210, a Biller Name field 1212, a Biller Nickname field 1214, a Reference field 1216, an Amount field 1218, and a Translated Amount field 1220. The transaction interface 1200 also includes a Description field 1222. In the example of Fig. 12, the transaction interface further includes a Transaction Legend 1230 that includes a set of rows corresponding to different ranges of values. In this example, the transaction interface 1200 highlights a row of the Transaction Legend 1230 corresponding to a value of an amount received in the Amount field 1218. In this example, the transaction interface 1200 includes a first audio activation device 1232, that when pressed by a user generates an audio translation of the amount in the Amount field 1218. The transaction interface 1200 further includes a second audio activation device 1234, that when pressed by a user generates an audio translation of the reference identifier entered into the Reference field 1216. [00125] In one arrangement, the transaction interface includes a verification page that is displayed to the user in response to the user pressing a "Submit" button in relation to a financial transaction. The verification page provides a summary of details relating to the financial transaction before the transaction engine processes the financial transaction. In one implementation, the verification page includes one or more of account information 28 relating to a payor, account information relating to a payee, and a value of funds or other property to be transferred from the payor to the payee. In this example, payor refers to the user making the transaction and payee refers to the recipient of the funds, shares, or other property that is to be transferred. Transfer in this context can include, but is not limited to, a payment, allocation of shares, purchase amount, rental amount, lease amount, or the like. [00126] Fig. 13 is a screenshot of a verification page 1300 relating to a transaction using the BPAY payment system. The verification page 1300 includes an Amount field 1318 that includes the numerical amount involved in the financial transaction, which in this example is a payment of $1,321.49 from Jake Allan to James Smith. A Translated Amount field 1320 provides a translation of the amount in the Amount field 1318 into words, to act as a validation cue to the user that the correct amount is being transferred. The verification page 1300 further includes a Transaction Legend 1330. In this example, Row H of the Transaction Legend is highlighted to provide a second validation cue to the user of the amount to be transferred, as Row H corresponds to the range of $1,000 to $1,999. An audio activation device 1335 is available for the user to press if the user wants to hear an audio translation of the amount in the Amount Field 1318. [00127] The transaction interface optionally includes in the verification page a translation of a payment amount from numerals to words. The transaction interface further optionally includes a transaction legend, such as the Transaction Legend of Figs 7c to 7g. In one implementation, the payment amount is displayed in a colour in accordance with a corresponding match in the Transaction Legend, thus providing the user with a visual cue of the quantum involved in the proposed financial transaction. The verification page further optionally includes an audio activation button adapted to play an audio translation of the payment amount and/or other entries in the verification page. The verification page includes an option for the user to continue or cancel the proposed transaction. Other Embodiments [00128] One embodiment provides a method for presenting a transaction interface in relation to a financial transaction, comprising the steps of: displaying a transaction interface to a user; receiving a numerical input value in a first field of the transaction interface; processing the numerical input value; and 29 displaying the transaction interface to the user with a validation cue based on the processed numerical input value. [00129] In one arrangement, the validation cue includes formatting applied to a component of the transaction interface. In one implementation, the component is the first field and formatting includes displaying the first field in a predefined colour. In another implementation, the predefined colour is determined by mapping the numerical input value to a predefined transaction legend defining a plurality of bands of transaction amounts, wherein each band of the scale is associated with a colour. [00130] In another arrangement, the validation cue includes a translated word amount corresponding to the numerical input value. [00131] In a further arrangement, the validation cue includes an audio translation of the numerical input value. [00132] In a yet further arrangement, the transaction interface includes a transaction legend defining a plurality of bands of transaction amounts, and the validation cue includes highlighting a band of the transaction legend corresponding to the numerical input value. In one implementation, processing the numerical input value includes mapping the numerical input value to a band of the transaction legend. [00133] In one arrangement, processing the numerical input value includes comparing the numerical input value to a stored transaction history associated with the user. [00134] One embodiment provides a computer-implemented graphical user interface for use in relation to a financial transaction, comprising: a first field for receiving a numerical input value relating to the financial transaction; and a validation cue based on the numerical input value. [00135] In one arrangement, the validation cue includes a translated word amount corresponding to the numerical input value. [00136] In another arrangement, the validation cue includes formatting applied to the first field. [00137] In a further arrangement, the graphical user interface further comprises: a transaction legend defining a plurality of bands of transaction amounts, wherein the validation cue includes highlighting a band of the transaction legend corresponding to the numerical input value.

30 [00138] In a yet further arrangement, the graphical user interface further comprises: an audio activation device adapted to play an audio translation of the numerical input value. [00139] In another arrangement, the graphical user interface further includes a display region for receiving inputs relating to an account to which funds are to be transferred. Industrial Applicability [00140] The arrangements described are applicable to the financial industries and particularly for the banking, investment, payment gateways, retail sector, and online trading industries. [00141] The foregoing describes only some embodiments of the present invention, and modifications and/or changes can be made thereto without departing from the scope and spirit of the invention, the embodiments being illustrative and not restrictive. [00142] In the context of this specification, the word "comprising" and its associated grammatical constructions mean "including principally but not necessarily solely" or "having" or "including", and not "consisting only of". Variations of the word "comprising", such as "comprise" and "comprises" have correspondingly varied meanings. [00143] As used throughout this specification, unless otherwise specified, the use of ordinal adjectives "first", "second", "third", "fourth", etc., to describe common or related objects, indicates that reference is being made to different instances of those common or related objects, and is not intended to imply that the objects so described must be provided or positioned in a given order or sequence, either temporally, spatially, in ranking, or in any other manner. [00144] Although the invention has been described with reference to specific examples, it will be appreciated by those skilled in the art that the invention may be embodied in many other forms.

Claims (5)

1. A method for presenting a transaction interface in relation to a financial transaction, comprising the steps of: displaying a transaction interface to a user; receiving a numerical input value in a first field of said transaction interface; processing the numerical input value; and displaying the transaction interface to the user with a validation cue based on said processed numerical input value, wherein said validation cue includes a translated word amount corresponding to said numerical input value.

2. The method according to claim 1, wherein said transaction interface includes an audio activation device for playing an audio translation of said numerical input value.

3. The method according to either one of claims 1 and 2, comprising the further step of: highlighting a most significant value of said translated word amount.

4. A computer-implemented graphical user interface for use in relation to a financial transaction, comprising: a first field for receiving a numerical input value relating to the financial transaction; and a validation cue based on said numerical input value, wherein said validation cue includes a translated word amount corresponding to said numerical input value.

5. The graphical user interface according to claim 4, wherein a most significant value of said translated word amount is highlighted. SMART GORILLA PTY LIMITED By Patent Attorneys for the Applicant ©COTTERS Patent & Trade Mark Attorneys