Fraud prevention and anomaly detection now feed Kademi's reporting. You can put fraud events, refused operations and anomaly alarms on a reporting dashboard, or on a page of your client's website, the same way you add any other report. Two ready-made dashboards get you started, and every piece can be mixed into dashboards you build yourself.

What you can report on

Two Kademi features watch a programme for trouble, and both now have reports:

• Fraud prevention scores every purchase, voucher redemption and signup against a set of fraud rules. Operations that score high enough are recorded as fraud events, and, when blocking is switched on, the highest-scoring ones are refused. Each event records the score, the operation, the profile, the IP address and location, and why it scored: which rules fired, the points each added, and what each one saw. See Kademi Fraud Prevention for how it works.
• Anomaly detection watches metrics such as orders, points, signups and website errors, and reports when one moves well away from what is normal for it. Each anomaly detector has a state (building a baseline, normal, pending or in alarm) and a history of the periods it found abnormal. See Anomaly Detectors for how they work.

Until now you could only see these on their own admin pages. Now they are available as reporting building blocks:

Everything follows the date range you pick, except Anomaly detectors in alarm and the Anomaly detectors table, which always show the situation now.

The ready-made dashboards

Go to Reporting, Reporting dashboards. Two new system dashboards are in the list.

Fraud prevention

Reading a fraud event:

• Score is out of 100. Each fraud rule that fires adds its points.
• Band is Watch (recorded and allowed) or Block (scored at or above the block threshold).
• Refused says whether the operation was actually turned away. A Block event that was not refused means blocking is switched off for the account, so it was recorded and allowed through. That is the normal state for a new account, while it gathers evidence.
• Why lists each rule that fired, for example order-velocity-ip +35 (6 orders from 203.0.113.45 in the last 1h): the rule, the points it added, and what it saw.
• A signup has no profile yet, so its Profile cell is empty.

Anomalies

A detector's State is one of:

• Building a baseline: it has not yet seen enough history to know what normal looks like.
• Normal: the latest period was within the usual range.
• Abnormal, not yet an incident: a period was abnormal, but not yet for long enough to raise an alarm.
• In alarm: abnormal for long enough to count as an incident. In alarm since says when it started.
• Paused or Not running: switched off, or unable to run, for example because the index query it watches has been deleted.

The detectors themselves, including their sensitivity and notifications, are managed under Reporting, Anomaly detectors.

Building your own dashboard

The system dashboards cannot be changed, because app updates replace them. To build one for your client, start a dashboard of your own: open any dashboard, click the cog at the top right, and choose Save as new dashboard. Then use Add widget from the same cog menu.

Widgets can sit beside any other report, so a single dashboard can tell the whole story of a programme. Here fraud and anomaly widgets share one dashboard:

Use each widget's own menu to resize it, move it or change its title. Use Change access to limit who can see the dashboard. Whatever access you give, each widget still checks its viewer: see Who sees what.

Putting it on your client's website

There are two ways to show this on a website page.

• Publish a whole dashboard with the Reporting Dashboard component, and choose Fraud prevention, Anomalies or a dashboard you built. This is the quickest way, and the dashboard stays in step as you change it in the admin.
• Place components one by one for full control of the layout, as below.

The Anomaly detector component

In the content editor, add a component and search for anomaly.

Fraud and anomaly tables

Use the existing Query Table component. Choose Query table as the query type, then pick a table by its id:

• fraudEvents: all fraud events
• fraudRefusedEvents: refused operations only
• anomalyDetectorStatus: every detector and its state
• anomalyIncidents: every abnormal period

Metric cards

Use the Metric component and choose one of the fraud or anomaly metrics listed in What you can report on. Cards and tables follow the date range the visitor chooses on the page.

Who sees what

Fraud events contain names and IP addresses, and anomaly figures describe the whole account's trading. So these reports have their own rules, on top of any access you set on a dashboard or page.

• Fraud reporting is shown to people who hold Fraud Viewer, Fraud Manager or Reports Manager on the account itself, and to Administrators. The same role granted on a child organisation, or only for a website, does not count, because fraud events are not split by organisation.
• Anomaly reporting is shown to people with full reporting access to the account (Reporting Access on the account itself, or Administrator) and a reporting role such as Reports Viewer. Each detector is also only shown to people who can open the index query it watches. For example, the website traffic detectors read the log query, which is limited to Website Administrators.
• Regional and partner managers whose reporting access is limited to their own organisations do not see fraud or anomaly data. These reports describe the whole account, not one organisation.

When someone without access opens a page or dashboard, nothing is revealed:

• On a dashboard, widgets they may not see are left out, and the Add widget list does not offer them.
• On a website page, components placed directly show that the data is not available to them:

In the content editor, a detector that was deleted, or that you are not allowed to see, shows a short grey note instead, so you can tell why it is blank.

So you can place these reports on a page that other people also use, and grant the roles only to the people who should see them.

Things to know

• IP addresses are shown in the fraud tables, including on websites and in CSV exports. For a fraud event the address is often the most useful thing to know. The same address across unrelated profiles is a strong sign of trouble, so take care over who you give the fraud roles to.
• Fraud events are only recorded above the recording threshold (30 by default). Operations that score below it are not kept, so they never appear in these reports. The thresholds are set under Website Manager, Fraud Prevention.
• A new detector needs history. Until it has a baseline, its readings show no % of normal.
• Don't turn on caching for these metrics. A cached metric is stored once and shown to everyone, so it would skip the access checks above.
• To use any of this, the site needs current versions of the KReporting app and admin-lib. Update both together from the website's Apps tab.