Financial institutions all over are working to build effective data strategies and improve decision-making. With so many new technologies and innovations out there, it can get very difficult to keep up with the industry and even keep straight the buzzwords we hear throughout the day. In this piece, let’s dive in to better understand what makes a data lake.

What is a Data Lake?

Simply, a data lake is a data repository for raw data in its native format. As the name implies, these repositories are capable of holding massive amounts of data. Ideally, data lakes are available at an enterprise level and can be easily queried to find relevant data for managers to analyze.

How does it compare to a Data Warehouse?

Data Lakes and Data Warehouses have a number of similarities. Both are designed to:

• House disparate data sources in a single repository
• Allows improved data analytics
• Provide an enterprise source for querying data

However, there are distinct differences between a Data Lake and a Data Warehouse. As the name implies, a Data Lake’s architecture is completely flat. As opposed to a warehouse, in which data is integrated and organized hierarchically in files and folders, data lakes rely on utilizing a proper series of unique identifiers and metadata tags for organization.

A key point to note about the definition of the data lake is that the data is contained in its “native form”.  A primary reason to utilize a data lake is to deposit and analyze data from any number of disparate data sources. As the lake accepts any data format, data can easily be submitted to the repository, and extracted in the original format of its disparate source system. This differs from a Data Warehouse, which aggregates the various disparate sources and standardizes the data into a single source, superseding the native formats of the data.

Like anything worth doing, managing a data lake requires some effort. It is not a set-it-and-forget-it solution. When properly managed, a data lake and a data warehouse should not be viewed as competing products, but should create a fantastic partnership, which allows any data consumer within an organization to easily uncover answers to his or her questions from years of past transactional data.

The previous blog, “What is a Data Lake? Part 1”, discussed how to define a data lake, and how it differs from a data warehouse. To better understand the idea, let’s dive a bit deeper and get to know the advantages and disadvantages surrounding data lakes.

To start, there are a number of advantages data lakes serve for financial institutions:

     1. Storage/Scalability – As mentioned in the definition, data lakes are capable of holding vast amounts of data, and can easily be scaled up if needed.

     2. Input Form – Due to the fact that data lakes accept data in its native forms, it is easy for credit unions to dump data in from as many sources as desired. Data from any disparate sources, internal or external, structured or unstructured, can be stored easily in the data lake, regardless of the data format.

​

     3. Price – Data lakes are relatively affordable form of data repository. Due to the flat architecture, there is not a need for special hardware systems, and server and license reduction actually helps to cut cost.

     4. Enterprise Solution – Data lakes are designed so that data can be retrieved by query enterprise-wide. Anyone in the organization with a question should be able to access the data lake and extract the necessary data for analysis.

These advantages work together to create a very compelling product for certain purposes. Prior to declaring a data lake to be your primary tool for analytics though, there are several other characteristics of this technology to consider:

     1. Connectivity – As previously mentioned, data is stored in its native form. This means the various data sources are collected in the same place, but not integrated. The data silos still exist, which is a major pain-point for the purposes of enterprise analytics, as there is not a single source of truth.

     2. Organization – Rather than a filing system, data lakes work by relying on metadata and a consistent tagging system. While this can be a very successful method, it requires extreme governance. Especially if it is used as an enterprise system, everyone within an organization must understand how to properly tag the data, and know the system well in order to retrieve the desired data. If not, you run into the risk of maintaining a “data swamp”.

     3. Data Quality – By lacking proper governance and organization, it can become very difficult to determine data quality. Some users may be successfully finding value from the lake, but there is not necessarily a way to track that lineage or take advantage of the reports being built by other users.

     4.  Training – While marketed as an enterprise solution, data lakes do not generally act as such in the real world. For it to be a true enterprise solution, it assumes every user in the organization has the necessary training to analyze and manipulate the various data sources contained within the lake. Unfortunately, this does not tend to be case, and most “users” will rely on others within the organization to find and analyze the data for the rest.

In the two previous blogs​, the concept of a data lake was defined and differentiated from a traditional data warehouse. Yet, a key point was a data lake and a data warehouse are not mutually exclusive. In fact, a structured data warehouse could be a subset of an overall data lake architecture.

Simply stated, a data lake is an effective way to store and access very large quantities of data.

What does this mean for credit union decision makers?

Delving into these questions, OnApproach Senior Engagement Manager, Pete Keers recently discussed the world of data lakes and other cutting-edge ideas with Bill Preachuk, Solutions Engineer with Hortonworks. With a mission, “to manage the world’s data”, Hortonworks describes itself as an innovator in creating, distributing and supporting enterprise-ready open data platforms and modern data applications. Among “Big Data” players, Hortonworks ranks in the top tier.

PK: Bill, what do you consider to be the major themes regarding data lakes?

BP: I think of them as a synthesis of structured data and unstructured data. Yet, they are not just a dumping ground for all kinds of data. It’s all about the business value and answering the questions that credit unions have.

PK: Why data lakes? Credit unions are just now starting to embrace the idea of the traditional structured data warehouse.

BP: Credit unions are used to fixed queries and fixed data. There’s only “rear view mirror reporting” now. Data lakes can help set a larger vision for the credit union industry. In a data lake, large volumes of structured and unstructured data can be brought into one place. When you bring transactional data from multiple sources into one place you can expand that reporting. It’s like having multiple data warehouses where you will be able to drill across and drill down.

Where it really gets exciting is where you have disparate data sources – weather, time, geography, external financial feeds, or credit rating information. It can be structured and unstructured. For example, imagine having geographic information about homes and neighborhoods sorted by geo-location or zip code. What if all that was in one place? It could be integrated and used to expand and augment existing reports. This is a step along the road but the real value comes when you can go from rearview reporting to predictive analysis.

All this data allows for forward thinking and integrated forecasting. It allows extrapolation of past information with external data resulting in faster analysis and faster forecasting. It means being able to make decisions forward and see patterns.

It’s a situation where data scientists can prepare and build out predictive analyses. It also allows the use of machine learning and augmentation via artificial intelligence. Augmentation and machine learning can not only add value but also set business direction.

PK: How can this translate in actual business benefit for a credit union?

BP: The benefits can be such things as cost savings, cost avoidance, or finding new opportunities that were not previously known. You end up with more products you can sell. A specific example for credit unions would be to look at mortgage information for particular customers and augmenting that with real estate information for forecasting home sales of homes in a particular area. The analysis would involve applying patterns to see how they look forward. You may be able to see potential cash crunches in certain zip codes.

Another possible area of value might be risk avoidance. Being able to apply patterns, mine information, and see potential risk threats at a credit union level or zip code or even with individual members. It enables detecting fraud and avoiding fraud. There’s a huge potential for security. Being able to take disparate log information from servers, from external rating agencies, and bring that all together and apply machine learning credit unions can look for those patterns which could identify service attacks and brute force attacks. It could stop threats as they happen.

PK: If data lake can have both unstructured and structured data, what does this mean for the traditional data warehouse?

BP: A data lake does not necessarily do away with the data warehouse. The data warehouse can be replicated in the data lake and in doing so extends the utility of the data warehouse.  You can run your data warehouse on the cluster.

PK: Can you define a cluster?

BP: A Hortonworks Data Platform (HDP) Hadoop cluster refers to a group of commodity computers that are connected and centrally coordinated – each with their own processors and disk. Processing and storage are all redundant and fault-tolerant by default. (A really nice intro to clusters can be found at https://hortonworks.com/apache/hadoop/).

Jobs are divided into tasks and tasks are sent to the nodes in the cluster. Each node completes tasks in parallel and the results are brought together. Massive amounts of data can be processed at a low cost using this method.

Suppose a credit union were to attempt to use a single server to build a very large data lake and was experiencing 6 to 8-hour processing cycles. In that case a single server is tasked with all the computational requirements, and cannot easily scale out.  When they bring those same data feeds onto a 20 to 30 node HDP cluster, all of the sudden you have similar ETL processing to load the dimensional data warehouse but you only require perhaps a half hour of processing since you have so much more parallel horsepower you can throw at it.

The cost of storage and the cost of processing in a cluster is also much lower since it uses commodity disk, allowing you to keep full fidelity of your historical source data and all of your transaction feeds in the cluster. You can restate or add information to your data warehouse because it is there and available – you didn’t have to purge source data since it is no longer cost-prohibitive to store it. 

Within the cluster you can bring all of your structured data warehouse data and other unstructured data together in one place.  Multiple tools are available that allow you to explore these different types of data very quickly and derive value with little overhead.  Later you can choose to store it in a highly optimized format.

PK: When you talk about clusters handling large amounts of data, how large are we talking about?

BP: Hadoop clusters scale to petabyte levels.

But a big difference is how Hadoop handles data ingestion.  Conventional relational database data has to be loaded into a single specific schema/format. This is where a huge amount of time is spent during ETL processing.  But Hadoop gives you “schema-on-read” capabilities.  You need only ingest your file as-is into the cluster, and if your data has any kind of structure (CSV, tab-separated, JSON, etc.) – you can instantly define a schema on the file and use the data immediately. 

As soon as you have that, which only takes a second after the file shows up, you can issue SQL queries against it, and that can validate your data. At that point you have your data available. Data scientists love it. They can analyze data quickly without load processing overhead.  

PK: It sounds like this technology could evolve in these traditional data stores where everything migrates to Hadoop clusters. They are in a more efficient environment.

BP: I came originally from the traditional SQL relational database world, and what I see is a kind of convergence. Relational databases are adding more Big Data capabilities, and at the same time Big Data SQL offerings (like Hive LLAP, Spark SQL, and Phoenix) are adding more and more capabilities available to the relational databases.

But it’s not just performance improvements, It’s that open source software overall improves at a pace far quicker than closed source software. For example, four years ago Security, Metadata handling, and stream processing were rather immature in Hadoop.  Now you’ve got Ranger and Kerberos built/integrated for security and Atlas for metadata.  You also have massive improvements to the ability to stream in your data in real time, process it, and cleanse it in-stream with Storm, Kafka, and NiFi. All built in the open, with contributors and committers from dozens of organizations and companies.

I recall there were 12 eco-system tools in a Hortonworks Cluster 3 years ago and now there’s almost 30.

PK: As I said before, credit unions are just now embracing the concept of the traditional data warehouse. Isn’t this asking the industry to move a bit too fast?

BP: And perhaps they aren’t able to move too quickly.

PK: So, it seems to me that there’s an opportunity for a vendor to create a product that will help with a standardized solution. It would take some of the complexity out of the situation. OnApproach is interested in partnering with companies like Hortonworks to bring in the concept of data lakes and unstructured data to reduce the complexity so credit unions can more quickly get the value out of it. A credit union wouldn’t have to get its own data scientists or hire whole crew of employees who know how to run this. It would be an effort to bring value without big cost or having to hire their own experts.

BP: Yes, this would be a situation where credit unions that already have a data warehouse can augment what they have and make it better. It would provide them the opportunity to develop and sell entirely new products that are built upon this data that they would never have been able to do themselves.

PK: A huge component of this that we haven’t touched on yet is the prospect for multiple credit unions to pool their data in a data lake. OnApproach has been looking for a way to pool data across the industry. As we’ve been discussing, the technology to do this is readily available. I think the challenge is to convince credit unions to contribute their data and articulate why it is valuable to pool data across credit unions. My sense is if the immense value of the opportunity can be clearly communicated, credit unions will gladly join in to get that value. Again, one of the value opportunities is not only sharing data in a pool but sharing a centralized group of data scientists.

BP: There’s great value in being able to take information from multiple credit unions as an anonymized aggregate and find patterns in the customers and in the states – then being able to package that up for them across the country. Individual credit unions cannot do this alone. There’s such a value in bringing all that data together. It’s a terrific opportunity.

The trend of data-driven decision making is exploding within the credit union space.  Pressures to increase revenue, reduce risky assets, and efficiently identify qualified sales leads have all contributed to the growing trend.  But as the push for data-driven decision making has gained popularity, the need for a wider breadth of data has become apparent. 

For most decision making, credit unions need only leverage the data within their own walls. However, some types of decisions require a larger volume of data. Data like credit risk forecasts require immense amounts of underlying data to be accurate. Most credit unions by themselves do not have the critical mass of necessary data for such forecasting.  However, in the collaborative spirit of the industry, credit unions can join forces to amass an adequate amount of data through the process of data pooling. 

What is Data Pooling?

The process of data pooling involves multiple credit unions securely transmitting their data to a data pool provider. The data is compiled into a single data set where algorithms created by the data pool provider generate analytic results.  The results are then sent back to the originating credit unions for their personal use.  A credit union will only receive data back related to the data they originally sent. 

The beauty of data pools, however, is the results sent back from the data pool are based off ALL the data within the data pool.  In effect, a credit union can leverage another credit union’s data.  That being said, pulling together multiple credit union data sets into one common data set is not an easy feat.

The challenge in data pooling arises from the fact that credit unions tend to store their data in varying systems.  Different core and ancillary data systems sometimes do not mix well when creating a data pool.  In order for multiple credit unions’ data to be compatible, the data needs to be stored under the same standard.  Once the data is housed under a uniform standard, creating a data pool becomes more manageable.

The key to successful data pooling is establishing the connection.  Connection to a data pool consists of five main phases: data extraction, data transmission, data pool presence, data retrieval, and data storage. 

Data extraction first involves identification of the relevant data that will be sent to the data pool.  In a data pool, not all data at the credit union needs to be sent to the pool.  Only the data needed for analysis and identification will be sent, and it will be arranged to fit the data pool format. 

Data transmission to the data pool requires a few preparations for security measures.  First data is masked, meaning that the data which identifies either an individual member or credit union is scrambled to random characters.  The credit union has the unique key to unmask its own data.  The data transmission will also be packaged in an encrypted file.  The credit union and the receiving pool have the unique key to decrypt the transmission package.  With the data security measures in place, the data is sent via a secure file transfer protocol to the data pool.

In the data pool (data pool presence), the data pool provider will run its data analytics model against the pool’s data and assign the result to the corresponding individual credit union data.  The data itself will not be identifiable, just the origin of the data so it can be packaged for retrieval by the appropriate credit union.  The new package of data is then prepared for retrieval.

For data retrieval, the results are posted to an origin specific directory.  A credit union based scheduler pings credit union specific mailboxes and retrieves data when present.  Once returned, the data is decrypted using the credit union unique password, and unmasked using the unique masking key.

Data storage is the last phase in a data pool connection.  After the data is retrieved, the analytic results are linked to the corresponding member data and are integrated back into the credit union’s data set.  The newly generated data is stored into the credit union’s data warehouse as another data element and can now be used for analysis and reporting.

Data pooling is an innovative process that can expand a credit union’s view of useful (and profitable) information.  Utilization of analytics from pooled data can give your credit union the extra validation needed for important decision making.  Imagine knowing that each decision made has measurable and tangible proof behind it.  Integrating data from your organization into a data pool may provide the answers your credit union is missing out on.   

Apple has made a tremendously successful company off of one thing… Is it the iPhone, iPad, iPod, or Mac series? No.  What makes Apple​ so powerful and successful is not its products, but rather the ecosystem it’s created through its standard operating system, the iOS.  An operating system or “platform” that enables its users to connect with the rest of its users as a community and its developers.  With this common platform, all users are on a level playing field with a similar access to all “apps” and services that have been created on the platform – rather than each user building everything themselves.

While this wildly successful model exists in several industries, it has failed to gain traction with credit unions, especially as it pertains to digital transformation (including data and analytics).  Instead of having one common platform, credit unions are all on their own unique “platforms” comprised of different data sources with different data definitions.  In other words, each credit union is on its own to create all new “apps” and services required to compete in the modern world.  At one time, this wasn’t an issue but with the new regulatory pressures and competitive threats of today, this is no longer a viable option for credit unions.

In the new, digitally-transformed world of today, credit unions must adopt a collaborative and common “platform” to compete, which for the sake of a better term, I will call the CuOS (or Credit Union Operating System) to stay aligned with the Apple iOS analogy.  Doing so will require all credit unions to find a means to conform to one common standard.  While this is no easy task with all of the different data sources that exist in the credit union industry (Core, LOS, Debit, Credit, etc…), it is possible and several efforts are striving for this common standard such as the CUFX (Credit Union Financial Exchange) and OnApproach’s CU Analytics Ecosystem (which leverages CUFX).

While CuOS might not seem like a strategic priority for a single credit union today, the future needs to be the consideration.  By establishing this common platform today, all credit unions will be able to leverage the work of the industry.  The largest, and even the smallest of credit unions will be able to work together to compete with the rest of the financial institutions out there including the largest banks and the newly establish FinTechs.  Rather than one credit union taking these institutions on their own, the industry would be able to work as one, leveraging its inherit collaboration, to compete with all other financial institutions.  All of the work being done an industry platform versus a single credit unions site will begin to grow exponentially just as the apps and services on the Apple iOS have.

Credit unions need to fully embrace the inherit collaboration of the industry they’ve always celebrated and come together on one common platform with one common cause – digitally transforming the industry to compete with the rest of the financial institutions in the digital age.  This one common platform leads to success for ALL credit unions and builds an industry that will compete and survive for years to come.

​By Nate Wentzlaff​

As credit unions begin their journey into the future, they must rely on an industry standard analytics platform to guide them to their destinations.

Google Maps has revolutionized how we navigate our lives. It saves us from headaches caused by unnecessary traffic and other challenges in traveling. My journey from work to home has many different routes depending on traffic patterns. During days with slower traffic (i.e. - winter snowstorms), the Google Maps recommended route will change every 5 – 10 minutes. Using an analytics engine that informs me of the best route allows me to spend extra time on more important things in life. Credit unions have a similar opportunity when navigating their institutions into the uncertain future of financial services. Establishing an industry standard analytics platform will enable credit unions to cooperate on analytics and guide them to their desired destinations.

Analytics Platform

Google Maps uses complex algorithms and thousands of integrated data sources to provide users a clear path to their destination. Utilizing a common data platform to conform the data for its users provides a unique opportunity to share data throughout the globe. This platform empowers users to navigate an ever-changing world. The credit union industry needs to embrace a similar type of analytics platform for all users to enable collaboration throughout the industry. Speaking the same data language is crucial for the success of credit unions throughout the world. With a common data platform, applications can be designed for credit unions regardless of their software systems feeding the data. When someone develops an application, it can be used throughout the industry without a need for costly (and time intensive) implementation. A majority of time spent on application development is mapping data. As credit unions adopt an industry standard analytics platform, developing APIs (Application Program Interface) from an analytics platform will become much easier, which will enable credit unions to navigate their journeys cooperatively.

Data Integration

“We recognize that in order to provide our users with the best, most up-to-date map possible, we must partner with the most comprehensive and authoritative data sources.” -Google

Understanding that they don’t have all the data (logistically and legally) within their company, Google reaches out to trustworthy 3^rd parties to integrate data within their analytic platform. Through Google’s Base Map Partner Program, they are able to integrate thousands of sources to improve Google Maps every day. Credit Unions have the same opportunity when contributing to an analytics platform. With all the credit union data integrated, the route will become much clearer.

Data Pooling

“Yes, that’s right: if Google has access to the location data collected by your smartphone, then you’re part of Google’s crowdsourced operation to improve and expand Maps.” -Rob Nightingale

Google Maps uses anonymized user data to build dynamic analytics for all users. For example, using the speed of users driving on the road, Google can infer traffic conditions. In order to bolster their analytics platform, credit unions should pool anonymized member data including all transactions on a daily basis. Understanding how members behave throughout the industry will give credit unions the power to drive to their destinations efficiently.

Setting your destination

Utilizing Google Maps is only useful when users know their desired destination. Beginning an adventure without a destination will inhibit any type of analytics from assisting the user. Analytics without a purpose will result in another fancy dashboard hidden in an analyst’s folder (while usually incurring a monthly payment to a vendor). Setting up goals and defining KPIs (Key Performance Indicators) is essential before a credit union begins their journey.

Data Visualization

Visualizing data along the path is another powerful feature of Google Maps. Seeing their environment allows users to spot outliers and identify opportunities along the route (i.e. - gas and food). As credit unions embark into the future, they will be able to identify valuable opportunities along the way. This will allow credit unions to alter their route to obtain value that was not directly identified by the analytics. This Ad Hoc ability allows credit union employees to steer their credit union with the guidance of analytics. The analytics is the most efficient route. However, sometimes value can be found outside of the most efficient route. Data visualization gives analyst the power to give data-driven recommendations on any alteration of the analytics-guided path.

Applied Analytics

Sometimes Google Maps takes users on routes that are unfamiliar. Most people assume that the analytics are correct and will follow wherever it leads them. However, there may be times that the analytics need to be overridden by a user. For example, the destination address may have been entered incorrectly. However, this should not be done based on a “gut” feeling about a particular area the user is driving through. Sometimes, a thriving city is on the other side of a barren desert. Similarly for credit unions, when the analytics don’t seem to make sense, further experimenting should be performed before adjusting the route. Many different hypotheses may be formulated along the journey. By utilizing the scientific method, credit unions will be able to “trust but verify” their analytics along the way.

Credit Union Efficiency

Just as our transportation systems are becoming more efficient with commuters collaborating on an analytics platform, the credit union industry can become more efficient as they embrace an industry standard analytics platform. With scarce resources (i.e. - time and money), credit unions should take advantage of an analytics platform that will bring them greater efficiencies. As a movement built on collaboration and using resources thriftily, cooperating on analytics will allow the credit union industry to thrive in 2017 and beyond!

Analytics has been a prevalent topic for many years but never more prevalent in the credit union industry than it is today.  Just a few years ago, the topic hardly came up, but in 2017, it’s hard to find a credit union not talking about, or planning and budgeting for a proper analytics solution.  This excitement about analytics has gathered widespread attention, involving industries, companies, and individuals new to the field of analytics.

Now that there is a lot of buzz around the topic, it is important to understand whose challenge, but more importantly, whose opportunity analytics is.  Analytics is the credit unions’ opportunity.  Not just one individual credit union, but all credit unions – the industry or movement.

Credit unions need to understand the value of their data, not just as one credit union’s data, but the value of all credit union data.  Alone, as a single credit union, how do we compete with U.S. Bank, Wells Fargo, and Citi Group, not to mention the FinTechs like SoFi?  We can’t.  The answer to our biggest challenges is something that is inherent to the credit union industry – collaboration.  While we might not be able to fully execute on analytics alone, we can do it together – as ONE.

One of the best things that the credit union industry has ever formed is the Credit Union Service Organization (CUSO).  Doug Petersen, President/CEO of Workers Credit Union says it best:

“ provide a means to an end – allowing credit unions the capability to fulfill the financial needs of their members in a cost effective environment through efficient delivery channels.  Plus, they attract the brightest and most innovative minds to the board table, bringing best practices of credit unions across the country, which is a priceless experience.”

The CUSO model is exactly what the credit union industry needs in order to tackle the analytics challenge and take advantage of the opportunity.  CUSOs leverage the power of collaboration that already exist within the industry to offer several benefits such as:

Economies of Scale

Economies of scale are achieved when a company produces goods and services on a larger scale while simultaneously lowering average input costs.  CUSOs achieve economies of scale by producing goods or services for several credit unions rather than having a single credit union attempt to replicate the same benefit.  By utilizing the power of collaboration, CUSOs can specialize on a given product or service, which enables them to provide higher-value products and services at a much lower cost.

Competitive Advantage

CUSOs offer credit unions the ability to remain competitive by improving efficiencies and producing a wider array of products and services that would be unobtainable without CUSO collaboration.  They enable credit unions to acquire scale and market power along with other resources, such as capital and staff that far exceed their individual sizes.  For example, an analytics solution can take about three years to build and has an initial cost of about $2,000,000 with an additional cost of $200,000 per year to support. With a CUSO; however, credit unions can get the same solution for less than $50,000 upfront and only $40,000 per year to support.

Multiple Credit Union Perspectives

The collaboration of several owners spurs more innovative products and services because there are several different viewpoints, many of which are from the most innovative minds in the industry.  Unlike most other vendors in the credit union space, CUSOs have board members and owners that represent the industry as a whole.  “There can be some overlap with the credit union, but the management team can’t be 100% the same,” says Guy Messick, Attorney/Partner at Messick & Lauer and General Counsel to NACUSO.  This is incredibly beneficial because there are more minds contributing to what’s best for the industry.

For Credit Unions, by Credit Unions

Owners of CUSOs are, themselves, credit unions. Therefore, it is in their best interest to do what is best for credit unions.  Rather than focusing solely on profit, CUSOs also focus on the overall well-being of credit unions and their members.  Credit unions, not shareholders, are in control of the CUSO’s product development roadmap and the CUSOs deliver on the roadmaps by leveraging expertise of credit union executives.  Using ideas from the best and the brightest in the industry, both large and small credit unions, ensures best practices are shared and practiced. This results in the best products and services available for the industry.

Ownership

This is easily the most important aspect of a CUSO, especially as it pertains to data and analytics.  WHO OWNS THE DATA and WHO OWNS THE TECHNOLOGY – it needs to be the credit union industry.   When, or if, credit unions start to give away their data and/or the technology that effectively stores, mines, and utilizes their data, they not only give away the value of their data, but they also give away what makes them who they are – their members.  When we start to give away our member data, we start to give away our members.  This industry must hold onto our most important asset, our members.  Which in 2017 and beyond, is their data and the technology required to leverage that data.

For all of the reasons above, the CUSO is the only way credit unions can successfully execute on analytics.  Credit unions must realize that this is much bigger than one credit union.  This is an industry opportunity and it many ways, analytics, and digital transformation, is the demise, or prosperous future for credit unions – in all hopes, the latter.