Systems, methods and computing programs for monitoring of accounting platform activity

Abstract

A computer-implemented-method providing, by accounting platform server, an accounting platform in a cloud computing environment, wherein the accounting platform is configured to gather accounting data and provide accounting services to the plurality of users. The method comprises importing from a financial institution, financial data for each of a plurality of users having a user account with the accounting platform, receiving from an event logging engine, a request to receive event notifications; transmitting to the event logging engine, over a first period of time, a plurality of event notifications; after the period of time, sending to the event logging engine, a request for one or more event objects associated with the account or a group of similar accounts; receiving, from the event logging engine, a dataset of event objects; and training a model based on the dataset of event objects to provide a trained model.

Description

[0001] "Systems, methods and computing programs for monitoring of accounting platform activity"

[0002] Technical Field

[0003] [1] Described embodiments relate to systems, computing -implemented methods and computing programs for monitoring of accounting platform activity. Some embodiments relate to techniques for performing quality control assessments of accounting platform activity, for example to detect accounting mistakes. Some embodiments relate to techniques for detecting fraud based on accounting platform activity, and thereby providing improved accounting platform security. Some embodiments relate to techniques for auditing accounts with an accounting platform.

[0004] Background

[0005] [2] Some prior art methods for monitoring activity on digital service platforms, such as accounting platforms, involve collecting periodic database snapshots to track or monitor changes in the database and determine user activity therefrom.

[0006] [3] It is desired to address or ameliorate some of the disadvantages associated with such prior methods and systems, or at least to provide a useful alternative thereto.

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

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

[0009] [6] Some embodiments relate to a computer-implemented-method comprising: providing, by accounting platform server, an accounting platform in a cloud computing environment, wherein the accounting platform is configured to gather accounting data and provide accounting services to the plurality of users; importing, by the accounting platform server, and from a financial institution, financial data for each of a plurality of users having a user account with the accounting platform, wherein the accounting platform is configured to import the financial data over a network through a bank feed or document, or over a network via an application protocol interface; receiving, by the accounting platform server, from an event logging engine, a request to receive event notifications, wherein each event notification is indicative of an action taken on an account associated with the accounting platform; transmitting, by the accounting platform server to the event logging engine, over a first period of time, a plurality of event notifications, each event of the plurality of the action notifications comprising one or more action attributes; after the period of time, sending by the accounting platform server to the event logging engine, a request for one or more event objects associated with the account or a group of similar accounts; receiving, from the event logging engine, a dataset of event objects; and training a model based on the dataset of event objects to provide a trained model.

[0010] [7] In some embodiments, the method further comprises providing, by the accounting platform server, account credentials of the plurality of users to the financial institution to obtain access to the financial data for the plurality of users.

[0011] [8] The trained model may be trained to detect instances of fraud, potential fraud and / or attempted fraud on the accounting platform. The action may be a login attempt indicative of an attempt by a user to log onto the accounting platform, wherein the one or more action attributes of the action event notification comprise one or more of: Internet Protocol (IP) address, Internet Service Provider (ISP), user or device location, and device identifier. The trained model may be configured to evaluate a risk of a specific login event based on an input comprising values for one or more of: InternetProtocol (IP) address, Internet Service Provider (ISP), user or device location, and device identifier. The dataset of event objects may comprise examples of historic login attempts associated with one or more users or accounts.

[0012] [9] In some embodiments, the method further comprises: receiving a candidate login event, the login event comprising one or more attribute values for one or more of: Internet Protocol (IP) address, Internet Service Provider (ISP), user or device location, and device identifier; providing the attribute values as an input to the trained model; and determining an output indicative of likely fraud.

[0013]

[0010] In some embodiments, the method further comprises: responsive to determining an output indicative of likely fraud, instigating one or more mitigation actions, wherein the mitigation actions comprise: issuing a notification to a relevant user and / or organisation associated with the candidate login attempt to notify them that a potentially fraudulent login attempt was made on their account; providing an opportunity to the a relevant user and / or organisation to verify the login attempt as a verified or true login attempt; and / or enhancing the security of the account.

[0014]

[0011] In some embodiments, the method further comprises: retraining the ML model using the candidate login attempt as a training example to improve its accuracy in predicting fraudulent login attempts.

[0015]

[0012] Some embodiments relate to a computer-implemented-method comprising: receiving, by an accounting platform, from an event logging engine, a request to receive action notifications, wherein each action notification is indicative of an accounting action taken on an account associated with an accounting platform provided by the accounting platform server; transmitting, to the event logging engine, an action notification, the action notification comprising one or more action attributes indicative of an action; sending, to the event logging engine, a request for one or more event objects associated with the account; receiving, from the event logging engine, a dataset of event objects; and determining from the dataset behaviours indicative of the account.

[0013] Some embodiments relate to a computer-implemented-method comprising: computer-implemented method comprising: sending, by an accounting platform, to an event logging engine, a request for a plurality of event objects, the request comprising one or more event object criteria; receiving, by the accounting platform, from the event logging engine, the plurality of event objects, each of the event objects being associated with an account of an accounting platform and at least some of the event object criteria; determining, from the plurality of event objects, a first dataset of event objects, each of the event objects of the first dataset being indicative of a first financial attribute of the account; determining, from the plurality of event objects, a second dataset of event objects, each of the event objects of the second dataset being indicative of a second financial attribute of the account; and comparing the first dataset and the second dataset to determine an indication of whether fraud has been detected.

[0016]

[0014] Some embodiments relate to a computer-implemented method comprising: sending, by an accounting platform, to an event logging engine, a request for a plurality of event objects; receiving, by the accounting platform, from the event logging engine, the plurality of event objects, each of the plurality of event objects being associated with an account of an accounting platform; determining, from the plurality of event objects, one or more quality control attributes; determining, from at least the plurality of event objects, one or more ground truth attributes; determining, by comparing the quality control attributes with the one or more ground truth attributes, an indication of the quality of the plurality of event objects.

[0017]

[0015] Some embodiments relate to a computer-implemented method comprising: sending by an accounting platform, to an event logging engine, a request for a plurality of event objects, the request comprising a time period; receiving, by the accounting platform, from the event logging engine, the plurality of event objects, each of the plurality of event objects being associated with an account of an accounting platform, and comprising information relating to activities that occurred on the account during the time period; determining, from the plurality of event objects, one or more account histories indicative of one or more behaviours of the account over the time period; anddetermining from the one or more account histories, one or more behaviour characteristics of the account over the time period.

[0018]

[0016] In some embodiments, the method further comprises importing into user data, by the accounting platform in a cloud computing environment, financial data for each of a plurality of users having a user account with the accounting platform, wherein the accounting platform is configured to access and import banking data over a network through a bank feed or document, or over a network via an application protocol interface, wherein the accessing the banking data comprises providing account credentials of the plurality of users to obtain access to the banking data for the plurality of users, and wherein the accounting platform is configured to gather accounting data and provide accounting services to the plurality of users.

[0019]

[0017] In some embodiments, the method further comprises receiving, at the accounting platform server, from a financial system, an authorization to link a financial account at the financial system with a bookkeeping account at the accounting platform server, the accounting platform server maintaining bookkeeping accounts for a plurality of entities, the authorization identifying a first user associated with a first entity of the plurality of entities; based on the receiving of the authorization identifying the first user, linking the bookkeeping account associated with the first entity to the authorized financial account; registering, by the accounting platform server, for a bank record feed from the financial system, the registering using the authorization from the financial system; responsive to the registering for the bank record feed, receiving financial account data related to the financial account from the financial system; generating accounting data related to the bookkeeping account using the financial account data; and storing the accounting data in a database.

[0020]

[0018] In some embodiments, the method further comprises storing, at a primary data center storage layer, the imported financial data for each of the plurality of users having a user account with the platform; and replicating the primary data center storage layer in a secondary data center storage layer, including replicating the imported financial data for each of the plurality of users having a user account with the platform, so thatthe imported financial data for each of the plurality of users having a user account with the accounting platform is consistent at the secondary data center storage layer and the primary data center storage layer.

[0021]

[0019] In some embodiments, the accounting platform is provided by a primary data center comprising a plurality of pods, each pod comprising one or more application server virtual machines that are specific to the pod, and the plurality of pods collectively providing an internal services virtual machine that is shared between the plurality of pods, and wherein the internal services virtual machine provides back-end tools for the application server virtual machines and / or monitoring tools to an application hypervisor monitoring the application server virtual machines.

[0022]

[0020] In some embodiments, the accounting platform is provided in a cloud computing environment, and wherein the accounting platform server provides the accounting platform by a primary data center in an online state and comprising one or more pods, each pod comprising one or more application server virtual machines that are specific to the pod, and in case of a fault in the primary data center, the accounting platform server provides the accounting platform by a secondary data center in an online state, the secondary data center comprising one or more pods to which the one or more pods of the primary data center are replicated, respectively.

[0023]

[0021] In some embodiments, while the primary data center is in an online state, maintaining the secondary data center in an offline state in which energy consumption is reduced relative to power consumption in the online state of the secondary data center; and in response to the primary data center developing a fault, changing a state of the secondary data center from the offline state to an online state in which the secondary data center is providing the accounting platform in the cloud computing environment, and changing a state of the primary data center to an offline state.

[0024]

[0022] In some embodiments, the method further comprises, while the primary data center is in the online state, balancing load between the one or more pods of theprimary data center; and while the secondary data center is in the online state, balancing load between the one or more pods of the secondary data center.

[0025]

[0023] Some embodiments relate to a system comprising: one or more processors; and memory comprising computer code, which when executed by the one or more processors, causes the system to perform any one of the described methods.

[0026]

[0024] Some embodiments relate to a machine -readable medium storing computer readable code, which when executed by one or more processors is configured to perform any one of the described methods.

[0027] Brief Description of Drawings

[0028]

[0025] Figure 1 is a block diagram of a system for monitoring accounting platform activity, according to some embodiments;

[0029]

[0026] Figure 2 is a block diagram depicting an example hosting infrastructure for the accounting platform, according to some embodiments;

[0030]

[0027] Figure 3 is a depicting an example data centre system of the system for monitoring accounting platform activity, according to some embodiments;

[0031]

[0028] Figure 4 is a process flow diagram of a computer-implemented method for monitoring accounting platform activity, according to some embodiments;

[0032]

[0029] Figure 5 is a process flow diagram of a computer-implemented method for monitoring accounting platform activity to detect fraud or attempted fraud, according to some embodiments;

[0033]

[0030] Figure 6 is a process flow diagram of a computer-implemented method for monitoring accounting platform activity to perform quality control, according to some embodiments;

[0031] Figure 7 is a process flow diagram of a computer-implemented method for monitoring accounting platform activity to perform auditing, according to some embodiments; and

[0034]

[0032] Figure 8 is a block diagram depicting an example data flow for interactions between the banking platform and the accounting platform, according to some embodiments.

[0035] Description of Embodiments

[0036]

[0033] Described embodiments relate to systems, computer-implemented methods and computer programs for improved monitoring of accounting platform activity. Some embodiments relate to techniques for performing quality control assessments of accounting platform activity, for example to detect accounting mistakes, and in some examples, to suggest and / or make corrections. Some embodiments relate to techniques for detecting fraud based on accounting platform activity, and thereby providing improved accounting platform security, and in some examples, providing suggestions for improved security and / or making modifications to the accounting platform to mitigate future fraudulent activity. Some embodiments relate to techniques for auditing accounts with an accounting platform.

[0037]

[0034] Some prior art methods for monitoring activity on digital service platforms, such as accounting platforms, involve collecting periodic database snapshots or performing fetching runs to track or monitor changes in the database and determine user activity therefrom. However, how up to date the determined user activity is depends on the how regularly the snapshots are acquired or fetching runs are performed. If the information is acquired too infrequently, the determined user activity may not be accurate or up to date. And if the information is acquired too frequently, computer resources (e.g., network connection resources, disk space, and / or computation power) may be ineffectively utilised. For example, performing collections too often can mean that no-up-dates are available, and consequently computing resources are wasted.

[0035] Performing fetching runs or acquiring snapshots according to a fixed contextual business logic for a respective database, or at a fixed time interval, may not achieve the desired result of acquiring the desired information, and can lead to suboptimal use of computational resources. For example, from time to time, databases alter their protocols or system configurations which may change how fetching applications interact with them, and accordingly connections between the fetching applications and the database may fail, or break. As a result, multiple attempts may be made before the information is successfully retrieved. This may result in a lag in the acquiring of data, and subsequent determination of user-activity, which may negatively impact downstream applications and decision engines.

[0038]

[0036] Timely retrieval and importation of the desired information to the relevant platforms or management systems means that the information available to the platform or management system is current or up to date. In the case of an accounting platform or system, this can assist in management of a user’s finances, allowing the user and / or their accountant to ensure the user’s bookkeeping accounts are up to date, reducing or eliminating any onus on the user or accountant to acquire or instigate the importation of the desired document to ensure currency. Furthermore, any data interrogation or data insights derived from the information have more integrity and are likely to more accurately reflect the reality of the determination at the time it is made.

[0039]

[0037] To provide a more resource efficient way of acquiring desired information, and / or to allow for more efficient scalability of underlying infrastructure of the system or platform, the described embodiments rely on eventing or event sourcing. Event sourcing is an architectural approach which is configured to keep track not only of a current state of a system, but also of an entire sequence of state transitions, or history of state transitions (i.e., events) that led to the current state. The events are the “source of truth” of the system from which the current state, or any past state is inferred.

[0040]

[0038] In particular, the described embodiments relate to using eventing or event sourcing to record an ordinal history of actions performed by a user of an account of a digital services platform, such as an accounting platform. In some embodiments, thedigital services platform is an accounting platform configured to perform accounting / bookkeeping actions such as issuing invoices for goods and / or services provided, payment of received invoices and / or bills, paying employees, calculating and / or paying tax or any other fmancial / book keeping activities. The accounting platform may be configured to manage accounting accounts for a plurality of organisations.

[0041]

[0039] Some embodiments relate to an event logging engine which subscribes to event notifications associated with digital service platform actions, such as entering data and / or altering data, sending messages (e.g. an invoice or request for funds), transferring funds or causing funds to be transferred, notification of financial transactions or payments, reconciliation of transaction, and / or login attempts. On receipt of an event notification, the event logging engine may be configured to create an event object for the event notification (which may comprise information derived from the event notification) and append the event object to an event log associated with the user or organisation.

[0042]

[0040] The event log comprises one or more event objects, linked in time sequence. The event log represents a historical record (which may be in the form of an ordered list) of actions performed by, on or through, or received at or by a digital services platform. The event log may be immutable; in other words, the event objects are not updated or changed in any way once they have been appended to the event log. Even if an error occurs, such as incorrectly entered data, and the error is subsequently corrected, a record of the incorrect data entry and the subsequent correction are both recorded. Accordingly, errors may be corrected, but the historical record remains unchanged.

[0043]

[0041] Digital services platforms that use mutable data structures such as a data store (i.e., non-eventing data stores) for action recordal and / or tracking may not support post-hoc (post data storage) feature design and implementation. For example, actions performed by accounts and / or users associated with accounts may alter the mutable data stored within a database and the only evidence is a change in the database value.Accordingly, multiple actions may be performed, causing multiple changes to the mutable database value, and the only indication of actions performed is the change from the last database value and the current database value.

[0044]

[0042] With non-eventing data stores, such use cases need to be anticipated and accommodated during the design process, or the design of the non-eventing data store needs to be updated to accommodate them. This requires additional upfront understanding and work to make sure any data that may be required is captured from the beginning to use later when the features are added, and / or modification to the system and database design when the feature is being added meaning no history of data is available for features that require history to work effectively.

[0045]

[0043] With eventing or event stores as the data store for, or supporting, such digital services platform action histories, with no additional forethought or work, a full history of data that may be required is captured in the event stream for the account and / or user associated with an account by the nature of how the described event logging engine and event data store function. Information isn’t lost since data is only ever added to the event log. All state transitions may be captured as the event logging engine subscribes to event changes. It is possible to reproduce any past state of the system. Data synchronization may be easier; since data that has been recently added can be determined, novelty can be propagated to other components of the system, which enables the building of materialised views (e.g. representing your data in search or analytics -optimized query engines such as ElasticSearch), and sending notifications (e.g. to a browser UI), etc.

[0046]

[0044] Described embodiments relating to accounting platforms, such as online accounting platforms, that use event storing architecture and are equipped with functionality to detect fraud and thereby improve security, perform audits and / or determine and / or correct mistakes by recording and making available an ordered comprehensive list of events / actions.

[0045] Figure 1 is a block diagram of a system 100 for recording / monitoring accounting platform activity. The system 100 may comprise client device 110, network 130, database 132, event logging engine 140, event store 160 and / or accounting platform server 170. The system 100 and its constituent components may be configured to work in concert to perform the any one of the methods, as described.

[0047]

[0046] The client device 110 may comprise a mobile or handheld computing device such as a smartphone or tablet, a laptop, or a PC, and may, in some embodiments, comprise multiple computing devices. The client device 110 may comprise one or more processor(s) 112, communicable with memory 118. The processor(s) 112 may comprise one or more microprocessors, central processing units (CPUs), application specific instruction set processors (ASIPs), application specific integrated circuits (ASICs) or other processors capable of reading and executing instruction code. The communications module 114 facilitates communications with components of the client device 110 across the network 130, such as: database 132, event logging engine 140 and / or accounting platform server or system 170. The communications module 114 may comprise a combination of network interface hardware and network interface software suitable for establishing, maintaining and facilitating communication over a relevant communication channel.

[0048]

[0047] The client device 110 may also comprise user interface 116 may comprise at least one output device, such as a display and / or speaker, for providing an output for the client device 110 and at least one input device, such as a touch-screen, a keyboard, mouse, microphone, video camera, stylus, push button, switch or other peripheral device that can be used for providing user input to the client device 110. In some embodiments, the user interface 116 comprises a display, a speaker, a microphone, and / or a video camera.

[0049]

[0048] The memory 118 may comprise one or more volatile or non-volatile memory types. For example, the memory 118 may comprise one or more of random access memory (RAM), read-only memory (ROM), electrically erasable programmable readonly memory (EEPROM) or flash memory. The memory 118 is configured to storeprogram code accessible by the processor(s) 112. The program code comprises executable program code modules. In other words, memory 118 is configured to store executable code modules configured to be executable by the processor(s) 112. The executable code modules, when executed by the processor(s) 112 cause the system 100 to perform certain functionality, as described in more detail below.

[0050]

[0049] In some embodiments, the memory 118 may comprise a browser application 118 which comprises computer executable code, which when executed by the one or more processors 112, is configured to allow client device 110 to access websites via network 130. The memory 118 may also comprise accounting platform app 122, which comprises computer executable code, which when executed by the one or more processors 112, is configured to allow the client device 110 to avail of the services of an accounting services platform via network 130.

[0051]

[0050] The browser application 120 may comprise executable program code that when executed by processor(s) 112, allows the client device 110 to access web pages and related services via network 130. In some embodiments, the client device 110 may access the accounting platform server 170 and use its functions via the browser application 120.

[0052]

[0051] The accounting platform application (or “app”) 122 may comprise executable program code that when executed by processor(s) 112, allows the client device to communicate with accounting platform server 170. The accounting platform app 122 may be downloaded to client device from app provision module 178, via an app marketplace (not shown), such as the android play store or Apple app store. In some embodiments, the accounting platform app 122 may be downloaded directly from a web page hosted by the accounting platform server 170, via the browser application 120.

[0053]

[0052] The network 130 may include, for example, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages,packets, signals, some combination thereof, or so forth. The network 130 may include, for example, one or more of: a wireless network, a wired network, an internet, an intranet, a public network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a public-switched telephone network (PSTN), a cable network, a cellular network, a satellite network, a fibre-optic network, some combination thereof, or so forth.

[0054]

[0053] The database 132, which may form part of or be local to the system 100, or may be remote from and accessible to the system 100, for example, via the communications network 130. The database 132 may be configured to store data associated with the system 100. The database 132 may be a centralised database. The database 132 may be a mutable data structure. The database 132 may be a shared data structure. The database 132 may be a data structure supported by database systems such as one or more of PostgreSQL, MongoDB, and / or ElasticSearch. The database 132 may be configured to store a current state of information or current values associated with various attributes (e.g., “current knowledge”).

[0055]

[0054] The event logging engine 140 may comprise one or more processor(s) 142, communications module 144 and / or memory 146. The processor(s) 142 may comprise one or more microprocessors, central processing units (CPUs), application specific instruction set processors (ASIPs), application specific integrated circuits (ASICs) or other processors capable of reading and executing instruction code. The communications module 144 facilitates communications with components across the network 130, such as the client device 110, the database 132 and / or the accounting platform server 170. The communications module 144 may comprise a combination of network interface hardware and network interface software suitable for establishing, maintaining and facilitating communication over a relevant communication channel.

[0056]

[0055] The memory 146 may comprise one or more volatile or non-volatile memory types. For example, memory 146 may comprise one or more of random access memory (RAM), read-only memory (ROM), electrically erasable programmable readonly memory (EEPROM) or flash memory. Memory 146 is configured to storeprogram code accessible by the processor(s) 142. The program code comprises executable program code modules. In other words, memory 146 is configured to store executable code modules configured to be executable by the processor(s) 142. The executable code modules, when executed by the processor(s) 142 cause the event logging engine 140 to perform certain functionality, as described in more detail below. For example, memory 146 may comprise a subscription module 148 and / or an event object management module 150.

[0057]

[0056] The subscription module 148 may be configured to subscribe to actions associated with systems, servers and / or computing devices such as client device 110, database 132, the financial services platform server 190 and / or accounting platform server 170. In some embodiments, the subscription module 148 may be configured to subscribe to receive notifications of actions associated with the accounting platform server 170. The subscription module 148 may be configured to receive action notifications from notification module 177 of the digital serve platform server 170.

[0058]

[0057] In some embodiments, the actions subscription module 148 may subscribe to the occurrence of activities that involve generating accounting data or records. For example, such activities may include issuing invoices, paying invoices, paying bills, sending bills, paying employees, issuing purchase orders, addressing business expenses, and / or paying superannuation / retirement plan payments. In other words, the actions subscription module 148 may subscribe to any action that results in a debit, credit, or change in net or gross financial amounts of any one or more financial accounts associated with the accounting platform. The event object management module 150 may be configured to respond to or address notifications received by the subscription module 148, or other requests received by the event logging engine 140.

[0059]

[0058] In some embodiments, the actions subscription module 148 may subscribe to the occurrence of notifications of financial data, such as bank data as may be imported from a financial institution of a financial services platform server 190, as discussed below. For example, the bank data may be a financial statement and may comprise oneor more transaction line items, indicative of payments to or from an account associated with an organisation or user.

[0060]

[0059] In some embodiments, the actions subscription module 148 may subscribe to the occurrence of the reconciliations of transactions, such as matching financial data, such as bank line items of bank statements with respective accounting data, such as invoices.

[0061]

[0060] In some embodiments, the actions subscription module 148 may subscribe to login in attempts by a user or organisation. The actions subscription module 148 may subscribe to changes in permissions or account settings., for example.

[0062]

[0061] The event store 160 may comprise one or a plurality or cluster of event logs, each configured to store one or more event streams associated with particular applications and / or systems and / or users. The event store 160 may comprise one or more sets of event logs 162, for the system 100. Each event log may be associated with a particular account associated with the accounting platform, and / or a particular user or organisation of the accounting platform. The event log comprises one or more event objects, linked in time sequence. The event store 160 and event logs 162 may be immutable; in other words, the event objects are not updated or changed in any way once they have been appended to the event log.

[0063]

[0062] The accounting platform server 170 may be configured to facilitate the operation of an accounting platform, such as an accounting platform. The accounting platform 170 may comprise one or more processor(s) 172, a communications module 174, and / or memory 176. The processor(s) 172 may comprise one or more microprocessors, central processing units (CPUs), application specific instruction set processors (ASIPs), application specific integrated circuits (ASICs) or other processors capable of reading and executing instruction code. The communications module 174 facilitates communications with components across the network 130, such as the client device 110, the database 132 and / or the event logging engine 140. The communications module 174 may comprise a combination of network interface hardware and networkinterface software suitable for establishing, maintaining and facilitating communication over a relevant communication channel.

[0064]

[0063] The accounting platform server 170 provides an accounting platform in a cloud computing environment. The accounting platform is configured to gather accounting data and provide accounting services to a plurality of users. In some embodiments, the accounting platform server 170 imports into user data, maintained for the plurality of users in memory 176, for example, financial or banking data for one or more of the plurality of users having a user account with the platform. The accounting platform server 170 may acquire access to the financial or banking data by providing account credentials of the plurality of users to one or more financial services platform server(s) or system(s) 190, as discussed in more detail below.

[0065]

[0064] The memory 176 may comprise one or more volatile or non-volatile memory types. For example, memory 176 may comprise one or more of random access memory (RAM), read-only memory (ROM), electrically erasable programmable readonly memory (EEPROM) or flash memory. Memory 176 is configured to store program code accessible by the processor(s) 172. The program code comprises executable program code modules. In other words, memory 176 is configured to store executable code modules configured to be executable by the processor(s) 172. The executable code modules, when executed by the processor(s) 172 cause the event logging engine 170 to perform certain functionality, as described in more detail below. For example, memory 176 may comprise a notification module 177, an app provision module 178, one or more platform communication module(s) 180, a fraud detection module 182, a quality control module 184 and / or an audit module 186.

[0066]

[0065] The notification module 177 may be configured to transmit or trigger event notifications to subscribers, such as an event logging engine 140. For example, the notification module 177 may be configured to monitor for specific events, for example, as may impact or be performed by an account or user of an accounting platform, and to transmit event notifications to the subscriber.

[0066] The app provision module 178 may be configured to provide access to and / or the ability to download accounting platform app 122, to client device 110. App provision module 178 may provide accounting platform app 122 via an app marketplace (not shown), such as the android play store or Apple app store. In some embodiments, app provision module 178 may make accounting platform app 122 via an app provision website or webpage hosted by or associated with accounting platform server 170 and / or app provision module 178.

[0067]

[0067] The platform communication module(s) 180 is configured to facilitate communication between accounting platform 170 and the client device via accounting platform app 122. In some embodiments, the platform communications module(s) 180 may be configured to communicate with one or more financial services platform (e.g. bank) server (s) 190 to facilitate communication with financial accounts associated with one or more accounts associated with the accounting platform.

[0068]

[0068] The fraud detection module 182 may provide for a secure online environment for users of the accounting platform and the services it provides. The fraud detection module 182 may be configured to calculate, derive or determine an instance or instances of fraud, potential fraud and / or attempted fraud. In some embodiments, the fraud detection module 182 is configured to communicate with, or cause the accounting platform server 170 to communicate with the event logging engine 140 and / or event store 160 to request and / or receive one or more event objects, logged by and / or stored on the event logging engine 140 or event store 160, respectively. In some embodiments, the fraud detection module 182 may be configured to receive a plurality of event objects, and determine therefrom, one or more datasets of event objects. The one or more datasets of event objects may be associated with one particular account, which may be associated with the accounting platform and be indicative of one or more financial attributes, financial behaviours, business behaviours, and / or user behaviours. The behaviours may be anomalous or standard behaviours. Standard behaviours may constitute actions taken by one or more users that are substantially similar to their regular actions, or similar to or in line with a typical user’s actions. Anomalous behaviours may constitute behaviours that are not regular, or not in keeping withstandards and practices established by the accounting platform, regulatory bodies, and / or internal entity rules, regulations and / or standards and practices.

[0069]

[0069] The fraud detection module 182 may be configured to determine a risk level (for example, a risk score) for users and / or organisations associated with a system such as the accounting platform to assist with fraud detection and implementation of strategies or activities to mitigate fraud. In some embodiments, the fraud detection module 182 is configured to calculate, derive or determine, using the one or more datasets, one or more instances of fraud, potential fraud and / or attempted fraud. The fraud module 182 may be configured to express the fraud determination as a Boolean determination (e.g., likely fraud or unlikely fraud) or a likelihood determination. In some embodiments, the likelihood determination may be a value on a likelihood scale, and / or a dataset comprising two or more likelihood metrics.

[0070]

[0070] In some embodiments, the fraud detection module 182 comprises a login risk assessment module 182A configured to evaluate a risk of a specific login event. The login risk assessment module 182A may determine an indication of likely fraud or unlikely fraud, or a value on a likelihood of fraud scale based on feature or variables such as Internet Protocol (IP) address, Internet Service Provider (ISP), user or device location, device identifier. For example, the login risk assessment module 182A may be or comprise a machine learning (ML) model configured to receive as input one or more of: IP address, ISP, user or device location, device identifier, and to provide, as an output of the machine learning model, an indication of likely fraud or unlikely fraud, or a value on a likelihood of fraud scale. For example, where a value of the likelihood of fraud scale is determined, the fraud detection module 182 may compare the value to a threshold to determine whether to flag or assign the event or action as a fraud or attempted fraud, or if it is a valid and non-fraudulent. In some embodiments, the login risk assessment module 182A may be trained using a training dataset comprising training examples of historic login events which were fraudulent or attempted fraudulent and / or valid or non-fraudulent. For example, the training examples may include values for one or more of an IP address, ISP, user or device location, and device identifier and, in some embodiments, a label indicative of whether the loginevent was fraudulent / attempted fraud or valid. For example, the machine learning (ML) model can be trained using supervised learning, semi-supervised learning, or unsupervised learning. The training data can be retrieved from the event log.

[0071]

[0071] Where the login risk assessment module 182A determines an output indicative of likely fraud, the fraud detection module 182 may take one or more mitigation actions. For example, the fraud detection module 182 may issue a notification (for example, by email, text message, voicemail etc) to the relevant user and / or organisation to notify them that a potentially fraudulent login attempt was made on their account. The user and / or organisation may then be provided with an opportunity to verify the login attempt as a verified or true login attempt, or to take measures, such as changing login details to enhance the security of their accounts. In some embodiments, where the suspected login attempt was validated as a genuine login attempt by the user / organisation, the login event / action may be used to retain the ML model to improve its accuracy in predicting fraudulent login attempts.

[0072]

[0072] The fraud detection module 182 may be configured to assign or allocate a risk score to each user and / or organisation account with the accounting platform. For example, the risk score may be based on a number of potentially fraudulent login attempts made on the respective account. For example, where the login risk assessment module 182A determines an output indicative of likely fraud associated with the account, the fraud detection module 182 may be configured to increment a risk score counter. Different weightings may be applied to increments to the risk score counter, for example, based on frequency of fraudulent attempts, a significant number of attempts being made in a relatively short period of time, etc. Accordingly, the more attempts to compromise an account, the higher the risk score that is allocated to that account. And conversely, the higher the risk score allocated to an account, the greater the expectation that attempts will be made to compromise the account.

[0073]

[0073] In some embodiments, where a user or organisation notifies the fraud detection module 182 that a suspected login attempt was a genuine login attempt by theuser / organisation, the fraud detection module 182 may adjust or decrement the risk score associated with the user and / or organisation account as appropriate.

[0074]

[0074] In some embodiments, where the risk score allocated to a particular user and / or organisation account exceeds a risk threshold, the fraud detection module 182 determines or identifies the account as a high-risk account and may elect to implement or additional authentication pathways for some actions, such as actions deemed particularly sensitive actions.

[0075]

[0075] In this way, the login risk assessment module 182A may enhance security and in particular, the authentication process.

[0076]

[0076] Some known techniques for mitigating bad actors from issuing masses of unsolicited communications include limiting a number of communications that can be issued be a given organisation or account for a period of time, for example, 20 emails a day. In some cases, paying subscribers are allocated a greater communication limit, such as 1000 emails a day. However, there is a possibility of malicious actors using fraudulent payment data to subscribe and gain access to the higher limit, and to create multiple organisations each with accounts to increase the overall number of communications being sent. For example, four unique organisation accounts for an individual malicious actor could be capable of transmitting 4000 communications per day. Communications or mail servers often provide relatively strong span prevention techniques to improve the user experience provided to their customers. Such mail servers typically allocate a spam score to transmittal addresses or domains and block all communications from that address or domain for a period of time if the spam score exceeds a threshold. This can be detrimental to services provided by systems, such as accounting platforms. Accordingly, the accounting platform server 170, and the fraud detection module 182, for example, undertakes measures to mitigate spam being transmitted from accounts with the accounting platform.

[0077]

[0077] In some embodiments, the fraud detection module 182 comprises a malicious (or “bad”) actor assessment module 182B. The malicious (or “bad”) actor assessmentmodule 182B is configured to assess or determine the risk of an organisation or user being a malicious or “bad” actor, for example, using the accounting platform for communicating irrelevant or unsolicited messages (“spam”) to users, such as user accounts of the accounting platform, or to perform other malicious activities. The malicious (or “bad”) actor assessment module 182B determines a malicious actor score indicative of the determined likelihood of malice. The malicious actor score is associated with an organisation or user or account of an organisation or user.

[0078]

[0078] The malicious actor assessment module 182B may determine the malicious actor score based on factors such as the age of the organisation, its name, a reputation score, the risk score allocated to each user and / or organisation account with the accounting platform, as described above and / or other attributes. The reputation score may be based on an IP quality score such as that provided by a service provider such as IPQualityScore LLC.

[0079]

[0079] In some embodiments, malicious actor assessment module 182B may be or comprise a machine learning (ML) model configured to receive as input one or more of: organisation name, organisation age, reputation score, and to provide, as an output of the ML model, a malicious actor score indicative of likely malice or unlikely malice, or a value on a likelihood of malice scale.

[0080]

[0080] The fraud detection module 182 is configured to compare the malicious actor score with a malicious actor score threshold, and response to the malicious actor score for a particular organisation meeting the malicious actor score threshold, the fraud detection module 182 may take action to block or potentially harmful actions and notify a security team. For example, the fraud detection module 182 may temporarily or permanently suspend the organisation’s account with the accounting platform. In some embodiments, the fraud detection module 182 may cooperate with a spam filter application to block or prevent unsolicited communications being transmitted from the organisations account and / or received by the intended recipients.

[0081] In some embodiments, the accounting platform server 170 provides an Application Protocol Interface (API) to allow other applications to access and leverage risk scores and / or malicious actor scores determined by the fraud detection module 182.

[0081]

[0082] I n some embodiments, the fraud detection module 182 supports the feature “remember this device” to enhance login risk assessment.

[0082]

[0083] The quality control module 184 may be configured to monitor and / or improve the data quality or integrity of data stored in the event store 160. Outputs from the quality control module 184 may assist with identification of data entry errors, system issues, process breakdowns and / or training needs.

[0083]

[0084] The quality control module 184 is configured to measure, calculate or determine the quality, accuracy and / or integrity of the accounting platform, and / or the stored eventing objects associated with the accounting platform. In some embodiments, the quality control module 184 is configured to communicate with, or cause the accounting platform server 170 to communicate with, the event logging engine 140 and / or event store 160 to request and / or receive one or more event objects, logged by and / or stored on the event logging engine 140 or event store 160, respectively. The quality control module 184 may be configured to determine, from the event object(s), history or historical information associated with one or more accounts of the accounting platform. In some embodiments, the history describes a plurality of accounting actions, performed by, on or via account(s) of the accounting platform, the financial services platform server 190, and / or the accounting platform server 170. The histories may be associated with one or more financial attributes associated with the account of the accounting platform, the financial services platform server 190, and / or the accounting platform server 170.

[0084]

[0085] In some embodiments, the quality control module 184 considers whether or not data is complete, and if determined incomplete, takes an action. The action may be to flag or otherwise provide an indicator that the relevant data is incomplete. The action may involve notifying a user, for example, a responsible administrator. In this case, theuser may use accounting platform functionality such as “find and replace / recode” to determine all instances of such an incomplete entry and make a bulk change to all instances.

[0085]

[0086] In some embodiments, the action may be an automatic completion of the incomplete data, for example by inserting missing values.

[0086]

[0087] In some embodiments, the quality control module 184 determines whether or not data is accurate.

[0087]

[0088] In response to determining that data is inaccurate, the quality control module 184 may take an action. The action may be to flag or otherwise provide an indicator that the relevant data is inaccurate. The action may involve notifying a user, for example, a responsible administrator. In some embodiments, the action may be an automatic correction of the inaccurate data, for example by correcting values.

[0088]

[0089] In some embodiments, the quality control module 184 determines or assesses consistency of the data. For example, the quality control module 184 may consider whether actual data values correspond with expected data values. In response to determining that data is inconsistent, the quality control module 184 may take an action. The action may be to flag or otherwise provide an indicator that the relevant data is inconsistent. The action may involve notifying a user, for example, a responsible administrator. In some embodiments, the action may be an automatic correction of the inconsistent data, for example by making values consistent.

[0089]

[0090] In some embodiments, the quality control module 184 determines or assesses timeliness of the data.

[0090]

[0091] The audit module 186 is configured to calculate, generate, derive, receive or determine datasets, metrics and / or attributes associated with and / or indicative of the behaviour of an account of the accounting platform. In some embodiments, the audit module 186 may be configured to request, from the event logging engine 140 or eventstore 160 a plurality of event objects. The request may comprise a time period, over which the event objects were recorded, generated, and / or logged. The time period may be a number of months, weeks and / or days and / or a defined range from a starting date to an ending date. In some embodiments, the audit module 186 may be configured to determine, from the plurality of event objects, one or more account histories, indicative of one or more behaviours occurring on and / or via a particular account associated with the accounting platform. The one or more histories may comprise debit histories, credit histories, histories of recorded assets, histories of recorded liabilities, and / or payroll processing histories.

[0091]

[0092] In some embodiments, the audit module 186 is configured to determine, using the one or more histories, one or more behaviour characteristics of the particular account. The behaviour characteristics may be indicative of standard and / or anomalous behaviours of an account holder and / or user of an account. In some embodiments, the behaviour characteristics may be used to determine whether an entity, associated with the account, has passed or failed an audit assessment.

[0092]

[0093] For example, the audit module 186 may be configured to determine from the history associated with an account or accounts, transactions summaries, compliance checks and risk assessments. In some embodiments, the audit module 186 uses this data to generate reports relating to volume analysis, value distributions, transaction patterns, risk indicators, etc.

[0093]

[0094] In some embodiments, the event logging engine subscribes to the accounting platform to receive event notifications for actions relating to accounting documents, such as invoices, credit notes, quotes, etc. The event notifications may include details relating to the action such as an organisation or user identifier, a reference identifier, a date the document was created (document creation date), a date the event took place, header text, body text, and / or a type of action reference (e.g., edit, create, delete, replace etc.). In this way, an immutable record of who has done what within the accounting document is maintained in the event logging engine 140 and / or event store 160.

[0095] The system 100 may also comprise and / or be in communication with one or more financial services platform server(s) 190. The financial services platform server(s) 190 may comprise online banking / fmancial services associated with financial institutions, including but not limited to: retail and commercial banks, internet banks, credit unions, savings and loan associations, investment banks, brokerage firms, and / or insurance companies. Accounting platform server 170 may facilitate communications between client device 110 and the one or more financial services platform(s) as part of the provision of services associated with the accounting platform.

[0094]

[0096] Figure 2 is a block diagram depicting an example hosting infrastructure 300 for the accounting platform. The platform may be implemented using one or more pods 210. Each pod 210 includes application server virtual machines (VMs) 220 (shown as application server virtual machines 220a-220c in Figure 3) that are specific to the pod 210 as well as application server virtual machines 220 that are shared between pods 210 (e.g., the internal services VM 230 and the application protocol interface VM 340). The application server virtual machines 220-240 communicate with clients and third-party applications via a web interface or an API. The application server virtual machines 220-240 are monitored by application hypervisors 250. In some example embodiments, the application server virtual machines 220a-220c and the API VM 240 are publicly-accessible while the internal services VM 230 is not accessible by machines outside of the hosting infrastructure 200. The app server VMs 220a-220c may provide end-user services via an application or web interface. The internal services VM 230 may provide back-end tools to the app server VMs 220a-220c, monitoring tools to the application hypervisors 250, or other internal services. The API VM 240 may provide a programmatic interface to third parties. Using the programmatic interface, the third parties can build additional tools that rely on the features provided by the pod 210.

[0095]

[0097] The internal firewall 260 ensures that only approved communications are allowed between the database hypervisor 270 and the publicly accessible virtual machines 220-240. The database hypervisor 270 monitors the primary structured query language (SQL) servers 280a and 280b. The primary SQL servers 280a and 280baccess the shared storage layer 350a or 350b (shown in Figure 3) to read and write data generated by or used by the application server virtual machines 220-240. The redundant SQL servers 290a and 290b provide backup functionality for the primary SQL servers 280a and 280b, respectively. The virtual machines 220-240 can be implemented using Windows 2008 R2, Windows 2012, or another operating system. The application and support servers supporting the virtual machines 220-240 can be built using spares for redundancy. The support servers can be shared across multiple pods 210. The application hypervisors 250, internal firewall 260, and database hypervisor 270 may span multiple pods 210 within a data centre. In some example embodiments, each primary SQL server 280 and redundant SQL server 290 is configured to support 30,000-45,000 organizations. Accordingly, in embodiments using two such server pairs per pod 210, the pod capacity is 60,000-90,000 organizations. The redundant SQL servers 290 may take advantage of the “always on” resilience feature of SQL 2012.

[0096]

[0098] Figure 3 is a block diagram depicting an example data centre system 300 of the accounting platform server 170 interacting with other systems over the network 130. The primary data centre 310 services customer requests and is replicated to the secondary data centre 320. The secondary data centre 320 may be brought online to serve customer requests in case of a fault in the primary data centre 310. The primary data centre 310 communicates over the network 130 with financial services platform (e.g. bank) server 190 (which may be similar or equivalent to financial services platform 190 of Figure 1), third-party server 370, client device 110A, and client device 110A. The financial services platform server 190 provides banking data (e.g., via the banking application 265). The third-party server 370 is running third-party application 375. The client device 110A and client device 110B interact with the primary data centre 310 using web client 385 and programmatic client 395, respectively.

[0097]

[0099] Within each data centre 310 and 320, a plurality of pods is shown. The primary data centre 310 is shown containing pods 340 A- 340 D. The secondary data centre 320 is shown containing pods 340 E- 340 H. The applications running on thepods of the primary data centre 310 are replicated to the pods of the secondary data centre 320. For example, EMC replication (provided by EMC Corporation) in combination with VMWare site recovery manager (SRM) may be used for the application layer replication. The database layer handles replication between the storage 350A of the primary data centre 310 and the storage 35 OB of the secondary data centre 320. Database replication provides database consistency and the ability to ensure that all databases are at the same point in time.

[0098]

[0100] In certain embodiments, the data centres 310 and 320 use load balancers 330A and 330B, respectively, to balance the load on the pods within each data centre. The data centres 310 and 320 can be created using identical hardware to ensure that the performance of the secondary data centre 320 is the same as the performance of the primary data centre 310. The storage 350 may be implemented using one or more EMC VNX storage area networks.

[0099]

[0101] The financial services platform server 190 stores financial or banking records for financial accounts associated with respective users. In certain embodiments, the financial services platform server 190 interacts with the primary data centre 310 to provide financial (or bank) records for financial (or bank) accounts of the client. For example, the client may provide account credentials to the primary data centre 310, which the primary data centre 310 uses to gain access to the account information of the client. The bank server 360 can provide the financial records to the primary data centre 310 for later reconciliation by the client using the client device 380 or 390.

[0100]

[0102] In some embodiments, the accounting platform server 170 or primary data centre 310 receives financial account credentials registered to a financial account at the financial services platform server 190. The financial account credentials may be received from a user of the accounting platform server 170, for example, via the client device 110, 110A, HOB. The client device 110, 110A, HOB may be equipped with technology or software to allow the user to selectively establish an encrypted connection between the financial account at the financial services platform server 190 and a user account associated with the user at the accounting platform server 170. Inresponse to the user selecting to establish the encrypted connection between the financial account at the financial services platform server 190 and the user account associated with the user at the accounting platform server 170, the accounting platform server 170 can register to receive, from the financial services platform server 190, financial or banking records for the financial account. The financial or banking data may be imported through a bank feed or a user- or accountant-created document, or over a network via an application protocol interface (API), for example.

[0101]

[0103] Where the financial or banking data is imported through a bank feed, the bank feed may allow up-to-date financial or banking records for the financial account to be transmitted in encrypted from the financial services platform server 190 to the accounting platform server 170 (i.e., a secure bank feed). In some embodiments, the accounting platform server 170 receives from financial services platform server 190, a randomly generated symmetric key encrypted with a public Rivest-Shamir-Adleman (RSA) key of the accounting platform server 170, and banking or financial records encrypted with the randomly generated symmetric key. The accounting platform server 170 may then use the private RSA key of the accounting system to decrypt the symmetric key and using the decrypted symmetric key to decrypt the financial or banking records. The accounting platform server 170 may then load the decrypted financial or banking records into a user account of the accounting system associated with the user.

[0102]

[0104] The third-party server 370 may interact with the primary data centre 310 and the client device 110, 110A, 110B to provide additional features to a user of the client device 110, 110A, HOB. For example, a user may authorize the third-party server 370 to access the user's data stored in the primary data centre 310. The third-party application 375 of the third-party server 370 may use the user's data to generate reports, provide macros, or otherwise improve the user's ability to access or manipulate the user's data. The third-party application 375 may communicate with the primary data centre 310 via the network 130 using an API. The third-party application 375 may communicate with the client device 110, 110A, HOB using a web or programmatic interface.

[0105] Figure 4 is a process flow diagram of a method 400 for monitoring accounting platform activity, according to some embodiments. At 410, accounting platform server 170 may receive a request from event logging engine 140, to subscribe to activity associated with the accounting platform server 170. Activity may comprise any one or more actions that may be performed by, on, via or through accounting platform server 170, such as entering credits, entering debits, receiving bills, sending invoices and / or paying employees and / or service providers. In some embodiments, subscription module 148 may be configured to monitor or wait to receive a notification from notification module 177. Subscription module 148 may be configured to poll accounting platform server 170 and / or notification module 177 to determine if any activity has occurred. In some embodiments, the notification module 177 may automatically, periodically and / or aperiodically transmit notifications to event logging engine 140 and / or subscription module 148, indicating that actions have occurred. In some embodiments, the accounting platform server 170 may cause or instigate the event logging engine 140 to subscribe to activity associated with the accounting platform server 170.

[0103]

[0106] In some embodiments, at 415, the accounting platform server 170 orthe platform communication module(s) 180 may receive an indication that an action has been performed by or on the accounting platform app 122, the accounting platform via the browser application 120, the financial services platform(s) 190 and / or the accounting platform server 170. The indication may be indicative of any action that may be performed and / or enabled by the functionality of the accounting platform. In some embodiments, the platform communication module(s) 180 may be configured to perform quality control and / or data curation on any communications received from client device 110, database 132 event logging engine 140, event store 160 and / or financial services platform(s) 190.

[0104]

[0107] At 420, the accounting platform server 170 may communicate a notification that an action has been performed on or via the accounting platform. In some embodiments, the notification may comprise one or more action attributes. Action attributes may be related to, indicative of and / or derived from any action performed on or by, or enabled by the accounting platform server 170. For example, actions may comprise a date, atime, an account identifier, a user identifier, a location, an IP address, a debit amount, a credit amount, invoice data, payroll data, and / or any other type of financial and / or accounting data that may be entered into, received and / or generated by the accounting platform server 170.

[0105]

[0108] In some embodiments, at 425, responsive to receiving the action notification from accounting platform server 170 and / or notification module 177, event object management module 150 may take the action attribute(s) and generate an event object comprising at least one or more of the action attributes. Subsequent to the creation of the event object, the event object management module 150 may communicate the event object to event store 160. The event store 160 may cause the event object to be stored in event logs 162. In some embodiments, each account associated with the accounting platform may have its own event log, or the accounting platform may have one event log.

[0106]

[0109] At 430, the accounting platform server 170 may request from event logging engine 140 one or more stored event objects. In some embodiments, the request may comprise one or more event object criteria, by which event logging engine 140 may use to determine a subset of the stored event objects. The event object criteria may comprise one or more of: an account identifier, a user identifier, a date / time range, an action type, a credit amount or range, and / or a debit amount or range.

[0107]

[0110] At 435, the accounting platform server 170 may receive from event logging engine 140 a dataset of event objects. The dataset of event objects may have been determined using the one or more event object criteria. In some embodiments, the event objects may be chronologically ordered based on the order the actions were performed and subsequently recorded. In some embodiments, the dataset of event objects may be associated with a particular account of the accounting platform. The dataset may be indicative of the accounting, financial and / or business behaviours of the account and / or the users associated with an account of the accounting platform.

[0111] In some embodiments, the dataset of the event objects may be used by the accounting platform server 170 to determine qualities and / or characteristics of the financial, accounting and / or business behaviours of the entity associated with the account. The qualities and / or characteristics may comprise, for example, fraudulent behaviours, account histories, and / or data quality indicators. For example, key patterns which may be likely indicators of fraudulent behaviour include velocity anomalies (for, example too many transactions too quickly), a threshold number of round number transactions for example, which may indicate potentially fake invoices), split transactions (for example, which may be indicative of an attempt to avoid delegation of authority controls, out-of-normal-hours transaction activity multiple source IP addresses, a number of unbalanced entries, missing sequence numbers, and / or unusual patterns in transaction amounts. Other examples are disclosed in the online published article “8 Steps to Efficient Transaction Fraud Monitoring”, by NayaOne (htps: / / nayaone.eom / 8-steps-to-efficient-transaction-fraud-monitoring / #)

[0108]

[0112] Figures 5 to 7 relate to various methods for monitoring accounting platform activity. The accounting platform server 170 provides the accounting platform in a cloud computing environment, the accounting platform being configured to gather accounting data and provide accounting services to the plurality of users.

[0109]

[0113] In at least some of these embodiments, the accounting platform server imports from the financial institution, financial data for each of a plurality of users having a user account with the accounting platform. For example, the accounting platform may be configured to import the financial data over a network through a bank feed or document, or over a network via an application protocol interface.

[0110]

[0114] In at least some of these embodiments, the accounting platform server receives from the event logging engine, a request to receive action or event notifications. The event notifications may relate to accounting data, financial data, transaction data, reconciled transactions, login or authorisations, changes to permissions and / or settings etc.

[0115] The accounting platform server 170 transmits to the event logging engine 140, a plurality of action notifications. For example, the action notifications may be transmitted to the event logging engine 140 for a particular period of time. Each of the plurality of action notifications may comprise one or more action attributes indicative of an action. Accordingly, the event logging engine 140 may comprise accounting platform activity including information derived from the event or action notifications. In some embodiments, the event logging engine 140 may communicate the action or event notifications or objects to the event store 160 to be stored in event logs 162.

[0111]

[0116] Figure 5 is a process flow diagram of a method 500 for monitoring accounting platform activity to detect fraud or attempted fraud, according to some embodiments. At 510, the accounting platform server 170 may request, from event logging engine 140 or event logs 162, a plurality of event objects. The request may comprise one or more event object criteria, for determining a set of event objects from the event objects stored in event store 160 / event logs 162.

[0112]

[0117] The event object logging engine 140 or the event object management module 150 may parse the event logs 162 to determine a plurality of event objects, the plurality of event object(s) being associated with an account of the accounting platform, and at least some of the event object criteria.

[0113]

[0118] At 515, the accounting service server 170 may receive, from the event logging engine, the event object(s). At 520, fraud detection module 182 may determine a first event object dataset from the plurality of event objects. The first dataset may be determined using one or more first criteria. The first criteria may be configured to derive a particular subset of event objects that are indicative of a particular quality and / or attribute of the account associated with the plurality of event objects. In some embodiments, the first dataset may be indicative of net income of an entity, entity financial statements, entity assets, net costs of an entity, net liabilities of an entity, and / or net incomings of an entity.

[0119] At 525, fraud detection module 182 may determine a second event object dataset from the plurality of event objects. The second dataset may be determined using one or more second criteria. The second criteria may be configured to derive a particular subset of event objects that are indicative of a particular quality and / or attribute of the account associated with the plurality of event objects. In some embodiments, the first dataset may be indicative of net income of an entity, entity financial statements, entity assets, net costs of an entity, net liabilities of an entity, and / or net incomings of an entity.

[0114]

[0120] In some embodiments, the first dataset and the second dataset may be complimentary and / or related. For example, the first dataset may be indicative financial incomings and the second dataset may be indicative of financial outgoings, or the first dataset may be indicative of entity assets and the second dataset may be indicative of entity liabilities.

[0115]

[0121] At 530, the fraud detection module 182 may determine an indication of whether fraud has been detected. In some embodiments, the indication may be a Boolean value, indicating either the presence or absence of fraud indicators, such as an imbalance between financial incomings and outgoings. In some embodiments, the indication of whether fraud has been detected may be a dataset of potential indicators and / or metrics, such as one or more financial and / or accounting discrepancies between the first and second datasets. In some embodiments, the indication may be a confidence score, indicating the calculated likelihood that fraud has occurred based on one or more potential fraud indicators, as derived from comparing the first and second datasets.

[0116]

[0122] In some embodiments, the fraud detection module 182 may determine an indication of whether fraud has been detected based on the techniques described in pending International (PCT) provisional patent application no. PCT / NZ2023 / 050061 filed on 26 June 2023 and entitled “Methods and systems for detecting compromised accounts and / or attempts to compromise accounts”, the entire content of which is incorporated herein by reference.

[0123] In some embodiments, the system 100 may implement one or more event notification, monitoring, collection, creation and / or logging techniques described in International (PCT) patent application no. PCT / NZ2021 / 050150 filed on 25 August 2021 entitled “Systems and methods for managing access credential requests”, the entire content of which is incorporated herein by reference.

[0117]

[0124] Figure 6 is a process flow diagram of a method 600 for monitoring accounting platform activity to perform quality control, according to some embodiments. At 610, the accounting platform server 170 may request, from event logging engine 140 or event logs 162 a plurality of event objects. The request may comprise one or more event object criteria, for determining a set of event objects from the event objects stored in event store 160 / event logs 162.

[0118]

[0125] At 615, the accounting service server 170 may receive, from the event logging engine, the plurality of event objects. At 620, quality control module 184 may calculate, derive or determine one or more quality control attributes from the plurality of event objects. The quality control attributes may be indicative of the quality or accuracy of the event objects, from which the attributes are derived.

[0119]

[0126] At 625, the quality control module 184 may determine, from at least the plurality of event objects one or more ground truth attributes. In some embodiments, the ground truth attributes may be determined from the plurality of event objects and one or more predetermined quality control metrics. The predetermined quality control metrics may comprise: acceptable limits for missing data; acceptable limits for unequal account values; and / or occurrences that are associated with and / or indicative of errors. The one or more ground truth metrics may be indicative of a known and / or expected state of the accounting actions as represented by the plurality of event objects.

[0120]

[0127] At 630, the quality control module 184 determines an indication of the quality of the plurality of event objects. In some embodiments, the indication is determined by comparing the quality control dataset and the ground truth dataset. The indication of the quality of the plurality event objects may be whether or not the recorded history asindicated by the series of event objects is accurate and / or correctly recorded. In some embodiments, the indication may comprise one or more determinations of inaccuracies and / or mistakes as represented by the plurality of event objects.

[0121]

[0128] Figure 7 is a process flow diagram of a method 700 for monitoring accounting platform activity to perform auditing, according to some embodiments.

[0122]

[0129] At 610, the accounting platform server 170 may request, from event logging engine 140 or event logs 162 a plurality of event objects. In some embodiments, the request may comprise a date range, over which the plurality of event objects were recorded over.

[0123]

[0130] At 715, the accounting service server 170 may receive, from the event logging engine, the plurality of event objects. At 720, the audit module 186 may determine, from the plurality of event objects, an ordered history of events, actions, financial account balances, debits, credits, and / or payments. The ordered history may be indicative of financial, account and / or business actions / behaviours of a particular entity over the predetermined date range.

[0124]

[0131] In some embodiments, the audit module 186 may use the ordered history to perform an audit of the entity the event objects are associated with. In some embodiments, the audit module may return a determination or indicate that the particular entity as passed or failed their audit.

[0125]

[0132] The audit module 186 may determine a number of payments made to an organisation based on a dataset of event objects derived from the event logging engine for a period of time, such as a given financial year. For example, the event objects relate to payments made to the organisation, which for example, may be derived from financial information imported from the financial institution. The audit module 186 may also determine the total revenue reported by the organisation for the given financial year. For example, the total revenue reported may be obtained from a database, or may be derived from an event object detailing the total revenue reportedand received from the event logging engine. The audit module 186 may compare the total amount of the payment with the revenue amount reported to determine any discrepancies. Responsive to the audit module 186 determining that the reported revenue differs from the total payments received, the audit module 186 may determine or flag the entity or organisation as potentially non-compliant and / or may determine the audit to have been failed.

[0126]

[0133] The audit module 186 may review or assess payroll events to ensure timely employee payments and / or proper, appropriate or compliant tax and / or super annuation / pension withholdings. For example, the audit module 186 may receive a dataset of event objects relating to payroll events for an organisation from the event logging engine. The audit module 186 may determine for each employee or a subset of employees, expected salary / wages payment amounts and due dates for payment, and / or expected super annuation amounts and due dates for payment. The audit module 186 may determine from the event objects relating to payroll events and based on the determined expects amounts and dates, whether the organisation attended to ensure timely employee payments and / or proper, appropriate or compliant tax and / or super annuation / pension withholdings. For example, the audit module 186 may determine from the event objects relating to payroll events, amounts and times of actual payroll and / or super annuation payments and compare the amounts and times with the expected values to determine whether the correct payments were made by a due date.

[0127]

[0134] The audit module 186 may track or monitor changes to account settings and / or permissions. For example, the audit module 186 may receive a dataset of event objects relating to changes to account settings or permissions from the event logging engine.

[0128]

[0135] The audit module 186 may monitor deletion or modification events of financial records. For example, the audit module 186 may receive a dataset of event objects relating to deletion or modification events of financial records from the event logging engine.

[0136] The audit module 186 may track or monitor chains of events for large or unusual transactions. For example, the audit module 186 may receive a dataset of event objects relating to transactions exceeding a threshold amount, or unusual transactions, from the event logging engine. For example, unusual transactions may comprise a group of transactions occurring within a threshold time period (e.g., velocity anomalies), a group of transactions with round number transactions, split transactions, transactions which occur out-of-normal-hours, transactions with multiple source IP addresses, unreconciled transactions, transactions with missing sequence numbers, and / or a group of transactions having unusual patterns in transaction amounts.

[0129]

[0137] The audit module 186 may identify seasonal variations in transaction volumes and track changes in spending patterns over time. For example, the audit module 186 may receive one or more datasets of event objects relating to transactions that occur during a specific time period, such as during a holiday seasons, or during a particular season, such as winter. Examples of identifying and monitoring seasonality in transactions are disclosed in International Patent Application No PCT / AU2020 / 051184, filed on 5 November, 2020 entitled “Systems, computer-implemented methods and computer programs for capital management” the entirely of which is incorporated herein by reference.

[0130]

[0138] Figure 8 is a block diagram 800 depicting an example data flow for interactions between a banking platform provided by the financial services platform server 190, according to some embodiments. A user (not shown) interacts with the internet banking UI 802 to select one or more accounts to share with an accounting service provider of the accounting platform server 170. The internet banking UI 802 redirects the user to the accounting service UI 808.

[0131]

[0139] Further, the accounting service UI 808 authenticates the user and links the bookkeeping or accounting accounts of the user with the bank or financial accounts at the internet banking service. The accounting service UI 808 further communicates with the accounting service backend 810 to store the account linkage data, and theaccounting service backend 810 communicates with the bank (or financial institution) using the private bank API 804.

[0132]

[0140] Features provided by the private bank API 804 include updating the registration for a financial or bank account, making a third party payment drawn from a registered bank account, and other services. The bank file delivery 806 provides a bank record feed for a registered account via a batch file delivery to the accounting service file mailbox 812, based on registration of the account via the private bank API 804. The accounting service file mailbox 812 provides the received batch file to the accounting service backend 810, which processes the batch to generate records for the bookkeeping account that correspond to the reported transactions in the received feed file. Additional details of example processes are discussed in more detail below.

[0133]

[0141] Overview of Example Financial Services

[0134]

[0142] According to one example embodiment, there is provided a method and a system for establishing links to bank accounts automatically and for providing a number of complementary services. The example method and system may include three parts, namely:

[0135] • Automated provisioning of accounts via Internet banking.

[0136] • Bank-provided services called by the accounting platform server 170 via a private application programming interface (API).

[0137] • Delivery of file data via secure transfer (e.g., Account Feed Service).

[0138]

[0143] Automated provisioning, according to one example embodiment, enables a mutual customer to establish a connection between the accounting platform server 170 and the financial institution of the financial services platform server 190. This may be achieved by allowing a financial institution customer to opt in to make their feeds from their bank accounts available to the accounting platform server 170 within financial Internet software (e.g., hosted and operated by the customer’s financial institution). Once a customer selects the bank account they want to share with the accountingplatform server 170, the accounting platform server 170 links the selected bank account with an account in the accounting platform server 170.

[0139]

[0144] Once these accounts are connected, the accounting platform server 170 will register the feed via a private API with the financial institution and request the data to be included in a periodic data feed (e.g., a nightly feed, but other periods are also possible, such as hourly, every 10 minutes, etc.).

[0140]

[0145] If the connected account supports automatic payments, and the customer has requested the service, the customer may also pass payment instructions back from the accounting platform server 170 into the Internet banking software of a financial institution for authorization. A variety of services provided by Internet banking software may be connected with the accounting platform server 170.

[0141]

[0146] Example of Automated Provisioning

[0142]

[0147] Automated provisioning, according to an example embodiment, may include multiple functions, two of which are:

[0143] • The activation / deactivation of services on the financial institution account for use with the accounting platform server 170.

[0144] • The management (e.g., mapping) of the financial institution accounts against accounts in the accounting platform server 170.

[0145]

[0148] Activation is the process by which a user identifies, within Internet banking software, which bank accounts the user would like to share with the accounting platform server 170. All accounts may be deactivated by default. An authenticated user of online services may be required to explicitly activate accounts that are to be used with the accounting platform server 170, and optionally select any additional services that they want to use.

[0149] Once an account is activated, statement data relating to the account is marked as pending for batched retrieval to the accounting platform server 170, which will later be confirmed by an “UpdateRegistration” service, further details of which are provided below.

[0146]

[0150] Example of Management of Accounts

[0147]

[0151] Once a financial institution account is activated, the financial institution account can then be connected. Services are not fully enabled against the accounting software account until the financial institution account is connected and the feed registration confirmed.

[0148]

[0152] An authenticated Internet banking user may opt to connect one or more activated accounts. From here, the user is redirected to the accounting platform server 170 , which will request the user to authenticate with the accounting platform server 170. After authentication, the user may be requested to select which bookkeeping accounts of the accounting platform server 170 they would like to connect their bank accounts that the financial institution.

[0149]

[0153] Once a bank account with the feed service is connected to an accounting platform account, the accounting platform server 170 calls the “UpdateRegistration” service. The service registers the account, allowing the latest data for this account to be retrieved on a schedule and loaded into the accounting platform account via a feed. The accounting platform server 170 processes the feed data from the financial institution to create or suggest corresponding entries in the single-ledger accounting system. For example, suggested entries can be presented to a user to confirm or modify before the entries in the single-ledger accounting system are created.

[0150]

[0154] When a bank account providing a third party payment service is connected to an accounting platform account, batch payments can be submitted directly to the bank for approval from this account, using the third-party payment service.

[0155] Account activation, according to one example embodiment, is a method for the assignation of available accounting platform server services against the financial institution accounts. All accounts may be deactivated by default.

[0151]

[0156] A single method, UpdateASServices, can take a map of accounts and requested accounting system (AS) services and update the active AS services against all of the user’s accounts. This method UpdateASServices updates the AS services activated against a user’s set of the financial institution accounts. For example, an execution of UpdateASServices on the financial system server may cause the transmission of data for each of the user’s accounts to the requesting AS. The data may be incremental (e.g., reflect only changes since the last data transmission) or complete for a predetermined time period (e.g., last month, current month, last six months, this year, etc.). Activation may occur within the financial institution’s services platform. An authenticated online services user can change the activation status of their financial institution accounts.

[0152]

[0157] A user is presented with a list of accounts available in their online services. Each account has a list of available services that that user can activate against each account. Term deposits may have no services available, credit cards may have Account Feed Service available, and current accounts may have the Account Feed Service and Third Party Payment Service available, depending on which accounts are capable of supporting feeds or batch payments.

[0153]

[0158] Upon making changes to the services against accounts, a map of accounts and services requested to be activated against them are posted to the server. If there are terms and conditions that may be agreed to before data can be shared, such agreement may be obtained before the changes are committed.

[0154]

[0159] Activation creates or assigns a unique identifier for the account (e.g., an AccountID), which is used for all services, and also when connecting the account to an accounting platform account. An AccountID is guaranteed to be unique and to persist, and is always the same for a given account (e.g., even if it’s disconnected andreconnected). An AccountID may be included in the feed of transactions and may be allowed in the payment batch fde format as the primary key. The AccountID may be an identifier that is already in use at the financial institution (including the account number), but security concerns recommend against using a credit card number or sensitive information as the AccountID.

[0155]

[0160] Activation may be performed by a user authenticated by the financial institution with access to presented accounts. The new map of activated AS services may be saved against the user’s list of accounts - assigning new AS services and deactivating ones that have been removed.

[0156]

[0161] No service is activated against an account unless those services are listed within the account’s available AS services. If an account has had the Account Feed Service added as part of the update, the account is marked as pending for inclusion in the nightly batch file. If an account has had the Account Feed Service removed as part of the update, it is removed from the batch file. If this is the first time an account has been activated, a unique AccountID is assigned or generated.

[0157]

[0162] Account connection and disconnection is handed over to the accounting platform server 170 to complete. For example, transfer to the accounting platform server 170 may be done via an HTTPS POST, triggered by the user from within the online financial software.

[0158]

[0163] In some embodiments, the online financial customer clicks submit and the form post is intercepted, an AJAX request retrieves the above information in encrypted form and inserts it into the form’s variables, the form is then posted. In order to complete the connection or disconnection, the user authenticates with the accounting platform server 170 with a valid user account.

[0159]

[0164] Example Data Structures and Algorithms

[0165] Described next is the format, according to an example embodiment, of the data transferred from the financial institution to the accounting platform server 170 via the user’s browser, when initiating or managing account feeds.

[0160]

[0166] The data transferred may be sent from the financial institution to the accounting platform server 170, according to some example embodiments. The data may be transferred via the user’s web browser client, as an encrypted, signed binary large object (BLOB) contained within a JavaScript object notation (JSON) data structure.

[0161]

[0167] The financial institution assembles a BLOB of data (e.g., the AccountMapMessage, discussed in more detail below) containing information about the bank accounts that the user has opted to connect to the accounting platform server 170. This BLOB contains unique identifiers, account numbers, balances, and other sensitive information, and hence can be encrypted so the data within is opaque to the client browser transferring the data.

[0162]

[0168] The AccountMapMessage data may be transferred by first encrypting the data, and then generating a message authentication code (MAC) for the encrypted data. This may be referred to as the “encrypt then MAC” pattern. For example, a symmetric key is randomly generated, and used to encrypt the AccountMapMessage data. The financial institution, sending the data, has the accounting platform server’s public RS A key that they use to encrypt the symmetric key. The accounting platform server 170, receiving the data, uses its private RSA key to decrypt the symmetric key and in turn uses it to decrypt the message.

[0163]

[0169] The financial institution has a private RSA key used to sign messages sent to the accounting platform server 170. The accounting platform server 170 uses the financial institution’s public RSA key to verify that the signature is valid. In example embodiments, various cryptographic algorithms may be used, such as advanced encryption standard (AES) for symmetric encryption, the RSA algorithm (named after Ron Rivest, Adi Shamir, and Leonard Adleman) for asymmetric encryption, and the secure hash algorithm (SHA) RSA-SHA2 for signing.

[0170] For cryptographic keys generated and used in the system, minimum key sizes may be specified. For example, an AES or SHA key may be a minimum of 256 bits, and an RSA key may be a minimum of 2048 bits. Cryptographic systems may make use of nonce and initialization vector values. The nonce is a value used once for a particular message and then discarded. The nonce generation algorithm may ensure that the nonce is unique among messages sent with the same timestamp, unique among messages from the same party, or use another criterion for selection of the nonce. In one example embodiment, a random nonce is generated and compared to previously-used values. If the nonce is acceptable, it is used. If the nonce is not acceptable, a new random nonce is generated and the process is repeated.

[0164]

[0171] An initialization vector is an input to the cryptographic system. Typically, the initialization vector is generated randomly. In some example embodiments, the initialization vector is generated using the nonce as an input to the initialization vector generation algorithm.

[0165]

[0172] Nonce and initialization vectors may be generated from a cryptographically secure random number generator. This ensures that the symmetric encryption will be strong and prevent brute force attacks against the encrypted data byes in the message. As the generation of nonce and initialization vector is performed by the financial institution, the accounting platform server 170 may request confirmation of the method used in order to confirm that the generation process is sufficiently random.

[0166]

[0173] For example, a number of default random number generators are not cryptographically secure. Instead, a cryptographically secure algorithm may be chosen (e.g. in C#, the System. Security. Cryptography.RandomNumberGenerator class should be used instead of the System. Random class).

[0167]

[0174] Example data structures that may be used by the financial institution to implement the discussed cryptographic features include:

[0168]

[0169]

[0170]

[0175] Example data structures that may be used by the accounting software to implement the discussed cryptographic features include:

[0171]

[0172]

[0176] The financial institution may use the following example algorithm to package a message for receipt by the accounting platform server. In the pseudo-code below, the JSON AccountMapMessage, containing the sensitive data, is encrypted and signed, and then the resulting MessageContainer is sent to the accounting platform server as a JSON data structure via the user’s browser.

[0173] PlainTextDataString = Base64Encode(AccountMapMessage)

[0174] IVBytes = Generate Randomly ()

[0175] EncryptedIV = RSAEncrypt(IVBytes, X PubKey) RandomKeyBytes = GenerateRandomKeyO

[0176] EncryptedRandomKey = RSAEncrypt(RandomKeyBytes, X PubKey)EncryptedDataBytes = AESEncrypt(PlainTextDataString, RandomKeyBytes, IVBytes)

[0177] SignatureBytes = CalculateSHA2Signature(

[0178] EncryptedIV + EncryptedRandomKey + EncryptedDataByte s,

[0179] FI PrivKey) MessageContainer.PC = "PROVIDER / BANKXYZ" MessageContainer.EIV = Base64Encode(EncryptedIV) MessageContainer.ERK = Base64Encode(EncryptedRandomKey) MessageContainer. Data = Base64Encode(EncryptedDataBytes) MessageContainer. S = Base64Encode(SignatureBytes) MessageContainer. SM = "RSA-SHA2"

[0180]

[0177] Verifying and unpackaging a message upon receipt by the accounting platform server may be performed as follows. Upon the receipt of a message from the financial institution, the accounting platform server may decrypt and unpack the message to ensure it has come from the financial institution, and has not been tampered with. The following algorithm, shown as pseudo-code, may be used to unpack the MessageContainer and receive the AccountMapMessage.

[0181] EncryptedIV = Base64Decode(MessageContainer.EIV) EncryptedRandomKey = Base64Decode(MessageContainer.ERK) EncryptedDataBytes = Base64Decode(MessageContainer.Data) SignatureBytes = Base64Decode(MessageContainer.S)

[0182] (Check MessageContainer. SM == "RSA-SHA2")

[0183] VerifySignatureBytes = CalculateSHA2Signature(

[0184] EncryptedIV + EncryptedRandomKey + EncryptedDataByte s,

[0185] FI PubKey)

[0186] (Check VerifySignatureBytes == SignatureBytes)

[0187] IVBytes = RSADecrypt(EncryptedIV, X PrivKey) RandomKeyBytes = RSADecrypt(EncryptedRandomKey,

[0188] X PrivKey)

[0189] PlainTextDataString = AESDecrypt(EncryptedDataBytes,

[0190] RandomKeyBytes, IVBytes) AccountMapMessage = Base64Decode(PlainTextDataString)

[0178] The accounting platform server 170 may then validate the internals of the AccountMapMessage to check whether it has integrity. Validating the origin of the message may be performed by verifying that the Check

[0191] AccountMapMessage. Pro viderlD matches MessageContainer. PC. Validating that the message is current may be performed by verifying that TimeStampUTC is within the tolerance for valid messages, and the message has not expired. Validating that the message is not a replay attempt may be performed by verifying that the (TimeStampUTC, Nonce) pair have not been used for this provider. Other validation of message contents that may be performed

[0192]

[0179] If all of these verification and unpackaging operations succeed, then in certain embodiments, the user is shown screens allowing them to continue the activation process within the accounting platform server 170.

[0193]

[0180] The message encryption and packaging described above may be implemented to allow messages to pass from the financial institution to the accounting platform server 170 over an untrusted communication mechanism (e.g., over the Internet via the user’s browser).

[0194]

[0181] The encryption and signing may provide guarantees that the message was legitimately generated by the financial institution, not tampered with or viewed in transit, and cannot be replayed. The financial institution can also be assured that only the accounting platform server 170 will be able to decrypt the data. Various security threats are discussed in more detail below.

[0195]

[0182] With regards to spoofing, it is not possible for anyone other than the financial institution to generate a valid message, due to the use of the public / private key pair shared between the accounting platform server 170 and the financial institution.

[0196]

[0183] With regards to repudiation, the financial institution signs the data using their private key, which is kept secret and held only by them. When the accounting platform server 170 receives the message and checks the signature using the financialinstitution’s public key, they can be assured that the financial institution originally generated the message.

[0197]

[0184] With regards to tampering, the signature check also prevents tampering in transit. If the IV, key or data is altered, then the signature check will fail.

[0198]

[0185] With regards to Information Disclosure, the AccountMapMessage may contain some sensitive information, such as bank account balances or account numbers. This is encrypted using a one-time-use encryption key. The encryption key is transmitted in the message, but is encrypted asymmetrically using the accounting platform server’s public key, which only the accounting platform server 170 can decrypt.

[0199]

[0186] With regards to Replay, Replay attacks are prevented by a timestamp and nonce value, which allows the accounting platform server 170 to guarantee it will receive and process a given message only once. If a message arrives with the same timestamp and nonce, the accounting platform server 170 will reject the message.

[0200]

[0187] With regards to Man-in-the-middle attacks, it is possible for an attacker to intercept the generated JSON from the financial institution, and forward it to the accounting platform server 170 before the legitimate user is able to. This is mitigated by SSL / TLS connections being used in the user’s browser, preventing MiTM on the client side, and the use of a short expiration against the message timestamp. As the user is not required to perform any action between the message generation and the immediate POST to the accounting platform server 170, the expiration can be kept short.

[0201]

[0188] With regards to Denial of Service attacks, this protocol does not provide protection against denial of service - an attacker could send large, malformed, or numerous messages to the accounting platform server endpoint and incur a costly signature check or decryption process to occur. This will be mitigated by using the accounting platform server’s standard brute force detection mechanisms.

[0189] With regards to Elevation of Privilege, the message transferred from the financial institution to the accounting platform server 170 does not convey privileges from one environment to the other. The user still has to authenticate independently with both the financial institution’s site and with the accounting platform server 170.

[0202]

[0190] Financial Institution Data Examples

[0203]

[0191] Data provided by the financial institution may indicate an account type for each financial account of the user. For example, the C# class below can be used to implement an account type indicator. Similarly, the JSON example below may be used to indicate that an account is a current account.

[0204] Sample C# class:

[0205] public enum AccountType

[0206] {

[0207] CreditCard = 1,

[0208] Current = 2,

[0209] Savings = 3,

[0210] Loan = 4,

[0211] Investment = 5,

[0212] Foreign = 6,

[0213] Other = 7,

[0214] }

[0215] Sample JSON value:

[0216] {

[0217] “AccountType”: 2

[0218] }

[0219]

[0192] Data provided by the financial institution may indicate one or more services provided for each financial account of the user. For example, the C# class below can be used to implement a service type indicator. Similarly, the JSON example below may be used to indicate that both an account feed service and a third party payment service are available for an account.

[0220] Sample C# class:public enum AS Service

[0221] {

[0222] AccountFeedService = 1,

[0223] ThirdPartyPaymentService= 2,

[0224] }

[0225] Sample JSON value:

[0226] {

[0227] “ServicesA vailable”: [

[0228] 1,

[0229] 2

[0230] ]

[0231] }

[0232]

[0193] Data stored at the AS system can reflect information about a financial account at the financial institution, including services available for that financial account. Below is a table of data types and descriptions for values that can be used in a C# class to store such account-specific data.

[0233]

[0234]

[0235] Sample C# class:

[0236] public class ActiveAccountServiceMap

[0237] {

[0238] public string AccountID;

[0239] public string AccountNumber;

[0240] public string AccountDescription;

[0241] public AS Service [] ServicesA vailable;

[0242] public AS Service [] ServicesActivated;

[0243] public decimal CurrentBalance;

[0244] public AccountType AccountType;

[0245] public string Currency;

[0246] }

[0247] Sample JSON value:

[0248] {

[0249] “AccountID”: “1123451111111100”,

[0250] “AccountNumber”: “1123451111111100”,

[0251] “AccountDescription”: “My Current Account”,

[0252] “ServicesA vailable”: [

[0253] 1,

[0254] 2

[0255] ],

[0256] “ServicesActivated”: [

[0257] 1

[0258] ],

[0259] “CurrentBalance”: 213.97,

[0260] “AccountType”: 2,

[0261] “Currency”: “NZD”

[0262] }

[0263]

[0194] Another example data type is the AccountMapMessage, containing the complete message indicating activated accounts to be sent from the financial institution to the accounting platform server 170.

[0264]

[0265]

[0266]

[0267] Sample C# class:

[0268] public class AccountMapMessage

[0269] {

[0270] public string ProviderlD;

[0271] public string UserID;

[0272] public Active AccountServiceMap[] ActiveAccountServiceMaps; public DateTime TimestampUTC;

[0273] public string Nonce;

[0274] public string RetumURL;

[0275] }

[0276] Sample JSON value:

[0277] {

[0278] “ProviderlD”: “PROVIDER / BANKXYZ”,

[0279] “UserID”: “user@bank”,

[0280] “ActiveAccountServiceMaps”: [

[0281] {

[0282] },

[0283] {

[0284] }

[0285] ],

[0286] “TimestampUTC”: “2012-12-10T00:00:00”

[0287] “Nonce”: “A7813747-C47A-496E-8DE6-682D16A457D2”, “RetumURL”: “https: / / www.xyz.com / ”

[0288] }

[0289]

[0195] Another example data type is the MessageContainer, containing the message that is sent from the financial institution to the accounting platform server 170 via the user’s browser. Each Byte[] is transmitted as a Base 64 encoded string when rendered as JSON.

[0290]

[0291] ""

[0292]

[0293] Sample C# class:

[0294] public class MessageContainer

[0295] {

[0296] public string PC;

[0297] public byte[] Data;

[0298] public byte[] ERK;

[0299] public byte[] EIV;

[0300] public byte[] S;

[0301] public string SM;

[0302] }

[0303] Sample JSON value:

[0304] {

[0305] "PC": "PROVIDER / BANKXYZ",

[0306] "Data": "qas43...==",

[0307] "ERK": "Rxut..

[0308] "EIV": "QEDF...==",

[0309] "S": "zyw...==",

[0310] "SM": "RSA-SHA2"

[0311] }

[0312] (Base 64 encoded values elided)

[0196] Example of User Account Management

[0313]

[0197] Once the user has been redirected from the financial institution to the accounting platform server 170, and the appropriate information passed, the accounting platform server 170 can associate each AccountID with a user’s accounting platform server 170 account. If an account is connected, then the active AS services are provided to that account.

[0314]

[0198] The user can manage accounts that have already been connected. In this case, they can be shown the status of the connection and be enabled to disconnect the accounts if they wish. If an account is disconnected, then the active AS services are removed from that account.

[0315]

[0199] In embodiments, prior to allowing a user to manage an account, one or more of the following preconditions is verified. The user is authenticated with the accounting platform server.

[0316]

[0200] Example Private Financial API

[0317] The ProviderCode is recognized.

[0318] The random key can be decrypted with the accounting platform server’s private key. The request data can be decrypted with the random key.

[0319] The signature is verified with financial institution’s public key.

[0320] The ProviderlD is a valid provider.

[0321] The nonce has not been used before.

[0322] The data is able to be parsed and all required elements are included.

[0323] At least one AccountServiceMap with an Active Service is included in the list of ActiveAccountServiceMaps.

[0324] The timestamp is within a valid timeout period.

[0325]

[0201] In some embodiments, in order for the accounting platform server 170 to share services with the financial institution, the financial institution exposes a number ofservices to the accounting platform server 170. These allow the accounting platform server 170 to perform actions against the financial institution when instructed by the customer. Additional services may also be supported.

[0326]

[0202] The financial institution may implement a small web service that accepts and responds to JSON POST requests. The specifications for expected requests and responses are below.

[0327]

[0203] Access to the financial services endpoint may be secured by VPN and usable only by the accounting platform server 170. The complete URL for the service is unique to the providing financial institution, but the endpoints may be the same for all participating financial institutions. Example endpoints are given below with each service.

[0328]

[0204] With respect to third party payments, once the financial institution account has been activated and connected with a third party payment service, a batch payment against that account can be submitted to the financial institution. If an account has the third party payment service against it, when an accounting platform server 170 user creates a batch payment as part of their management of accounts payable, they have the option to directly submit that batch to the financial institution for authorization and completion.

[0329]

[0205] A representational state transfer (REST) architecture may support a RESTful interface between a client and a server. The RESTful interface may be stateless (e.g., no client context may be stored on the server between requests). The RESTful interface may be cacheable (e.g., responses from the server may indicate if they are cacheable). A client may cache the cacheable responses, reducing network traffic and latency. The RESTful interface may be layered (e.g., the client may connect to an intermediate server rather than an end server). The RESTful interface may identify the resources involved in each request in order to allow the client to modify the resources it possesses. Furthermore, in a stateless RESTful interface, each REST message may beself-contained and include enough information to describe how to process the message. Some clients may track their own state and make state transitions only through hypermedia (e.g., hyperlinks).

[0330]

[0206] The third-party payment request may be a RESTful HTTP request that posts a JSON message and expects a JSON response. The format of example JSON requests and responses are provided below.

[0331]

[0207] Third Party Payment Request - Request that a payment or batch of payments be made from an account of the user to a third party. The request is made by the AS to the financial institution. In some example embodiments, the bank executes the payment based on the payment request, without further intervention from the account holder. In other example embodiments, after receiving the payment request from the accounting application, the bank holds the payment for authorization from the account holder. For example, the bank may present a list of requested payments to the account holder via a mobile application or web interface, and execute the payments only after receiving an authorization from the account holder.

[0332]

[0208] Endpoint: / thirdpartypayment

[0333]

[0209] Each item in a batch describes a single transaction. Example elements of a batch item:

[0334]

[0335]

[0336]

[0210] Example Elements of a Third Party Payment Request:

[0337]

[0338] Sample Request:

[0339] Header:

[0340] POST / thirdpartypayment

[0341] Content-Type: application / json

[0342] Message:

[0343] {

[0344] "ProviderCode" : "Xero",

[0345] "UserID" : "12312323","AccountID" : "060158390390200",

[0346] "FromParticulars" : "PayerName",

[0347] "fromReference" : "PayerReference",

[0348] "fromCode" : "PayerCode",

[0349] "PaymentDate" : "2012-12-13",

[0350] "Batchitems" : [

[0351] {

[0352] "AccountNumber" : "040932093021903",

[0353] "Amount" :

[0354] "323.00",

[0355] "Name" : "Payee", "Particulars" : "PayeeName",

[0356] "Reference" : "PayeeReference"

[0357] "Code" :

[0358] "PayeeCode",

[0359] }

[0360] ],

[0361] "TotalAmount" : "323.00",

[0362] }

[0363]

[0211] Third Party Payment Response - The financial institution provides a response to the third party payment request.

[0364]

[0212] The response returns HTTP status to report the success of the request. If there is a server error, the message will include a JSON packet that contains a non-empty array of error messages. The batch should be processed in full, returning a 200 status, or not processed at all, returning a 500 error and the relevant error messages.

[0365]

[0213] Example Elements of an error message type:

[0366]

[0367]

[0368]

[0214] Sample Response:

[0369] Header:

[0370] HTTP / 1.1 200 OK

[0371]

[0215] Sample Error Response:

[0372] Header:

[0373] HTTP / 1.1 500 Server Error

[0374] Message:

[0375] {

[0376] "ErrorMessage": [

[0377] "Human readable error message",

[0378] "Can be multiple lines"

[0379] ],

[0380] }

[0381]

[0216] Update Registration Request is a request to update the registration data at the financial institution for an account already registered. The request is made from the accounting platform server 170 to the financial institution. Updating the registration data for a financial account may include registering a feed for the account with the bank, disconnecting the financial account from the corresponding the accounting platform server 170 account, or otherwise changing the registration of the account.

[0382]

[0217] The accounting platform server 170 may implement a periodic job to identify disconnected accounts and verify that they meet certain criteria (e.g., time period for which they have been disconnected, etc.), prior to updating their status to show that they have been deregistered. The requests may be submitted in a batch.

[0383]

[0218] Endpoint: / updateregistration

[0384]

[0219] Each item in a batch request indicates a single account to update. Exampleelements of a request for update of a single account:

[0385] Element Type Description

[0386] Name

[0387] UserID String(50) Financial institution’s customer number / unique identifier.

[0388] Accountld String(50) Financial institution’s account identifier.

[0389] Unique within the financial institution.

[0390] AccountStatus String(50) Valid values are “Register” or “Deregister”. Indicates whether an accounts data should be included in the nightly feed provided to the accounting platform server. Typically an account will be registered once connected to the accounting platform server account, and deregistered on customer instruction, on the deletion of their subscription or if they have been removed from an organisation.

[0391]

[0220] Example elements of an Update Registration Request:

[0392]

[0393] Header:

[0394] POST / updateregistration

[0395] Content-Type: application / json

[0396] Message:

[0397] {

[0398] "ProviderCode" : "Xero",

[0399] "AccountsToUpdate" : [

[0400] {"UserID" :

[0401] "234324324",

[0402] "AccountID" : "23432432432",

[0403] "Accountstatus" : "Register"

[0404] }

[0405] ]

[0406] }

[0407]

[0221] With regards to the Update Registration Response, the financial institution provides a response to the Update Registration Request. Additionally, upon receiving a registration or deregistration request, the financial institution may add or remove the account from the list of accounts used in the feed provided to the accounting platform server 170.

[0408]

[0222] The update registration request may be processed in full, returning a 200 status, or not processed at all, returning a 500 error and the relevant error messages for the accounts that could not be registered or deregistered.

[0409]

[0223] Example elements of an error response from the financial institution:

[0410]

[0411]

[0224] Sample Success Response:

[0412] Header:

[0413] HTTP / 1.1 200 OKSample Error Response:

[0414] Header:

[0415] HTTP / 1.1 500 Server Error

[0416] Message:

[0417] {

[0418] "ErrorResults": [

[0419] {

[0420] "UserID" :

[0421] "234324324",

[0422] "Accountld" : "23432432432",

[0423] "ErrorMessage" : [ "Human readable error message",

[0424] "Can be multiple lines"

[0425] ]

[0426] }

[0427] ],

[0428] }

[0429]

[0225] Other Data Types

[0430]

[0226] The table below contains additional data types that are used in various embodiments at either or both of the accounting service and the financial institution.

[0431]

[0432]

[0227] The table below contains additional data that is used in various embodiments at the financial institution.

[0433]

[0434]

[0435]

[0228] The table below contains additional data that is used in various embodiments at the accounting system.

[0436]

[0437]

[0438]

[0439]

[0229] Example Account Feed Service with File Delivery

[0440]

[0230] Batched Supply of Statement Data

[0441]

[0231] The financial institution can submit data to the accounting platform server 170 in a batch. In some embodiments, the financial system verifies that each account has been activated, registered, and confirmed prior to adding data for the account to the batch.

[0442]

[0232] The financial institution may post the latest transactions for all active and confirmed accounts via a periodic (e.g., nightly) batch file over secure file transfer protocol (SFTP). The batch contains statement data for all accounts that are marked as activated, or a subset thereof. The batch file may be keyed by AccountID. If the accounting platform server 170 encounters an AccountID that is not recognized (e.g., activated but not connected), the data is ignored. Otherwise the data is loaded into the accounting platform server 170 account associated with that AccountID. The accounting platform server 170 processes the feed data from the financial institution to create corresponding entries in the single-ledger accounting system.

[0443]

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

[0444]

[0234] It will be appreciated by persons skilled in the art that any particular method and / or technology that is described in relation to or used in combination with any one or more individual element or elements in the above-described embodiments may equally be applied to any other applicable elements described above, without departing from the broad general scope of the present disclosures.

Claims

CLAIMS:

1. A computer-implemented-method comprising:providing, by accounting platform server, an accounting platform in a cloud computing environment, wherein the accounting platform is configured to gather accounting data and provide accounting services to the plurality of users;importing, by the accounting platform server, and from a financial institution, financial data for each of a plurality of users having a user account with the accounting platform, wherein the accounting platform is configured to import the financial data over a network through a bank feed or document, or over a network via an application protocol interface;receiving, by the accounting platform server, from an event logging engine, a request to receive event notifications, wherein each event notification is indicative of an action taken on an account associated with the accounting platform;transmitting, by the accounting platform server to the event logging engine, over a first period of time, a plurality of event notifications, each event of the plurality of the action notifications comprising one or more action attributes;after the period of time, sending by the accounting platform server to the event logging engine, a request for one or more event objects associated with the account or a group of similar accounts;receiving, from the event logging engine, a dataset of event objects; andtraining a model based on the dataset of event objects to provide a trained model.. The method of claim 1, further comprising:providing, by the accounting platform server, account credentials of the plurality of users to the financial institution to obtain access to the financial data for the plurality of users.

3. The method of claim 1 or claim 2, wherein the trained model is trained to detect instances of fraud, potential fraud and / or attempted fraud on the accounting platform.

4. The method of any one of the previous claims, wherein the action is a login attempt indicative of an attempt by a user to log onto the accounting platform, wherein the one or more action attributes of the action event notification comprise one or more of: Internet Protocol (IP) address, Internet Service Provider (ISP), user or device location, and device identifier.

5. The method of any one of the previous claims, wherein the trained model is configured to evaluate a risk of a specific login event based on an input comprising values for one or more of: Internet Protocol (IP) address, Internet Service Provider (ISP), user or device location, and device identifier.

6. The method of any one of the previous claims, wherein the dataset of event objects comprises examples of historic login attempts associated with one or more users or accounts.

7. The method of any one of the previous claims, further comprising:receiving a candidate login event, the login event comprising one or more attribute values for one or more of: Internet Protocol (IP) address, Internet Service Provider (ISP), user or device location, and device identifier;providing the attribute values as an input to the trained model; and determining an output indicative of likely fraud.

8. The method of claim 6, further comprising:responsive to determining an output indicative of likely fraud, instigating one or more mitigation actions, wherein the mitigation actions comprise:issuing a notification to a relevant user and / or organisation associated with the candidate login attempt to notify them that a potentially fraudulent login attempt was made on their account;providing an opportunity to a relevant user and / or organisation to verify the login attempt as a verified or true login attempt; and / orenhancing the security of the account.

9. The method of claim 7 or claim 8, further comprising:retraining the ML model using the candidate login attempt as a training example to improve its accuracy in predicting fraudulent login attempts.

10. A computer-implemented-method comprising:receiving, by an accounting platform, from an event logging engine, a request to receive action notifications, wherein each action notification is indicative of an accounting action taken on an account associated with an accounting platform provided by the accounting platform server;transmitting, to the event logging engine, an action notification, the action notification comprising one or more action attributes indicative of an action;sending, to the event logging engine, a request for one or more event objects associated with the account;receiving, from the event logging engine, a dataset of event objects; anddetermining from the dataset behaviours indicative of the account.

11. A computer-implemented method comprising:sending, by an accounting platform, to an event logging engine, a request for a plurality of event objects, the request comprising one or more event object criteria;receiving, by the accounting platform, from the event logging engine, the plurality of event objects, each of the event objects being associated with an account of an accounting platform and at least some of the event object criteria;determining, from the plurality of event objects, a first dataset of event objects, each of the event objects of the first dataset being indicative of a first financial attribute of the account;determining, from the plurality of event objects, a second dataset of event objects, each of the event objects of the second dataset being indicative of a second financial attribute of the account; andcomparing the first dataset and the second dataset to determine an indication of whether fraud has been detected.

12. A computer-implemented method comprising:sending, by an accounting platform, to an event logging engine, a request for a plurality of event objects;receiving, by the accounting platform, from the event logging engine, the plurality of event objects, each of the plurality of event objects being associated with an account of an accounting platform;determining, from the plurality of event objects, one or more quality control attributes;determining, from at least the plurality of event objects, one or more ground truth attributes;determining, by comparing the quality control attributes with the one or more ground truth attributes, an indication of the quality of the plurality of event objects.

13. A computer-implemented method comprising:sending by an accounting platform, to an event logging engine, a request for a plurality of event objects, the request comprising a time period;receiving, by the accounting platform, from the event logging engine, the plurality of event objects, each of the plurality of event objects being associated with an account of an accounting platform, and comprising information relating to activities that occurred on the account during the time period;determining, from the plurality of event objects, one or more account histories indicative of one or more behaviours of the account over the time period; anddetermining from the one or more account histories, one or more behaviour characteristics of the account over the time period.

14. The method of any one of the preceding claims, further comprising:importing into user data, by the accounting platform in a cloud computing environment, financial data for each of a plurality of users having a user account with the accounting platform,wherein the accounting platform is configured to access and import banking data over a network through a bank feed or document, or over a network via an application protocol interface,wherein the accessing the banking data comprises providing account credentials of the plurality of users to obtain access to the banking data for the plurality of users, andwherein the accounting platform is configured to gather accounting data and provide accounting services to the plurality of users.

15. The method of claim 14, further comprising:receiving, at the accounting platform server, from a financial system, an authorization to link a financial account at the financial system with a bookkeeping account at the accounting platform server, the accounting platform server maintaining bookkeeping accounts for a plurality of entities, the authorization identifying a first user associated with a first entity of the plurality of entities;based on the receiving of the authorization identifying the first user, linking the bookkeeping account associated with the first entity to the authorized financial account;registering, by the accounting platform server, for a bank record feed from the financial system, the registering using the authorization from the financial system; responsive to the registering for the bank record feed, receiving financial account data related to the financial account from the financial system;generating accounting data related to the bookkeeping account using the financial account data; andstoring the accounting data in a database.

16. The method of claim 15, further comprising:storing, at a primary data center storage layer, the imported financial data for each of the plurality of users having a user account with the platform; and replicating the primary data center storage layer in a secondary data center storage layer, including replicating the imported financial data for each of the plurality of users having a user account with the platform, so that the imported financial data for each of the plurality of users having a user account with the accounting platform is consistent at the secondary data center storage layer and the primary data center storage layer.

17. The method of any one of claims 1 to 13, wherein the accounting platform is provided by a primary data center comprising a plurality of pods, each pod comprisingone or more application server virtual machines that are specific to the pod, and the plurality of pods collectively providing an internal services virtual machine that is shared between the plurality of pods, and wherein the internal services virtual machine provides back-end tools for the application server virtual machines and / or monitoring tools to an application hypervisor monitoring the application server virtual machines.

18. The method of any one of claims 1 to 13, wherein the accounting platform is provided in a cloud computing environment, and wherein the accounting platform server provides the accounting platform by a primary data center in an online state and comprising one or more pods, each pod comprising one or more application server virtual machines that are specific to the pod, and in case of a fault in the primary data center, the accounting platform server provides the accounting platform by a secondary data center in an online state, the secondary data center comprising one or more pods to which the one or more pods of the primary data center are replicated, respectively.

19. The method of claim 18, wherein, while the primary data center is in an online state, maintaining the secondary data center in an offline state in which energy consumption is reduced relative to power consumption in the online state of the secondary data center; andin response to the primary data center developing a fault, changing a state of the secondary data center from the offline state to an online state in which the secondary data center is providing the accounting platform in the cloud computing environment, and changing a state of the primary data center to an offline state.

20. The method as recited in claim 19, further comprising:while the primary data center is in the online state, balancing load between the one or more pods of the primary data center; andwhile the secondary data center is in the online state, balancing load between the one or more pods of the secondary data center.

21. A system comprising:one or more processors; andmemory comprising computer code, which when executed by the one or more processors, causes the system to perform the method of any one of claims 1 to 20.

22. A machine -readable medium storing computer readable code, which when executed by one or more processors is configured to perform the method of any one of claims 1 to 20.

Images