Regulation 504 and The Evolving Compliance Landscape

On June 30, 2016, the New York State Department of Financial Services (“NYS DFS”) issued the final version Rule 504, “Banking Division Transaction Monitoring and Filtering Program Requirements and Certifications.” The Rule takes effect on January 1, 2017, with the first reporting date of April 15, 2018. In a sense, the Rule follows upon the Office of the Comptroller of the Currency’s Bulletin 2011-12 and the Board of Governors of the Federal Reserve’s Supervisory Regulation Letter SR 07-11, while adding significant qualifiers to the validation process.

Filtering Programs have occupied a prominent place in a financial institution’s (FIs) systems environment – especially US Branches of FBOs – since the early 1990s. Transaction Monitoring Systems grew in implementations after the tragedy of 9/11 and the enactment of the USA Patriot Act, which required monitoring for suspicious activity. During the course of the annual Bank Secrecy Act (BSA)/Anti-money Laundering (AML) Examinations, the regulators, both federal and state, grew in awareness of deliberate abuses of the systems, as well as unintentional, or perhaps intentional, ignorance on the part of financial institutions, foreign and domestic. These abuses led to significant fines as exemplified by:

During the regular independent reviews as required by the federal guidance, the reviewing parties exposed deficiencies in the monitoring and filtering systems installations. The deficiencies varied from institution to institution, but centered on data validation between the core systems and the monitoring and filtering systems, setting of thresholds and other parameters, model governance, lack of institutional knowledge concerning the proper use of the systems, and lack of tie-in of the models to the institution’s BSA/AML/OFAC Risk Assessment.

The DFS Rule 504 adds to the federal guidance by requiring an annual certification by a senior officer of the financial institution that the transaction monitoring and filtering programs comply with the provisions stipulated in the Rule. These provisions are extensive and expansive. The Rule puts forth eight specific attributes for the transaction monitoring system, a separate additional five attributes for filtering programs, and another eight attributes, common to both. The following table presents a very brief summary of the attributes:

One can see that the Filter Program attributes correspond to the equivalent Transaction Monitoring Program attributes. In addition to the requirements listed above, the Rule contains other stipulations, as follows:

The Rule stipulations reflect a proactive initiative by the DFS, designed to eliminate deliberate or accidental abuses of the monitoring systems and make money laundering and the financing of terrorists as difficult as possible. It behooves any institution falling under this regulation to begin a thorough review of the covered systems without delay.

Some Good News

For those who have followed the development of the Rule from the Notice of Proposed Rule-Making to the final version, the DFS made several modifications enabling some to give a sigh of relief:

– The certification sign-off was removed from the Chief Compliance Officer and assigned to a Senior Officer, who may – or may not – be the CCO;

– The stiff mention of penalties in the proposed Rule was softened to “[t]his regulation will be enforced pursuant to, and is not intended to limit, the Superintendent’s authority under any applicable laws.” [504.5] Take note: the possibility of criminal penalties pre-existed the Rule, so they continue to lurk in the background, mentioned or unmentioned.

– The original 504.3(d) stated that no financial institution may set its thresholds to meet its workforce resources, etc. (paraphrased). As noted above, it now addresses changes and remediation efforts.

Potential Pitfalls

The Rule has a broad-reaching character and includes all facets pertaining to a standard model validation and then some. Unfortunately, it also contains elements of ambiguity and subjectivity.

Certification

The Certification process makes crystal clear to covered institutions the responsibility to bring monitoring and filtering programs into compliance with the Rule. Given the complexity of those programs, even the most basic programs, and the multiplicity of the moving parts, it is certainly possible for an institution to know that it is 95% compliant, but not 100%, owing to some one of the moving parts needing remediation. But the wording of the certification states, “We are compliant to the best of our knowledge.”

So, hypothetically of course, an FI knows it isn’t compliant, but then what. Filing a positive “we are,” while knowing “we aren’t,” would constitute willful falsification. What is the institution to do? I think we will find out, probably sooner than later.

Risk-based

Risk-based evaluations are a constant theme in BSA/AML/OFAC speak. FIs develop, implement, manage, report on, etc. their systems on a risk-based approach. The problem with that approach is that it is by nature ambiguous and open to wide-ranging interpretation, very much a half-full/half-empty glass scenario. Even with the ample guidance found in the FFIEC BSA/AML Examination Handbook, subjectivity is unavoidable, leaving sufficient room to be wrong.

Funding

Section 503(c)6 refers to “funding to design, implement and maintain a … Program that complies with the requirements …” Another area of ambiguity. How does one gauge the appropriateness of the level of funding? What yardsticks apply? What guidelines?

Re-living the Past

It is a certainty that there are some institutions who, in their haste to implement monitoring/filtering systems, did not construct a Business Requirement Document (“BRD”), or conduct pre- and post-implementation end-to-end testing, or User Acceptance Testing (“UAT”) prior to the implementation. Once the systems are implemented and in production, one cannot go back to conduct pre-implementation testing. But as an FI, I have to certify that I did.

Hosted Systems

Firms that conduct Independent Validations and Verifications (“IVVs”) have encountered a reluctance from vendors of “hosted systems” to permit access to the related databases for the data mapping and validation exercises. Self-validation by the vendor may not suffice in Rule 504. Institutions that utilize hosted systems may find themselves caught in the dilemma of having to validate a system without a system to validate. As an alternative approach, the institution may require the vendor to provide a locally installed test system for validation purposes.

Looking Ahead

Fortunately, we are at the beginning of the cycle. In a few months, the Rule will take effect and the DFS field examiners will begin to evaluate the readiness of the entities under examination. The pitfalls in the Rule will become evident over time so that the covered institutions will have time to adjust their programs and prepare for the certification process.