Credit routing infrastructure: separate orchestration from underwriting

What is a credit orchestration platform?

A credit orchestration platform coordinates how an application is collected, checked and handed to a banking institution. In the model described for FABA Finance, the platform orchestrates distribution while the bank underwrites. Keeping that boundary explicit gives the product and the engineering team a common language.

FABA’s published project scope covers credit origination, scoring, institution routing and interfaces for borrowers and banks in the UEMOA region. The architecture recommendations below develop the implications of that scope. They do not describe confidential implementation details or establish regulatory requirements.

Separate the application from the institution decision

An application may be incomplete, ready for submission, sent to an institution or awaiting a response. An institution may then request more information, decline or issue an offer. These are different facts with different owners.

A practical platform model preserves the original application and records each institution handoff separately. It should be possible to explain where an application is, which actor is expected to act and what information was available at the time of a handoff.

Make that explanation useful to both the borrower and the operator. A status such as “in progress” can hide very different situations: waiting for a document, waiting for a bank response or recovering from a failed integration.

Keep institution adapters at the boundary

Different institutions may use different fields, eligibility inputs and response formats. A recommended approach is to keep the platform’s application vocabulary coherent, then translate it through a dedicated adapter for each institution.

The adapter should make unsupported fields, validation errors and ambiguous responses explicit. If a response cannot be safely mapped to a platform status, send it to a defined operational review path rather than inventing a result.

Routing rules also need identifiable ownership. Record which version of a rule was used and why a destination was selected. This is a technical design recommendation for explaining platform behavior, not a recommendation to approve or reject an applicant.

Design the failed handoff before adding another bank

What happens when an institution receives an application but the platform never receives confirmation? Automatically sending it again may create a duplicate. Marking it as failed may hide an application that the institution is already processing.

Agree on the reconciliation behavior with the integration partner. Preserve submission identifiers, attempts and the latest known state. Give the operator a way to distinguish a safe retry from an unresolved result. This is where the product’s operational model needs to meet the API contract.

The AWS Well-Architected Framework is a useful starting point for reviewing reliability tradeoffs. The actual implementation should follow the institution contract and the consequences of a missed or repeated handoff.

Make data access explicit

A bank dashboard must not infer permission from an application identifier. OWASP’s object level authorization guidance calls for authorization checks on the requested record and action. For a platform connecting institutions, that means identifying which actor can read, change or export which application data.

Define data handling and retention with the institution, security and legal teams responsible for the operating model. This article addresses engineering boundaries. Those teams must establish the applicable financial and legal obligations.

What should a first integration prove?

Prove one complete application lifecycle: collection, validation, handoff, response and an operator resolving an exception. Keep the history understandable. Then add institutions against an integration contract that the team can explain and test.

The architecture is doing its job when the next handoff is predictable and an uncertain outcome is visible to the person responsible for resolving it.