How is Transaction Watchdog™ different from CCM-T products like Approva?

Our product may be recognized as Continuous Controls Monitoring for Transactions (CCM-T). However, instead of Approva we control a core business transaction that is a long running and usually operates in heterogeneous ERP or financial application environments. Transaction Watchdog is different because it monitors business process based solely on transactional data. Also, it doesn’t rely on business application’s policies and controls at all. Our business transaction impacts upon multiplicity of  business processes across distributed or local business applications. Our product 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 responds to Sarbanes-Oxley Act (SOX) compliance rules. With our product you are both looking in real time for fraud and for human data entry errors, systems errors and data loss.

How is Transaction Watchdog™ different from Database security products?

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”.

How is Transaction Watchdog™ different from SIEM products?

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.

How does Transaction Watchdog™ complements existing transaction monitoring products?

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. Note, 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.

Can Transaction Watchdog™ replace products like Gardium or ArcSight?

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.

What does the term “transactional risk” mean?

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.

Why not use a workflow?

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”, in other words, it consists of several separated workflows and a “gateway” between different workflows that usually cannot be explicitly described. For example, between two buyer workflows – 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.