Big Data – Panacea or Pandemic?

You’ve probably heard that “data is the new oil” (but you just need to know where to drill?). Or alternatively, that the growing lakes of “Big Data” hold all the answers, but they don’t necessarily tell us which questions to ask. It feels like Big Data is the cure for everything, yet far from solving our problems, it is simply adding to our confusion.

Cartoon by Thierry Gregorious (Sourced from Flickr under Creative Commons – Some Rights Reserved)

There’s no doubt that customer, transaction, behavioral, geographic and demographic data points can be valuable for analysis and forecasting. When used appropriately, and in conjunction with relevant tools, this data can even throw up new insights. And when combined with contextual and psychometric analysis can give rise to whole new data-driven businesses.

Of course, we often use simple trend analysis to reveal underlying patterns and changes in behaviour. (“If you can’t measure it, you can’t manage it”). But the core issue is, what is this data actually telling us? For example, if the busiest time for online banking is during commuting hourswhat opportunities does this present? (Rather than, “how much more data can we generate from even more frequent data capture….”)

I get that companies want to know more about their customers so they can “understand” them, and anticipate their needs. Companies are putting more and more effort into analysing the data they already have, as well as tapping into even more sources of data, to create even more granular data models, all with the goal of improving customer experience. It’s just a shame that few companies have a really good single view of their customers, because often, data still sits in siloed operations and legacy business information systems.

There is also a risk, that by trying to enhance and further personalise the user experience, companies are raising their customers’ expectations to a level that cannot be fulfilled. Full customisation would ultimately mean creating products with a customer base of one. Plus customers will expect companies to really “know” them, to treat them as unique individuals with their own specific needs and preferences. Totally unrealistic, of course, because such solutions are mostly impossible to scale, and are largely unsustainable.

Next week: Startup Governance

 

Assessing Counterparty Risk post-GFC – some lessons for #FinTech

At the height of the GFC, banks, governments, regulators, investors and corporations were all struggling to assess the amount of credit risk that Lehman Brothers represented to global capital markets and financial systems. One of the key lessons learnt from the Lehman collapse was the need to take a very different approach to identifying, understanding and managing counterparty risk – a lesson which fintech startups would be well-advised to heed, but one which should also present new opportunities.

In Lehman’s case, the credit risk was not confined to the investment bank’s ability to meet its immediate and direct financial obligations. It extended to transactions, deals and businesses where Lehman and its myriad of subsidiaries in multiple jurisdictions provided a range of financial services – from liquidity support to asset management; from brokerage to clearing and settlement; from commodities trading to securities lending. The contagion risk represented by Lehman was therefore not just the value of debt and other obligations it issued in its own name, but also the exposures represented by the extensive network of transactions where Lehman was a counterparty – such as acting as guarantor, underwriter, credit insurer, collateral provider or reference entity.

Before the GFC

Counterparty risk was seen purely as a form of bilateral risk. It related to single transactions or exposures. It was mainly limited to hedging and derivative positions. It was confined to banks, brokers and OTC market participants. In particular, the use of credit default swaps (CDS) to insure against the risk of an obiligor (borrower or bond issuer) failing to meet its obligations in full and on time.

The problem is that there is no limit to the amount of credit “protection” policies that can be written against a single default, much like the value of stock futures and options contracts being written in the derivatives markets can outstrip the value of the underlying equities. This results in what is euphemistically called market “overhang”, where the total face value of derivative instruments trading in the market far exceeds the value of the underlying securities.

As a consequence of the GFC, global markets and regulators undertook a delicate process of “compression”, to unwind the outstanding CDS positions back to their core underlying obligations, thereby averting a further credit squeeze as liquidity is released back into the market.

Post-GFC

Counterparty risk is now multi-dimensional. Exposures are complex and inter-related. It can apply to any credit-related obligation (loans, stored value cards, trade finance, supply chains etc.). It is not just a problem for banks, brokers and intermediaries. Corporate treasurers and CFOs are having to develop counterparty risk policies and procedures (e.g., managing individual bank lines of credit or reconciling supplier/customer trading terms).

It has also drawn attention to other factors for determining counterparty credit risk, beyond the nature and amount of the financial exposure, including:

  • Bank counterparty risk – borrowers and depositors both need to be reassured that their banks can continue to operate if there is any sort of credit event or market disruption. (During the GFC, some customers distributed their deposits among several banks – to diversify their bank risk, and to bring individual deposits within the scope of government-backed deposit guarantees)
  • Shareholder risk – companies like to diversify their share registry, by having a broad investor base; but, if stock markets are volatile, some shareholders are more likely to sell off their shares (e.g., overseas investors and retail investors) which impacts the market cap value when share prices fall
  • Concentration risk – in the past, concentration risk was mostly viewed from a portfolio perspective, and with reference to single name or sector exposures. Now, concentration risk has to be managed across a combination of attributes (geographic, industry, supply chain etc.)

Implications for Counterparty Risk Management

Since the GFC, market participants need to have better access to more appropriate data, and the ability to interrogate and interpret the data, for “hidden” or indirect exposures. For example, if your company is exporting to, say Greece, and you are relying on your customers’ local banks to provide credit guarantees, how confidant are you that the overseas bank will be able to step in if your client defaults on the payment?

Counterparty data is not always configured to easily uncover potential or actual risks, because the data is held in silos (by transactions, products, clients etc.) and not organized holistically (e.g., a single view of a customer by accounts, products and transactions, and their related parties such as subsidiaries, parent companies or even their banks).

Business transformation projects designed to improve processes and reduce risk tend to be led by IT or Change Management teams, where data is often an afterthought. Even where there is a focus on data management, the data governance is not rigorous and lacks structure, standards, stewardship and QA.

Typical vendor solutions for managing counterparty risk tend to be disproportionately expensive or take an “all or nothing” approach (i.e., enterprise solutions that favour a one-size-fits-all solution). Opportunities to secure incremental improvements are overlooked in favour of “big bang” outcomes.

Finally, solutions may already exist in-house, but it requires better deployment of available data and systems to realize the benefits (e.g., by getting the CRM to “talk to” the loan portfolio).

Opportunities for Fintech

The key lesson for fintech in managing counterparty risk is that more data, and more transparent data, should make it easier to identify potential problems. Since many fintech startups are taking advantage of better access to, and improved availability of, customer and transactional data to develop their risk-calculation algorithms, this should help them flag issues such as possible credit events before they arise.

Fintech startups are less hamstrung by legacy systems (e.g., some banks still run COBOL on their core systems), and can develop more flexible solutions that are better suited to the way customers interact with their banks. As an example, the proportion of customers who only transact via mobile banking is rapidly growing, which places different demands on banking infrastructure. More customers are expected to conduct all their other financial business (insurance, investing, financial planning, wealth management, superannuation) via mobile solutions that give them a consolidated view of their finances within a single point of access.

However, while all the additional “big data” coming from e-commerce, mobile banking, payment apps and digital wallets represents a valuable resource, if not used wisely, it’s just another data lake that is hard to fathom. The transactional and customer data still needs to be structured, tagged and identified so that it can be interpreted and analysed effectively.

The role of Legal Entity Identifiers in Counterparty Risk

In the case of Lehman Brothers, the challenge in working out which subsidiary was responsible for a specific debt in a particular jurisdiction was mainly due to the lack of formal identification of each legal entity that was party to a transaction. Simply knowing the counterparty was “Lehman” was not precise or accurate enough.

As a result of the GFC, financial markets and regulators agreed on the need for a standard system of unique identifiers for each and every market participant, regardless of their market roles. Hence the assignment of Legal Entity Identifiers (LEI) to all entities that engage in financial transactions, especially cross-border.

To date, nearly 400,000 LEIs have been issued globally by the national and regional Local Operating Units (LOU – for Australia, this is APIR). There is still a long way to go to assign LEIs to every legal entity that conducts any sort of financial transaction, because the use of LEIs has not yet been universally mandated, and is only a requirement for certain financial reporting purposes (for example, in Australia, in theory the identifier would be extended to all self-managed superannuation funds because they buy and sell securities, and they are subject to regulation and reporting requirements by the ATO).

The irony is that while LEIs are not yet universal, financial institutions are having to conduct more intensive and more frequent KYC, AML and CTF checks – something that would no doubt be a lot easier and a lot cheaper by reference to a standard counterparty identifier such as the LEI. Hopefully, an enterprising fintech startup is on the case.

Next week: Sharing the love – tips from #startup founders

The 3L’s that kill #data projects

The typical data project starts with the BA or systems architect asking: “fast, cheap or good – which one do you want?” But in my experience, no matter how much time you have, or how much money you are willing to throw at it, or what features you are willing to sacrifice, many initiatives are doomed to fail before you even start because of inherent obstacles – what I like to refer to as the 3L’s of data projects.

Image taken from "Computers at Work" © 1969 The Hamlyn Publishing Group

Image taken from “Computers at Work” © 1969 The Hamlyn Publishing Group

Reflecting on work I have been doing with various clients over the past few years, it seems to me that despite their commitment to invest in system upgrades, migrate their content to new delivery platforms and automate their data processing, they often come unstuck due to fundamental flaws in their existing operations:

Legacy

This is the most common challenge – overhauling legacy IT systems or outmoded data sets. Often, the incumbent system is still working fine (provided someone remembers how it was built, configured or programmed), and the data in and of itself is perfectly good (as long as it can be kept up-to-date). But the old applications won’t talk to the new ones (or even each other), or the data format is not suited to new business needs or customer requirements.

Legacy systems require the most time and money to replace or upgrade. A colleague who works in financial services was recently bemoaning the costs being quoted to rewrite part of a legacy application – it seemed an astronomical amount of money to write a single line of code…

As painful as it seems, there may be little alternative but to salvage what data you can, decommission the software and throw it out along with the old mainframe it was running on!

Latency

Many data projects (especially in financial services) focus on reducing systems latency to enhance high-frequency and algorithmic securities trading, data streaming, real-time content delivery, complex search and retrieval, and multiple simultaneous user logins. From a machine-to-machine data handover and transaction perspective, such projects can deliver spectacular results – with the goal being end-to-end straight through processing in real-time.

However, what often gets overlooked is the level of human intervention – from collecting, normalizing and entering the data, to the double- and triple-handling to transform, convert and manipulate individual records before the content goes into production. For example, when you contact a telco, utility or other service provider to update your account details, have you ever wondered why they tell you it will take several working days for these changes to take effect? Invariably, the system that captures your information in “real-time” needs to wait for someone to run an overnight batch upload or someone else to convert the data to the appropriate format or yet another person to run a verification check BEFORE the new information can be entered into the central database or repository.

Latency caused by inefficient data processing not only costs time, it can also introduce data errors caused by multiple handling. Better to reduce the number of hand-off stages, and focus on improving data quality via batch sampling, error rate reduction and “capture once, use many” workflows.

Which leads me the third element of the troika – data governance (or the lack thereof).

Laissez-faire

In an ideal world, organisations would have an overarching data governance model, which embraces formal management and operational functions including: data acquisition, capture, processing, maintenance and stewardship.

However, we often see that the lack of a common data governance model (or worse, a laissez-faire attitude that allows individual departments to do their own thing) means there is little co-operation between functions, additional costs arising from multiple handling and higher error rates, plus inefficiencies in getting the data to where it needs to be within the shortest time possible and within acceptable transaction costs.

Some examples of where even a simple data capture model would help include:

  • standardising data entry rules for basic information like names and addresses, telephone numbers and postal codes
  • consistent formatting for dates, prices, measurements and product codes
  • clear data structures for parent/child/sibling relationships and related parties
  • coherent tagging and taxonomies for field types, values and other attributes
  • streamlining processes for new record verification and de-duplication

From experience, autonomous business units often work against the idea of a common data model because of the way departmental IT budgets are handled (including the P&L treatment of and ROI assumptions used for managing data costs), or because every team thinks they have unique and special data needs which only they can address, or because of a misplaced sense of “ownership” over enterprise data (notwithstanding compliance firewalls and other regulatory requirements necessitating some data separation).

Conclusion

One way to think about major data projects (systems upgrades, database migration, data automation) is to approach it rather like a house renovation or extension: if the existing foundations are inadequate, or if the old infrastructure (pipes, wiring, drains, etc.) is antiquated, what would your architect or builder recommend (and how much would they quote) if you said you simply wanted to incorporate what was already there into the new project? Would your budget accommodate a major retrofit or complex re-build? And would you expect to live in the property while the work is being carried out?

Next week: AngelCube15 – has your #startup got what it takes?