Credit Decision Engine: An RFP Checklist for Lenders

Last updated: September 2026

A credit decision engine RFP should describe what the credit team must be able to do after migration, because an RFP written from today's integrations, data fields and rule counts buys a faster copy of the current system. Write each requirement as an outcome, ask every provider to show it on your data rather than describe it, and set the weights before the responses arrive. Make a proof on your own applications a condition of the shortlist. Put the terms for in-flight applications, historical decisions and parallel running into the RFP itself, while you still have leverage.

TL;DR

• An RFP copied from the current system's integrations, fields and rule counts carries that system's limits into the new contract. Write requirements as outcomes the credit team must achieve after migration, and list integration constraints separately.

• Ask each provider to show every capability on your data or in a working session. A demonstrated capability scores above a described one.

• Agree the weights with compliance, credit, risk and technology before any response arrives, and score the must-haves pass or fail.

• Make a proof on your own applications a condition of the shortlist: a backtest on past applications and a true shadow on live ones, with success criteria both sides sign before it starts.

• Settle in the RFP how in-flight applications are treated, where historical decisions will live, how parallel running ends and how you would exit.

• The RFP is where third-party due diligence starts. The June 2023 interagency guidance on third-party relationships is in force as of 28 September 2026, but the agencies proposed a replacement on 11 September 2026, so check which version applies when your RFP goes out.

What does a credit decision engine RFP need to get right?

A credit decision engine RFP needs to describe the operating model the lender wants after migration, because requirements copied from the current system buy a faster version of it. The RFP should contain six parts: requirements written as outcomes, questions that make each provider demonstrate those outcomes, weights set before responses arrive, a proof on the lender's own applications as a condition of the shortlist, reference checks, and migration and cutover terms.

A credit decision engine is the system that runs the data calls, rules, models and policy that turn each credit application into a decision and the reasons for it. How an engine works is covered in what a decision engine is and does; this guide is about buying one.

The RFP is often one of three workstreams that run at the same time. A vendor risk and project manager at a bank described them as "parallel tracks that we can do simultaneously": "fleshing out the RFP is one set," the third-party risk management review is another, "and then also the proof of concept." Write the RFP to feed the other two, with the due-diligence questions the risk team will ask anyway and the proof terms the shortlist will be held to.

If the team has not yet decided whether to build or buy, settle that before writing the RFP, which assumes the answer is buy.

Why RFPs end up specifying the system you're replacing

Requirements usually start from the documentation of the current system, because that is what the team has on hand. Its integrations, data fields and rule counts get copied into the RFP as requirements, and its habits come with them. A BSA officer at a bank, planning the replacement of a compliance system, named the habit to watch for: data mapping done "the easy way" and by "this is what we've always done," which the officer called "a phrase that's around here that we need to kill."

The requirements document that results is often generic, and nobody owns it. Asked whether a business requirements document existed for the platform under evaluation, a growth lead at a digital-asset company answered, "We have a very generic one," and said it "needs to get more granular specific, especially like to... what is the risk tolerance, what kind of controls we want to have in place?" The company was also hiring "a person that will be responsible for this flow," which is the right fix: an RFP needs an owner who can say what the credit team must be able to do.

Some of the rigidity in the system being replaced was designed in at purchase, by the buyer and the provider together. An SVP and director of AML and sanctions at a large regional bank, describing the bank's AML system, said "both the client and the vendor were complicit in certain design situations," and that the result was "very hardwired": "you've got to take it to the dealership to get that thing done on the engine. You can't do it yourself." An RFP written around today's build repeats that choice for the next engine.

The cost of that rigidity shows up whenever the credit team wants a change. At one large regional bank, a credit executive said a brand-new card policy took months end to end, much of it spent on testing. A director of financial crimes at a card issuer said "every change request is an astronomical amount of money," and that the team was looking for "a system that is so much self-service because we literally can't take the change requests anymore."

None of this means the current system is broken, and an RFP that describes it as broken costs the buyer credibility. A senior director of credit at a digital bank, drafting a business case, said "we are in a pretty good state with [our current system]. So it's not broken," and planned to reword a current-state assessment that showed "limited capability, no capability," because "if I put this business case in front of execs, they're going to say what the heck I've been doing, right?" Describe today's system accurately, and make the case from what the operating model after migration needs.

One way to keep the requirements pointed forward is the method an operations lead on the credit and collections side at a digital financial-services firm described: "a requirements or spec doc" covering what it would take to meet the team's needs in-house, compared against "a contrast document with everything that's already ready made" from providers. Build the requirements document from the capabilities the credit team will need, and use the contrast to see which providers already meet them.

Signs that an RFP is describing the old system:

• Requirements name today's integrations, fields or rule counts instead of what the credit team must be able to do.

• The requirements document is a generic template, or nobody owns it.

• Every change the requirements describe assumes the provider makes it.

• The current state is written up as broken when it is not.

• Migration terms are left for the statement of work.

Write requirements for how you'll operate after migration

Write each requirement as an outcome a named team must be able to achieve after migration, and name the evidence you will accept. The table below rewrites nine requirements that RFPs commonly copy from the current system.

The capabilities worth wanting in the first place are covered in what to look for in a credit decisioning platform. The RFP's job is narrower: to turn those needs into requirements a provider must meet with evidence.

Each rewrite names who must be able to do what, which is something a provider can be asked to demonstrate.

Policy change and testing come first because that is where the time goes. A credit executive at a large regional bank said "the big lift is always the testing which I think is manual," with teams that "construct test cases manually, but then trigger different branches of the policy to make sure that the policy is implemented as intended." The requirement should ask for what a head of credit risk strategy at a large regional bank described: "rerun it through the decision engine and we see the impacts on everything, that's so much quicker to do."

The record of each change belongs in the engine, because change evidence gets audited. An implementation lead at a bank, describing the start of auditing ahead of a launch, said "every new change now require[s] a change request, which is a [ticket]." Require the engine itself to keep that record: who changed what, when and with whose approval. A separate ticketing tool leaves the evidence somewhere else.

Overrides need the same treatment. A senior commercial lender at a community bank asked during an evaluation, "Is there a way to do overrides inside of this? Or do you have to live inside the credit policy once you put this in?" The OCC's Comptroller's Handbook booklet Lending and Loan Portfolio Risk Management (July 2026) describes loan booking as generally including "capturing exceptions to policy and ongoing monitoring requirements for tracking and reporting purposes," so write that capture into the requirement.

Explanations are a legal obligation, so they belong in the requirements. Regulation B requires the statement of reasons for adverse action to "be specific and indicate the principal reason(s) for the adverse action" (12 CFR 1002.9(b)(2)), and where a consumer report contributed, FCRA section 615(a) adds its own notice content, including the credit score if one was used. The test the engine has to pass is the one a credit lead at a card issuer set: "I needed to make sure I... could tie it back to the... decisioning."

Write the decision record as a requirement too. A risk leader at a bank recalled its regulators saying "you need to validate what's there" and asking the bank to "start sending us every app and every data point that goes into that decision, so that we can verify the decision engine." That is one bank's account of what its supervisors asked for, and it makes a good test of the requirement: any decision can be rebuilt from its inputs, the policy version that ran and the reasons it produced.

Testing has to happen on the engine being bought. When backtesting and monitoring run in a data warehouse separate from the decision engine, as they do at one digital lender, the team is testing a copy of its policy instead of the engine that makes the decisions. For champion-challenger testing, specify a true shadow on live applications and consistent assignment, because a returning applicant who lands in a different test arm contaminates the comparison.

State the application volumes and query needs in the RFP, and ask for performance and storage cost at that scale, so the price reflects your scale. Adding a data source should not require re-platforming. If consumer-permissioned bank data is part of the plan, write the requirement so it does not depend on the timetable of the CFPB's personal financial data rights rule under Section 1033, whose compliance dates are stayed by court order while the CFPB reconsiders the rule, as of September 2026.

If models will be built or monitored on the engine, name the tooling in the requirement. One consumer lender's list for its provider covered sampling and weights, reject inference, holdout testing, stability and discrimination measures such as PSI, KS and AUC, how adverse action reason codes are derived from a model, characteristic analysis, and a choice of algorithms. If the lender brings its own models, require a stated path for deploying and monitoring them.

Say what the decision engine owns and what stays in the loan origination system. One consumer lender keeps every decision on its engine but keeps contract generation and signing outside it, and treats the platform strictly as a decision engine.

Add one requirement about the future: a new model, data source or strategy reaches production without new infrastructure. Integration constraints such as the core, the streaming platform and the bureaus are real, and they belong in a separate list, so a provider cannot answer an outcome with an integration diagram. A partnerships strategy manager at a card issuer traced the limits of an on-premises platform to its architecture and named what it lacked: "the ability to back-test, the ability to beta-test different things." Those abilities are what the requirements should name.

The RFP checklist: questions to put to every provider

Each question below asks the provider for a demonstration on your data or in a working session. Lift the groups into the RFP and add your own must-haves. A BSA officer at a bank kept one question in play throughout an evaluation: "have we asked the next question to the vendor?"

Ask of every capability whether it is live today or on a roadmap. A director of financial crimes at a card issuer, recalling a pitch about an "AI centric model that's going to be applied to our legacy systems," asked: "that ever happened? I'm looking at a system from years ago."

Policy change and control

• Which capabilities in your response are live today, and which are on a roadmap? Will you commit the roadmap items we depend on in the contract?

• Show a credit analyst changing a cutoff, testing it and releasing it, with none of your staff involved.

• Who can approve a policy change, and where is that approval recorded?

• How are overrides made, what limits apply, and where does each exception to policy appear in reporting?

• Which changes need your team after go-live, and what do they cost?

Testing and the proof

• Rerun a sample of our past applications through a changed policy and show the impact before release.

• Show a new policy running in true shadow on live applications, and show where the shadow decisions are recorded.

• How do you keep a returning applicant in the same test arm?

• Will you run a proof on our own applications before contract, on the terms in this RFP, and is there a limit on how long it can run?

• What data do you need for the proof, in what form, and how do you run it when we cannot share full data?

Explanations and adverse action

A chief risk officer at a card issuer set the standard for this group: "I need to be able to explain why we chose these thresholds. And if my explanation is because [the vendor] told us to, it's not going to go over very well."

• Show the reasons your engine produces for these sample declines, and trace each one to the step that declined the application.

• Send your full reason-code list, with a plain-language definition of each code.

• Show the credit-report factors reaching the adverse action notice on a declined application that used a report.

• How are reasons produced when a model contributes to a decline?

• What documentation will let us explain our own thresholds and cutoffs without relying on you?

Data and integration

• Which data sources are connected today, and what does adding a new one involve?

• Quote performance and storage cost at the application volumes and query needs in this RFP.

• How do we export our decision data, and in what format?

Models and monitoring

A model risk management leader at a regional bank described the order validators expect: "We would need to validate it before... first line implements it and runs it."

• Which components of your engine do you treat as models, and what documentation comes with each?

• What will our validators receive for each model you supply, and when?

• How do we deploy and monitor a model we built ourselves?

• What does monitoring watch after go-live, and who sees the alerts?

Decision records and audit

• Rebuild this past decision for us: its inputs, the policy version that ran and the reasons it produced.

• What does a change record hold, and can we export it for an examiner or auditor?

• How long are decision records and the information used to reach them kept, and in what form?

Security, resilience and third-party due diligence

• Provide your information security documentation, and your operational resilience and business continuity arrangements.

• How do you report incidents to us, and on what timetable?

• Which subcontractors touch our data or decisions, and how will you tell us about a new one?

• Provide your financial condition and insurance coverage.

• Which performance measures will you commit to in the contract?

Migration and cutover

• How do you treat applications already in flight at cutover, and at every later policy-version change? Answer in writing.

• What history moves from our current engine, in what form, and what stays behind?

• How will the two engines run in parallel, and what counts as an explained difference?

• Will production be built clean, or promoted from the proof environment?

• What do you need from our core, our origination system and our bureaus during migration and after it, by when, and who controls each connection?

Commercial terms and exit

• Price the proof, the implementation and the running cost before the proof starts.

• What support and credit expertise do we get after signing, and from whom?

• What flexibility do the terms allow if the service falls short?

• At termination, what notice, transition help, and return or destruction of our data and decision history do you commit to?

How to score and weight the responses

Set the weights on your vendor evaluation criteria before the responses arrive, so the scores reflect priorities agreed in advance. A fraud strategy lead at a neobank drafted a scorecard "with different weights" and then planned to "align with cross functional stakeholders on my weights," expecting the head of compliance to say "if you're going to make this investment, we must check [these] boxes." Let compliance name the must-haves, and score them pass or fail.

Give each area an owner. A partnerships lead at a fintech that serves community banks and credit unions described a scorecard split so that "different team members are owning usability and scalability, existing capabilities and switching costs, and vendor viability and business continuity." Switching costs and continuity belong on the scorecard alongside the features.

Score what a provider showed above what it wrote. A capability demonstrated on your applications, in a working session or in the proof, earns more than the same capability described in a response, and a roadmap item earns nothing until it is in the contract.

The weights matter most when two providers look even. A risk leader at a bank, describing a previous selection, called it "a coin toss. Both were very competitive and both were very good," and said the choice came down to members of the fraud team who "just preferred" the other provider "from a usability standpoint." Weights agreed in advance and a proof on your own applications are what separate providers who look alike on paper.

Hold every response to the same bar: complete and governed. A risk leader at a consumer lender described the goal as "not just a shiny object but an object that has all the guardrails and everything that are needed."

A pass/fail row is a gate: a provider that fails one is out, whatever it scores elsewhere.

Make a proof on your own applications a condition of the shortlist

A proof clause exists because buyers remember what implementation revealed last time. A stakeholder who owned contracts and regulatory exposure explained why a proof was being demanded: "The solution that we have right now is not what we would really like, right? So with that, we don't want to put ourselves into the same situation that we put ourselves into the last time that we purchased a tool and kind of got into the implementation and then realized that there were things that we just couldn't do."

A demonstration cannot settle that question. A CTO at a fintech lender said a proof "doesn't need to be a large exercise," only enough to answer one question: "does it actually work as well as in the beautiful demo, or did he wave his hands and make the whole thing up?"

Write the proof into the RFP as a condition of the shortlist, with these terms:

• Scope. A backtest on your own past applications and a true shadow on live ones. A credit risk technology lead at a consumer lender described the usual substitutes, "launching a model and calculating a score and then doing nothing with it... or having a champion challenger that we have at a low volume," and concluded "that's not true shadow scoring."

• Criteria signed before it starts. Fix the timeline, write success criteria both sides sign, and get an executive to agree in advance that meeting them means proceeding. How to write those criteria is covered in acceptance criteria for a proof of concept.

• What each side provides. Agree in writing what the proof must answer and what each side will supply. A risk leader at a bank traced a backtest still being done by hand to scope that was not pinned down at the start: "some misses on what is the capability of the system and what are we trying to accomplish."

• Duration and limits. State how long the proof runs, on what traffic, and what ends it. An integration lead at a fintech lender asked a provider directly: "Is there a limitation on your side for how long the POC can run?"

• Price first. Settle pricing and scope before the proof runs, so a technical pass does not stall on a budget surprise.

Settle the data terms with counsel and your privacy team before any data leaves the institution: which data, in what form, and under what agreement. Institutions handle it differently: a data and operations lead at a bank said it could provide real data but would "prefer to go ahead and do synthetic data" if that was faster, and that the information it had prepared "has been tokenized, so there's no disclosure or exposure of any personally identifiable PII or NPI." Ask each provider how it runs a proof when full data cannot be shared.

Be clear about what a proof can show before contract. It can show the decisions the engine makes on your applications, the reasons it gives, and how a policy change is made, tested and released. It cannot show long-run losses, which appear only after loans have had time to perform, so loss evidence comes from the backtest on past applications whose outcomes are already known. A fraud strategy lead at a neobank called a head-to-head proof for a platform decision "a bit of a heavy lifting," because a real read on one option against another would take many months.

The guide to the best credit risk decisioning platforms for lenders sets out how to run those tests on a shortlist: a backtest on past decisions, a challenger beside current policy, a check of adverse action reasons, a timed policy change, and monitoring agreed before go-live.

What to ask a provider's references

Reference calls are part of due diligence, so give them a place in the timeline. A project manager at a bank listed them with the rest of "vendor due diligence" and added, "I don't mean like get them out of the way, but it's something we have to do."

Ask for a reference that looks like you: the same kind of institution, similar products, and a move from a similar system. Ask for the specific problem each reference had and how it was solved. A credit risk lead at a card issuer said "I always struggle with certain things like, okay, average risk rates reduced," and preferred "a very specific problem that they were having before they came to you and how you solved this problem."

Ask how support and credit knowledge held up after signing. A head of credit strategy at a fintech lender, planning to leave its current provider, summed up the complaint as "lack of support, lack of knowledge, lack of everything," along with a refusal to let the lender go month to month.

Questions to put to each reference:

• What system did you move from, and what broke at cutover?

• What specific problem did you bring to this provider, and how was it solved?

• How did the delivery team compare with the sales team?

• How have support and credit knowledge held up since you signed?

• Which roadmap commitments arrived, and which did not?

• How long does a policy change take you now, and who makes it?

Put the migration and cutover terms in the RFP

Migration terms settled after the contract is signed are settled without leverage. Put them in the RFP, ask for written answers, and score them. Work through them in this order.

1. Applications in flight. Ask how applications already in progress are treated at cutover and at every later policy-version change, and require the answer in writing. An application that starts under one policy version and finishes under another needs a recorded rule for which version decided it.

2. Historical decisions. Regulation B requires a creditor to keep each application, "any other written or recorded information used in evaluating the application," and copies of the notice of action taken and any written statement of specific reasons, for 25 months after notifying the applicant for consumer credit and 12 months for business credit, with exceptions (12 CFR 1002.12(b)). Decide what history moves to the new engine, what stays readable in the old one and who pays to keep it readable, and treat the historical data load as a workstream from the start of the project. An engineering leader at a payments company that did not move its history still runs "a small instance of case management" from its former provider so that auditors can "still see those older cases." How the retention rule applies to a particular engine's records is a question for counsel.

3. Parallel running. Plan it backwards from the current contract. A BSA officer at a bank worked the new system's go-live date back from the end of the incumbent contract and its notice period, with a buffer for the year-end stretch when "nothing gets done," and an AVP of compliance risk strategy at a regional bank named the hard limit: "if we do want to do a true parallel run, right? It has to be before [the date the current system goes away]." Set exit criteria in advance and define what counts as an explained difference, since a new engine that matches the old one decision for decision has only reproduced it.

4. Production built clean. Build production fresh. A program lead running a vendor evaluation turned down the shortcut of promoting the proof environment into production, because a cutover plan always includes deleting test data, and "you never want to delete from a production environment."

5. Dependencies. Name every system the engine's data depends on, such as the core, the origination system and the bureaus, and who controls each. A chief BSA and operations officer at a bank whose core had just moved to an outsourced, managed service could not get the core provider's people, while all of the new platform's data had to come from that core. Sequence the switch against other programs too: a BSA and compliance program lead at a bank declined to start a second program during a platform migration already under way, because adding it at the same time "would create additional complexity and execution risk beyond what we're prepared to absorb today."

6. Phasing. If a whole book of lending products will move onto one engine, phase the move by product line and write the RFP for the whole book, including the products that move last. One consumer lender is consolidating its lending products onto one decision engine that way, one product line at a time, with its executive team watching progress.

7. Exit terms. State how the work transitions to another provider without prohibitive cost, and how your data and decision history come back to you, or are destroyed, on a timetable you set.

Once the new engine is live, each later change needs its own approval, testing and release discipline, which is covered in change control after the engine is live.

Third-party due diligence starts with the RFP

The June 2023 Interagency Guidance on Third-Party Relationships: Risk Management is the third-party risk management guidance in force for banks as of 28 September 2026. On 11 September 2026, the FDIC, the Federal Reserve, the NCUA and the OCC proposed replacement guidance, and once it is finalized the bank agencies plan to rescind the 2023 guidance and replace it, so check which version applies when your RFP goes out.

The 2023 guidance organizes third-party risk management into five stages: planning; due diligence and third-party selection; contract negotiation; ongoing monitoring; and termination. An RFP belongs to the due diligence and selection stage, with planning before it, and the guidance's overview is explicit about who stays accountable: "A banking organization's use of third parties does not diminish its responsibility to meet these requirements to the same extent as if its activities were performed by the banking organization in-house."

Under that 2023 guidance, as it stands on 28 September 2026, due diligence covers topics such as information security, operational resilience, incident reporting and reliance on subcontractors, and contract negotiation covers topics such as performance measures, an orderly transition at termination and the return or destruction of the bank's data. Put the first set into the RFP as questions and the second as terms, so providers answer and price them before selection.

A lender that sits inside a bank's group, or works through a partner bank, inherits that bank's process. A credit and collections executive at a bank-owned commercial lender explained that as a subsidiary of a bank, "any vendor that gets close to it has to go through the bank's vendor selection." A fintech lender usually meets the same process through its partner bank, so bring the bank's vendor management in when the RFP is written.

A provider's models also stay the lender's to understand. The revised interagency model risk management guidance of 17 April 2026 (Federal Reserve SR 26-2, OCC Bulletin 2026-13, FDIC FIL-15-2026) says banking organizations "may not receive from the vendor the underlying code, data, or methodology that they would have if a model were developed internally. Nevertheless, the principles of model risk management remain applicable." It says sound practice "includes developing an understanding of the vendor model, including its conceptual soundness, design, development data, and performance," along with "conducting ongoing monitoring and outcome analysis" of vendor models.

The same guidance defines a model as "a complex quantitative method, system, or approach that applies statistical, economic, or financial theories to process input data into quantitative estimates," and excludes simple arithmetic and deterministic rule-based processes that lack underlying statistical or economic theory. Which parts of a decision engine fall inside that definition is a judgment for the lender's model risk team, so ask each provider which components it treats as models and what documentation comes with each.

How Oscilar answers this RFP

Oscilar's credit underwriting pages state that teams can run backtests on historical data to validate new credit policies before deploying them, test how model performance changes across versions of a model, and manage approval rates, default rates and their own KPIs. Oscilar monitors data, feature and concept drift alongside outcome KPIs by segment.

For the decision-record and approval questions above, Oscilar's answer is a full audit trail per decision with stored reasoning, and human-in-the-loop by design. Its platform specification is decisions in under 100 milliseconds; like any provider's specification, test it on your own volumes in the proof.

Chartis Research named Oscilar to its 2026 FCC50, a ranking of financial crime and compliance technology vendors, with category wins for Agentic AI Innovation and Low-Code/No-Code Customization. The ranking covers financial crime and compliance technology, so it says nothing about how credit decision engines compare. Companies using Oscilar for credit and risk decisions include SoFi, Nuvei and Clara.

Frequently asked questions

How do you keep an RFP from locking in your current architecture?

Write each requirement as an outcome the credit team must achieve after migration, such as changing and testing a policy without a ticket to the provider, and keep integration constraints in a separate list. Ask every provider to demonstrate each outcome on your data. Describe today's system accurately, and make the case for change from what the operating model after migration needs.

Should the incumbent provider get the RFP too?

Yes, if the lender would genuinely consider staying. The incumbent's answers show whether the current engine can meet the operating model after migration, and holding it to the same proof clause keeps the comparison fair. If it cannot meet the must-haves, the RFP has documented why a switch is needed.

What can a proof show before contract, and what can't it?

A proof on your own applications can show the decisions an engine makes, the reasons it produces, and how a policy change is made, tested and released. It cannot show long-run losses, because those appear only after loans have had time to perform. Evidence on losses comes from the backtest, which runs on past applications whose outcomes are already known.

Does the 2023 third-party guidance still apply to a decision engine purchase?

Yes, as of 28 September 2026: the June 2023 Interagency Guidance on Third-Party Relationships: Risk Management is in force for the banks it covers, and a decision engine RFP is where its due diligence stage begins. On 11 September 2026, the FDIC, Federal Reserve, NCUA and OCC proposed replacement guidance, and the bank agencies plan to rescind the 2023 guidance once the new version is finalized. Check which version applies when your RFP goes out.

Can the old decision engine be switched off as soon as the new one is live?

Only once you have decided where its history will live. Regulation B requires creditors to keep applications, the information used to evaluate them and the notices sent for 25 months for consumer credit and 12 months for business credit, with exceptions, so history that does not move to the new engine has to stay readable somewhere. The RFP should say what moves, what stays and who pays to keep it readable.

Where to start on a credit decision engine RFP

Start with the requirements copied from today's system. Rewrite each one as an outcome the credit team must achieve after migration, attach the evidence you will accept, and agree the weights before the RFP goes out. Then add the proof clause and the migration terms, which are easier to settle before signing than after.

If Oscilar is on the shortlist, send it the same RFP and the same proof clause. The page on Oscilar's B2B credit underwriting describes how it handles commercial credit decisions.