Hello BOLers,

I'm working my way through a FCRA/FACTA audit and have reached sections 623(e) and 623(a)(8) regarding reasonable policies and procedure to ensure accuracy of data reported.

I can write the p&p but would like to know of any best practices your FI has with regards to this area.

Do you have a review process that occurs prior to information being submitted to the bureaus?

Do you perform periodic spot audits of the data submitted for testing?

Thank you in advance for your time and input.

The first thing I would do is drop any reference to FACTA.

It is like referring to MDIA of 2008 when dealing with the TILA. It was just an amendment and does not stand alone.

Thanks for that pointer Randy.

Anyone else have any input?

Do you have a review process that occurs prior to information being submitted to the bureaus?

We do not, it pulls straight from our core system and reports to the CRA.

Do you perform periodic spot audits of the data submitted for testing?

We do not.

would like to know of any best practices your FI has with regards to this area

We have a policy statement within our larger loan policy that describes our responsibilities as both a user and furnisher of data and general information about how we will comply with the requirements of FCRA.


I hope this helps!

Answered my own question.


Can't delete the post.

Norman,

Are you performing the audit or responding to an audit?

If you are performing the audit, you shouldn't be the one writing the policy and procedures.

Ah, the encumbrances of community banking.

Just to tag on, our reports are pulled from our core too. However, when I reviewed the data, I found that we had some items improperly coded in our core. For instance, a certain type of loan was showing as unsecured, when it was a secured loan.

Just a reminder that it will pull what's in the core, but there is no guarantee that the information was put in correctly.

Do you perform periodic spot audits of the data submitted for testing?

We do not.

Then unless you have other provisions in place to test data integrity, as an auditor I would site your bank for a violation of Regulation V § 1022.42 and Appendix E.

Establishing and implementing appropriate internal controls regarding the accuracy and integrity of information about consumers furnished to consumer reporting agencies, such as by implementing standard procedures and verifying random samples of information provided to consumer reporting agencies.

The provisions you cite say that an institution's policies and procedures should be "appropriate to the nature, size, complexity, and scope of each furnisher's activities." We are a small shop and only report on consumer loans, which do not make up much of our portfolio. Auditors and examiners have read our policies and procedures and have never suggested we aren't doing enough.

It also says we should consider the guidelines in Appendix E. To me that doesn't mean we are bound by each line item in the appendix. It's about setting up a program that is appropriate for your institution, which I believe we have done.

Auditors and examiners have read our policies and procedures and have never suggested we aren't doing enough.

That my friend is the worse case of false security a compliance officer can ever rely upon. This specific issue is heating up in the field. All you have to do is ask the 30 or so banks that I stay in close contact with.

How can you say you are confident in your data integrity without testing it????

That would be like saying: "Oh, I'm sure that all of our cash transactions are included in our cash aggregation reports because it is done through our core system."

I always appreciate your experience, and will consider it going forward.

For what it is worth, I agree with Randy. Check to see if there are dual controls around the data entry piece in ops; I can't imagine that the bank has no controls, but I have been surprised before.

It is more than that - see the post from JacksTigger above. You might think you know what your core is reporting, but do you really????

There are verification steps in place when a loan is set up on the system if that's what you are referring to. So loan type, collateral, etc. are all verified. Part of our existing policies and procedures.

But do I go in and pull the credit reporting history and check it against the very system that's spitting it out? No.

We have a follow-up review to ensure data used to "book" the loan is accurate. We also work the "reject" reports from the Credit Reporting Agencies that indicate any accounts the CRA was unable to report due to an error/inconsistency. If anyone is doing additional testing, would you give a brief description of what you're doing?

Randy,
Our bank has a policy entitled FACTA 312 and Credit Bureau Reporting. This policy was put in place back in 2010 prior to the FACTA 312 compliance date and includes all of our procedures regarding data integrity and testing. Based on your comment about dropping reference to FACTA, would you suggest we change the name of this policy to Regulation V? This policy goes to Board this month for annual review and this would be a good time to fix it if it needs fixing. Comments?

Regulation V includes a lot of things. If you want to refer to just the policy on accuracy and integrity, here is the regulation you could cite, 12 CFR 1022.42:

http://www.bankersonline.com/regs/12-1022/12-1022-042.html

We have double checks on what's entered into the system too. I reviewed the actual report that is sent to the bureaus and found our error. It was not an error anyone may have found without checking the actual report.

That would be my point. Just because you know what the loan looks like on your system has no bearing on what the coding might that is actually going to the credit bureaus.

If you think it does, you have placed way too much faith in your vendor.

How many other instances can you name where your core system was not doing what you thought it was doing? It happens all the time.

Just came across this discussion and been worrying about this as part of my monitoring. We are a small community bank with many new employees in new positions, myself included. At the risk of sounding like a total dimwit (a year in compliance has made me realize how dim I really am), JacksTigger, when you say, that you have double checks on what's entered into the system and then you reviewed the actual report sent to the bureaus and found the error,,, #1 what is the double check procedure at your institution? pull a sampling of loan files and audit how they were booked? and then comparing to the "actual report"
#2 where does the "actual report" come from? Your core provider produces such a report? My original question that lead me to this thread is concerning Re-Pollution. Is the monitoring of the prevention of inaccurate information being re-reported, a matter of the core providing a report a month after the dispute has been handled? Is that pretty much the same process of checking what the core/vender is doing? Any help is appreciated.

JacksTigger and rlcarey, please clarify for me. Are you verifying the loan "features" (type, collateral, amount, etc.) or are you verifying the payment history coding on the loan account over time? I'm talking about the payment history coding, not the "set up" of the loan. All that is already verified.

Our actual report comes from our core provider. It is prepared by them each month and then a copy is provided to us for our records.

When the loan is booked, one person enters the information and then another person verifies that it was entered correctly.

I checked the payment history coding (correct balance, correct last pay amount) I also verified that we had the correct "codes" to tell the bureau what type of loan--mortgage, HELOC, unsecured, auto etc. I also checked that we were reporting joint loans correctly--showing both borrowers and showing that both were liable for the loan.

Hope that helps.

OK - Let's try this approach.

The credit bureau information is submitted to the credit bureau using the coding as required under the coding scheme called Metro II. It includes person information about the customer, the type of loan, acct #s, payments amounts, histories, etc.

You think that just because your core processor takes the information from your core system that they code everything correctly???

That is like saying that you never look at the actual submission files for CTRs and SARs that you send to FinCEN because your core provider developed the reporting process.

I can't tell you how many errors I have uncovered. The bank says but we check this box on the entry screen and I have to say that's great, but the information is not being transmitted to FinCEN.

Both your responses are helpful, thank you for explaining a bit further.