The Feedback Loop in Reverse: What One Consent Order Says About Your Risk Assessment

Fintech and payments partnerships are one of the few ways a community bank can offer what the largest banks offer, at a price its customers will pay. That line of business matters. It also changes the bank’s risk profile the day a new partner goes live, whether or not the risk assessment notices.

An OCC consent order made public in May 2026 shows what happens when it does not.

What happened

The OCC signed a consent order with Community Federal Savings Bank, a New York institution of roughly $866 million in assets that acts as a sponsor bank for fintech partners, on April 24, 2026. The order described a payments line that had grown since 2020 without the controls to match.

Among the deficiencies the OCC cited:

• Alert filtering criteria and thresholds had not been tuned to the risk profile of the payments line, despite significant growth in higher-risk products and international exposure.
• An automated triage system closed a very high percentage of alerts that should have been escalated.
• The bank had not adequately understood certain customers’ businesses or the purpose of their transactions.
• The bank had not determined whether it maintained correspondent accounts for foreign financial institutions, so it could not show compliance with the related due diligence requirements.
• Independent testing had not identified the weaknesses or tested the high-risk areas.

Why it is a risk assessment story

On RiskRator’s October 8 webinar, Cody J. Smith, CPAML, called it the feedback loop in reverse. In a healthy program, monitoring output flows back into the risk assessment and tests whether the institution’s picture of its own risk is still accurate. Here, the monitoring system was quietly discarding the very data the risk assessment needed to see.

The remediation tells you where the OCC located the root cause. The order requires a written, institution-wide, ongoing BSA/AML risk assessment that weighs the impact of the bank’s activities, product lines and third-party relationships, based on appropriate data and information, including products, customer types, customer risk ratings, transaction types and volumes, and geography.

Based on appropriate data and information is the phrase that matters. An assessment built from questionnaires and last year’s assumptions cannot see a payments line that has outgrown its controls. One built from the bank’s actual transaction data can.

You can outsource the operation, not the risk

Cody framed the lesson with a paraphrase of FATF Recommendation 17, which governs reliance on third parties: you can outsource the operation, but you cannot outsource the risk. The bank remains responsible for every risk that flows through a partner’s program, whatever the contract says about who runs the monitoring.

Andrea Valentin, Chief Risk Officer at Maxwell State Bank, described how orders like this one shape her own work, speaking for herself rather than her employer. The answer is not a single approach to every vendor. It is risk tiering inside third-party risk management, clean data, and a framework for every supporting process, from onboarding to disputes. The best monitoring system in the world will not hold up if the processes around it treat every partner the same.

Three questions to ask this quarter

1. When did your risk assessment last change because of a partner? If you have added a fintech, payments or correspondent relationship since your last assessment and the risk profile did not move, the assessment is describing a different bank. The proposed FinCEN and Federal Reserve AML/CFT program rules both point toward updating the assessment when the risk changes, not on a calendar.

2. Do your thresholds have a story? Andrea’s standard: if the monitoring team cannot explain why a threshold exists and what it is doing for the bank, it is not good enough. A threshold set before a partner launched cannot have a story about that partner.

3. What is your automation closing? Automating alert disposition to manage volume is exactly what drew the OCC’s attention here. Automate the assembly of data. Keep the judgment human.

For the full framework behind these questions, read Risk Assessment vs. Transaction Monitoring: Why Your BSA/AML Program Needs Both.

How RiskRator fits

RiskRator assesses the bank’s own exposure, including the exposure that third-party relationships bring in, using the bank’s transaction data. When a partner goes live or volumes shift, the assessment can be rerun and the risk profile updated, so the loop between monitoring and assessment stays closed.

Watch the full webinar replay · See how RiskRator works

Frequently asked questions

What did the OCC cite in the Community Federal Savings Bank consent order?

Among other findings, alert thresholds not tuned to the payments line’s risk, an automated triage system that closed a very high percentage of alerts, controls that did not keep pace with growth, and weak independent testing.

What does the OCC require a bank to do about its risk assessment after an order like this?

In this case, prepare a written, institution-wide, ongoing BSA/AML risk assessment that considers products, third-party relationships, customer types, transaction volumes and geography, based on appropriate data and information.

Is a bank responsible for risk in its fintech partners’ programs?

Yes. FATF Recommendation 17 and US supervisory practice place ultimate responsibility on the bank that relies on a third party.

How often should the risk assessment change when a bank adds partners?

Whenever a new partner, product or channel meaningfully changes the risk profile. Waiting for the annual cycle leaves monitoring calibrated to a bank that no longer exists.