MeridianLink Portal

Overview

MeridianLink builds cloud software for banks, credit unions and mortgage lenders. Founded in 1998 and based in Costa Mesa, California, it served more than 1,900 institutions by 2021. Portal is its point-of-sale front end: the screens an applicant uses to apply for a loan or open an account, wired to MeridianLink Consumer and MeridianLink Opening behind them.

I worked on Portal from August 2022 to September 2024 as a software engineer at Bhavna Software India, building customer- and partner-facing screens and the ASP.NET Core APIs behind them. The highlighted part of the map below is where that work sat.

1. Where applications start

   Applicants, members, dealers and brokers

   • Online (this case study)
   • Mobile (this case study)
   • Branch
   • Indirectauto dealers
   • Brokers and TPOs

2. Point of sale

   The application front end

   • MeridianLink Portal (this case study)succeeded by Access, Oct 2023
   • Mortgage Accessmortgage point of sale

3. Origination

   Systems of record for loans and accounts

   • MeridianLink Consumerconsumer loan LOS
   • MeridianLink Openingdeposit account opening
   • MeridianLink Mortgagemortgage LOS, formerly LendingQB
   • PriceMyLoanpricing and eligibility engine

4. Around it

   Hundreds of partners through the MeridianLink Marketplace

   • Core banking
   • Credit checks
   • Identity and fraud
   • eSignature
   • Document management

The platform in numbers

16M+

auto loan applications

8M+

unsecured loan applications

5M+

new accounts opened

1M+

home loan applications

Lifetime figures published on meridianlink.com, read October 2026. They describe the platform, not my work.

Impact

Five things that changed for the people on either side of an application. Each row names the problem, what I did about it, and which layers of the stack the work went through.

The product

An applicant's path through Portal, from the first screen to a submitted application.

What it is

MeridianLink's point-of-sale front end for loan applications and deposit account opening, used by community banks and credit unions. It connects behind the scenes to MeridianLink Consumer and MeridianLink Opening.

Applications and workflows

Configurable fields, multi-product applications in one session, post-submission cross-sell logic, pre-qualification and pre-approval rules, and built-in validation to cut manual work.

Applicant experience

Prefill, save-and-resume, document upload, in-session identity verification and eSignature, and single sign-on so a member can apply for another product without re-entering anything.

Where it went next

In October 2023 MeridianLink launched Access, a fully configurable successor, and the product page now presents Portal's role through Access. My work was on Portal, from 2022 to 2024.

Lender console · Incomplete applicationsRedrawn · fictional data

Swipe to see the whole screen.

Screens

Two screens of Portal, drawn for this page with fictional data: the application on a phone, and a two-product application on a laptop. Pick a callout to see which part of the screen it explains.

Screen 1 of 2

The application on a phone

Jump to a screen

123456789

Full size

Prefill, custom questions, documents, identity and eSignature in one flow.

Three steps of a vehicle loan application as an applicant sees it on a phone: known details prefilled for a member, a lender-defined question, inline validation, document upload, identity verification in session, the signature, and a pre-qualified offer after submit.

1. 1Save and come backSave-and-resume keeps the application, so a phone call or a dead battery is not an abandoned loan.
2. 2Progress you can seeConfigurable, mobile-first flows I built: each step is configuration, and the applicant always knows how far is left.
3. 3eSignature in the flowThe applicant signs on the same screen, timestamped, with no printing or second visit.
4. 4Prefill for membersKnown details are filled for existing account holders and marked, so they check instead of retyping.
5. 5Documents from the phoneDocument upload in the flow, with the file confirmed on screen, stored behind the API in Azure Blob Storage.
6. 6Custom questionsLenders add their own fields and questions per product; the shared core components render them the same everywhere.
7. 7Identity in sessionVerification runs through a partner without sending the applicant elsewhere.
8. 8Cross-sell after submitA pre-qualified offer appears once the application is in, and accepting it reuses everything already entered.
9. 9Validation that helpsErrors appear at the field, in plain words, before submit, built into the reusable input components.

Role

• Software engineer at Bhavna Software India, on MeridianLink's products from August 2022 to September 2024.
• Created core components, and coded across HTML, CSS, JavaScript (ES6 and later), TypeScript, React, C#, VB.NET and ASP.NET Core.
• Wrote maintainable, testable code with NUnit and Moq.
• Worked with the client on requirement analysis for stories and tasks, system design, and product enhancements.
• Managed deployments and monitoring through Azure Monitor and Azure Blob Storage.

Constraints

• Mobile-first flows that still had to cover identity verification, document upload and eSignature end to end.
• A security bar appropriate to a top US FinTech vendor, with Azure Blob Storage and Azure Monitor in the deployment path.
• Legacy VB.NET and MSSQL systems that had to be extended, not replaced.
• Applications submitted here land in Consumer and Opening, so every field had to mean the same thing on both sides.

Architecture

A mobile-first UI with configurable forms and cross-sells, over an ASP.NET Core API that owns workflow automation, with EF Core on MSSQL for application records. eSignature, identity verification and the MeridianLink Consumer and Opening products plug in alongside.

Key decisions

• Configurable application flows. Forms, cross-sells and verification steps are configuration, so a lender can change a journey without a release.
• Reusable React components. One component set across modules kept the UI consistent and let modules used by thousands of applicants ship on time.
• Request-cycle optimisation. API bottlenecks were addressed at the request and response level rather than hidden behind loading states.
• Working with the US teams directly. Refining legacy interfaces into modern ones went faster when the people who owned the old behaviour were in the conversation.

How I worked

Straight from the client

Requirement analysis for each story and task happened with MeridianLink directly, so system design and enhancement ideas came from the people who own the product.

Sprint rhythm

Feature planning, sprint discussions and peer code reviews, with work tracked in Jira and designs handed over in Figma.

Tested as it ships

Unit tests in NUnit with Moq for the services behind each change.

AI assistants, used deliberately

GitHub Copilot and ChatGPT to speed up feature work, troubleshoot issues and support code reviews.

Results

A smoother, more automated application experience aimed squarely at reducing drop-off: modules I delivered on my own, used by thousands of applicants, on one shared component set over faster APIs.

1,000+

end users on modules I delivered

5

applicant steps built into one flow

2

years on the MeridianLink stack

Stack

• ASP.NET Core
• C#
• VB.NET
• Web API
• EF Core
• MSSQL
• React
• TypeScript
• JavaScript (ES6+)
• NUnit + Moq
• Azure Blob Storage
• Azure Monitor
• Jira
• Figma