This site uses different types of cookies, including analytics and functional cookies (its own and from other sites). To change your cookie settings or find out more, click here. If you continue browsing our website, you accept these cookies.
Australian Financial Crime Exchange (AFCX) is collaborative partnership between Australian banks, Government and Law Enforcement with a mission to prevent financial fraud and cybercrime. AFCX embarked in a three-month journey to redesign their architecture adding Alteryx Designer and Server to deliver strong and scalable solutions across the industry. Alteryx went into our system in March of 2018, I uploaded our workflows to Alteryx Server, and we have several different types of reports that we run every day in real-time. Alteryx now operates as the backbone of our system. It does everything every day that the system was meant to do and more!
Welcome to the world of fraud! Some of the things that are happening around the world and that affect us are data breaches and the loss of peoples’ identity. What that means for our detection engines is when your accounts start to be affected, it's not necessarily that we expect the first or second transaction to be stopped. Maybe not even the third or the fourth, but by the time there's a fifth and a sixth, we do really need to start closing your account and making actions with the consumer themselves. We're just not getting the information quickly enough, and we're not helping the consumer fast enough to stop that fifth and sixth transaction.
This is how our data exchange was happening. We trade 11 unique data sets. It is structured data and banks provide them in a form of a flat file or a CSB. Originally our banking partners told us that they would manually hit a button to upload that CSB to us. We decided to use Atlassian, JIRA and Confluence in our pilot. We have completely customized the inside of Atlassian and JIRA so that it stores every single fraud event to custom specifications.
This chart below shows the utilization of each service we had at the time, and then how much we were using it. We can say JIRA is critically overloaded and also highly important in that original architecture.
There were some unintended consequences from this design for the platform:
Describe your working solution
Back in 2014, the four major banks in Australia, who represent 85% of financial transactions in the country, came together and realize that data sharing was the only way forward to solve this problem effectively. Each bank has great detection engines in their in-house. They stop 80% of the fraud that is attempted in Australia at the dawn. But, for the 20% that remains and is growing in value, they've worked out that they need each other. More data is always better because you can only know what you know inside your own house.
MAZE OF REQUIREMENTS
Complement the Existing tools
|
Strengthen Security
|
Run it 24 x 7
|
Supply & Scale Quickly
|
Use the Atlassian System and UX, Manage the data and fix the issues without being seen.
|
Align with ISO27001, maintain & strengthen security stature against PCI-DSS in the existing cloud.
|
Validate data safely and in close to real time in the most customizable, agile way all of the time.
|
Choose and implement quickly, be able to test, enhance and scale after launch as needed.
|
We needed something that was going to work and could be stood up quite quickly. We checked some reviews by Gartner, and we came up with the three-product metrics. They were the three products that we thought were going to do best. As a result of that exercise, we decided on Alteryx. We then embarked on a three-month journey to implement this architecture (below).
INFRASTRUCTURE AT WORK: AMPLIFY.AFCX
What we have now is still a two-tier environment. Every query that we have has to run down to the database layer every time a user makes a query, that's one piece of software on the top layer, making a query down to the database and returning the results.
We also needed something with a separate table DB. Hello Mongo. Alteryx Server is actually in our top user layer. It's one of the few analytic products that is able to do this. We can set the persistence when it runs the workflow to zero. We still store our data on the user layer that JIRA box, we also write it down to historical DB table. Basically, I store the data in three forms. Exactly what a bank provides to us, then we also store any removed data.
Alteryx scheduler on the Gallery is designed to produce every export for every major bank. We're a give and get service, so if you give me your data, I will give you everyone else's data in return, on a schedule of your choosing and to a customized spec. All of those custom specs for each bank sit in the Gallery and run automatically.
There was also a firewall that sits between Alteryx Server and the user interface. The only way to get into Alteryx Server is actually via an RDB connection and personal private VPN. We also needed to build APIs two ways. We use the Alteryx APIs to connect and talk to JIRA all the time, and we had to prove resilience in that mode.
We start off with rested API to read in the data and this can be done via automation or it can be done via the user interface. If anyone still wants to upload a file to JIRA in the same way they used to, we now have a really clean service desk to allow them to do that. Otherwise, they can drop files down their automated SFTP pipe.
Then we do a range of data management and validation on the data. This also produces a report, a PDF report. We then do validation against selected fields, so if I have certain values in my fields, let’s say I only want to see whether it’s a fraud or a scam, those are the only two values my software will accept. Alteryx also make sure that they are the only two values and does fuzzy matching against those values in case there are minor blips and flips in the data.
We currently convert 12 different date time stamps which are provided by our banks in this workflow, to something standard. We also give the data back to Ravia API in the format.
To send data to JIRA we completely map the inside of the JIRA database, and Alteryx literally tells JIRA where to put each and every value that we give it. Not only are we giving it correct data, which makes it super-fast for JIRA to run, it's not really asking itself any questions anymore. We're also telling it exactly where to put it.
I upload the workflow to Alteryx Server and we have several different types of reports that we run every day in real-time. Alteryx now operates as the backbone of our system. It does everything every day that the system was meant to do and more.
With this workflow we're now looking at instead of seven hours for 7000 records, we're now looking at about seven seconds, and that includes the push to JIRA. That API push to JIRA that is the most extensive part of our workflow. Instead of spending my time worrying about whether I have the correct dates in my JIRA instance, I now spend my time actually doing real-time analytics, and detecting fraud patterns, because I know anything that's uploaded to Alteryx is going to be processed successfully, and any schedule that I create is going to run all the time, every day.
Main return on investment:
The entire PowerPoint presentation can be found here.