 Welcome to the demo of Defend, the IBM dispersed financial fraud enhanced detection solution. We're going to show you how the Defend mobile client works, along with a peek behind the scenes to simulate what happens at the backend when transactions are suspected of being fraudulent. This screen shows our server that simulates the backend of a credit card company. The server collects all of the user's transactions, alerts the user when new credit card transactions take place, and lets administrators at the bank upload and modify data as needed. On the right side of the screen, we see the Defend mobile app for Android. First, our user Charlie logs in by entering his username, password, and credit card number. After login, the Defend client displays the transaction screen. Charlie's transactions are divided into two tabs, purchases, and ATM cash withdrawals. He can choose either tab depending on what he's interested in. Tapping a transaction gives more details, and we can now see the location of the shop or ATM relative to Charlie's location at the time of the transaction. The GPS of his mobile device shows that he's now in New York City. On the map, his location is marked by the blue icon. The store or ATM is marked by the red icon. At the bottom of the transactions screen, you can see the Create Analytics Model button. This indicates that the application is still learning our user's behavior. The button will disappear after enough data has been collected to create a model of Charlie's typical behavior, or when the credit card company decides to create that model. Let's see how the app handles a new transaction like a withdrawal before it's finished formulating a model of Charlie's behavior. We're going to use our demo server to manually add a transaction. In this example, the cash machine and the location of the user and his mobile phone are identical. The cash withdrawal we added is shown as a new transaction on Charlie's mobile app, and a notification icon appears in the tray. If we expand the new row, we can see more details. You can now see that Charlie and the ATM are at the same address, and the icons for Charlie and the ATM overlap each other on the map. Let's look at another example where the transaction takes place far from where Charlie and his mobile device are. Again, we can see the new transaction on Charlie's screen and the notification icon in the tray, but when we expand the transaction, the details show us that the ATM location and Charlie's location are different. By tapping the ATM location, we can see the distance between the ATM and Charlie. The notification icon now indicates that this is a possible fraud, and Charlie has the option of deciding whether this is the case or not. If he decides it's a fraud, the transaction is reported to the bank and canceled. Now let's see how Defend handles a new transaction like a cash withdrawal after the app has finished creating its model. Keep in mind that the system will continue learning and improving even after the model is created. We're going to use a simulation server to add a bank withdrawal for a valid, non-fraudulent ATM. As before, we can see the new row added to the ATM transactions. Expanding the row displays the details of the transaction. Since Defend checked the transaction and found no suspicion of fraud, no further action is needed. Now let's use the server to add a fraudulent ATM transaction. The Defend system detects that a fraud took place, and a notification is presented to Charlie with the details of why it's probably fraudulent. In this example, the distance between Charlie and the ATM is about one and a half kilometers. Since we know he always has his phone on him, the score for the fraud is 100%. Charlie can now decide if it's a fraud or not, and the result is reported to the bank. Defend also uses call history to check when a fraud took place. Charlie often makes purchases by phone, and the system's model has learned what's normal when it comes to his behavior. Here we can see a recent call he made to a New York area restaurant. Let's go back to the Defend server and push a transaction where the phone number of the shop is not presented together with the credit card purchase. As we can see, a new row is added with the details. Defend checks the details of the transaction, and the system does not notify Charlie since the call history showed a recent call to the shop. Now we're going to use the Defend backend to add a fraudulent transaction. Charlie always uses his mobile phone when calling in a purchase, but here the store's phone number is not in his phone's call history. As a result, the system alerts Charlie with the details of why this might be a fraudulent transaction. He then reports it as a fraud, and Defend notifies the credit card company. Thank you for watching this demo. For more information, contact us at IBM Research.