When Compliance Goes Wrong
By: Greggory B. Oberg, Esq.
Often, a compliance or regulatory issue arises out of poor training, poor oversight/management involvement in process, and/or a simple lack of attentiveness.
This is a story about how all three of those can be preset and effective, yet still go wrong. The names and certain facts have been changed to protect the innocent (and well-meaning) people or institutions involved.
The Setup
As often occurs, a consumer has applied for a mortgage loan. Nothing special about this loan. The consumer is a repeat customer of the lender.
In another common occurrence, our consumer has failed to completely fill out their GMI addendum on the 1003. For sake of a good story, let’s assume the consumer wasn’t affirmatively asked to fill it out, and didn’t elect to or decline to do so.
Now, we’re in process. And given the COVID world we live in, it’s mostly going to be done via remote processes.
The Initial Reaction
Our lender here discovers this missing data, and engages the lending and oversight teams within the institution to determine how to follow up and correct the issue. Everyone is worried that we’ve failed to get the info…as we know how much HMDA impacts our Fair Lending and other high-level metrics.
So the issue is escalated, and a handful of senior individuals across departments are engaged to determine how to solve this.
Keep it Simple
The right choice here was the easiest one, just go ask for the information from your applicant. As SCA has addressed many different times in our blog since the 2018 rules came out, the key here is simply requesting the info and parroting back to the regulators what the applicant disclosed to you.
What Not to Do
This is where well-meaning compliance goes wrong. Two principal solutions emerged from the senior management discussion.
Make a visual ID; or
John over in Commercial plays golf with the applicant, and handled another loan for them last year. John KNOWS what the GMI of that individual is…so let’s just write it in.
While one of these seems somewhat logical, you can (hopefully) quickly see how the other creates problems. Let’s address in turn.
Visual ID:
Remember, a visual ID can only be made if(generally, at least):
The application originated (or at least some portion of the processing) occurred in person;
The consumer is asked their GMI; and
The consumer declines to provide the GMI.
Here, we have no evidence of in-person application or video component, as required for visual ID. Additionally, suppose the info John happens to know about our applicant indicates they are Cuban and Filipino.
As we know, only the applicant can use these “dis-aggregated” or sub-set race/ethnicity fields. They can never be used by the LO (or similar) in a visual ID.
Assuming Race:
Probably don’t need to elaborate on the societal perils of this one. But regulatory consequences also clearly arise here. The intent of the HMDA regs, as described in the requesting statement at the top of the GMI Addendum, is to capture the demographic data the borrower or applicant identifies with.
Is it entirely possible that John is right, and that his friend and golf buddy would have identified in the way John supposed? Sure. But it’s still not proper to make this assumption.
Wrap-Up
Here, our heros created more of an issue than they otherwise would have had. In almost any conceivable scenario, if the institution had proceeded in this manner, a simple HMDA scrub and eyes on the GMI addendum’s various check boxes would likely have flagged the issue. You cannot have a visual ID on a remote app; you cannot have visual ID with a disaggregate field. And it’s entirely possible the email communication ends up in the file.
End of the day, the institution chose to CC Spillane’s hotline on the above-mentioned thread, and the problem was quickly solved by sending a new GMI addendum to the consumer.
Bigger Picture
Compliance is hard. Compliance is complicated. And sometimes, attempts to comply with complicated and convoluted regulations creates compliance issues that are bigger than the initial concern. Here the institution included multiple management-level employees AND paid a third party to review their determinations in real time.
Certainly a valid way to ensure you DON’T make mistakes, but how many other avenues might an institution have to eliminate this risk ahead of time? Could increased training or better documented procedures have helped? Can you see other problems/solutions?
Maybe. But I think this simple example demonstrates how any number of the interconnected elements of a Compliance Management System can make or break the overall quality of the program.