How to Evaluate HMDA, CRA and Fair Lending Software
Written for whoever has been handed the job of comparing compliance platforms. It names no vendors, including ours, and it is meant to be useful even if you buy from someone else.
The short version. Every serious HMDA, CRA and fair lending platform imports from your loan origination system, geocodes to census tract, runs the FFIEC edit checks, calculates rate spread, writes a submission file, and does regression-based fair lending analysis. Those are table stakes, not differentiators, and comparing them produces a tie.
The questions that actually separate vendors are about what happens after the filing: who builds the analysis you need but do not have, how specific a failure message is, whether the vendor will publish how it measures accuracy, whether the software can run where your policy requires, and whether the person who answers the phone knows the regulation as well as the software.
Everything you should expect
Use this as a disqualifier, not a scorecard. If a platform cannot do these things, stop the evaluation. Most established vendors can do all of them, which is exactly why they are the wrong basis for a decision.
| Capability | What to confirm |
|---|---|
| LOS import | Reads your specific origination system's output — fixed-length, delimited or direct database — without a manual re-key step |
| FFIEC edit checks | Validity, quality and macro edits, run on demand rather than only at submission |
| Compliance-grade geocoding | Census tract, county FIPS, state code and MSA/MD, on current Census TIGER boundaries |
| Rate spread | Calculated against the FFIEC's weekly APOR tables, with the correct methodology chosen per loan |
| Submission file | Written in exact CFPB format, with a final pre-submission check |
| CRA reporting | Assessment area definition at tract level, disclosure and performance tables |
| Section 1071 | Current with the 2026 revised rule — one compliance date of January 1, 2028, and coverage at 1,000+ covered originations in each of two preceding years |
| Fair lending analysis | Logistic regression for underwriting, linear for pricing, plus a demographic proxy method such as BISG |
| Matched-pair file review | Pair selection on criteria you set, then the paired files reviewed side by side. Some vendors call this match pair testing, others comparative file review |
| Peer comparison | Market share and peer performance against a peer set you can define and defend |
| Mapping | Assessment areas, tract demographics and branch geography, not just tables |
| Audit trail | A record of who changed what, sufficient to answer an examiner's question months later |
One note on terminology, because it causes real confusion in evaluations: matched-pair analysis and comparative file review are two halves of one procedure, not competing methods. Matched-pair analysis is how the files get selected — pairing a denied protected-class applicant with a similarly-situated approved one. Comparative file review is the examination of the files it selected, to determine whether a legitimate factor explains the difference. Vendors market one name or the other. Ask whichever vendor you are talking to about both steps. Definitions for this and roughly 190 other terms are in our compliance glossary.
The questions that actually separate vendors
1. What happens when you need a report the system does not have?
This is the question we would ask first, and it is the one buyers most often skip. Every platform ships a fixed set of reports. Every compliance department eventually needs an analysis nobody anticipated — the comparison your board keeps asking for, the spreadsheet you rebuild by hand every quarter, the question your examiner raised last cycle. The default answer across the category is that you export to Excel and build it yourself, again, every time.
2. When an edit check fails, what does the message actually say?
Every platform will tell you that an edit failed. The useful ones name the field, the rule behind it, and what a valid value would look like — which is the difference between resolving it yourself and opening a support ticket. Across a filing cycle with hundreds of exceptions, that difference is most of the work.
3. Will the vendor publish how it measures geocoding accuracy?
Everyone advertises compliance-grade geocoding, so the adjective carries no information. What carries information is whether the vendor will document the method. Be aware that match rate and accuracy are different measures: match rate is the share of addresses that get a geographic code at all, accuracy is the share where that code is correct. A vendor quoting one as though it were the other is not necessarily being dishonest, but you should know which number you are being given.
4. Can it run where your policy requires it to run?
Ask this early, because it can disqualify vendors before anyone looks at a feature list. Some institutions' examiners, IT policies or vendor-risk frameworks require that loan-level data stay inside the institution. That rules out browser-only platforms regardless of their merits. If the constraint does not apply to you, cloud deployment genuinely removes installation, hardware decisions and update management.
5. How long is implementation — and what is inside that number?
Implementation estimates are quoted in ways that hide most of the work. The figure often starts after the historical data conversion and the import definitions are finished, which is the part that takes the time.
6. Who answers the phone, and do they know the regulation?
Software comparisons systematically undervalue this, because it does not fit in a feature matrix. But the practical question during a filing cycle is whether you can reach a person who understands HMDA, CRA, geocoding, the software and your data — or whether you are explaining Regulation C to a first-line agent reading a script.
7. What can the software not do?
Ask every vendor to name a limitation. The answers are informative in both directions: a vendor who names a real gap is telling you something checkable, and a vendor with no answer is either not listening or not being straight with you. Every platform in this category has gaps, including ours.
8. How will you verify any of this after the sales process ends?
Most of what a vendor tells you during an evaluation is unverifiable at the time. The things you can check are documents and demonstrations, so weight them accordingly.
One question most buyers do not think to ask
Question 1 above is worth returning to, because the answer varies more across this category than any other and it compounds over the life of the contract.
Consider what happens when another institution asks their vendor for an analysis nobody had built before — say, which counties outside their assessment area they lend in heavily enough to justify a branch. If the vendor builds it as a one-off file for that customer, nothing changes for anyone else. If the vendor builds it as a definition that enters a shared library, every other customer on that platform can run the same analysis against their own data tomorrow. Report definitions describe the analysis; they contain no institution's loan data, which is what makes sharing them possible at all.
The practical difference is that on one model the product you bought is the product you keep. On the other it grows without you asking. Worth asking any vendor which model they operate, and what evidence they can show you of it.
In the interest of being straight about it: that is how ComplyBI works, and it is the reason we wrote this page. The rest of the questions above are ones we would want a prospect to ask us, and a few of them we answer better than others.
What we cannot show you, and why
Since this page asks you to demand evidence, it should be honest about the limits of ours. Large institutions' legal departments routinely prohibit being named as a software reference — we have asked, repeatedly, and been refused. So we publish no customer logos and no named references, and you should discount any vendor's logo wall accordingly: it reflects which customers' lawyers said yes, not which product is better.
What we can offer instead is checkable: 39 years filing this data since 1987, a stated 95%+ geocoding accuracy figure used consistently everywhere we talk about it, a public compliance glossary, and a demonstration against your own file rather than ours.
Frequently Asked Questions
How do HMDA and CRA compliance platforms actually differ from each other?
Less than their marketing suggests on the core filing workflow, and more than it suggests on everything after. Any serious platform imports from a loan origination system, geocodes to census tract, runs every FFIEC validity and quality edit, calculates rate spread against the weekly APOR tables, writes a submission file in CFPB format, and performs regression-based fair lending analysis with a demographic proxy method. Treat all of that as table stakes rather than differentiators. The real differences are in who builds an analysis you need but do not have, how specific an edit-check failure message is, whether the vendor will publish how it measures geocoding accuracy, whether the software can run where your policy requires it to run, how long implementation takes, and whether the person who answers the phone understands the regulation as well as the software.
What should I ask a compliance software vendor that I probably have not thought to ask?
Ask what happens when you need a report the system does not have. Every vendor ships a fixed set of reports, and every compliance department eventually needs an analysis nobody anticipated. The usual answer is that you export to a spreadsheet and build it yourself every reporting cycle. Ask instead whether the vendor will build it, what it costs, how long it takes, and whether it then becomes a permanent part of the product rather than a one-off file. Also ask the vendor to name something the software cannot do. A vendor with no answer is either not listening or not being straight with you.
How can I verify a vendor's geocoding accuracy claim?
Ask three questions. First, what is the published figure, and is it stated consistently everywhere the vendor talks about it. Second, does it refer to match rate or to accuracy, because they are different measures: match rate is the share of addresses that receive a geographic code at all, accuracy is the share where that code is the correct one. Third, will the vendor publish the methodology behind the number, covering how accuracy is measured, what validation layers exist and how exceptions are handled. A vendor that will not document how it measures accuracy is asking you to take the figure on trust, and a geocode one block out is a different census tract and therefore a different filing.
Should I choose cloud or on-premise compliance software?
Start with whether your institution has a choice. Some examiners, IT policies and vendor-risk frameworks require that loan-level data stay inside the institution, which rules out browser-only platforms regardless of their merits. If that constraint does not apply, cloud deployment removes installation, hardware decisions and update management, and is usually faster to stand up. Ask the question early in an evaluation, because it can disqualify vendors before anyone looks at features.
How long should implementing HMDA or CRA compliance software take?
Ask for a specific figure rather than a range, and ask two follow-ups that expose what the figure really means. First, does it include converting your historical data and building the import definitions from your origination system, or does the clock start after those are done. Second, can you switch mid-filing-cycle, because a vendor that requires you to wait for a year boundary is telling you something about how much of the work falls on you.
If you want to run these questions at us
A demonstration against a sample of your own loan file, with whichever of the eight questions above matter most to you. Comply HMDA/CRA/SBL, Comply Fair Lending and ComplyBI read one database, so the answers come from the same place.
Schedule a Free Demo Have questions?
This evaluation framework may be republished with attribution to RATA Associates and a link to rataassociates.com. If you think a question here is wrong or missing, tell us.
