Managing Unstructured Data with Big Data Notions

Data is traditionally structured. It makes the data easy to read and simple to consume. Are those statements actually true? I have a hard time accepting that perception. What if I told you we collectively perceive data as traditionally structured because we select to ignore unstructured data? All that remains is the structured data and because that turns into the primary focus, it becomes natural to claim data is traditionally structured. It makes the data easier to read and simpler to consume.

Unstructured data is defined as information that does not have a pre-defined model or is not organized in any sensible manner. This is not a new phenomenon. However, the sheer quantity of unstructured data is on the rise across all industry verticals and there is growing interest in the ingestion of that data. One of the largest examples of this is in the healthcare space. Take a minute to think about all the pre-printed medical forms, questionnaires, insurance forms, procedure and diagnosis forms, and claim forms you are exposed to as a patient or guarantor. That is what you see. Those same forms can exist in a variety of formats and layouts based on the insurance company, hospital or medical facility, or the state or locality where the services are performed. It may be a single field variance or a completely different looking form altogether. Whether typed into an electronic form or scanned into a system as an image, the data is likely unstructured making it nearly impossible to develop software to read, recognize and accurately ingest all of the data all of the time.

Instead of setting unstructured data aside, we need to use technology to reduce the constraints and structure the data. This will allow for the consumption of more data, which is really what enterprises are after. By understanding the data, you are creating a modern architecture ideally easy to use, repeatable, and secure. What could you accomplish with more data? What could society accomplish with more data, specifically in the healthcare space? Could we prevent outbreaks? Could we cure disease?

All enterprises deal with unstructured data. Some have more than others but unstructured data does exist everywhere. There are many methods of thinking about unstructured data, getting it into a structured format, and ultimately loading it into the system or data warehouse. It can be done manually with users reading and inputting the data, it can be done electronically with extract, transform, load-type processes to deal with most of the data, or it can be a combination of electronic and manual effort. Making the process as electronic and systematic as possible will be very helpful but remember it is nearly impossible to consume 100% of the data this way. Some manual effort will still be required when a form field is blank or has been moved to the next box, for example.

You need the right challenges while making the decision to ingest and make sense of unstructured data. It is important to know or at least question what you are possibly missing or what you can possibly gain from this additional data. Do not go blindly into the effort of managing unstructured data. Also, do not get caught up in the immediate issues or only a few use cases. Architect the process for a long term and comprehensive build out. You may know the challenges you are facing today but consider what challenges you may face down the road. Regulation, security, and technology are examples of ever-changing items in our industry that may present future challenges. Finally, data governance must be addressed. This is particularly true in the healthcare industry. The days of only a few fields being deemed personally identifiable information (PII) are fading away. If you are dealing with healthcare data, you are better off considering everything as PII. Secure access to the data on a need-to-know basis or at least with the vision that not everyone requires access to everything.

The concept of ingesting unstructured data is relatively new in the debt collection industry. Much of what I have presented crosses the line between what is considered data integration and what is considered Big Data. Managing unstructured data requires integration processes but understanding why unstructured data is important is a Big Data thought. Regardless of your approach, plan to pay for the sins of the past. Not capturing all the data and randomly dropping data into fields that “look” good may end up skewing your results as you ingest unstructured data.

Advertisements

Texting Is The Final Frontier?

How are there two extremes when it comes to sending a text message to a debtor? The answer is actually quite simple. There is no answer because the FDCPA does not specifically address text messaging. In 1977, when the FDCPA was passed into law, text messaging and other contemporary forms of communication did not exist. Since then, not only have new methods of communication been introduced but the population’s preference for how they want to be communicated with has changed dramatically. Almost anyone with children can confirm that texting and social media dwarfs communicating over the phone or in person. In fact, we see these same preferences in the younger generation workforce as well.

Education aside, how can the agency start sending text messages? There is no law detailing the use of text messages as a method of communication; however there is law regarding how the agency can communicate with the debtor. The same rules in place for communicating via phone calls, letters, and emails need to be followed when sending text messages. If we evaluate this from a technology perspective, agencies are faced with a challenge. Even the newest collection software available does not include a module for text messaging. For now, agencies must partner with an outsider provider to capture the necessary technology to launch a text messaging campaign. Using an outside service provider equals a need for integration. Here are three technology considerations for implementing your text messaging campaign:

1. Consent

As with calling a cell phone or sending an email, you must get consent from the debtor. Yes, this can be achieved over the phone if you actually speak with the debtor but I have seen a more systematic approach. If you are driving the debtor to a payment portal, whether from your own website or through a letter campaign, ask for consent when they log into the portal. Setup the first screen to include a checkbox for consent to receive text messages. Furthermore, if the box is checked, ask for updated contact information. Force the debtor to confirm or update their phone numbers and address information before they can move to the payment portion of the site. I have seen technology offerings like this from several letter vendors and payment processing vendors in the industry.

2. Data Integrity

If the debtor does consent and provides updated demographic information, do not assume it is accurate. You should not be in a hurry to overwrite the primary phone number and address you have in your collection software just because something newer has been presented. The debtor may consent to receiving text messages and then deceitfully or not, provide a wireless phone number that does not belong to them. Sending a text message to the wrong phone number could mean you have just disclosed the debt to a third party and violated the law. Ask the debtor to respond to an initial text somehow confirming the phone number belongs to them. After passing your integrity checks, update the primary phone and/or address information in your collection software with the newly provided demographic data. However, do not fully delete any previous demographic data. Capture it in a previous record module or in the account notes.

3. Integration

The design and development of the data integration, or interface, will need to be tested and in place before launching your text messaging campaign. Most vendors will offer a batch mode integration. This file-based solution usually involves an overnight file delivery for updates that day. The agency will receive that file and import it into their collection software. An import interface must be built into your collection software. Depending on how many files are delivered or the schema of the files, more than one import interface may be required. The data in your collection software will always be up to 24 hours behind the payment/consent portal because the updates will not be received and processed until later that night. A real-time solution will process updates from the portal as they occur and import the updates into your collection software automatically.

For now, sending text messages to debtors remains a gray area. While text specific regulation is being formed, will you wait for others to push ahead and evaluate the fallout or will you implement this modern day, and often preferred, contact method?

Collecting for the IRS

Last December, the Fixing America’s Surface Transportation Act (FAST Act) was made law by the federal government. Unlike the previous ruling which only allowed the IRS the authority to place collections with private debt collection companies, this new law went a step further by requiring the IRS to use private debt collection companies. The law also states that the IRS must begin entering into contracts within three months after the date of enactment. That time frame is rapidly closing but there is no language detailing when the IRS will actually start placing inactive tax receivables.

Last year, I wrote about agencies investing their time and dollars in preparing for a government contract, primarily for the Department of Education contract. Collecting for the IRS is a new opportunity for established agencies to get into the government space and for agencies already in the space to service another line of government receivables. There is plenty of work that can be done in advance to prepare for this opportunity.

Data security should be a primary concern. If your collection software is preventing your agency from achieving compliance and hitting security benchmarks you may want to evaluate other software options or work with your current software provider to implement additional security features. Make sure the backend database is fully encrypted and that data in transit is as well. If encryption is available, you may want to verify it is turned on because in some collection products the encryption feature is optional and turned off by default in an effort to save space. Aside from the actual software, you should review and enhance your information security policies. If you do not already have these policies documented, you should address that immediately. Policies detailing available user accounts, access privileges, password policies, and how to work with sensitive data need to be covered. If you find yourself overwhelmed with implementing or updating data security policies, a great resource to start is the Federal Information Security Management Act (FISMA). It will not answer all the questions but FISMA will provide great direction and help to set things in motion.

Simply having a strong data security policy is not good enough. Awareness of the policy and to the ever-changing landscape of compliance and data security is key as well. Awareness begins with a strong training program. Create an electronic training program that focuses on working with government data and the sensitivity of that data. In a test environment, stage examples for users to encounter and work with sensitive data in your collection software. Wherever possible, implement automated IT processes that promote awareness.

So far, I have touched on policy and procedure ideas with a focus on the operation and environment. There are many items you can fine-tune directly in your collection software as well. First and foremost, make every effort to eliminate manual processes by replacing them with automation. Every time a user manually kicks off a process, renames or moves a file, or manually retrieves/sends data with an external vendor, the likelihood for user error increases. You may be surprised to find out that most manual processes like those mentioned can be automated within your software or with custom applications that work with your collection software. Take a step back to really understand and document all your processes. Then, review the list with your team or consultant(s), pick out areas where automation is an option, and prioritize the list before beginning any design or development. Second, take the time to evaluate and enhance your workflow. Agencies should implement this practice at least twice per year. The addition of new clients, the performance of your consumer representatives, and the strengths/weaknesses of your skip tracing efforts may introduce new trends or change trends that were evaluated when your existing workflow was designed. Find something that works best for your agency. Third, develop your own performance reports. Do not rely solely on canned reports that were delivered with your collection software. Like enhancing the workflow, there are metrics and key performance indicators (KPIs) meaningful for your agency. Many of the collection products have some sort of built-in mechanism for developing custom reports. If custom reporting within your software is not available, there are plenty of reporting tools with many connectors that may work with your product. Take a look at Business Objects (Crystal Reports), Cognos BI, Microsoft SSRS, or Tableau.

By refining a few of your operational policies and procedures and implementing some strategic changes in your collection software, your agency can be set up nicely for that new government contract. As with the Department of Education contract, you can bet the IRS will be gathering performance data on the agencies receiving placements and that the data will be made public via several published reports. Wouldn’t it be nice to see your agency at the top of that list?

Managing Unconventional Skip Tracing Data

The common skip trace practice many third-party agencies follow after loading a new placement file is to address skip trace, phone number skip trace, bankruptcy skip trace, deceased skip trace, and credit score. Most collection professionals are well versed on this now monotonous routine. All agencies do it. The difference lies in how the return data is evaluated, captured, and embedded into the daily workflow for managing the inventory. However, there are some other, unconventional skip tracing services and often, they will provide some very revealing information. This information may be just enough to separate you from the competition. I would like to detail three unconventional skip tracing services and more importantly, ideas for how to manage them in your receivables management software.

Possible Incarceration

You may eventually discover a consumer is incarcerated over the course of working the account but have you considered running a skip trace for incarceration before any effort goes into contacting the consumer or sending a letter? Executing this skip trace and identifying a consumer is incarcerated will allow your representatives to focus on accounts that are more collectible. The possible incarceration skip trace should be scheduled one of two ways. First, the request can be automated to run with your normal skip trace service requests (address, phone, bankruptcy, deceased, credit score). Alternatively, you have your regularly scheduled requests run first and then based on those results, segment the ideal consumers for a possible incarceration skip trace. For example, if you receive a return that a consumer is deceased or has a credit score less than 400, your automated workflow may be set up to automatically close the account. In those cases, your skip tracing automation should bypass that consumer altogether for the possible incarceration scrub.

When receiving a hit for incarceration, some decisions need to be made. Most often, a release date (if applicable) is provided with the incarceration hit. Depending on the duration of the incarceration, you may option to close the account and re-open it immediately after the release date. On the other hand, you may just want to close the account and archive it. Either way, let your system handle it with built-in automation.

Possible Litigious Debtor

The litigious debtor skip trace could save thousands of dollars in legal costs. This may be one of the most fascinating services available these days. A returned hit on this service may indicate you are facing a consumer who has filed one or several lawsuits against agencies. It exists because consumer lawsuits against agencies and first parties are on the rise. Furthermore, consumer initiated lawsuits are steadily increasing because more and more consumers are becoming well educated on the FDCPA and other federal or state regulation.

Unlike the possible incarceration skip trace, you may want to set up workflow to run the possible litigious debtor skip trace right away. If a hit is returned, most agencies establish rules in the software to immediately flag and close the account in an effort to eliminate any contact whatsoever. When going this route, utilize workflow or other automation to close the account, remove it from any dialing queues, stop any other skip tracing efforts, halt all contact attempts, and flag the consumer so it is understood to steer clear of this account.

Property

This skip tracing service is a fun one and can arm your representatives with some very valuable information prior to contacting the consumer. The property skip trace will inform you if the consumer has recently purchased, leased, or somehow acquired new property. A house, condo, and land are all property examples. This information is especially valuable when a representative is working a consumer who indicates they are on a tight budget or simply does not have the financial resources to repay the debt.

As for automating this service, it is best to send the request after your first blast of skip tracing. You will want to carefully segment and select the consumers you want for the property skip trace. Construct the workflow to select consumers with a valid phone number and address, populated with full SSN, an outstanding balance that justifies the property skip trace, and a moderate to high credit score. Unlike possible incarceration and litigious debtor, turning on monitoring is a great idea for this service. This will allow your skip trace provider to continuously seek property hits for the consumer, rather than a one-time scrub, and notify you when a new hit becomes available. With this information, a representative can easily counter an excuse-ridden consumer by simply questioning his financial position since he has recently purchased a new property.

Before jumping right into unconventional skip tracing, you must first develop guidelines for isolating and marking the consumers for these different services, for identifying them when hits are received, and for the special handling they require. Regardless of the decisions for implementing unconventional skip tracing or managing the returns, store the data in your software or data warehouse and make the process automated in your software by including it in your everyday workflow.

4 Compliance Areas Debt Buyers Must Address

For years, debt buyers could operate outside the scope of compliance and regulation in the accounts receivable management industry. This was not because debt buyers were attempting to be deceitful, rather this sector of the industry was so new and innovative that too much was unknown to attempt to govern it. Those days are over and no longer are debt buyers overlooked. In fact, they are now very much on the radar of the CFPB. It was only a matter of time as compliance administration was on the rise with larger creditors and other first parties. The CFPB is already visiting the organizations. Most would agree that debt buyers are not far down the list.

What can debt buyers do to prepare themselves for a call from the CFPB? Debt buyer certification programs are fairly new in the industry and several options are available. The standards for most of these certification programs focus on the primary areas of concern debt buyers are facing these days. Topics including media, chain of title, agency management, and credit bureau reporting all make the cut. I would like to examine these four primary topic areas and present some solutions for capturing and maintaining the compliance related information using the same technology debt buyers are using to manage their inventory. Let’s set the precedence that present day debt buyers are managing their inventory with proper, enterprise level software. Any debt purchasing operation still managing inventory using spreadsheets is destined for compliance violations and trouble with the CFPB should there be an audit.

Media

Also referred to as account and debtor documentation, media is crucial for debt buyers and it is important to have software that will allow for media attachments on a per account basis. Often, media is not included in the actual purchase agreement. It usually must be requested from a separate entity, or if the seller does have the media, it comes with an additional cost. In many systems, media attachment components are not included but hopefully your software allows for custom configuration and you are able to add media attachment options.

Make sure media attachments are available at both the account and consumer levels. For example, there may be a contract at the account level but separate credit reports if there is more than one responsible party on the account. The setup should be able to store the credit report for the respective responsible party. Most media is large in file size and because of this, disk space will be consumed quickly. Proper system sizing is often overlooked and needs to be planned accordingly. Lastly, in the event a consumer pursues litigation, the debt buyer will need to be in a position to confirm the consumer opened the account and is a responsible party by presenting media.

Chain of Title

The history of account ownership is referred to as chain of title. When a debt buyer purchases an account from a creditor or another debt buyer, the ownership is transferred. Like media, chain of title is additional documentation for the account. It should be requested at the time of purchase and any information or media related to chain of title should be stored in the software at the account level. You will want to have this information for compliance purposes, in the event of litigation, or if you eventually sell the account. Storing the chain of title in your software will also position you to set up your placement strategies with external agencies and provide them with chain of title for each account in the placement file.

Agency Management

As a debt buyer, knowing the agencies you are placing with is almost as important as knowing your own agency. At least that is what an auditing entity will expect. Until sold and ownership changes hands, debt buyers are responsible for all their accounts regardless if being worked inhouse or placed with an external agency. There is some very nice software available for debt buyers that will not only allow for automated account placement strategies, but will also include features for ranking an agency, certifying an agency, and tracking compliance related data points for an agency. If you cannot find the latter in your current software, it is in your interest to build out the agency management module to capture compliance related information. For example, you may be expected to know any certifications your agencies have achieved, how they enforce and maintain data security related to your inventory, and their backup and restore procedures. In most cases, this is not only a single field of data. You should be able to capture and store short text descriptions of the processes or attach documentation to the external agencies that are configured in your software.

Credit Bureau Reporting

How debt buyers report to the credit bureaus is one of the most common violations in the industry. Far too often, workflow elements for credit bureau reporting is not detailed enough. Ensure your credit bureau reporting workflow is not re-reporting debtors and is also deleting debtors from the bureau’ s file upon resolution of the debt or in the case of bankruptcy. Be ready with documentation that details your process. It is much easier to hand an auditor a detailed document and walk through it together than attempt to explain your process for others to appraise. Credit bureau reporting practices are also key processes debt buyers should understand about each of their external agencies.

Understanding and documenting compliance standards such as those described above will help prepare you for a visit from the CFPB. At the very least, you will have addressed and standardized some important, compliance related business processes should the CFPB never call or visit.

Increase Telecom Recoveries with Robust Scoring Models

When handling telecom accounts, agencies need to have a distinct approach to be successful in their recovery attempts. Customer delinquency is on the rise in the telecom market. Higher subscriber prices, providers combining services, the competitive nature of the players in the market, and third-party involvement is to blame for the growing number of delinquent subscribers and rising write-off amounts. News like this should be welcoming to agencies servicing telecom accounts, but with it comes increased pressure on the agencies to recover.

It is a mistake to think of telecom accounts just like every other account. It is an even greater mistake to treat telecom consumers as you would treat bank card, student loan, or medical consumers who have delinquent accounts. Take a minute and think about yourself as a consumer in the telecom market. This should be easy as you likely have some combination of telephone, cable, satellite, or streaming service accounts in your name. As a consumer in the market, do you understand what you signed up for, how much you owe, and in what respect the money is applied when you make a payment? Generally, consumers in the telecom market cannot answer these questions and furthermore, cannot explain the contract they signed or if they even signed a contract. We see this phenomenon in the telecom industry because it has been commoditized to the extent where it is too easy for consumers to switch suppliers. When a consumer switches, he/ she usually either does not know or does not care he/she owes money. The point is the industry is different so how an agency utilizes systems and technology to collect needs to be different.

Closer management is essential. Creating and implementing finely segmented profiles using strong scoring models is one way to manage telecom accounts in your collection software. First and foremost, identify the data elements that should factor into generating your recovery score and how each may positively or negatively impact the score. The list below includes some data elements and considerations when generating a recovery score for your telecom accounts.

Credit Score

In most cases this is undoubtedly the top data element to include when generating a custom recovery score. It should weigh heavily in determining the collectability of an account. The workflows or queue logic in your software should stage consumers with the higher credit scores to receive the most attention. Likewise, you may set up your workflow to all but close out accounts with a credit score in the 300 or 400 range.

Quantity and Quality of Data

It is important to know how much data you have per account and the quality of the data. Generating a custom recovery score with not enough and or unqualified data may hurt your recovery attempt more than helps it. Ideally, you already have the data captured in your software. If not, most data should be included in the placement file from the service provider or can be obtained by interfacing with data scrub service providers like LexisNexis, MicroBilt, or any of the major credit bureaus. At a minimum, make sure you are receiving and storing data points like full name, social security number, full and verified address, and verified phone.

Number of Delinquent Accounts

Any consumer with multiple delinquent accounts in your system should receive a lower score. It is an indication the consumer is hopping suppliers when better deals or introductory offers are available.

Geographic Location

Some may question the significance of this data element but in remote or lesspopulated areas of the country, consumers do not have many options for telecom service. They may even be limited to a single supplier for Internet, cable, and/or telephone service. In these cases, a higher recovery score is reasonable as the consumer must satisfy the debt in order to resume service or to receive new services from the supplier.

Type of Residence

You may consider increasing the recovery score if the consumer owns versus rents or shares a residence. In just about all cases, the telecom accounts for a homeowner are in his/her name. When working with consumers in an apartment, condo, or other renting situation, the telecom services and responsibilities may be split among many of the residents, making it somewhat easier to neglect their portion of the service.

After identifying and detailing the data elements important for generating your custom recovery score, they must be built into your software for automatic and fluent management. Some recovery software platforms include modules to set up custom scoring but none I have encountered are very impressive. More flexibility and options are likely available outside of the software. In most cases, custom scripting will be required to consume the data and make systematic scoring decisions. If you have strong programmers on staff, their skills will certainly be required to configure your scoring model. This can be handled strictly with scripting a solution that will integrate with your recovery software or externally in a data warehouse or “black box.” The terms data warehouse and black box are interchangeable on this topic. It is a place external to the recovery software where data from your recovery software, accounting software, web portal, CRM, or any of other in-house system is captured.

Custom scripting can be applied here as well and may be a better option than against the recovery software database because you may have more data elements to work with in the data warehouse. Regardless of the database(s) utilized, it is imperative to apply the recovery score logic uniformly and against all consumers in the system. One mistake agencies make when implementing new logic is only applying it on a go-forward basis. Circle back on all the existing telecom consumers in your system and run them through your new custom scoring logic as well. Allow the system to make decisions and commit to allowing your scoring to drive collection efforts.

Synchronizing Collection Software with Hospital Data

As a server of medical accounts, agencies often find themselves facing some additional technology concerns. Every vertical brings its own technological challenges. In most verticals these challenges are shared but the healthcare vertical adds complexity when considering items such as system of record and the detailed nature of industry accepted data standards.

Medical collection software exists for any serious agency in the healthcare space. However, I see and hear agencies are simultaneously working in two different systems, their own collection software and the hospital’s system. (Throughout this column, I will repeatedly reference the “hospital’s system” but the terms “medical facility’s system,” “insurance company’s system,” “claims management system,” and so on could easily take its place.) The questions I will address in this column are: Why are there disparate systems and how can these agencies work out of one system? Most often the “why” is one of three scenarios. One, the hospital requires the agency to work directly in their system. Two, the agency software does not have the same data points as the hospital’s system. Three, there is no seamless integration between the two systems so real-time updates are not sent back and forth between the two pieces of software. In any case, system of record becomes a question. When working in two separate systems, which one wins when there is a conflict? No wrong answer to this question exists and the better question to answer is how can the conflicts be avoided? Unless you have a compelling case, the hospital will insist your reps work directly in their system and will not be convinced your receivables management software is sufficient enough to allow otherwise. You can utilize your technology to build this compelling case by addressing the integration scenario previously presented.

Before detailing a seamless integration between systems, there are a few prerequisites. Ideally, the following statements are all true:

  • Both the agency and the client have technical teams available to implement and test the integration.
  • There are application programming interfaces or web services available for both the source and target systems.
  • The source and the target system include functionality to track data changes and events that occur as users are working.

Consider your collection software as the source. This is the system you are familiar with and the system you prefer to work with. A data push can be developed using system inherent data integration tools or an external data integration tool with connectors to the system database. This push process will need to be constructed in a manner that captures the data level events as they occur and will need to be shared with the hospital’s system. Simultaneously, a pull or retrieve process will need to be in place for the hospital. This process will grab the real-time data events being provided by the agency’s system. After some analytic, transformation, or validation routines are performed, the data from the agency’s system will ideally auto-update in the hospital’s system. Additionally, reverse processes will need to be engineered for the hospital to automatically share real-time data events with the agency’s system. Achieving this sort of real-time integration will allow your representatives to work exclusively in your system while keeping the hospital’s system in sync and vice versa.

Prior to engineering the solution described above, there will need to be a requirements gathering session with your client to identify the data elements that are important to share and are able to be shared between the two systems. A significant takeaway from these sessions needs to be a requirements document. At a minimum, the following should be detailed in this documentation:

  • A very detailed listing of the data fields to exchange.
  • Any business rules related to data transformations, data validations, and data extract/load procedures.
  • Instructions for using any web service technology.

Utilizing existing data standards is almost essential in the healthcare space. These standards are also helpful in achieving real-time system integration. Your agency is likely already using data standards like Health Level Seven (HL7), HIPAA formats, or something EDI related in order to exchange data with clients. Transaction and code standards like these provide a uniform method for sending and receiving healthcare related data in near real-time. It is important to understand these standards not only because your clients will expect it but also because it displays a higher level of sophistication regarding your operation. The client’s only expectation is you are staying up to date with the ever-changing healthcare standards. The October 1, 2015 countdown to ICD-10 (10th revision of the International Statistical Classification of Diseases and Related Health Problems – Clinical Modification/Procedure Coding System) is on the horizon. Are you ready?