Why Does Your Core Provider's Compliance Role Matter More Than Most Credit Unions Realize?
Regulatory compliance at a credit union is ultimately the institution's responsibility. The NCUA doesn't examine your core vendor; it examines you. That's a fact, and it's not going to change.
But the practical reality is that your ability to meet your regulatory obligations depends directly on what your core system does and doesn't do. The accuracy of your BSA/AML transaction monitoring depends on the quality and timeliness of the data your core produces. Your NCUA examination readiness depends on whether your core generates the reports examiners need in formats they can use. Your data governance posture depends on whether your core has a coherent model for where member data lives, who can access it, and how it moves between systems. Your ability to respond to a regulatory inquiry in hours rather than days depends on whether your core's audit trail is comprehensive and accessible.
When a core provider treats compliance as a checkbox, a set of features that exist in the platform but are the client's problem to configure, maintain, and use correctly, the compliance burden falls entirely on your institution. When a core provider treats compliance as a shared responsibility, maintaining regulatory currency proactively, flagging changes, producing documentation that supports your examination process, and being accountable for data integrity, your institution is in a fundamentally stronger position.
The question this post is designed to answer: what does the second model actually look like in practice, and how do you know whether your current provider is delivering it?
What Are the Core Regulatory Obligations That a Core Banking System Directly Supports?
Before defining what good looks like from a core provider, it's worth being specific about which regulatory obligations your core system directly touches. The list is longer than most credit union leaders realize.
BSA/AML Compliance
Your Bank Secrecy Act and Anti-Money Laundering program depends on transaction data that is accurate, complete, and delivered to your monitoring system in a timely manner. If your core produces delayed, incomplete, or inconsistently formatted transaction feeds, your monitoring program has blind spots regardless of how sophisticated your AML tool is. The core is the data source. Its reliability directly determines your monitoring program's reliability.
Specific core dependencies:
- Transaction posting accuracy and timing
- Customer Identification Program (CIP) data completeness and integrity
- Currency Transaction Report (CTR) threshold monitoring and filing support
- Suspicious Activity Report (SAR) documentation support
- OFAC screening data feed quality
NCUA Examination Readiness
NCUA examiners work from reports, data extracts, and audit trails that come primarily from your core system. An examiner who requests five years of member loan data, a specific transaction history, or documentation of a particular process should be able to receive that information cleanly and quickly. In practice, the quality of your core's reporting and data export capabilities directly determines how much staff time your examination preparation requires and how smoothly the examination itself runs.
Specific core dependencies:
- Call Report data accuracy and production
- Financial Performance Report accuracy
- Share and loan portfolio reports by examiner-specified parameters
- Member account history with a complete audit trail
- Risk concentration and liquidity reporting
Truth in Lending Act (TILA) and Regulation Z
Loan disclosure accuracy, APR calculations, payment schedules, and fee disclosures are a core system function. Errors in core-generated disclosures create regulatory findings and member remediation obligations that are expensive and time-consuming to resolve.
Regulation E and Electronic Fund Transfer Act
Error resolution processes, dispute documentation, and provisional credit workflows for electronic fund transfers all depend on accurate core transaction records and accessible audit trails.
Data Privacy and Cybersecurity Compliance
NCUA's cybersecurity expectations under the Information Security Program requirements, and state-level data privacy obligations, require credit unions to maintain clear data governance, knowing where member data lives, who can access it, and how it moves between systems. In a fragmented technology environment, this is harder than it sounds. In a well-integrated environment with a core that maintains a coherent data model, it's significantly more manageable.
CECL (Current Expected Credit Losses)
CECL compliance requires loan portfolio data that is accurate, consistently formatted, and accessible at the granularity your methodology requires. Core systems that make it difficult to extract clean, historical loan performance data create CECL compliance overhead that compounds over time.
What Should a Core Provider Actually Do for Compliance and What Should They Clearly Own?
This is where I want to be specific, because the line between what a core vendor should own and what a credit union should own is genuinely unclear in many vendor relationships, and that ambiguity almost always costs the credit union.
What Your Core Provider Should Proactively Own
Regulatory currency in the platform. When a regulatory requirement changes, a new NCUA rule, a FinCEN update to BSA reporting requirements, or a change to TILA disclosure calculations, your core provider should update the platform before the effective date, communicate the change to your team clearly, and document what was changed and why. You should not be discovering regulatory gaps in your core system during an examination.
The test: ask your current provider to show you the last three regulatory updates they made to the platform, what the requirement change was, and how they communicated it to clients. The quality and completeness of that answer tell you whether regulatory currency is proactive or reactive.
Audit trail integrity. Your core should maintain a complete, tamper-evident audit trail of every transaction, every account change, every user action that touches member data. That trail should be accessible, not buried in a database that requires vendor involvement to query. Examiners expect to see it. Your internal audit team should be able to use it without calling support.
Data integrity assurance. If your core is producing data that flows to downstream systems, your AML monitoring tool, your CECL model, your analytics platform, the accuracy of that data is your core provider's responsibility. Not the downstream system's. Not yours to validate manually. Your core vendor should be able to demonstrate, with documented testing processes, that the data it produces is accurate and complete.
SOC 2 Type II certification, maintained annually. A SOC 2 Type II report is the baseline third-party validation of a technology vendor's security and operational controls. It should not be optional, and it should not be provided on request only after you ask for it. Your core provider should maintain current SOC 2 Type II certification and make the report available to clients annually without being prompted.
Third-party audit support. When your institution's external auditors or the NCUA examination team needs information about your core system's controls, your core vendor should have a defined process for supporting those requests, not a vague commitment to be helpful. That means documented control descriptions, dedicated examination support contacts, and a track record of responsive engagement with auditors.
What Your Core Provider Should Never Leave Entirely to You
There's a category of compliance-adjacent responsibility that some core vendors treat as the client's problem entirely. In my view, that's a misallocation of accountability that puts smaller institutions at a systematic disadvantage.
Configuration guidance for compliance-relevant features. Your core system has compliance-relevant configuration options, CTR threshold settings, OFAC screening frequency, CIP field requirements, and Regulation E dispute workflow parameters. Your core provider should not simply provide these as configurable options and leave you to figure out the right settings. They should provide documented guidance on compliant configuration, flag when your current configuration creates regulatory risk, and update that guidance when requirements change.
Notification of regulatory gaps in the platform. If there is a known limitation in your core system that creates a compliance risk, a report that doesn't meet current NCUA format requirements, or a disclosure calculation that doesn't reflect a recent regulatory change, your core provider has an obligation to tell you before you find out from an examiner. Vendors who discover platform limitations and wait for clients to surface them are not compliance partners.
Examination finding remediation support. When an examination produces a finding related to your core system, a report that didn't produce the right data, a process that wasn't documented correctly, or a configuration that created an inconsistency, your core vendor should be an active partner in resolving it, not a resource you have to push to engage. That includes providing documentation, participating in follow-up calls with examiners when appropriate, and treating your examination findings as feedback on their platform.
How Do Fragmented Technology Environments Amplify Compliance Risk?
This is a dimension of the compliance conversation that doesn't get enough attention in vendor evaluations, and it's directly relevant to credit unions managing multi-vendor technology stacks.
In a tightly integrated environment, where your core, digital banking platform, and lending solution operate from a consistent data model, the data an examiner needs lives in one place, with one audit trail, governed by one data governance framework. Producing it is straightforward.
In a fragmented environment, the same data may live in three different systems, each with its own data structure, its own access model, and its own audit trail. When an examiner asks for a complete view of a member's loan application history, from initial inquiry through to account booking, assembling that record may require manual extraction and reconciliation from multiple systems. The margin for error is higher. The staff time required is significant. And the risk that data in one system doesn't match data in another creates a category of finding that well-integrated environments simply don't produce.
Specific compliance risks that fragmented stacks amplify:
- Inconsistent member data: When member records in the core don't match records in the digital banking platform due to sync delays or integration gaps, CIP compliance and OFAC screening can have blind spots.
- AML monitoring gaps: Transaction monitoring tools dependent on real-time or near-real-time data feeds from the core are compromised when those feeds are delayed or incomplete.
- Audit trail fragmentation: When a transaction touches three systems before posting, a complete audit trail requires assembling records from all three, a process that's manual, time-consuming, and error-prone.
- CECL data quality: Historical loan performance data distributed across systems with different data structures creates reconciliation overhead and potential accuracy issues in loss reserve modeling.
- Examination response delays: Requests that should be fulfilled in hours require days when data has to be pulled from multiple systems, transformed, and reconciled before it can be presented.
These aren't hypothetical risks. They're patterns I've seen produce examination findings at institutions that were doing everything else right. The root cause wasn't compliance negligence; it was an architecture that made data integrity harder to maintain than it needed to be.
What Questions Should You Ask Your Core Provider About Compliance?
Whether you're in a vendor evaluation or conducting an annual review of your current provider, these questions surface what a vendor's compliance posture actually is, rather than what their sales materials say it is.
On Regulatory Currency
- How do you communicate regulatory changes to clients, and how far in advance of the effective date?
- Show me the last three regulatory updates you made to the platform. What was the requirement change, and what did you change in the system?
- What is your process when a regulatory change requires client-side configuration updates, rather than platform updates?
- Have any of your clients received examination findings in the past two years related to platform limitations or delayed regulatory updates? How were those addressed?
On Audit and Examination Support
- What does your examination support process look like? Who is the point of contact, and what is the typical response time for examiner document requests?
- Can you provide a sample SOC 2 Type II report, and confirm that the current certification is maintained annually?
- If an examination produces a finding related to our core system, what is your process for supporting remediation?
- Do you have a dedicated team or contact for regulatory and examination support, separate from your standard support queue?
On Data Integrity
- How do you validate the accuracy of data feeds to third-party systems, AML monitoring, analytics platforms, CECL models?
- What is your documented process for detecting and resolving data integrity issues between your core and integrated platforms?
- How are audit trail records maintained, and are they accessible to our internal audit team directly or only through your support team?
- What is your data retention policy, and how does it align with NCUA examination and record-keeping requirements?
On Configuration Guidance
- Do you provide documented guidance on compliant configuration for compliance-relevant features, CTR thresholds, OFAC screening, CIP fields, and Regulation E workflows?
- When regulatory requirements change in ways that require configuration updates, do you proactively notify clients of recommended changes?
- Is there a compliance configuration review included in your standard client support model, or is that a separate engagement?
What Questions Should You Ask Your Core Provider About Compliance?
I want to be specific here, because the compliance question is one I hear from both current clients and prospects, and the answer matters.
At FLEX, regulatory compliance is treated as a platform responsibility, not just a client responsibility. That means a few specific things in practice.
Regulatory updates are proactive, not reactive. When a regulatory change requires a platform update, we communicate the change to clients before the effective date, document what changed and why, and provide guidance on any configuration updates required. We don't wait for clients to surface compliance gaps through examination findings.
SOC 2 Type II certification is maintained annually and made available to clients and their auditors without requiring a formal request. It's part of the baseline we hold ourselves to as a provider to federally regulated institutions.
Examination support is a defined service, not an ad hoc favor. When NCUA examiners need documentation related to our platform's controls, our team has a defined process for responding. When clients receive examination findings that relate to their core system, we treat those as shared problems, not the client's problem alone.
Data integrity between FLEX core and integrated platforms, Mobicint, Smart Lending, FLEXBridge, is tested as part of our release process, not assumed. The data that flows to downstream systems is our responsibility to validate, not our clients' responsibility to audit after the fact.
FLEX Ten, targeting production readiness by the end of 2026, is being built with these compliance commitments as architectural requirements, not afterthoughts. A next-generation SaaS core for community-focused credit unions has to make compliance easier, not more complicated, and that starts with data model coherence, audit trail accessibility, and regulatory currency baked into the deployment model itself.
If you're evaluating your current provider's compliance posture or comparing compliance support models in an RFP process, I'd encourage you to hold every vendor, including us, to the specific standards in this post. The ones who can answer those questions clearly and with evidence are the ones who have actually built compliance into how they operate.
Key Takeaways: What Regulatory Compliance Should Look Like for Your Core Provider
- Compliance is your responsibility, but your core provider's platform determines whether you can meet it. The data accuracy, audit trail integrity, and reporting quality your core produces directly determine your regulatory posture.
- Proactive regulatory compliance is not optional. Your core provider should update the platform before regulatory effective dates, communicate changes clearly, and document what changed and why.
- SOC 2 Type II certification is the baseline, not a differentiator. Any core provider serving federally regulated institutions should maintain current annual certification and make it available without prompting.
- Examination support should be a defined service. Ad hoc promises to be helpful are not the same as a documented process with designated contacts and defined response standards.
- Fragmented environments amplify compliance risk. Data distributed across multiple systems creates audit trail gaps, data integrity inconsistencies, and examination response delays that integrated environments avoid.
- Configuration guidance is a vendor responsibility. Compliance-relevant configuration options should come with documented guidance, proactive update notifications, and ongoing review, not just a settings menu and a manual.
- Data integrity is the core vendor's obligation. If your core produces the data that feeds your compliance programs, the accuracy of that data is their responsibility to validate and maintain.
Frequently Asked Questions
Is my core provider responsible if I receive a regulatory finding related to their platform?
Ultimately, regulatory findings are the credit union's responsibility; the NCUA examines you, not your vendor. However, a finding that results from a platform limitation, a delayed regulatory update, or a data integrity issue in your core system is a shared problem your vendor should actively help you resolve. A core provider who treats examination findings related to their platform as entirely your problem is not operating as a compliance partner.
What is SOC 2 Type II, and why does it matter for a core banking provider?
SOC 2 Type II is a third-party audit of a technology vendor's security, availability, processing integrity, confidentiality, and privacy controls, assessed over a period of time (typically six to twelve months). Unlike SOC 2 Type I, which assesses controls at a single point in time, Type II validates that those controls are operating consistently. For a core banking provider, the current SOC 2 Type II certification is the baseline evidence that its operational controls meet an independently audited standard. It should be a baseline requirement in any vendor evaluation, not a differentiator.
How should a credit union handle compliance obligations that span the core and a third-party system?
The first step is documenting who owns each compliance-relevant data flow. For every integration that touches member data or produces data used in a compliance program, AML monitoring, CECL modeling (included in FLEX), OFAC screening (included in FLEX), document which system is the data source, who validates the accuracy of that data, and what the escalation path is when a discrepancy is found. That documentation is useful both for your internal compliance program and for examination readiness. If your core provider and third-party vendors can't clearly answer those questions, that's a governance gap worth addressing before an examiner finds it.
How often should a credit union review its core provider's compliance posture?
At a minimum, annually, as part of your vendor management program. The review should include requesting a current SOC 2 Type II report, confirming that any regulatory changes since the last review have been reflected in platform updates, reviewing any examination findings from the prior year that related to core system performance, and assessing whether the vendor's examination support model has changed. Credit unions that conduct this review proactively are consistently better positioned in examination cycles than those that address compliance questions only when an examiner raises them.
What should a credit union do if its current core provider can't answer the compliance questions in this post?
Start by asking the questions in writing and requesting a response within a defined timeframe. Many compliance gaps in core provider relationships exist because the questions have never been formally asked, not because the vendor can't or won't address them. If the response is incomplete, vague, or not forthcoming, that's meaningful information for your vendor management file and your next contract renewal conversation. If you're in an evaluation, it's a disqualifying signal.
Most credit unions treat regulatory compliance as an internal responsibility and their core provider as a passive tool that processes transactions. That framing creates a compliance gap that's easy to miss until an examiner finds it. Your core provider should be a proactive compliance partner, maintaining regulatory currency in the platform, producing audit-ready reporting, supporting your NCUA examination preparation, and owning accountability for the data integrity that makes compliance possible. This post defines what that partnership should look like, the specific obligations your core vendor should be able to demonstrate, and the questions to ask if you're not sure whether your current provider is meeting that standard.
