Controls Force

Any ERP system is great at running each business processes separately (a single ERP can manage thousands of business processes). However, ERP is unable to handle a single transaction that consists of multiple business processes. If, for example, a user with a given access rights overrides system policies or rules for personal gain, your ERP won’t be aware of any wrong doing. The most of the staff frauds, supplier frauds and cyber crime cannot be caught by an ERP, as well as, system’s bugs and errors. ERP as any other system cannot be trustworthy because it is self controlled.

That’s why in addition to ERP, organizations employ a staff of controllers and internal auditors. These controllers are your “watchdogs” who already use different tools to automate their control processes and to manage risks.

Control’s Force Watchdog applied novel technology makes your control system substantially better by eliminating financial risks rather than managing them. Our A/P Watchdog™ makes sure that each invoice and payment to supplier is under strict control.

Any process based technology that runs and coordinates a business process is presented with a continuous, explicitly described workflow model. Today, a process that involves an execution of a different IT systems or/and organizations cannot be managed by one system. The workflow of this entire process is “broken”, into several separated workflows and a “gateway” between different workflows that usually cannot be explicitly described. An example of this would be, two buyer workflows, a PO preparation and A/P invoice processing that sets out the workflow of a supplier that eventually provides the mentioned A/P invoice to the buyer. The buyer is not aware of supplier’s workflow, has no access to it, and is, therefore, no system can be build within workflow concept to monitor a single business deal across the entire (multiple) process. Moreover, the workflow transaction involves only one input (i.e.one invoice) to process, while a business deal involves multiple inputs (invoices) arriving in different points of time for the same workflow. In other words, many invoice processing transactions should be correlated with the initial PO preparation transaction.

Our technology monitors 100% of your raw business data, like order, invoice, shipment data, delivery note and payment that different systems or business processes provide. Then, we correlate this data to a holistic transaction, like customer or supplier deal, and identify any data inconsistency within the context of individual transaction. Any detected exception can have one of the following root causes: data entry error, system error, broken procedure, business process, system policy or staff/supplier/merchant/customer fraud. No inconsistency is missed with our technology, and this is why we alert users without false positives. 

We take historical data that is dumped into excel files (POs, invoices and payments). For this purpose you would use the script downloaded from our website. If the script is not available, then you would also provide us with the data mapping table. Only after you get the results of historical run you can decide whether to purchase our services – Data Analyzer™ for continuos auditing or/and Watchdog™ for real time monitoring. Once the historical run is completed, you can subscribe to our Watchdog™ service and install compatible Control’s Force adaptor that will send XML messages to our Engine. You will then contact us and choose the adaptors according to your data source types. 

The data taken from the enterprise represent a very small subset of Accounts Payable records. Furthermore, at your request, any names can be omitted and not used. Any data that is hosted on the ARM web client is delivered via secure connection.

Our product can be recognized as Continuous Controls Monitoring for Transactions (CCM-T). Unlike Approva, we control a core business transaction that is long running and usually operates in heterogeneous ERP or financial application environments. Transaction Watchdog is different because it monitors business process that is based solely on transactional data. Also, it doesn’t rely on business application’s policies and controls. Our business transaction impacts upon multiplicity of business processes across distributed or local business applications. The technology identifies risks that can’t be detected at one point in time, in single business application or business process. That is why our product extends technological ability to reduce operational risks and prevent money leaks rather than responding to Sarbanes-Oxley Act (SOX) compliance rules. With our product you are looking at fraud, human data entry errors, systems errors and data loss in real time.

Our product works differently than database security products, because we do not monitor database transactions like inserting, deleting and updating the data. We do not monitor SQL transactions, as well. Unlike TW, database security products correlate the database transactions to person, time, etc. for auditing “who, what, when, where, and how”.

Our product works differently than SIEM (Security Information and Event Management) products, because we not deal with intrusion detection events (IDS/IPS). For example, the SIEM products correlate system login events to a pattern of incident identification alerts.

Our product monitors long running business transaction. The database and log transactions are short running IT transactions. The above mentioned short running transaction is measured in seconds or mili seconds. A long running (core business) transaction is measured in hours, days or even years. One long running transaction may consist of many short running transactions. It may also include workflow transactions, as well. A product that monitors short running, and workflow transactions cannot monitor an entire business process that the referenced transactions belong to. In contrast, our product puts process context into a short (IT) transaction’s event analysis. In other words, we correlate an event, provided with XML message to a core business process instance it belongs to.

No. We do not receive logs or database calls. We receive database records (selection of data fields) or application level messages provided with ESB.  We have an absolutely different goal: detect/prevent transactional risks.

Transactional risk is the type of operational risks that can be detected by tracking a single transaction that consists of different types of business processes and IT transactions across systems, people and documents. Transactional risk examples are : data input human errors, system incompatibility errors, duplicate data inputting, and insiders’ fraud schemes like ghost payments, cooking the books, etc.