WO2001048626A2

WO2001048626A2 - Intelligent transaction monitor system and method

Info

Publication number: WO2001048626A2
Application number: PCT/GB2000/004757
Authority: WO
Inventors: Jason Kingdon; Konrad Simeon Feldman
Original assignee: Searchspace Limited
Priority date: 1999-12-23
Filing date: 2000-12-12
Publication date: 2001-07-05
Also published as: GB2357603A; WO2001048626A3; EP1244976A2; AU2195701A; GB2357603B; GB9930565D0

Abstract

An automated system and method that uses historical models of business activity to automate business monitoring and analysis tasks. The system builds profiles of historical business transactions and performs comparative analysis between these profiles and new, unseen data. In this way, the system can classify and make judgements about new, unseen transactions and alert operators to unusual transactional patterns. Operators may also be alerted when the system recognizes prescribed patterns of activity. The system provides a means to update the historical activity profiles and maintains them such that they may be used to provide supporting evidence in order for operators to make decisions about alerts generated by the system and to perform other forms of analysis on the transactional data. Alerts generated by the system are ranked according to their relative importance and may be assigned for processing by a specific operator, or group of operators.

Description

INTELLIGENT TRANSACTION MONITOR SYSTEM AND METHOD

Background of the Invention

Field of the Invention

This invention relates generally to the monitoring, recording and analysis of business activity. In particular the invention relates to an automated business monitoring system and method that uses historical profiles of activity in order to assess the relevance associated with given business transactions or business events. The system compares unseen transactions with historical profiles of business activity and can alert operators to unusual patterns of activity or patterns of prescribed activity that are known to be of interest.

Description of the Related Art

In the following discussion, the term "bank transaction" will be used for illustrative purposes; however, the techniques and principles discussed herein apply to other types of transactions, such as those of retail companies, finance institutions, securities exchanges, internet payments, telecommunication payments, and data transacted over computer networks.

The concept of a transaction exists in all business and financial processes. A transaction may be considered as the act of obtaining and paying for an item or service, a business deal or negotiation, the exchange of value, or the transmission and processing of an item of data. Transactions occur in retail industries, finance, banks, stock exchanges, Internet payments, computer networks as well as a plethora of other businesses and services. Transactions may also be used for identification purposes and may represent requests and responses for action. Historically, transactions have been recorded for accounting purposes, for stock control and for other business management purposes. As an example, a transaction would include details of parties involved, the volume, value and type of goods, services or value transacted and other fields that might have relevance to the transaction process. Such transactions can be described and stored in computer systems.

The use of automated computer based systems to record and process transactions has become commonplace. As transaction volumes increase, the ability to monitor and record transactions is of increasing importance for businesses. Computer based Management Information (Ml), Enterprise Resource Planning (ERP), Customer Relationship Management (CRM) and Data Warehouse (DW) systems allow businesses to record transactions in databases and perform processing based on the content of the transactions.

Systems of this type record the transactions and associated reference data in databases that may be queried for business analysis purposes. These systems allow analysts to query and extract information that may have particular significance for the business concerned. For example, an analyst might extract accounting or payroll information or might use the system to identify other factors such as the most commonly traded product or service. Where such systems are used for regulatory purposes, an analyst might run a sequence of queries or fixed reports in order to monitor the activity of various business entities, including individuals or groupings of individuals, within an organisation. On the basis of the results of such reports, an analyst may then make decisions concerning aspects of a business including security, regulation, compliance and audit.

The dimensionality of many problems and the number of variables that must be considered make it difficult for an analyst to consider all possible aspects that may be required to make an informed decision concerning a business or process. These problems are compounded as transaction volumes increase and the quantity of data that must be considered makes it difficult or impossible for a human to make a fully reasoned decision. Given large data sets and high transaction volumes, it becomes difficult for analysts to identify characteristic patterns in transaction data that might be indicative of behaviors or details that have significance for a business. Data mining approaches have been proposed as a solution to some of these problems. Data mining tools attempt to recognize patterns in data in order to identify behavioral or other characteristics. Data mining approaches often apply neural network or rule learning techniques in order to identify characteristics in underlying transaction data. These methods often assume a training data set, providing a reference set of example characteristics to be identified in unseen data sets. In many business environments, such data is unavailable or the quality of sample data is insufficient to make appropriate generalizations. Many data mining solutions are unsuitable in business environments because their results lack explanation, or the explanation that they may provide may be too complex for business analysis purposes.

Further, in all of these processes the investigative processes are initiated by an analyst seeking to answer specific business questions. A significantly more efficient approach is for a system to automatically screen and process data in a systematic fashion in order to identify characteristic behaviors and patterns that may be of interest to a business, and for such a system to inform operators when such events occur.

Summary of the Invention

In accordance with the present invention, there is provided an automated system and method for monitoring business activity, which builds historical profiles of transactions and makes comparisons between these profiles and unseen business events in order to detect unusual patterns of behavior and alert system operators to them. In addition to the detection of unusual activity, the system may also be configured to alert operators to the occurrence of known, or predetermined, patterns of activity. The system provides storage for business transactions that may be grouped according to business entities and provides storage for the profiles associated with these transactions. In this way, the system provides a record of business activity across a predetermined timeframe. This data is updated in accordance with ongoing business activity and according to the entities being monitored. Updates are generally, but not exclusively, performed nightly and may also be performed as data becomes available for processing or during periods in which the system would otherwise be inactive. Historical profiles are re-generated on a regular basis, which may or may not be based on the frequency of data updates and additions. The historical profiles are based on aggregate statistics of the business data being stored and provide statistical distributions of business activity. The system uses the historical profiles as a reference of previous business activity in order to qualify unseen business transactions or business events. In this way the system can identify unusual patterns of activity and alert system operators to them. The system may also use the profiles in order to identify and alert operators to pre-determined patterns of activity. Alerts generated by the system are ranked according to their relative importance or likelihood of interest to the system operators. The system provides the means to manage the distribution of specific alerts to given operators, or groups of operators. The system also provides the means to manage the processing and lifecycle of these alerts allowing alert re-direction based on operator input, alert priority, or to guarantee processing within a given time period. The system retains logs of all alerts generated and operator actions and may use this information in order to improve system performance. The invention has application in numerous business areas including but not limited to the following: for the detection of patterns of payment fraud and money laundering in banking environments, for market surveillance in stock exchanges, and for risk analysis, regulatory control and compliance in other financial, business and insurance, for on-line fraud detection, customer profiling for marketing and cross-selling, and for product usage analysis.

Brief Description of the Drawings

A specific embodiment of the present invention is now described, by way of example only, with reference to the accompanying drawings, in which:

Figure 1 is a block diagram of an implementation of the present invention.

Figure 2 is a block diagram showing detail of an implementation of the present invention. Figure 3 is a block diagram showing detail of a typical transaction record.

Figure 4 shows a schematic presentation of profiles constructed across different time periods.

Figure 5 shows an example profile record for a business entity.

Figure 6 shows an example alert record raised by an investigation unit. Figure 7 is a sample graphical user interface which forms part of the typical output interface for the present invention showing alerts raised by the system.

Figure 8 is a sample graphical user interface which forms part of the typical output interface for the present invention showing justification for an alert raised by the system. Figure 9 is a sample graphical user interface which forms part of the typical output interface for the present invention showing justification in a graphical form for an alert raised by the system.

Figure 10 shows a flow diagram of the transaction data input and validation process. Figure 11 shows a flow diagram detailing the construction of profile records for business entities based on the transaction data.

Figure 12 shows a flow diagram detailing the alert generation process where multiple investigation units are being used. Description of the Preferred Embodiment

The present invention is described in terms of an example banking environment. Those skilled in the art will understand that the invention may be applied in a wide range of business monitoring systems and a multitude of environments. Given the description herein, it would be obvious to one skilled in the art to implement the present invention in any general computer or computing environment and in a multitude of business types and areas.

Description in these terms is for convenience only. It is not intended that the invention be limited in application to this example environment. In fact, after reading the following description, it will become apparent to a person skilled in the relevant art how to implement alternative environments of the invention.

In general, but not exclusive terms, the invention can be implemented as shown in Figure 1. Figure 1 shows a block diagram of a typical implementation of the system 100 in accordance with the present invention. Transaction data 140 enters the system from one or more transaction data sources 141 , 142, 143, 144. This data originates from sources including but not limited to existing database systems, automated teller machine (ATM) systems, and bank branch level systems or banking transactions systems such as CHIPS and SWIFT. The data may be transported across computer networks using standard transaction and messaging systems that perform data delivery and distribution tasks. It may also enter the system in the form of flat files, database format files or database archives. Transaction data can be extracted from systems or be delivered directly for processing.

The invention comprises a monitor 110, a data storage facility 130 and a multitude of output devices 120 to convey system findings to operators. In the preferred embodiment, the monitor 110 operates on a variety of conventional computer hardware platforms and operating systems, the data storage 130 is performed using one or more database systems, and the output devices 120 are standard computers, workstations or other computer enabled devices. The output devices 120 may also be used for system maintenance and administration tasks.

The monitor 110 processes all transactions as they enter the system. Processed transactions are stored in the data storage 130 unit and are used during further analysis stages. On the basis of the transactions entered into the system, the system identifies patterns of known interest for the business and may also present information based on changes in known transactional characteristics. The system generates alerts that identify each such occurrence. These alerts are ranked according to the significance or the business interest of the occurrence. Alerts generated by the system are distributed to system operators and displayed on output devices 120.

Figure 2 shows a more detailed view of the system. The monitor 110 comprises a number of functional units. A data manager 200 controls the processes of access and storage of data to and from all other system units. Data is maintained and stored within the system over a predetermined timeframe appropriate to the business; this might typically be between 1 and 5 years. The data manager 200 validates transaction data as it arrives into the system and is responsible for the archiving and deletion of data from the system. Data storage comprises three logical units: storage of transaction data 220; storage of reference data 210 which contains system specific data, system audit information and logs, and may contain additional supporting information relating to the transaction data; and profile storage 230 which contains aggregate and statistical information derived from the transaction data and holds in addition transaction data that may be in normalized forms. The profile data is used to identify known characteristics and the changes in these characteristics, and to provide summary analysis of the transaction data.

A data modeler 240 is responsible for construction of the transaction profiles stored in the profile storage 230. The data modeler 240 may construct multiple profiles for each business entity, the exact form of which are dependent on the business monitoring and analysis task. An event manager 250 controls process sequences in the system and is responsible for alert routing, alert processing and alert distribution. The system may operate with one or more investigation units 261 , 262. The investigation units use the profile data 230 as a source for analysis, which allows analysis tasks to be performed quickly and efficiently. The results of the investigation units may be cascaded such that the investigations performed by one unit triggers further investigations by other units. Certain investigations may require supplementary data representations which are provided on request by the data modeler 240. The output of multiple investigation units may be combined to generate system alerts. The output of single investigation units may also create alerts directly.

A reporting unit 270 is responsible for the generation of reports which present details of the transaction information extracted from the transaction storage 220 or information extracted from the reference storage 210 or the profile storage 230. Reports may be generated at immediate operator request, when the system has available resource to perform the request, or on a batch basis at defined times or at given intervals. Reports generated may be viewed by the operators using the output devices 120, although these may also be presented in other forms and also stored and printed.

An access manager 280 is responsible for operator authorization, operator authentication and system access control. The access manager uses password authentication methods to verify operator identity, but may also use alternative forms of identification and access control. Encryption and other methods may be used to ensure that all information passed to and from the output devices is secure, and this may also be used for non-repudiation purposes. All system access is audited in the reference storage 210. The access manager provides methods for the control and change of user passwords. It applies methods to prevent the selection by users of passwords that would be considered to compromise the security of the system. The access manager 280 controls the frequency at which users are required to change passwords. The access manager 280 provides operator groupings in order to provide different levels of access to system functionality for different groups of operators. In this way, different operator groups are limited in the extent to which they may access the functionality of the system. Operators may be members of multiple operational groups and therefore have access to the functionality associated with each group. Typically these groupings allow access to different sets of profiles and access to the transaction data in differing degrees. Some operator groups are allowed to add, update or change profile or transaction records or data controlling system operation. Other operator groups are restricted to views of specific system results, profiles or transaction records.

Figure 3 shows an example transaction record 300 for a bank payment. The record 300 contains a number of data fields including the time and date of payment 310, the payer customer account 320, the payee account 330, the currency 340 associated with the transaction, the value of the transaction 350 and numerous other fields for other bank purposes 360, 370. Such transactions may appear in a multitude of other forms, which may include single entry systems where only the payer or payee account details are present.

The profiling of transaction data is performed by the data modeler 240. Profiles are generated automatically by the data modeler 240 and aim to capture and quantify the salient characteristics of the transaction data being profiled. The actual selection of profile types used in the system is dependent on the business characteristics being monitored. The data modeler 240 builds numerous profiles for each business entity. For example, profiles generated for a banking environment would typically include, but not be limited to, regional entities, bank branches, customers and account types. Other profiles will be generated that provide aggregates across complete business entities, such as aggregate details according to customer account type at branch and regional levels, and counterparty profiles. For example, a customer's transactions would contribute to profiles built to represent the account associated with the transactions, the profiles for the customer involved, the profiles of the bank branch to which the customer belongs and profiles of account types associated with this branch. In this way a plethora of different profiles are generated each providing different views of characteristics of entities associated with a business.

Profiles may encompass temporal characteristics that are built across given timespans. Figure 4 shows the relationship of profile views that may be constructed over time. 410 represents numerous transactions associated with a bank entity over a period of time, these are aggregated by day 420, further aggregated by week 430, by month 440, and by year 450. Other aggregate forms are possible across quarterly periods, 4 weekly periods or at greater granularity such as hourly or by the second where there is a requirement for this to be performed or the transaction volumes present a requirement for such aggregations. Other aggregations based around notional concepts such as a business day or working periods are possible, or those related to transaction arrival rates. Such profiling allows seasonal and other characteristics to be considered during further analysis.

Figure 5 presents an example profile record 500 for a business entity. In this example the profile record 500 consists of an identifier 510, profile statistics 520 and a profile distribution or histogram 530. The identifier 510 consists of a time period field 511 which identifies the timespan of transaction data over which the profile was generated and an entity field 520 identifying the business entity being profiled. The profile statistics 520 consists of but is not limited to a number field 521 giving the number of transaction samples associated with this profile, a maximum value field 522 giving the maximum value found in the transactions, a minimum value field 523 giving the minimum value found in the transactions, an average field 524 giving the average value of all transactions in the profile sample, a sum field 525 giving the sum of all transactions, and a standard deviation field 526 giving the standard deviation of the transactions in this profile sample. The profile statistics 520 may contain any required combination of statistical aggregations or numeric functions. The profile histogram 530 consists of numerous bins 531-537 each giving aggregates of values of transaction variables, or functions of transaction variables, in discrete ranges. Profiles can be generated for numeric data fields, such as payment size or value, and also for enumerated fields such as currency code or other payment flags. For numeric data types, a profile record 500 containing identity 510, statistics 520 and histogram 530 parts would be common. Profile records 500 for enumerated data types would generally only require identity 510 and histogram 530 parts. In some scenarios, the histogram 530 may be replaced with other forms of empirical or standard distribution representations.

Information relating to other characteristics may be contained in other profile forms. The address details of customers may be retained, which would include zip codes or co-ordinate forms. Transactions between accounts are profiled to identify the relationships between entities.

As would be recognized by anyone skilled in the art, once generated the profiles provide significant benefit as a management information tool for business understanding. Profiles automatically capture and quantify the usual activity of entities in a business and the relationship between the entities. Profiles provide understanding of the transaction environment and provide the basis for monitoring and reporting tasks. Since profiles provide a historical record of typical behaviors of entities, they can be used to identify changes in behaviors and unusual patterns of activity.

The investigation units 260 use the profile information for two purposes, to identify patterns of defined activity and to identify patterns of unusual activity. The profiles provide the basis on which statistical measures and probabilities can be used by the investigation units 260 to identify patterns of unusual activity. Unusual activity can be considered as activity that is statistically unlikely or has a low probability of occurrence. Consideration of multiple profile characteristics may be necessary in order to make decisions concerning the likelihood of events. For example, dormant bank accounts becoming active after long periods of inactivity may be too numerous to provide a sufficient indicator for suspicious account activity. If, however, the value transacted through the account is statistically very high compared with other peer accounts, then this provides additional evidence for investigation. Such evidence may be further compounded where the net balance associated with an account is low and the value passing through the account is transient.

Investigation units 260 may apply particular business rules against the profile data in order to identify behaviors that conform to pre-defined activity. Such comparison may be based on precise measures or relative measures based on profile characteristics. Comparisons may be based on known profiles of activity or a historical store of profiles known to be of interest to the business. Other more complex forms of analysis are possible including, but not limited to, statistical analysis, clustering methods, machine learning and intelligent systems based methods.

The operation of investigation units can be initiated by the arrival of transaction data and the completion of transaction profiling. Investigation units operate in an iterative fashion processing transaction profiles that have been updated and changed. In this way the system performs systematic analysis of all transaction entities. Investigation units may also perform speculative analysis when system processing is available to do so. This allows lengthy analysis to be performed without negatively impacting other system performance requirements. However, in this mode of operation coverage of all transaction data is not guaranteed. The output of investigation units is a normalized numeric value in the range of zero to 1 , where zero denotes that the analysis performed presents no data of interest to the business and a value of 1 indicates that the investigation unit has identified an absolute pattern of interest to the business. In this way, the investigation units produce results that define degrees of business interest associated with the profiles analysed. This may also be considered as the probability associated with the occurrence of the event or process under investigation. The outputs are then thresholded according to the following expression in order to formulate a decision as whether to raise a system alert:

y_k =

I 0 otherwise \ where p_k is the assigned probability of occurrence of an event detected by an investigation unit, t_k is a threshold value and y_k is the system alert decision variable. When the value of y is 1 , then a system alert is generated; otherwise no alert is raised by the investigation unit. The value of y_k is used to rank the alerts that are generated.

Where behaviors that are more complex are considered, the output of one or more investigation units may be aggregated according to the following expression:

N if ^ τv_iy_l ≥ T then raise system alert (Equation 1) ι=l

where y,- is the output of the rth investigation unit, w,- is a weight associated with the rth unit, N is the number of investigation units being considered and T is a threshold function for the combination of these investigation units. Where the weighted sum is greater than or equal to the threshold value, a system alert is raised. The resultant value of the weighted sum is retained in order to attribute a ranking to the alert. Both the values of the weights (w,) and the threshold values (T or t ) may be adjusted to improve the per ormance. The adjustment of these weights may be performed automatically through feedback from operator actions or through optimization or similar search techniques.

Figure 6 presents a typical alert record 600 as raised by the results of an investigation unit or units. The record comprises a date and time field 601 , a unique identifier 602, a rank field 603 equivalent to the probability associated with the event, an alert type field 604 defining the reason for the alert, an entity field 605 defining the entity involved in the alert, an alert priority 606, as well as numerous other fields 607, 608 that may be included based on the wishes of the business or be associated with results of the analysis produced by the investigation units. The alert priority 606 is used by operators to identify the relative importance of alerts. The priority of the alert is initially set automatically by the system. Figure 7 through Figure 9 show sample screens from a window-based interface which forms part of the output device 120 used by operators. The content of the display of these screens is dependent on the task performed by an operator. Figure 7 shows a sample alert view screen. The screen comprises a window 700, with a menu bar 730 and toolbar 740 to access system functionality and a status bar 750 for information purposes. The window is divided with a tree view pane 710 on the left and an alert list pane 720 on the right. The alert list pane 720 makes up one view of many possible combinations. The tree view pane 710 provides access to different combinations of alert view dependent on alert type and operator role. It also provides access to functionality controlling aspects relating to alert workflow and administration tasks. The alert list pane 720 provides a view of alert records 600 accessible by the current operator. Activating one of the alert record views 600 allows more detail relating to the alert to be viewed.

Figure 8 shows additional information that is reported following activation of an alert record, this process is termed "drilldown". The screen provides details of the entity involved in the alert 810, details about the alert and workflow aspects of the alert processing 820 and a number of different drilldown views 830 presenting different aspects associated with the alert. During the alert generation process, the investigation units consider numerous profile characteristics. The profiles used during this analysis are known and are conveyed to the operator in the form of supporting evidence with the alert. This evidence is presented in the multiple drilldown views 830 and may be used by operators to consider the alert findings and allow them to perform additional analysis. Such views may comprise text box 840 and tabular views 850 of the profile data. Figure 9 shows an alternate drilldown view containing textual 910, tabular 930 and graphical 920 views of the profile data.

The user interface provides functionality for the operator to change the status of an alert 860, in order to sign-off the alert to mark processing of it as complete, to escalate the importance associated with an alert, to re-direct the alert to another operator for further analysis or simply to close the alert with no action taken on it. Alerts can be re-directed from one operator to another operator for further investigation. The rules associated with this re-direction process are controlled by the system and may be parameterised by administrative users. The life-cycle of alerts is recorded at all times and details of operators that have processed each alert are maintained along with other information such as operator comments 870 concerning an alert in order to build case histories. Alerts that are not processed within a given timeframe may be automatically escalated by the system for attention by other groups of operators.

By systematically monitoring the actions of operators associated with alerts generated, the system can improve its performance. The system can increase the likelihood of generating alerts with characteristics recognized to be of interest to operators and reduce the occurrence of alerts with characteristics known to be of no interest. Further, the characteristic profiles of alerts generated by the system of specific known interest to system operators may be recorded and used for comparison against unseen data to identify entities with similar behaviors or characteristics. Operator actions relating to the processing of alerts, the redirection of alerts between operators and the escalation of alerts by operators may also be characterized by the system and used to improve system performance.

Figure 10 provides a flow diagram showing the transaction data input process. Transaction data is either loaded into the system or collected by the system for processing 1002. Reference data required for the loading and validation process is then loaded 1003. The transaction data is then validated 1004 in order to prevent erroneous data from being considered by the system. If the validation is successful 1005, the data is stored in the system for further processing 1007. If the data is not validated as being correct, a system alert is raised 1006 and the data is stored 1008 in accessible form to be manually validated or changed by system operators.

Figure 11 provides a flow diagram showing the transaction profiling. Transaction data 1102, reference data 1103 and existing profile data 1104 are all loaded by the data modeler 240. Profiles are updated 1105 for each associated change in the transaction data. The profile changes are then stored 1106 for further processing in the profile storage 230. Every time period associated with the transaction data is updated 1107. In this way for example, daily, weekly, monthly, and yearly profiles are all updated to reflect the changes in the underlying transaction data. This is performed for every different profile type associated with a business entity 1108. The profiles are generated for each business entity 1109. It will be understood that different business entities will have different profile forms according to their characteristics and the requirements of the system.

Figure 12 provides a flow diagram of the investigation and alerting process where multiple investigation units are being used. Transaction data 1202, reference data 1203, and profile data 1204 are all loaded according to the needs of the investigation units being operated. If there have been no changes in the profiles associated with the investigations being performed 1205, the profiles associated with other business entities can be considered for processing. If the profiles have changed, an investigation is performed 1206. If the output of the investigation unit is greater than a predetermined threshold 1207, a weighted sum according to the aforementioned formula (Equation 1) is performed 1208. If for this analysis more investigation units are required 1209, these further calculations are performed. Once this has been done then if the weighted sum of the output of the numerous investigation units is greater than a predetermined threshold 1210, a system alert is generated 1211. If the value is less than this threshold, no alert is generated. The process is then repeated for each business entity 1212 being considered for analysis within the system.

It will of course be understood that the present invention has been described above purely by way of example, and that modifications of detail can be made within the scope of the invention.

Claims

1. A system for data monitoring and analysis, comprising: a data monitor for receiving and processing data; and a data store for storing the processed data; wherein the data monitor (i) includes means for constructing aggregate profiles of the received data, (ii) uses the profiles as a basis for targeted investigative analysis to identify characteristic patterns of behavior and (iii) provides an output on the basis of the investigative analysis.

2. A system according to claim 1 , wherein the data monitor includes a data manager for controlling the processing of data.

3. A system according to claim 1 or claim 2, wherein the data monitor includes a data modeler for constructing profiles based on the received data.

4. A system according to any preceding claim, wherein the data monitor includes an event manager for controlling the sequence of data handling.

5. A system according to any preceding claim, wherein the data monitor includes an investigation unit for undertaking analysis tasks based on received data and stored data profiles.

6. A system according to any preceding claim, wherein the data monitor includes a reporting unit for generating reports resulting from the investigative analysis.

7. A system according to any preceding claim, wherein the data monitor includes an access manager for controlling authorizations and authentication procedures.

8. A system according to any preceding claim, wherein the data store includes a profile storage unit for storing profiles of received data.

9. A system according to any preceding claim, wherein the data store includes a reference storage unit for storing system specific data relevant to the data being processed.

10. A system according to any preceding claim, wherein the data is business transaction data.

11. A system according to any preceding claim, wherein the data originates from a plurality of different business entities and the system provides separate output profiles relating to the individual business entities.

12. A system according to any preceding claim, wherein the data monitor generates an alert signal in response to a particular outcome of an investigative analysis.

13. A system according to claim 12, wherein the outcome of an investigative analysis is ranked, and the alert signal is dependent upon the ranking.

14. A system according to claim 13, wherein the ranking is based on level of importance for a business.

15. A system according to any one of claims 12 to 14, wherein the alert signal includes supporting evidence.

16. A system according to any one of claims 12 to 15, wherein alert sensitivity is dynamically and automatically adjusted based on user response.

17. A system for data monitoring and analysis, substantially as hereinbefore described with reference to and as shown in the accompanying drawings.

18. A method of data monitoring and analysis, comprising: receiving and processing data; storing the processed data; constructing aggregate profiles of the received data; using the profiles as a basis for targeted investigative analysis to identify characteristic patterns of behavior; and providing an output on the basis of the investigative analysis.

19. A method according to claim 18, wherein the stored data is updated each time new data is received.

20. A method according to claim 18 or claim 19, wherein the construction of profiles and subsequent analysis are conducted dynamically, preferably in real time.

21. A method according to any one of claims 18 to 20, wherein the profiles relate to characteristic patterns of behavior across predetermined time periods.

22. A method according to any one of claims 18 to 21 , wherein the data is business transaction data.

23. A method according to any one of claims 18 to 22, wherein an alert signal is included in the output when the investigative analysis produces a particular outcome.

24. A method according to claim 23, wherein the alert sensitivity is dynamically and automatically adjusted based on user response.

25. A method according to claim 23 or claim 24, wherein the alerts are managed and routed automatically to appropriate recipients for action.

26. A method of data monitoring and analysis substantially as hereinbefore described with reference to and as shown in the accompanying drawings.