As an online vendor, HPShopping.com is responsible for losses due to fraud. The goals of the fraud management project were:

• To reduce incidents of credit card fraud on HP’s consumer e-commerce storefront HPShopping.com, and
• To increase productivity and efficiency in fraud analysis and order review.

To achieve these goals the fraud management project team set about designing and implementing a robust fraud management suite of tools, including algorithms, web services, an order review portal and dashboard, and analytic reports.

The challenge was to protect HP from fraudulent attempts, while maintaining a quick online transaction processing time and ensuring good customers were not accidentally turned away due to inaccurate fraud analysis. The previous fraud screening technology was outdated and HPshopping.com needed an upgraded fraud management solution that would scale with the business. HP also wanted to ensure that the technology was predictive and would be able to keep up with the ever-growing sophistication of fraudulent credit card attempts.

The business needed to mitigate the risk that modifying the process and technology involved in fraud management might result in longer customer response times. In addition, any site downtime would mean a loss of revenue to the business. HP needed to upgrade the technology and process seamlessly to prevent any customer dissatisfaction or shopping cart abandonment.

The users of the fraud management system are HPshopping.com’s loss prevention team made up of both operations and fraud analysts. The operations team is responsible for managing the fraud review strategy. The fraud management system allows the operations team users to develop more complex strategies and exercise greater control. The fraud analyst team is responsible for reviewing potentially fraudulent orders and determining whether to approve or decline them. The fraud management system helps the fraud analysts review and approve orders quickly and more efficiently. By combining the order details, risk profile, order history, and a summary of results from various third party data sources into one web portal, the analysts no longer have to manage data from multiplesources or cut and paste results from online searches.

Within the first couple of weeks of launching the new fraud management system, HPshopping.com’s loss prevention team immediately noticed productivity improvements in order review cycle times. In fact, with the new fraud management tools fraud analysts are able to review about twice as many orders per hour than they were able to do with the old system. Additionally, an unexpected benefithas been an increase in storefront revenue due to more orders being approved.

The fraud management project met the projected goals of saving time and money. It reached the break- even point within six months. The benefits were measured by tracking order volume, revenue, operating expenses and chargeback’s (losses due to customers refusal to pay) during the first six months and comparing that to the same six-month period the year before.

The system is mission critical to HPshopping.com’s loss prevention organization.

The fraud management system allows HPshopping.com’s loss prevention team to manage strategies to reduce the risk of online fraud, and to efficiently review orders that the system flags as potential fraud.

The fraud management system includes a comprehensive suite of services including:

1) Cybersource’s Risk Management Service (RMS) which is a tool that allows users to create and maintain a complex fraud screening algorithm, 2) Fraud Queue Manager (FQM), which is an HP developed web based portal and dashboard that presents the order information and history for analyst review and approval and 3) Analytic reports, which help the operations team manage the business. Each order placed online and through the call center passes through a complex fraud-screening algorithm, RMS, involving real-time web service call outs to validate customer information from five third-party data sources, prior to order acceptance. Orders that cannot be systematically approved or declined in the RMS algorithm are sent to the FQM portal. Trained fraud analysts access this portal to approve or decline orders.

The RMS functions as a way to create and maintain business logic that determines whether or not an order placed online could be fraudulent.

The FQM portal allows fraud analysts to review order detail, feedback from third party data sources that match billing and shipping addresses, view order history, approve or decline orders, mark fraudulent orders and manage hot lists of good and bad customers.

The HP global operations team collaborated with HPshopping.com’s operations team to sponsor the project. These teams were responsible for the business goals and it made the most sense to have these groups also act as sponsoring bodies.

The users of the system, HPshopping.com’s loss prevention team, were involved in the planning, design, and testing phases of the new fraud management system. Originally, a team observed the fraud analysts using the old tools and processes to understand where improvements could be made. During the design and testing phases for the FQM portal, HP also reviewed the proposed changes with the fraud analysts for feedback and any additional suggestions for improvements.

The project presented several challenges, including ensuring successful coordination of over five external vendors, precise implementation of new and proprietary technology, training staff on a new hardware infrastructure and new business processes, and ensuring a high availability Internet application. The challenges were overcome with diligent project management and daily communication sessions.

No, the goals were met throughout the project as expected.

Not applicable

There was minimal use of development testing with Junit, a java based, script oriented testing tool. However, the use was informal and applied inconsistently throughout the development lifecycle.

There were also a series of test scripts that were created and run that utilized the QuickTest Pro and TestDirector 8.0 platforms from Mercury Interactive. These tests were also carried on an informal basis, but were run during each of the phases of infrastructure migration to baseline the application in each environment.

A formal software development lifecycle methodology was employed. The lifecycle passes through six phases:

• Opportunity Development: Present project charter and get management approval.
• Scoping and Analysis: Gather business requirements and present plan of record. Create a functional specification.
• Design and Construction: Create and review design. Complete code construction and unit testing.
• System Testing: System and User acceptance testing. Includes regression testing, performance testing, and exception testing.
• Implementation: Includes training and communication.
• Support: Support team manages production issues. Warranty release with high priority fixes. Success metrics reported.

Tools used during the project included Microsoft Project to manage the project resources, tasks and timeline, TestDirector (an automated testing tool), BugZilla (a web based test tracking and issue management application) Microsoft Excel (to manage and track issues and actions) and Microsoft SharePoint (to share documents).

Automating the fraud screening process required the technical team to integrate applications running on Broadvision, .NET and J2EE platforms as well as integrating data from several third-party vendors. To do this in real time while maintaining a level of performance we had to ensure that this did not negatively impact the customer shopping experience.

Out of the box, Cybersource’s RMS requires a custom XML message as an input. Integrating the fraud management system with the storefront required choosing an industry standard mechanism that could be used as an adaptor in front of the RMS rules engine. To connect storefronts in a standard way, the team added a SOAP Web service adapter between the two and an existing financial Web service gateway running on .NET was chosen as the adapter. The storefront sends a SOAP message to the financial gateway application, which processes and transforms the SOAP request into the XML request for RMS. By utilizing the SOAP standard over SSL HP was easily able to link systems running on Broadvision, .NET, and J2EE in a secure and high performing manner.

Calls to third-party vendor data are critical to successful fraud screening. It allows independent verification of customer order data by comparing order data to the vendor’s database in real time. However, each call returns a high volume of data that can severely impact order-processing performance. To increase the performance of third-party data calls and overall system throughput, the calls are processed using asynchronous JMS message queues. JMS messages are sent to a message driven Enterprise Java Beans (EJB), as third-party calls are made. The main order processing can continue while third-party calls are processed in parallel by the message driven EJBs.

1. Database: MS SQL Server 2000
2. Operating System: Windows 2003
3. Application Server: BEA Weblogic 8.1
4. Rules Engine: Cybersource Risk Management Server
5. Development tools: Eclipse IDE, Weblogic Workshop 8.1, Struts, Hibernate
6. Source Control: CVS, Microsoft Visual SourceSafe
7. Bug Tracking: Bugzilla

Cybersource’s RMS was chosen as the decision engine to detect fraudulent orders. RMS was chosen due to its configurability and extensibility. RMS’ configurability allows business users to react quickly to new fraud scenarios and deploy new rules without changing any application code. The extensibility features of RMS allow custom developed plug-ins to be integrated into the fraud detection rule set. This feature was used to transform existing offline processes into real-time processing of orders.

Development tools were chosen for their ability to enable rapid application development. Hibernate was used as the object-relational mapping tool. It automatically generates an application database layer based on an existing database schema. Hibernate is a widely used open source project so it was easy to hire new team members with Hibernate knowledge to help augment the team. Struts was used as the web framework. It was chosen because it is a standard within HP and the Java development community in general. BEA Weblogic Workshop was used to rapidly develop Web services and J2EE components. The development team did not have experience with J2EE however, Workshop’s simplified interface into J2EE allowed HP to develop EJBs and Web services with no learning curve. BEA Weblogic Server was chosen as the application server because of its performance, support, and documentation.

When new orders come into HPshopping.com, a fraud check is done before orders receive final approval. The storefront Broadvision platform sends a SOAP request over SSL to the .NET financial processing platform. The SOAP request is logged, converted to a custom XML message and sent to RMS. The fraud screening strategy executes on the order data. As the strategy executes, calls are made to newly developed EJB plug-ins, which query third-party vendor data sources or compare the incoming order to the storefront’s complete order history. The third data sources are queried by a combination of SOAP Web services, custom XML message passing and Java client-server calls. After being approved, declined or marked for manual review, the order and third-party results are saved to the database asynchronously using JMS message queues. As data is received, a JMS message is published to a message driven EJB with the logic to process and persist the data. The main order processing can continue as soon as the JMS message is generated without waiting for the persistence to complete.

New orders are detected by newly developed web GUI tools that allow users to manage any potentially fraudulent orders detected. As users view each order, it can quickly be checked against more detailed third-party data or compared against the full order history. Running the order history checks in the fraud database is very fast compared to running the checks against the storefront database because the fraud database was tweaked for these specific order history queries.

The order history database is kept in synch with the storefront database by SOAP Web services. The storefront calls the fraud system to request updates to orders made in or publish updates to the fraud system. Once an update has been received, an acknowledgement is sent to confirm the update. This confirmation ensures data integrity between the two systems and has resulted in no loss of data in several hundred thousand transactions.

Interoperability, rapid development and widespread industry acceptance were the most important characteristics of the tools and technologies used by the development team. The interoperability of the SOAP protocol enabled the team to deliver a fraud management system that can be integrated into a wide variety of storefront platforms in a short amount of time. This was critical in the HP application environment, which contains a wide variety of platforms.

The development team benefited greatly from the rapid development features of the tools used in this project.

The fact that the development tools used, such as Hibernate and Struts, are de facto industry standards made it easy to add knowledgeable resources to the team during the critical project development time.

Each developer had several years of experience developing server side Java applications. Projects the team had previously worked on include e-commerce storefronts and credit card processing platforms.

While the team had extensive Java development experience they did not have any J2EE development experience. By using rapid application development tools such as Weblogic Workshop and Hibernate, the team was able to utilize new technologies with a minimal learning curve.

A formal project schedule was created at the start of the project. The project did not stay on target to the original schedule. After the development was complete, a new integrated testing schedule was published that included four rounds of testing. This new schedule was executed against with only minor modifications. The project was completed in one calendar year.

Yes

The development team was very pleased with the implementation of this project, but if it could be done over again, they would have used more extensive test-driven development early in the project. The initial rounds of testing revealed bugs that had been fixed early in development, but regressed as further work was completed. A "test first" development policy would have taken a larger initial investment from the team to develop, but would have paid dividends during the final phases of development as the small team was spread thin.