The internal audit finding lands on a Tuesday. Your partnership API—the channel that lets fintech partners submit loan applications directly—has been approving applications against eligibility thresholds that were retired four months ago. The customer portal is current. The relationship banker tool is current. But when OCC guidance shifted your concentration limits, the update reached the partnership channel last, and for four months the same borrower could get a different answer depending on which door they walked through.
Now someone has to explain that to an examiner. Not why one loan went bad—why the bank's own systems disagree about what the rules are.
If you run engineering at a commercial lender, you've either lived some version of this or you know exactly where it's hiding in your stack. It's worth being precise about what kind of problem this is, because the instinct to treat it as a process failure is what keeps it recurring.
This an architecture flaw
Nobody on your team is careless. The eligibility logic—auto-approve if the loan is under $500K, DTI is at or below 43%, the business has operated for two-plus years with no defaults, and sector exposure stays within concentration limits—was implemented faithfully in every channel. The problem is the word every.
The portal was built first. The banker tool came two years later, built by a different team against a different service. The partnership API was stood up quickly to close a strategic deal. Each one needed eligibility logic, so each one implemented it. That's three independent copies of business logic that were identical on day one—and every copy drifts on its own schedule from the moment it exists.
When rules change (and in lending, they change constantly—regulatory guidance, credit policy updates, concentration limit adjustments), the change becomes three tickets, three sprints, three deploy windows. The gap between the first deploy and the last is a window where your bank is applying two different versions of its own credit policy. This is the scattered business logic problem we've written about across financial services, and lending is where it bites hardest.
In lending, logic drift exposes you to compliance risks
For most industries, inconsistent logic is an engineering annoyance. In commercial lending, it's two distinct regulatory problems.
The first is fair lending. If two substantially identical applicants receive different eligibility determinations because they arrived through different channels, that's not a bug report—that's a pattern examiners are specifically trained to look for. You don't get credit for the inconsistency being accidental.
The second is safety and soundness. Concentration limits exist so the bank doesn't quietly overexpose itself to a single sector. If the partnership channel is applying stale thresholds, your actual sector exposure is drifting away from your reported risk posture—and an internal audit finding it before the OCC does is the good outcome.
Here's the useful reframe: the regulator has already made the case for centralization. Every exam question about consistent rule application is an argument for having one rule to point to. You don't have to sell consistency internally. You have to deliver it architecturally.
Why the usual fixes don't hold
Most lenders have already tried the obvious remedies.
- Synchronized updates. Coordinate the three teams so changes ship together. This works until the fourth channel appears, or until one team's sprint slips, or until the change lands during someone's freeze window. Coordination is a process patch on an architecture problem.
- A canonical document. Write the rules down in one place; every implementation references it. But documentation doesn't fail obviously. Code drifts from the doc silently, and you discover the gap in an audit, not a code review.
- A shared library. Closer—the logic exists once. But a library still has to be versioned, imported, and redeployed by every consuming service. Version skew across services just recreates the drift problem one layer down, with deployment coupling as a bonus.
Each fix reduces the frequency of drift. None eliminates the possibility of it, because in all three, multiple running systems still each hold their own executable copy of the rules.
One governed rule, many consumers
The pattern that actually eliminates drift inverts the relationship: the eligibility rule lives in exactly one place, as a running service, and every channel calls it rather than copying it.
The portal, the banker tool, and the partnership API all become consumers of the same endpoint. A credit policy change is one change, made once, deployed once. It's versioned, so you know exactly which rule version made every historical determination. It's logged, so every decision—approval, decline, exception—lands in one audit trail. And there is no synchronization problem, because there is nothing to synchronize.
That's the concept. What separates a concept from a plan is whether it maps to the systems you actually run.
What this looks like in practice
Here's how this pattern is implemented on Xano, using a mid-size commercial bank as the model.
The backend is organized into four workspaces that mirror the lending lifecycle: loan applications, credit & risk scoring, underwriting workflow, and disbursement & servicing. Connectors handle the systems the bank already depends on—FIS for core banking data, Experian for credit bureau pulls, Plaid for income verification—and every decision event streams to Splunk for compliance audit logging.
The eligibility rule itself lives on the visual canvas: under $500K, DTI ≤ 43%, two-plus years operating, no defaults, sector exposure within concentration limits. Not pseudocode in a wiki, not logic buried across three codebases—the actual executing rule, rendered visually, where a compliance officer and an engineer can inspect it together and both understand what they're looking at. When the Chief Credit Officer asks "what are we actually applying in production right now," the answer is a screen, not an archaeology project.
The demo below shows the part that matters most to credit leadership: extending the governed layer without breaking governance. We build an exception routing endpoint—because in real lending, the exceptions are where risk concentrates. When an application falls outside auto-eligibility, the endpoint captures the regulatory exception with full justification, routes it by severity to the right approval authority, and logs every decision to Splunk with the rule version attached. The override process, which in most banks lives in email threads and tribal knowledge, becomes part of the same governed, auditable system as the rule itself.
[Embed demo video here]
Notice what didn't change: FIS is still the core. Experian and Plaid still do what they do. The channels keep their frontends. Centralizing the logic layer doesn't mean replacing the stack—it means the stack stops holding five opinions about your credit policy.
Back to the audit
Same examiner, same question: how do you know your eligibility rules are applied consistently across every origination channel?
Different answer: every determination—portal, banker tool, partnership API—resolves through one governed rule. Every decision in the log carries the rule version that produced it. Every exception carries its justification, its severity routing, and its approver. When guidance changes, there's one change record, one deploy, one effective date.
The question that used to take a war room to answer now takes a query. That's the difference between proving consistency and reconstructing it.
See it in your own stack
Watch the full demo above to see the four workspaces, the connectors, and the exception routing endpoint built end to end. Then talk to us to see how the pattern maps to your environment—we'll walk through the scenario using your actual tech stack. Thirty minutes, no commitment.
