Projects:Loss Prevention/Functional Specification

Contents 1 Functional Specifications 1.1 Overview 1.2 Fraud Detection & Prevention 1.2.1 References 1.3 Un-intential Neglection 1.4 Design Considerations 1.4.1 Detection and Communication Framework 1.4.2 Master table definitions 1.4.3 History of Situations 1.4.4 Configurations 1.5 Use-Cases from the field 1.5.1 JORGE MONTFORT 1.5.2 ASIER ZABALETA 1.5.3 ELENA MARTINEZ 1.5.4 XAVIER PLACES 1.5.5 JUAN PABLO CALVENTE

Functional Specifications

Loss Prevention is the placeholder for two distinct types of loss: One caused by intentional fraud, another caused by un-intential neglection. The functionality that this document envisions, is a functionality that detects examples of (potential) loss with extensive capabilities to report the occurrences, either in real time or deferred.

Even though the mayor part of loss prevention focusses on the physical product as described below in Inventory Shrinkage, loss prevention in Openbravo also encompasses the detection of manipulative activities in order to obtain a fraudulent benefit. An example of this is the delayed purchase of an extended warranty, closely followed by a warranty claim for that product.

Overview

Inventory Shrinkage is the loss of products between initial receipt -either from production or from purchase- and sales. According to a study from 2015, approximately a third of inventory shrinkage is traced back to internal theft (intentional fraud) while anothe sixth is caused by administrative errors (un-intentional neglection).

Fraud is part of the reality in which we life, like it or not. As supplier of software and consultancy focussed on retail, it is our obligation to be aware, knowledgeble and assist our clients when and where possible with our know-how with the objective to fight and eliminate fraud from his business.

Fraud, in terms of IT systems, can be separated into two main activities: The detection of it and the prevention of it.

Fraud Detection & Prevention

Fraud (-detection) is an a-typical development in the sense that -from the development perspective, there is a seemingly endless list of potentialy fraudulent situations; The key-word here is 'situations' because it shows the difficulty to be more specific: A 'situation' can be anything and our best source for these situations come from the experienced people in the field. See below a list of Use-Cases from our own experience.

For detection of fraudulent activities in Openbravo, we first should define what activities or situations should be part of our scope. Also, we should be aware that there some activities -in itself- are not suspicious but in a specific context -behavior compared with fellow-workers and/or in a specific time-frame- they are. So, theoretically there is an unlimited list of situations that should be monitored or analyzed. And here lies the complexity of fraud detection: Newly concieved methods or ideas for fraud will go unpunished until it is detected, understood and transformed into a new indicator.

It is the purpose to list the known situations and present the occurence in an orderly and actionable manner.

errors, anomalies, inefficiencies, and biases which refer to people gravitating to certain dollar amounts to get past internal control thresholds. The analytic tests usually start with high-level data overview tests to spot highly significant irregularities.

• Example of potential fraud: Several months after the initial purchase, a customer purchases the extended warranty for the product. Not much later, the same customer returns the product claiming a faulty product. This situation should be reported in real-time to the shop-supervisor.

Fraud Prevention Under this paragrapgh we list the situations that not necesarily are fraud but are situations where fraud could be easy to commit. These deserve a further investigation.

References

Study other systems and learn.

• Authorizations -> transactions that require supervisor/password OK.
  • Returns above specific value??
  • Cash-back??
  • Returns to different shop??

• Compared behavior
  • Reported situation "Cash-up comparison": List the cash-ups for all cashiers for a certain time-span, defaulted last 4 weeks. Highlight negative (red) and positive (green) differences and intensify the color depending on the amount of the difference.
    • Alert on individual differences above the threshold (to be defined).
    • Alert on total differences outliers.
    • Alert on operators that exclusively show negative differences.

• Special situations
  • Reported situation "Returns after closing time". List the return transactions after the shop should have closed.

• • Reported situation: "On-duty Alone": List the transactions when the operator was on-duty alone.

Un-intential Neglection

• Example of unintential neglection: Show as daily report, all inventory whose expiry date will disallow sales, if the sales volumes continue in the same pace (as last n weeks). This information should be communicated to the shop manager and or supervisor and result in either a re-distribution of excess inventory or a sales promotion.

Design Considerations

Detection and Communication Framework

Fraud (-detection) is an a-typical development in the sense that -from the development perspective, there is a seemingly endless list of potentialy fraudulent situations; The key-word here is 'situations' because it shows the difficulty to be more specific: A 'situation' can be anything and our best source for these situations come from the experienced people in the field.

Nevertheless, we do recognize with this a few essential things that allows us to structure:

• Firstly, that there are 'situations', we just are not capable to foresee all possible situations right now. And that a situation-detector is like a 'spider' that detects -in real-time- these situations and stores them.
• With this we recognize that we need to store the occurences of the detected situations.
• And we can also assume that some situations require an immediate action where others require a statistical approach. We see here a 'situation communicator'.
• Finally, we recognize that the user, our customer, is the one to decide how a situation is handled. So the communication methods is to be configurable per 'situation'.

With this we at least can establish a basic foundation of the Fraud detection and prevention module:

• Situation detector (or 'spider'(?)): A set of rules or query that detects transactions with a potential fraudulent character and stores it in the...
• Situation: The occurence of a potential fraudulent situation, stored in a database/table.
• Comunication: The way that the customer wants to communicate the situation.

In general, the goal of the specs would be to have a master-table where all fraud possible situations are registered. This table would enable us to prepare any report of create alerts for the information in it.

Master table definitions

A proposed definition of a Spider:

ID	Type	Description	Parm-1	Parm-2	Program name	Active	LastRun
1001	Discounts	Applying non-standard discounts			aabbccdd	Yes	2015-05-12 11:43
1002	Cashup	Negative differences	PaymentMethod=Cash	Tolerance=10	bbccddee	Yes	2015-05-12 11:43	Note that an integration with schedular is assumed.
1003	Delete=Cancel	Delete orders or lines really cancels them			NA	Yes	2015-05-13 12:18
1004	Inventory Expires	Notify to create promotions			xxyyzzww	Yes	2015-05-12 11:43

Since every spider can have several communications, this is stored seperately:

Spider-ID	Sequence	Moment	Method	Role of startpoint	Role of endpoint	Text	Active
1001	10	Immediate	SMS	Cashiers	Supervisors	&SPIDER-NAME& for &AMOUNT& at &POS-ID& &END-USER&	Yes	Expressed here is that depending on WHO commits the situation, the SMS (in this case) is sent to a different role.
1001	20	Immediate	SMS	Supervisors	Store managers	&SPIDER-NAME& for &AMOUNT& at &POS-ID& &END-USER&	Yes
1002	10	Immediate	SMS	Cashiers	Supervisors	Authorization request for &SPIDER-NAME& at &POS-ID& &END-USER&	Yes
1002	20	Immediate	SMS	Supervisors	Store Managers	Authorization request for &SPIDER-NAME& at &POS-ID& &END-USER&	Yes
1004	10	EOD	Report		Store managers	Inventory close to expiry date - Proposed Promotions for &PRODUCT &LOT &BIN &EXPIRY-DATE &QTY &UOM	Yes

A proposed definition of a Situation

Situation-ID	Spider-ID	Date/Time	Organization	POS-ID	End-User	Order/Line	Amount	Currency
9345531	1001	2015-05-12 11:43:48	White Valley East	POS123	Maarten Tromp	22334455/1	-14,45	EUR
9345532	1003	2015-05-13 12:18:32	White Valley East	POS123	Maarten Tromp	10002/1	-29,95	EUR
9345533	1002	2015-05-13 12:40:11	White Valley East	POS123	Maarten Tromp		-15,01	EUR

And the resulting communications

Situation-ID	Method	Date/Time	Receiver	Text
9345531	SMS	2015-05-12 11:43:50	+34 661 621 xxx (Ismael Ciordia)	Non-standard discounts for -14,45 at POS123 Maarten Tromp
9345533	SMS	2015-05-13 12:40:13	+34 661 621 xxx (Ismael Ciordia)	Autorization request for Negative differences at POS123 Maarten Tromp

The tools we now see would be:

• Reports crossing the information in this fraud table versus stock dissorders.
• Alerts that can notice in real time a possible fraud situation. The company if its willing, can put people that monitor alerts in real time and take action if needed.

History of Situations

Situation-messages should be stored to build up history for statistical review.

Configurations

Preferences are used on Openbravo to set predefined values for specific situations and functions. These values can be used to default input in certain screens but can also be used as thresholds to define ceertain upper or lower limits.

The current set of preferences does not have a functional grouping theme, all are together in the same bowl. This absense of functional grouping provokes difficulties in configuring as it requires experience and knowledge in order to avoid incomplete -and therefore incorrect- configurations.

However, functional grouping is less trivial as it seems. A certain threshold can be grouped in multiple functional groups, depending the perspective of the viewer, for instance: A maximum Over-Receipt Tolerance (% or €...) for the purchase-order receipt will be seen as a Financial or Accounts Payable setting by the controller, while the warehouse manager might search for this in the group of Warehouse settings.

Use-Cases from the field

JORGE MONTFORT

Please add here examples

ASIER ZABALETA

• Fraud situaiton 1: Seller creates a ticket in draft mode, adds a line and sees that the customer is going to pay by cash. Then, asks the customer if he wants the ticket. If the customer says no, the seller takes the cash, and then deletes the ticket. Money is in the seller pocket, stock is gone and there is no sale in the backoffice.

• Fraud situaiton 2: Seller creates a ticket in draft mode, adds some lines. Then adds a line taking out the security alarm mechanism of a product (tablet, for example). Once the security mechanism is taken out, he deletes the line and keeps the product for him.

ELENA MARTINEZ

• Like Asier First situation: but with reprint option, i.e cashier prints ticket, gets the cash. Tenders the receipt to the customer. When customer is gone, he deletes the ticket. --> Solved with Approval on Delete button and Print this receipt option.
• Same as before but leaving the tickets without closing them and delete them in the cash up --> also solved with Approval in Delete option of the Cash up process
• Do a verified return many times to tender money back --> now not possible anymore with the new functionality of verified returns (from Q2)
• Use training mode as normal mode, to tender fake tickets to customer and keep the money. There is a different template for training receipts, but it can be still used for fraud
• Blind cash up or start count -> to avoid temptations when counting more money than the system says, so the cashier does not know the money the system thinks it is. At the moment we have approval when there are differences
• Situation: company sells valuable goods. Do a goods movement from the store to another store, there is no approval for that. Sometimes our customers ask us for a maximum number of "jumps" a goods can have, that means to allow 2 movements, and if users try to do more, not allow it.
• Visibility in the store: control who has access to stock visibility
• Have a maximum amount of discount a user can apply --> also controlled now
• Situation: a cashier needs to go to the toilet and blocks his session. While he is away another user logs in and does something fraudulent (first example) --> there is no way to block session, anyone can log in at any time
• Daily Unexpected and random inventory counting --> ask to randomly count valuable products daily to control the stock accurately
• Offline: wait till the store is offline to steal goods as there is no inmediate detection (for inventory counting) or stock visibility between terminals. For example: they could sell the same item with same IMEI as there is no way to control that unless there is a store proxy.
• In general, offline mode creates a bit of scepticism among our customers for fraud operations, as it seems the store is less controlled (before Approvals were not supported in offline mode)
• Control cash drawer opening with approvals when it is not due a ticket payment
• Allow only certain users to do cash withdrawals or deposits
• Don't allow to change prices in POS -> there is an approval for it
• Returns without previous ticket, not allow them if they are higher than a certain amount

XAVIER PLACES

Please add here your examples

JUAN PABLO CALVENTE

• Exchange or refund. Put exact amount when it's not: In this situation the seller would keep little cash differences that the customer does not want.
• Discount management. Try to apply discounts or special offers when it is not applicable. Here we have put in place the approvals
• Print a quotation as a ticket. The customer thinks he has the ticket, but the money will be in the seller hands

Category: Projects ERP Retail