How a US Mortgage Technology Startup Used Amazon Neptune to Unify Loan Origination Data for 30+ B2B Customers

Introduction

Our client was a US-based mortgage technology startup backed by a top-tier venture capital firm. Its goal was straightforward: build the API infrastructure layer that the US mortgage industry had never had. Getting a mortgage at the time took an average of 45 days and cost lenders over $9,000 per loan. The platform aimed to bring that down to 10 days and $1,000 by connecting every party in the origination process, loan servicers, brokers, banks, and credit bureaus, onto one platform where data could move without manual translation.

The execution was hard. Every customer connecting to the platform brought its own data sources, and every data source spoke its own language. A bank's data about a borrower's credit history looked nothing like a title company's data about a property, and neither looked anything like what a broker tracked about a transaction. The client needed a way to absorb all of it into a single, queryable layer without forcing every new customer through months of schema mapping first.

That requirement, handling structurally unpredictable data from five different industries inside one system, is what eventually led the client to Amazon Neptune graph database as the foundation of its data architecture.

Background: A Data Problem Relational Databases Couldn't Solve

Loan origination looks simple from a distance: a buyer, a seller, a property, a bank account, a credit rating. In practice, the entities involved and the relationships between them are far less predictable. A property might sit in a flood zone, which changes its risk profile. A buyer's co-signer might have an unrelated legal issue that affects the deal. These aren't edge cases that show up occasionally. They're the normal texture of real loan files, and there's no way to enumerate them all in advance.

That unpredictability is what ruled out the obvious database choices. A relational database requires the schema to be defined before the data arrives, which doesn't work when you don't know in advance what entities or relationships a given customer's data will contain. A document-oriented, non-relational option such as Amazon DynamoDB handles flexible storage well but isn't built for querying relationships between documents, and relationships were the entire point.

What the platform needed was a system designed around connections rather than fixed tables. That pointed toward a graph database.

The Challenge: Loan Data Doesn't Follow a Fixed Schema

The core business challenge was building a single platform that could ingest loan-related data from many different sources, each with its own data language, and make that data queryable in a unified way, without locking the system into assumptions about what the data would look like.

This created several compounding constraints:

• Schema instability. New customers meant new data sources, and each source could introduce entities or relationships the platform hadn't seen before.
• Relationship complexity. Some relationships were obvious (buyer owns property); others were indirect, conditional, or only mattered in specific risk scenarios.
• Cross-domain reuse. The same underlying data needed to serve servicers, brokers, banks, and credit bureaus, each asking different questions of it.
• Scale. As more customers connected, the dataset grew into hundreds of terabytes spread across 200 million+ data points, with relationships numbering close to a billion.

Graph databases carry a reputation in the industry for being harder to reason about than relational or document databases, mostly because fewer engineers have worked with one day to day. For a business problem defined by unpredictable relationships across multiple domains, that reputation didn't hold up in practice.

Solution Strategy: Why a Graph Database Was the Only Real Option

Perfsys evaluated the data problem against the constraints above and arrived at a decision-driven rather than feature-driven approach. The choice of engine mattered more than any individual feature.

The architectural decision: Use Amazon Neptune graph database as the system of record for loan origination data, modeled with RDF (Resource Description Framework) and queried via SPARQL rather than Neptune's Gremlin property-graph option.

Why RDF and SPARQL specifically: The existing lexicon for the loan domain, the vocabulary the client needed to express entities and relationships in, already existed in RDF form. Building on that lexicon meant the data model could express subject-predicate-object statements ("buyer has bank account," "seller owns property") in a way that mapped directly onto how the business already talked about loan data.

Why a graph database over the alternatives:

• Relational databases require the schema to be known upfront, which is incompatible with onboarding new, structurally different customers continuously.
• Document databases like DynamoDB store flexible documents well but don't support efficient relationship queries across entities.
• Graph databases store entities and relationships natively, and new relationship types can be added without a migration.

Why Amazon Neptune specifically: As a fully managed AWS service, Neptune removed the operational burden of running graph infrastructure at scale, which mattered given the eventual size of the dataset. It also supports both major graph query paradigms (Gremlin and SPARQL), giving the client flexibility to align with its existing RDF-based vocabulary rather than rebuilding it from scratch.

A secondary design principle shaped the approach as much as the choice of engine: building for a future where the same data could feed AI systems as well as human-facing dashboards and APIs. Subject-predicate-object structures map naturally onto how large language models process language. A Neptune-based graph solved today's query problem and set up the data to work well with retrieval-augmented generation (RAG) and AWS Bedrock knowledge bases later, without a second migration.

What Perfsys Delivered

1. Migrating the Core Data Model to Amazon Neptune

Perfsys led the migration of the client's data layer from its prior storage approach onto Amazon Neptune graph database, completed over roughly six months. The migration wasn't a lift-and-shift. Entities and relationships had to be remodeled as RDF triples rather than rows or documents, with the existing domain lexicon used as the foundation for the new schema-less structure. By the end of the project, every data point the platform touched lived in Neptune.

2. Modeling Loan Origination as a Graph, Not a Schema

Rather than defining a rigid set of tables, Perfsys modeled the loan origination domain as a network of entities, buyers, sellers, properties, bank accounts, credit ratings, financial transactions, connected by relationships expressed in SPARQL. This meant new relationship types (a flood zone designation, a co-signer's credit issue) could be added as they appeared in real customer data, without requiring a schema migration or downtime. The graph grew to encompass 200 million+ data points and close to a billion individual connections.

3. Serving Five Industries From One Unified Graph

Because the underlying data model captured relationships rather than rigid per-customer schemas, the same graph could answer fundamentally different questions for different types of customers. Loan servicing companies queried it for data tied to active loans. Brokers queried it for property and buyer information. Banks and credit bureaus queried it for financial and credit-related aspects of the same underlying records. The client onboarded more than 30 B2B customers across five distinct industry segments onto this single data layer, each able to query the graph from its own angle without requiring a separate data model per customer.

4. Laying the Groundwork for Graph-Based AI Retrieval

While the original project predates the current generation of graph-based retrieval-augmented generation tooling, the architecture Perfsys built anticipated it. Graph databases structured around subject-predicate-object relationships are a natural fit for AWS Bedrock knowledge bases , because large language models reason more effectively over explicit entity relationships than over flat documents or relational joins. The RDF-based Neptune model gave the client's data a structure that could plug into AI agents and Bedrock-based retrieval without re-architecting the underlying graph.

Thinking about whether your data is structured for AI retrieval rather than just storage?

If your platform aggregates data from sources that don't share a common schema, Perfsys helps assess whether a graph database approach, and a path toward AWS Bedrock-based AI agents, fits your architecture. Contact us to talk through your data model.

Contact AWS Specialist

Security & Reliability

Amazon Neptune is a fully managed AWS service, which shifted patching, backups, and infrastructure-level reliability concerns away from the client's engineering team. That said, keeping a graph database of this scale healthy in production required deliberate monitoring: query performance, cluster availability, and write throughput all needed active attention as the dataset grew into hundreds of terabytes. Running Neptune inside a VPC with restricted network access and applying AWS Identity and Access Management (IAM) least-privilege roles for any service touching the graph kept the platform aligned with the access-control expectations of bank and credit bureau customers, entities with their own regulatory obligations around the data they were querying.

Results & Business Impact

Key Quantitative Outcomes

• 200 million+ entities and close to 1 billion relationships stored and queried in a single Amazon Neptune graph database
• 30+ B2B customers across 5 distinct industries, loan servicers, brokers, banks, and credit bureaus, served from one unified data model
• 6-month migration timeline from the prior data architecture to a fully Neptune-based system, with zero need for per-customer schema redesign afterward

Impact Summary

The graph database approach let the client support a fundamentally heterogeneous customer base, five industries with different data needs, without maintaining five different data models. New customers and new data relationships could be absorbed into the existing graph rather than triggering a schema change, which is what made it possible to scale to 30+ B2B integrations on a single platform. The RDF-based structure also meant the data was already shaped in a way compatible with later AI-driven retrieval, avoiding a second re-architecture when graph-based RAG became viable on AWS.

Conclusion & Next Steps

This project demonstrates that graph databases are not a niche choice for businesses dealing with genuinely unpredictable, relationship-heavy data. They're often the only architecture that scales without constant schema rework. For teams in a similar position, the natural next steps building on this kind of foundation include:

• Connecting the existing graph to an AWS Bedrock knowledge base to support AI-driven querying and natural-language search over the same entity relationships
• Extending graph-based access controls so different customer segments see only the subsets of the graph relevant to them
• Adding graph analytics (community detection, shortest-path queries) to surface risk patterns that aren't visible in flat reporting
• Evaluating Neptune Analytics for workloads that need in-memory graph algorithms at lower latency than the standard Neptune database engine

Stuck with a data model that breaks every time you onboard a new customer?

We help startups and SMBs handling complex, multi-source data move to graph database architectures on AWS, and connect that data to AI agents when the time is right.

Book a Discovery Call

Other Case Studies

• Building Investor-Ready AI Mental Health Assistant MVP on AWS Bedrock : how Perfsys built a healthcare AI assistant MVP on AWS Bedrock for a UK startup.
• How my-vpa Unified Access Management and Reduced Costs by 90% with AWS & Keycloak : identity and access management on AWS for a German SaaS platform.
• Video-on-Demand System Case Study, Roligt AB : a serverless AWS architecture powering a media streaming platform.

Eugene Orlovsky

CEO & Founder | Serverless architect with 10+ years of hands-on experience designing cloud-native architectures on AWS, backed by multiple AWS certifications. He is writing bridges deep technical expertise with real-world business strategy, covering topics from AWS best practices to scaling tech-driven organizations.