WSO2Con Insights: Experian Uses WSO2 to Uncover Credit Intelligence

Some call Experian a credit score checking service, but that would perhaps be an injustice: this company, which now counts some 17,000 people among its employees, is the credit information company. So deeply ingrained are they that in certain countries, it’s common to be told “Go talk to Experian” when you have a problem with your credit. Nor does it stop there. Experian’s products have long since expanded beyond credit and into everything from financial education to digital user analytics: it’s now a business with revenues in the billions of dollars.

Experian has a very interesting set of needs. Day in and day out, customers arrive at Experian looking not only for credit reports, but for financial advice. Experian, analyzing their spending patterns and the ripple effects of those, is in a position to tell customers what to buy, what cards to keep, how to handle their bank accounts and loans, and a myriad of other details. In his talk at WSO2Con EU 2015 Rafael Garcia-Navarro, Head of Analytics at Experian explained how shifting from huge volume/low speed batch data processing to small volume/high speed data execution, helped them get their big data into shape.

The problem of real-time

Given the nature of what they do, Experian needs a lot of intelligence and data analysis power. In the world of credit intelligence, everything is linked – from where a user votes to the loans they’ve taken to the smartphone plan that he or she is on. In the past, they would process vast amounts of data offline and use that to make analyses.

To this, Experian added a requirement: real-time operation – defined by them as systems that could take data from marketing channels, process and react with the required information under the average human reaction time of 200 milliseconds.

More specifically, they needed systems that detect patterns at very high speeds, passing data in such a way that as to enable the full machinery to deliver complete results in under 200 milliseconds.

This is where the WSO2 Complex Event Processor comes into the picture. Experian were working with some serious names in data analytics – like Google – and they began using the WSO2 CEP to analyze the customer data in real-time.

The first step, is taking log files from digital platforms at the user level – cookies, if you will – to develop batch prediction models which help them decide what to promote to different users. The next step was to move out of purely historical data. Experian developed a Java application that simulates Google data; this data streams into WSO2 CEP.

“What happens there is Siddhi is running the queries to identify the events that are relevant for further analysis, and driving that in into a Java-based platform,” said Garcia-Navarro “We take the latest events that we’ve identified from the streaming application, and we take those events to re-run the score with the latest information that is available to users, and re-optimizing that with MarketSwitch.”

The system would constantly re-examine their data, updating it and fine-tuning it with the latest information, and drive the final, optimised decision back for execution on the marketing platforms. The challenge? In order to keep the whole system’s operation under 200 milliseconds, this particular sub-system had to do all of this at a mere 50 milliseconds. That’s a staggeringly small amount of time.

After a pause, he added, “This 50 milliseconds has now been brought down to between 3 and 5 milliseconds.”

From code to credit

WSO2’s involvement began, ironically, not in the field of marketing analytics, but with analyzing credit risk. Experian had a product (now called PowerCurve) traditionally built for mainframes in the credit risk space; it allowed credit risk analysts to design business rules visually. They wanted to use this along with MarketSwitch to examine a user’s propensity to buy something.

After the initial QuickStart program, Experian’s internal integrator – they have a team set aside for this – took it to the rest of the company. Even within Experian’s ocean of established technology stacks and software, the WSO2 CEP made a splash big enough to be a critical product. The first implementation connected to WSO2 CEP through WSO2 ESB. Later iterations directly connected to the Siddi processing engine.

Experian likes the way WSO2 has worked for them on this.

“We explored all the typical suspects,” said Garcia-Navarro. “The CEP world is well known, and CEP for high-frequency trading had been in use for years. We explored all those commercial providers, but we chose WSO2 for three key reasons:
The first is because it’s open source. We believe that whenever possible we need to start embracing open source much more widely in business.
The second one is the depth of knowledge of the support provided. WSO2 takes a lot of pride in their support model; they claim – rightly – that they don’t have pre-engineers, but engineers who work on on the product providing the support needed for clients. And when you start working with them you see the depth of skills and expertise that they have. That’s a big plus for us.
The final one is the depth of offerings. CEP we’ve built the prototype for and implemented in house in our data centers and infrastructure. We’re starting to look into many aspects – the next one we’re looking into is ESB, but not the only one.“

Right now, Experian is pushing Complex Event Processor to the limits. Because of the nature of their business, they’re heavily interested in the next steps that we take with CEP and some of the new things we’re working on in the data and analytics space.

For more information on Experian’s work with WSO2, view Rafael’s presentation at WSO2Con EU 2015.

WSO2 Enterprise Store for the App Generation

More than a handful of people refer to the emerging generation as the app generation. The concept is simple; we are intuitively accustomed to searching for an app that would solve our day to day problems.

“I’m sure there’s an app for that,” is not just something you hear when craving pizza past bedtime anymore, it’s a familiar phrase at home, school and work. According to, the two most popular app stores (think Google and Apple) collectively lay claim to a stunning 3.1 Million apps as of July this year. So to answer your question, yes there is an app for that, but the better question is; where do you find it?

For consumers the solution is simple enough, desktop and mobile device operating systems are more likely than not to be embedded with an app store. If you can string up a couple of keywords, finding the right app is no rocket science. The formula isn’t quite that easy for enterprise users.

To start with, enterprise app stores are void of the intuitive UX and UI of consumer-grade app stores. This is only the lesser of evils when entertaining the possibility of an app store not existing at all.

Gearing Enterprises for the Future

Gartner predicts that by the year 2017, 25% of enterprises will feature an app store. While the projections is optimistic, it isn’t by any measure timely. As of now, the workforce age bracket (18-44 years) uses an average of nearly 30 apps per user and spends an approximate 35 hours per week interacting with these apps.

These numbers reported by Neilsen encompass a wide variety of app types including entertainment, social and photography. The promise for enterprise use may be less illustrious, however the numbers clearly reflect on the currently emergent practice of using apps.

Image Source: Nielsen–so-much-time.html

If the benefits of adopting an app store aren’t promising enough for enterprises, there is always the flipside to consider. Duplication of enterprise apps and assets (more on that below) cost large organizations a considerable amount of time and money.

Often, business units isolated by function and/or geography tends to reinvent the proverbial wheels in their daily routines. The natural solution is an easily discoverable, centralized app and asset collection. AKA; a store!

Limitless Possibility

For enterprises and business owners now starting to see the light at the end of the store, there’s good news and good news. First,apps are just the start of the story and secondly, the light is green in a Dollar shade.

Apps are only one type of asset that may be listed in a store. As for what else can be listed in the store, the short answer is anything and the long answer is everything. Whether they are apps, APIs, adapters, services, connectors, bookmarked websites, documents, gadgets, ebooks, audio files or whatever else you might fathom, the store is fair-game for all asset types.

As to the second point, enterprises may save on the cost of duplication but that’s just one method of monetization. The second method really isn’t rocket science. All our favorite app stores have introduced price tags to their app collections. The concept is simple; you pay, you buy.

Taking the monetization aspect a step further, however, the store allows custom action types. The thinking is simple; store owners are free to determine revenue models for their premium content. These models may take the form of straight out pricing, subscription, licenses and any other clever monetization scheme that businesses can think up. Your move.

Transforming Cost Centres

The beauty of the store concept extends far beyond business process optimization and the introduction of a fresh revenue channel. Potentially, the store can transform a business or business unit from a cost center to a highly profitable one.

Take, for example, a research unit of a large organization. Let’s take out the potential confidentiality of the information gathered by this team, for elaborative purposes. Typically, the team will provide insights for other internal departments. With the introduction of a store, the research team is able to expose assets generated by them to businesses operating in the same (or related) domains who may opt to purchase (or not) these assets to avoid creating them from scratch.

Open Source, Ready to Deploy

The natural next question for most businesses is how to set up an enterprise store. There’s an easy answer to that question. Enter WSO2 Enterprise Store, the fully open source store, ready for on-premise or cloud deployment.

WSO2 Enterprise Store ships with two out of the box asset types and allows unrestricted custom asset type support. Getting started is simple enough and the product page provides the necessary documentation. Feel free to contact us for support and queries on how to transform your business into the store of the future.

Download and try the fully open source WSO2 Enterprise Store to transform your pace of innovation today!

Everything You Need to Know About WSO2 ESB 4.9

We’ve just rolled out a new upgrade to the WSO2 ESB; version 4.9.

While 4.9 is not a major release, we feel that there’s enough of a leap in functionality that a bit of reading might be required. As Chanaka Fernando puts it, it brings over 100 improvements and 600+ bug fixes, including the addition of inbound endpoints to make the ESB the ultimate integration engine.

To help you out, our engineers have compiled a number of blog posts that will bring you up to speed on what you need to know.

  1. What’s new in the WSO2 ESB
    We’d recommend starting with Chanaka Fernando’s piece on what’s new, what’s improved and and how all of this ties in to make the 4.9 release important.
  2. Understanding the Failover Message Processor
    The Failover Message Processor is a nifty addition that helps guarantee message delivery when your usual message stores are down. Prabath’s Ariyarantha’s extremely detailed blogpost runs you through the theory of how this useful message delivery mechanism works and how to deploy it in your solution.
  3. How to get JMS Inbound Coordination running
    The concept of inbound endpoints now allows the WSO2 ESB to support many more transports in a multi-tenanted environment. Jagath Ariyarathne writes about using an inbound endpoint for coordinating inbound messages from the Java Message Service.
  4. Using worker / manager clusters without a load balancer
    Worker / manager cluster setups are quite common, especially when it comes to scaling applications. Ravindra Ranwala describes how to set up, configure and deploy such a cluster without using a load balancer.
    If you do have a worker / manager cluster set up, Ravindra’s next tutorial is about Message Processor Coordination support and its two main use cases.
  5. Everything MQTT
    MQTT and MQTT support is a topic in its own right. We’d recommend starting with Sriashalya Srivathsan’s concise introduction to MQTT, followed up with Elilmatha Sivanesan’s short post about how the  WSO2 ESB supports MQTT. Then it’s back to Sriashalya on configuring Axis2 MQTT.
    Following up with improvements in the RabbitMQ space (listed on Maheeka Jayasuriya’s blogpost), we recommend Ravindra Ranwala’s writeup on the technical wizardry of getting the WSO2 ESB to use RabbitMQ, both as a producer and as a consumer.
    Then of course, there’s Kafka. In Kafka Inbound use cases, Kathees Rajendram writes on various ways to use the WSO2 ESB’s Kafka support to consume messages from Kafka brokers.
  6. Last, but not least: on preserving HTTP Headers
    The previous version of our WSO2 ESB had limited support for preserving HTTP header fields, but with new ESB 4.9.0 introduces new tools for this task. See Prabath’s blog for a short list of what those properties are.

If you haven’t downloaded the latest WSO2 ESB already, you can start over here (remember – it’s free and open source). For more information, contact us and we’d be happy to help you out.