Building the bank's credit eligibility microservice
The bank was replacing a slow, manual credit check process with a new central platform. They brought us in as a development and QA partner for a microservice in a larger multi-vendor programme — a defined scope inside their architecture, with room to raise technical concerns, discuss changes with their architects, and ship production-ready code with solid QA.
- IndustryBanking & financial services
- Project typeBuild · Team extension
- Team4 people
- Duration6+ months
A leading European financial group modernizing credit eligibility at scale.
A leading European financial group — retail, SME, and corporate lending across several markets, millions of customers, and dozens of connected systems: Core Banking, CRM, credit bureaus, AML/KYC, risk tools, and analytics.
- Millions of customers across several European markets
- Credit eligibility spread across CRM, Core Banking, bureaus, AML/KYC, and risk systems
- Enterprise architects owned the Decisioning Hub design; scope split across internal squads and vendors
- Regulated environment — full audit traceability required on every eligibility check
Five systems, one eligibility check.
Before the new platform, checking whether a customer was eligible for a loan meant opening CRM, Core Banking, credit bureaus, AML/KYC, and internal risk tools — then manually comparing everything against rules scattered across applications.
Slow, hard to scale, and weak on audit. Regulators and internal audit need to see exactly which data was used and which rule produced the result — a manual checklist across five systems cannot provide that reliably.
The bank's enterprise architects designed a new Decisioning Hub and split the work across many teams and vendors. They assigned us a microservice inside the Credit Eligibility & Decisioning domain — build the logic, connect to specified systems, record everything for compliance, and pass QA before production.
- Platform architecture owned by the bank — we delivered inside their design and contributed input where our scope was affected.
- Multi-vendor programme — daily coordination with internal squads, integrators, and other external partners.
- Regulated banking — full audit traceability required on every eligibility check.
- Business rules defined by the bank's credit risk and lending teams — we implement, they specify policy.
How our piece fits.
The bank's architects owned the platform design. Our job was to build a microservice inside it — with an active voice when specs, integrations, or validation did not match production reality.
Bank-owned architecture. Our scope: a microservice and QA inside a regulated multi-vendor programme.
Defined scope — with pushback when it mattered
The bank decided what our microservice would do and how it fits the wider platform. We built, tested, and shipped that component — and flagged problems early when the spec and production reality did not match, working with architects to agree changes before coding the wrong thing.
Eligibility rules as implemented logic
Lending and risk teams defined the criteria. We built validation, rule processing, and structured results in .NET — FluentValidation on input, business rules on enriched data — and updated when requirements changed after sprint reviews.
Integrations, resilience, audit, and QA
REST and SOAP through a shared integration library with retry and timeout in our code. Idempotent handling for duplicate eligibility requests. OAuth/SSO authentication on the service; RBAC enforced at the bank's API gateway per programme standards. Structured audit records for every check and rule evaluation, plus functional, integration, and regression testing through UAT and go-live.
Retry and timeout on every outbound integration
CRM, Core Banking, bureaus, and AML/KYC calls went through a shared integration library with retry and timeout configured in our code — so transient downstream failures were handled at the service boundary, not passed through as silent errors.
Idempotent eligibility requests
Duplicate submissions for the same eligibility check did not re-run rules or create conflicting audit entries — required for a production decisioning path where retries and double-clicks happen in the real world.
Auth on the service; RBAC at the gateway
OAuth/SSO authentication was implemented on the microservice we delivered. Role-based access was enforced at the bank's API gateway per programme standards — not reinvented inside our scope.
Three roles, four people, embedded for more than 6 months.
A technical lead, 2× senior .NET backend engineers, and a QA engineer — working inside the bank's architecture, in daily coordination with product owners, enterprise architects, integration teams, and other vendor squads on sibling components. See how we work for the delivery model.
Team
3 roles · 4 people
- Technical leadFull-timeImplementation within the bank's design, coordination, code review, technical workshops and architect discussions
- 2× Senior .NET backend engineerFull-timeMicroservice development, business logic, REST/SOAP integrations, validation
- QA engineerFull-timeTest scenarios, functional/integration/regression testing, UAT support
Stack
What we shipped.
Our contribution — the microservice and QA. Programme-wide outcomes are below — enabled by every squad in the programme, including ours.
Shipped a production-ready microservice inside the bank's Credit Eligibility & Decisioning platform.
Implemented eligibility business logic as specified by lending and risk teams.
Production integration layer — REST/SOAP via shared library with retry, timeout, and idempotent requests; OAuth/SSO on the service.
Full audit traceability — every check and result recorded for compliance review.
Functional, integration, and regression testing with UAT and production go-live support.
What the Decisioning Hub — with our microservice inside it — enabled.
One place for eligibility checks instead of operators jumping between five systems.
Automated rule execution instead of manual comparison against scattered criteria.
A proper audit trail instead of reconstructing decisions from notes and screenshots.
Less manual work for credit operators — a process that scales with digital lending volume.
One of the things we appreciated most was how quickly the team understood both the technical and business context of the project. They worked closely with our internal teams and other vendors, took ownership of their scope, and delivered reliably throughout the engagement.
This is you if…
- You need more development capacity and you know what you want built.
Your architects or leads have the design, your backlog has the scope. You need engineers who take a defined piece, build it, integrate, test, and ship — embedded in your team and process, not in a silo.
- You want engineers who push back, not a body shop that says yes to everything.
Specs are sometimes wrong, APIs change, requirements shift mid-sprint. You need a team that raises problems early and talks to your leads — not one that quietly builds the wrong thing.
- Your internal team is stretched and you cannot hire fast enough.
A release has hard dates, or a domain service needs dedicated backend + QA for months. You need senior capacity plugged in quickly — stand-ups, refinement, and release coordination from day one.
Scope defined, deadlines real, internal team stretched — we embedded for more than 6 months and owned our piece end to end. Same model whenever you need senior engineers inside your team, not beside it.
Need a senior .NET squad embedded in your team?
We plug into your process — stand-ups, refinement, releases — and own a defined scope end to end: build, integrate, test, ship. Banking here; same engagement in fintech, enterprise IT, or any product where you need senior capacity without the hiring lead time.