Credit Union LOS RFP: The 25 Questions You Must Ask Every Vendor

Most credit union LOS RFPs are written by people who have already decided which vendor they want. The questions are structured to confirm the preferred vendor's strengths. The evaluation criteria are weighted after the scoring to produce the desired outcome. And the procurement process serves as documentation for a decision already made rather than as a genuine evaluation.

This is not cynicism - it is a pattern Cornerstone Advisors has identified repeatedly in community financial institution technology evaluations: many evaluations don't start with a baseline for desired improvement, defining the problems to be solved, the functionality needed to address those problems, and what metrics will measure success.

When the RFP is not grounded in specific problems and measurable success criteria, vendors answer the questions with marketing language, procurement teams score on features rather than fit, and the institution selects the most impressive demo rather than the most capable platform. Implementation reality surfaces the gap.

This guide is a working RFP tool - 25 specific questions organized by evaluation category, each with an explanation of what you are actually testing and what a strong versus weak response looks like. Use these questions to structure your RFP, sharpen your demo evaluations, and give your procurement team the framework to evaluate responses rigorously rather than impressionistically.

One caveat before the questions: the most important thing you can do before issuing an RFP is complete your internal alignment on what problems you are solving and what success looks like. Vendors answer the questions you ask. Make sure your questions reflect what actually matters to your institution.

These are not questions for vendors. They are questions your procurement team, VP of Lending, and COO need to answer before you issue the RFP - because the RFP questions that follow only produce useful answers if your team knows what it is evaluating against.

What are the three most operationally painful problems with your current LOS? Not categories - specific problems. "Policy changes take too long" is a category. "When the credit committee approves a threshold change, it takes 3–4 weeks to go live because we need IT involvement and a vendor release cycle" is a problem.

What is your current digital application abandonment rate? If you do not know it, add this to the first question you ask your current vendor.

What is your core banking system, and what is the integration method your current LOS uses? Certified program? Custom API? File transfer? This determines which vendors' RFP responses are actually meaningful for your institution.

What loan products do you need to originate in the next 36 months, including products you do not currently offer?

What does an acceptable implementation timeline look like given your internal capacity?

These answers become the evaluation lens through which every vendor response is read.

These are the questions with the most operational consequence. The integration with your core determines whether every other capability the LOS offers actually functions in your environment.

Question 1: What is your specific integration method with [our core banking system - name it explicitly]? Is it a certified vendor integration program (e.g., Jack Henry VIP for Symitar, Corelation's partner ecosystem for KeyStone), a custom API build, or a file-based transfer?

What you are testing: Whether the integration is maintained by program infrastructure (vendor-maintained, compatible through updates) or requires ongoing engineering attention from the LOS vendor or your IT team. This is the single most important integration quality question.

Strong response: Specific program certification named (Jack Henry VIP, Corelation partner ecosystem), with a description of what the certification covers and how compatibility is maintained through system updates.

Weak response: "We integrate with Symitar" without specifying the method. "We have a robust API integration" without naming the program. Evasion about maintenance responsibility.

Question 2: Walk us through the funded loan booking workflow - specifically what data fields transfer from your LOS to our core, how mapping errors are caught, and what happens when a field fails validation.

What you are testing: Whether the loan booking integration includes field-level validation (errors caught in the integration layer before writing to the core) or simply transfers data and discovers errors in the serviced loan record after funding.

Strong response: Description of specific field mapping, validation rules that catch errors before core write, and notification process when validation fails. Willingness to demonstrate this live, not in a canned demo.

Weak response: "Data transfers seamlessly at funding" without specifics. Demo that shows a successful booking without ever demonstrating error handling.

Question 3: Does your integration with our core include bidirectional real-time member data access at application intake - pulling existing member account data to pre-fill applications and feed the decisioning engine?

What you are testing: Whether the integration is one-directional (LOS pushes funded loan data to core) or genuinely bidirectional (core relationship data also flows into the LOS for pre-fill and decisioning). One-directional integration means existing members re-enter information the credit union already has.

Strong response: Specific description of what member data is pulled from the core at intake (membership tenure, existing balances, account standing, contact information) and how it is used in the decisioning model.

Weak response: Confirmation that integration exists with no detail on data flow direction.

Question 4: What happens to your integration with our core when either your platform or our core releases a major update? Who is responsible for maintaining compatibility, and what is your documented SLA for restoring integration function if it breaks?

What you are testing: Maintenance accountability. This is the question that separates certified program integrations from custom builds.

Strong response: Named maintenance accountability (program infrastructure for certified integrations; LOS vendor engineering team for custom builds), specific SLA for compatibility restoration, and a history of how recent major updates (e.g., Symitar's last major release) were handled.

Weak response: "We maintain close relationships with core vendors" without specific maintenance accountability or SLA.

The NCUA hired three AI officers for 2025–2026 and is actively examining AI governance frameworks. These questions are not optional - they are the compliance evaluation criteria that determine your regulatory risk exposure with each vendor.

Question 5: When your AI decisioning engine generates a denial, show us the adverse action notice that would go to the member. Where specifically did each reason code come from - the model's actual attribution output or a post-hoc checklist?

What you are testing: Whether adverse action reason codes are derived from the AI model's actual decision logic (SHAP values or equivalent attribution method) or from a generic checklist applied after the decision. The CFPB has explicitly stated that AI-driven decisions must produce specific, accurate adverse action reasons reflecting actual decision factors - a checklist is non-compliant.

Strong response: Demonstration of an adverse action notice alongside the model's attribution output, showing a direct mapping between the attributed factors and the reason codes. Specific description of the explainability methodology (SHAP or equivalent).

Weak response: Demo of an adverse action notice without connection to model attribution. Statement that the system is ECOA-compliant without explanation of how reason codes are generated.

Question 6: Provide documentation of disparate impact testing conducted on your AI decisioning model. What populations were tested, what methodology was used, what were the findings, and was a Less Discriminatory Alternative (LDA) search conducted and documented?

What you are testing: Whether the vendor has conducted and documented the pre-deployment fair lending analysis that the CFPB now explicitly requires - including the LDA search. This is the documentation NCUA examiners are requesting when examining credit unions that use AI in lending.

Strong response: Specific disparate impact testing documentation: populations tested (credit union member data or comparable), methodology (four-fifths rule, regression analysis, matched pairs), findings, LDA analysis documentation, and how the results informed the current model configuration.

Weak response: "Our model is fair and unbiased" without supporting documentation. Testing documentation that does not include an LDA analysis.

Question 7: How many of your credit union clients have had NCUA examination findings related to adverse action compliance or AI governance in the last 24 months?

What you are testing: The vendor's production compliance record. An honest answer reveals actual examination performance. Evasion reveals that the vendor does not track this - or that the answer is unfavorable.

Strong response: A specific number (ideally zero), with a description of the compliance architecture that produces that outcome.

Weak response: "We are not aware of any findings" (which may mean they do not track it). Refusal to answer. A pivot to marketing language about compliance capabilities.

Question 8: When the CFPB or NCUA issues new guidance that requires a change to how your platform generates adverse action notices or compliance disclosures - who is responsible for implementing that change in your platform? What is your documented timeline and process?

What you are testing: Whether regulatory update compliance is the vendor's operational accountability or the credit union's configuration project. This is the distinction between a vendor-maintained SaaS platform and a platform that shifts compliance change management to the institution.

Strong response: Vendor responsibility with specific timeline (e.g., within 60 days of effective date), notification process to clients, and recent examples of regulatory updates implemented.

Weak response: "We notify clients of changes and provide configuration guidance" - which means the credit union implements the changes itself. No documented timeline.

Question 9: Can your platform handle AI-driven decisioning and ECOA-compliant adverse action simultaneously - without a separate process for generating reason codes after the decision is made?

What you are testing: Whether ECOA compliance is an architectural property of the decisioning system (reason codes generated at the moment of decision from model attribution) or a post-processing workaround (reason codes assembled manually or from a separate system after the decision).

Strong response: Confirmation with architecture description and demonstration.

Weak response: "Yes, we handle both" without explanation of the architecture. Demo that shows decisioning and adverse action as separate workflows.

Question 10: Provide your most recent SOC 2 Type II report - specifically the report from the independent CPA firm, not a vendor-produced summary. Which Trust Services Criteria does it cover, and what exception findings were identified?

What you are testing: Security governance depth. SOC 2 Type II (not Type I) is the operational security standard for cloud financial services platforms. Exception findings reveal how the vendor's security culture responds to control failures - their presence is not disqualifying, but the remediation response is revealing.

Strong response: Willingness to share the full report, coverage of Security criterion plus Availability and Confidentiality, and clear documentation of exception remediation.

Weak response: SOC 2 Type I instead of Type II (point-in-time assessment, not operational). SOC 2 summary produced by the vendor. Refusal or significant delay in providing the report.

Question 11: Demonstrate what happens when a member starts a loan application on mobile and continues at a branch. Show us the loan officer's screen when the member arrives. Does the member's in-progress application appear? Does the member have to re-enter any information?

What you are testing: True omnichannel continuity versus multichannel support. Most platforms support multiple channels - few preserve application session state across channel switches.

Strong response: Live demonstration (not a canned demo) showing the in-progress mobile application appearing in the branch interface with all entered data preserved.

Weak response: "Our platform is omnichannel" without demonstrating cross-channel continuity. Demo of each channel separately without demonstrating the handoff.

Question 12: It is Thursday afternoon. Our credit committee just approved a change to our Tier B auto loan DTI threshold from 43% to 46% for members with 24+ months of tenure. Walk us through exactly how that change gets implemented in your system, who does it, and when it goes live in production.

What you are testing: The true speed and ownership of policy changes. This is the most revealing configuration test in any LOS evaluation.

Strong response: Business user opens the relevant rule set in the interface, adjusts the threshold, tests the change in a sandbox against historical data, and deploys through a maker-checker approval workflow - without an IT ticket or vendor involvement. Timeline: Friday morning.

Weak response: Any answer that involves IT, a change request, a vendor support ticket, or a deployment window. Timeline longer than 24 hours.

Question 13: What categories of credit policy changes can lending staff make independently through your interface, without IT or vendor involvement? Provide a specific list.

What you are testing: The real scope of no-code configuration versus what is positioned as no-code in the demo.

Strong response: Specific list: credit score thresholds, DTI limits, LTV rules, pricing tier conditions, product eligibility criteria, stipulation rules, referral routing logic, counter-offer parameters, and disclosure templates - all through a business user interface.

Weak response: Vague claims about "configurable workflows" without specifying what business users can and cannot change independently.

Question 14: Show us a demonstration of your pre-fill capability for an existing member - specifically what data is pulled from our core at the start of a new application and how it is populated in the form.

What you are testing: Whether pre-fill is bidirectional (core data flows into the LOS at intake) or unidirectional (the LOS only pushes data to the core at funding). Pre-fill from core data is the single largest contributor to abandonment reduction for existing members.

Strong response: Live demonstration of member lookup at application start, showing specific fields pre-populated from core data (name, address, existing accounts, membership tenure, contact information) with the member validating rather than re-entering.

Weak response: "We support pre-fill" without a live demonstration. Pre-fill limited to name and contact fields without pulling relationship data.

Question 15: What is your digital application completion time for an existing member with all information pre-filled? Show us this timed.

What you are testing: Whether the platform's member experience achieves the sub-5-minute completion threshold that research identifies as critical for abandonment reduction.

Strong response: Timed demonstration showing an existing member completing a consumer loan application in under 5 minutes with pre-fill active.

Weak response: Inability to demonstrate a timed completion. Completion time above 8 minutes. Demo that uses pre-filled forms without explaining what data came from the core vs. what was manually entered.

Question 16: Who will manage our implementation? Can we speak with that specific person before we sign? Describe their current workload - how many simultaneous implementations are they managing?

What you are testing: Whether implementation is assigned to dedicated, experienced project management or to a shared support queue. The implementation project manager's experience and capacity is the single largest determinant of implementation success.

Strong response: Named individual, willingness to schedule a call before contract execution, and transparent disclosure of current project load.

Weak response: "You will be assigned an implementation manager at project kickoff." Inability or unwillingness to name the person before contract signing. Implementation manager managing more than four simultaneous full-scope implementations.

Question 17: Describe your sandbox implementation methodology. How long does the sandbox period last, what does validation look like, and what are the criteria for approving production cutover?

What you are testing: Whether the implementation includes genuine sandbox validation (adverse action outputs reviewed, TILA calculations verified, core integration tested, edge cases evaluated) or a compressed "configure and go-live" approach.

Strong response: Defined sandbox period (minimum 4 weeks for standard implementations), specific validation checklist including compliance output review and core integration testing, and defined go/no-go criteria for production approval.

Weak response: "We use a staging environment for configuration" without defining the validation scope or criteria. Implementation timeline that does not include a defined sandbox period.

Question 18: What is your parallel run protocol? How long does it run, what is compared between the legacy system and the new platform, and what conditions trigger extending or ending the parallel run?

What you are testing: Whether the implementation includes a genuine parallel run (both systems processing loans simultaneously, outputs compared) or whether parallel run is treated as optional. Skipping the parallel run is the most reliable way to discover critical integration errors after they have affected real members.

Strong response: Defined parallel run period (minimum 2–4 weeks), specific comparison criteria (funded loan data accuracy, adverse action output comparison, cycle time benchmarks), and defined conditions for early termination or extension.

Weak response: "Parallel run is optional" or "we recommend a phased rollout instead." No defined parallel run protocol.

Question 19: Share your last 12 months of P1 incident data - system-down events, response times, root causes, and resolution times. What was your worst incident and how was it resolved?

What you are testing: Actual platform reliability versus uptime claims. A vendor who cannot or will not share this information has not made operational transparency a priority.

Strong response: Specific incident log, documented response times versus SLA commitments, root cause analysis for material events, and post-incident process improvements.

Weak response: "We maintain 99.9% uptime" without supporting data. Refusal to share incident history. "We are not aware of any significant incidents" without documentation.

Question 20: Provide a complete 5-year total cost of ownership model including all licensing fees, implementation costs, per-loan or per-user fees, integration maintenance costs, compliance update costs, and any additional module or feature fees. What events trigger pricing changes during the contract term?

What you are testing: Whether the vendor is transparent about the full cost of the relationship or structures pricing to obscure the long-term cost.

Strong response: Complete TCO model with all fee categories, confirmation of fixed pricing for the contract term (or clear escalation mechanism), and disclosure of all trigger events for additional fees.

Weak response: Licensing fee only, with other costs described as "TBD based on scope." Annual escalation clauses without a stated cap. Per-loan fees that compound significantly with volume growth.

Question 21: What are our data portability rights at contract termination? In what format is our data provided, within what timeframe, and at what cost?

What you are testing: Whether exit barriers are embedded in the contract terms - making switching expensive or practically difficult.

Strong response: Complete data export in an open, machine-readable format (CSV, JSON, or equivalent) within 30 days of termination at no additional cost. Specific file format documentation.

Weak response: Data export available "upon request" without defined format or timeframe. Data export fees. Data provided in proprietary formats that require vendor tools to read. Significant hesitation in answering this question.

Question 22: What are your contractual SLA commitments for uptime, P1 response time, and regulatory update implementation? What financial penalties apply when these commitments are missed?

What you are testing: Whether SLA commitments have financial consequences (contractual obligations) or are aspirational statements.

Strong response: Specific uptime percentage (99.9%+) with financial service credits for shortfalls, P1 response time commitment (30 minutes or less), and regulatory update SLA (60 days or less for material regulatory changes) with service credit remedies.

Weak response: SLA commitments without financial consequences. P1 response time commitments measured in hours rather than minutes. No regulatory update SLA in the contract.

These are the questions that reveal the most - and the ones vendor sales processes are designed to avoid.

Question 23: What would the credit union that had the worst implementation experience with your platform tell us? Walk us through what went wrong, what caused it, and what you changed as a result.

What you are testing: The vendor's relationship with accountability and its willingness to learn from failures. Every platform has had a difficult implementation. A vendor who claims otherwise is not being honest. A vendor who can describe a failure, its causes, and the structural changes made in response is demonstrating the institutional maturity that matters for a long-term relationship.

Strong response: Specific account of a difficult implementation, transparent description of root causes, and concrete process or platform changes made in response.

Weak response: "We work very hard to ensure every implementation is successful." Inability to describe any significant implementation challenge. A pivot to case studies about successful implementations without answering the question.

Question 24: What does your platform currently not do well - for credit unions specifically - that is on your development roadmap?

What you are testing: The vendor's self-awareness about limitations and the credibility of their roadmap. Every platform has gaps. A vendor who can honestly describe their current limitations for credit unions - and what they are specifically doing about them - is a vendor who understands their own product. A vendor who claims no meaningful gaps is a vendor whose self-assessment should not be trusted.

Strong response: Specific limitations acknowledged (for example: "Our indirect lending dealer network integrations are less mature than our direct lending capabilities, and we have [X] on the roadmap to address this"), with evidence of past roadmap delivery (features delivered in the last 12 months that were previously on the roadmap).

Weak response: "We are always improving" without specifics. A pivot to capabilities rather than an answer to the question. Claims of no significant gaps.

The RFP generates responses. The responses require a scoring framework that evaluates substance rather than production quality. A well-formatted vendor response document that does not answer the specific questions is a weaker response than a direct answer to every question - regardless of how much design work went into the packaging.

Score on specificity, not comprehensiveness. A vendor who provides a 200-page response document that does not address Question 6 (adverse action attribution) with a specific, demonstrable answer has not answered Question 6. Score zero for that question regardless of the volume of surrounding content.

Require live demonstration for Questions 11, 12, 14, and 15. These four questions cannot be answered adequately in writing - they require live platform access with your team present. Schedule a separate demonstration session specifically for these questions, using a structured scoring sheet.

Conduct reference calls with specific questions. Generic reference calls - "tell us about your experience with this vendor" - produce generic answers. Bring specific questions: How long did implementation actually take versus the projected timeline? What happened the first time your core updated after go-live? Who do you call when something breaks? Would you choose this vendor again?

Weight categories according to your specific situation. A credit union on Symitar planning to remain on Symitar should weight Category 1 (core integration) heavily. A credit union with a recent NCUA adverse action finding should weight Category 2 (AI and compliance) most heavily. A credit union whose primary pain point is digital abandonment should weight Category 3 (member experience) most heavily. The weight distribution should reflect the problems your credit union is solving, not a generic evaluation rubric.

Mistake 1 - Issuing the RFP before completing internal alignment. An RFP written without agreement on the problems to be solved and the success metrics produces responses that cannot be evaluated against a standard. The internal alignment questions at the beginning of this guide should be completed and agreed upon before the RFP document is issued.

Mistake 2 - Scoring on feature completeness rather than fit. A vendor who claims every capability on the RFP checklist does not necessarily outperform a vendor who honestly identifies two gaps and explains how they will be addressed. Evaluate whether the capabilities the vendor claims actually work in your operational environment.

Mistake 3 - Demo-based evaluation without live environment testing. Demos are controlled. The four demonstration questions in Category 3 of this guide should be evaluated in a live environment - not a canned demo with staged data. Require live access to the platform with your own test scenarios.

Mistake 4 - Not investigating post-go-live support before contract execution. The implementation team and the post-go-live support team are often different people. Ask specifically: who is our named contact after go-live, what is their response time commitment, and can we speak with them before signing? A vendor who cannot answer this question before the contract is executed will not answer it more clearly after.

Mistake 5 - Accepting vendor compliance claims without documentation. "Our platform is NCUA-compliant" is not documentation. The adverse action attribution source (Question 6), the disparate impact testing record (Question 7), and the SOC 2 Type II report (Question 11) are the documents that substantiate compliance claims. Require them before scoring the compliance section.

Mistake 6 - Not building a scoring rubric before issuing the RFP. Scoring rubrics built after responses arrive are unconsciously calibrated to make the preferred vendor win. Build the rubric first - assign weights to each category and scoring criteria for strong versus weak responses - before evaluating any vendor submission.

Algebrik One was built for credit unions that evaluate seriously - and these questions are the ones the platform was designed to answer directly, not deflect.

Questions 1–4 (Core Integration): Algebrik holds Jack Henry Vendor Integration Program certification for Symitar (April 2025) and a certified Corelation KeyStone integration. The maintenance responsibility sits with the program infrastructure. Bidirectional member data access at application intake is native to the platform. References from Symitar and KeyStone credit unions are available.

Questions 5–10 (AI and Compliance): Adverse action notices are generated from actual AI model attribution through Scienaptic AI's SHAP-based explainability layer - not from a post-hoc checklist. Scienaptic AI's 150+ credit union clients have maintained a 100% NCUA audit pass rate. Disparate impact documentation, LDA analysis, and model governance records are available. Regulatory updates are Algebrik's engineering responsibility.

Questions 11–15 (Member Experience): Live omnichannel continuity demonstration available with actual cross-channel session preservation. Policy change from Thursday approval to Friday morning production deployment - demonstrable live. Pre-fill from Symitar and KeyStone core data pulls specific member relationship fields at application intake.

Questions 16–19 (Implementation): Named implementation project manager available for a call before contract execution. Sandbox-first methodology with defined compliance validation criteria and go/no-go criteria before production cutover. Parallel run protocol with specific comparison criteria.

Questions 20–22 (Financial and Contract): Complete 5-year TCO model available. Data portability provisions are standard in Algebrik's contract terms. Uptime SLA with financial service credits. Regulatory update SLA of 60 days for material changes.

Questions 23–24 (Hard Questions): We will answer Question 23 honestly - including the implementation experience that taught us the most about what credit unions need that we had underbuilt. And we will answer Question 24 with the same specificity. We believe that honest self-assessment is the basis for a genuine vendor partnership. We are not the right platform for every credit union in every situation. We want to be the right platform for the credit union that is right for us.