Pineapple
Litepaper

Next level mortgage banking on a blockchain
Feb 2023 • Bhaskar Ravi, Gary Basin • Artwork by SD

Pineapple is a web3 mortgage brokerage. It is designed to make the act of getting a mortgage way simpler and way faster than it is today, and bring significant digital efficiencies to the origination process.

To put just how good Pineapple is into perspective: current originators take 45+ days to approve you for a mortgage, Pineapple takes ~15 minutes 🔥

This probably sounds crazy, so we are going to get concrete and reveal how we do it.

The ATR problem

We are going to assume you are aware of the terrible 1990s UX provided by the current crop of mortgage originators that we all use today. What you may not know is why they are so bad. TLDR; it boils down to regulation.

Back in 2008, originators were handing out mortgages without diligencing borrower financials, relying on made up data like stated income / stated assets instead. It resulted in a bunch of highly-levered high risk loans and the subsequent financial crisis.

In response, congress implements the ATR rule to kill these no doc loans. It mandates originators use verifiable financials to diligence a borrower’s “ability to repay” a loan before extending credit. If they can't prove they did so during an audit, the originator faces significant liability (putbacks from investors / agencies / buyers, fines, lawsuits, etc).

Though ATR has since proven useful in significantly reducing delinquencies and defaults, it has led to a different issue.

Originators now require borrowers to submit 28+ hard paper copies of various financial statements — like W2s, paystubs, and taxes — when applying for a loan. It's a terrible UX that has cascading consequences.

Paper isn't machine readable, so originators need teams of people -- like LOs, processors, and UWs — just to help collect and manually analyze everything. And people aren't efficient, which is why a single loan takes over 45 days to approve and comes with such high closing costs (2% LV). You can even blame servicing transfers and the concept of sub-servicing on the need to curtail bloating operations. We'd go as far as to say the effort to create and maintain an audit trail for ATR is the primary reason why originators are so inefficient today.

How are people currently trying to solve the problem?

Both incumbents and the Valley have invested billions to try and solve the ATR problem. That investment has gone to either:

building universal loan origination systems (LOSs) like Blend to try and streamline document collection and processing for all lenders or ...

building tech-enabled mortgage lenders like Better with the intent of doing something similar, but with the hope of capturing some additional alpha by controlling the entire origination process

Neither of these solutions have made much of a difference. In fact, the average mortgage approval times have gone up 🔼 since the early 2000s [36 >> 45 days] and the cost to originate a single loan has followed suit [$2,345 >> $9,140].

This shouldn't come across as a surprise. Originators are still fundamentally relying on paper. No matter how much tech is thrown at the problem, they will never escape the inefficiencies that come with that.

Wait … can’t you just use digital data?

Where investment dollars have made a big impact is in the creation of the open finance movement. We live in an age where all the data we need to originate a mortgage exists in the cloud — accessible through trusted third parties (TTPs) like Plaid, Equifax, CoreLogic, and others. Even the IRS has its own API now.

So why don't today's originators just use that digital data to grant us loans? Technically they do ... for pre-approvals. That's why, with the tech-enabled originators mentioned above, you can get a full pre-approval in just a few minutes.

Unfortunately when it comes to originating actual loans you need to underwrite a borrower using verifiable information. Digital data poses the same ‘trust’ issue as stated income / stated assets back in ‘08 — you can neither confirm its source nor its integrity. That poses a big problem for originators, who need ironclad proof that they did in fact diligence a borrower’s “ability to repay” in order to shield themselves from liability.

But herein lies the big web3 opportunity!

In theory, blockchains (specifically smart contract platforms) are built to solve these exact sorts of problems, with their ability to store digital data immutably with proofs. In fact the godfather of smart contracts himself, Nick Szabo, explicitly speculated that they could become the backbone for a digital mortgage market (for those who want to read his essay, we are linking here).

If we could solve the oracle problem and create a new kind of ‘chain’ whose smart contracts could download borrower financial data from TTPs and store the results immutably, with proof-of-source (PoS) and proof-of-integrity (PoI), it would make that data verifiable and thus usable for ATR compliance. You wouldn't need the borrower to submit a single document.

And that's exactly what we’ve done — we call it the Pineapple Upside Down Chain (Pud-C for short), and it’s the secret sauce that powers Pineapple 🍍

Overcoming the oracle problem

Whenever you talk about programming a smart contract (at least the ones that exist today) to download data, you run into what’s known as the oracle problem.

Essentially modern blockchains like Ethereum, Solana, HyperLedger, etc. all rely on some variation of Bitcoin's original decentralized consensus mechanism (specifically byzantine fault tolerance consensus models like PoW, PoS, etc) to achieve trustlessness.

The problem with that is that it actually precludes their smart contracts from performing certain basic functions — the biggest arguably being the ability to make API calls to external networks, which means there is literally no way for them to connect to external data sources like Plaid, etc and download data. It’s impossible.

If you’ve ever wondered as to why smart contracts haven’t lived up to their promise and haven’t been used to solve real world problems, this is the reason … because 90% of real world apps need to play nice with at least one or more external data sources (notable exceptions being social media / gaming, which is why all blockchain talk has been confined to those spaces).

The approach we take with Pud-C to overcoming the oracle problem is to throw out decentralized consensus altogether for an entirely new model for hosted smart contracts that achieves trustlessness by making a single ‘executor’ publicly auditable, effectively allowing a smart contract to perform the basic functions you’d expect out of a standard computer program and make API calls, while maintaining the trustlessness and verifiability provided by a traditional blockchain.

Implementing Pud-C

There are essentially two ways to implement this:

The first is to hack smart contracts in AWS by setting up something as simple as a multi-tenant cloud computer with cryptographically-verifiable system logs. A program run on this computer essentially becomes a ‘smart contract’ as logs can be watched by tenants in the system to achieve a trustless runtime — i.e. if the contract is manipulated in any way by any one tenant, the change would be captured in the log and you have potential fraud.

For efficiency purposes, the smart contract can write downloaded data to an immutable ledger DB, making it easy for anyone to verify PoS and PoI.

Obviously the logs would be hashchained to prove their integrity allowing for the system to be retroactively audited, and the system can have an unlimited number of tenants / auditors if necessary effectively making it a ‘public’ computer of sorts.

Technically this represents a smart contract sans blockchain (specifically a distributed blockchain), which is kind of cool. It is not scalable. It requires you to trust AWS (or any other cloud host). But it works.

The second and more robust implementation would be to create a decentralized network of proxy nodes (we actually call them ‘notaries’ in our system) to intercept and record web traffic between our TTPs and our smart contract, effectively capturing PoS. The proxies would then form a hashchain akin to a blockchain using a more traditional consensus mechanism e.g. Paxos , RAFT to create a source-of-truth and capture PoI.

The smart contract itself can then be audited by comparing the data in our systems with the data provided by notaries. If they match we are good and everything is running trustlessly, and if not we have provable fraud (thus making the contract ‘smart’).

We are purposefully keeping this implementation a bit vague as there’s some deep IP here. Overall both solutions work, but we think of the former as more of a minimum viable product and the latter as more of a full scale implementation.

Bringing it all together

In essence, with Pud-C we’ve created the ultimate digital notary; a cryptographic verification layer between our systems and our TTPs.

The reason we call it our ‘secret sauce’, and make such a big deal of it to begin with, is because once you're dealing with verifiable digital data, you can effectively digitize the rest of the mortgage stack. Put more tangibly, you can underwrite and originate mortgage loans programmatically and get rid of all the people (and their inefficiencies and their salaries) typically associated with the process.

Admittedly the tech required to do this is relatively trivial. We take inspiration from aforementioned pre-approval systems and FNMA's DU. Still it’s worth quickly walking through our specific implementation:

Pineapple is structured as a mortgage broker. As such, we don’t actually fund loans and hold paper ourselves. Instead we expose an API to a network of banks so that they can do so on our behalf.

The API provides access to all standard underwriting parameters, making it easy for banks to port over their loan products (we call them 'loan programs' in our system to keep the CS lingo), and allows for loans to be funded right off the balance sheet, similar to a standard retail loan.

A single loan can be underwritten, priced, and funded with just a few lines of code. Here's an example of a standard loan program for a conforming Fannie Mae loan:

/*
BankX FNMA CA Borrowers
*/

// ** UNDERWRITING **
// use templates to apply many rules at once
apply({template: "Fannie Mae Conforming 2022"});

// target specific borrowers or regions
apply({locations: ["Los Angeles", "San Francisco"]});

// reject borrowers who don’t have at least $1,000 in their bank account, using data from Plaid
bank_balance = get_bank_data(source: Plaid, type: Balance);
if (bank_balance < 1000) { reject_borrower(); }

// use a custom income calculation function
set_income_function(my_custom_function);


// ** PRICING **
// set a benchmark interest rate, imported from existing pricing engine
loan_rate = get_rates_from_optimal_blue(term: 30_year);

// customize interest rate offered based on borrower attribute
credit_score = average_FICO();
if (credit_score < 500) { reject_borrower(); }
else if(credit_score > 700) { loan_rate = loan_rate - 0.25%; }


// ** FUNDING **
// configure account number to draw wires from
fund_from({account_number: 123, note: "Pineapple Mortgage Funding"});

/*
BankX FNMA CA Borrowers
*/

// ** UNDERWRITING **
// use templates to apply many rules at once
apply({template: "Fannie Mae Conforming 2022"});

// target specific borrowers or regions
apply({locations: ["Los Angeles", "San Francisco"]});

// reject borrowers who don’t have at least $1,000 in their bank account, using data from Plaid
bank_balance = get_bank_data(source: Plaid, type: Balance);
if (bank_balance < 1000) { reject_borrower(); }

// use a custom income calculation function
set_income_function(my_custom_function);


// ** PRICING **
// set a benchmark interest rate, imported from existing pricing engine
loan_rate = get_rates_from_optimal_blue(term: 30_year);

// customize interest rate offered based on borrower attribute
credit_score = average_FICO();
if (credit_score < 500) { reject_borrower(); }
else if(credit_score > 700) { loan_rate = loan_rate - 0.25%; }


// ** FUNDING **
// configure account number to draw wires from
fund_from({account_number: 123, note: "Pineapple Mortgage Funding"});

That is remarkable, considering again the human ops currently involved. And it means that mortgages can effectively be granted, fully cleared-to-close, in real time.

Two other features worth mentioning for our fellow mortgage nerds: (1) title insurance and HOI are automatically placed on loans via 3rd party APIs, would not have been possible 10 years ago but now multiple providers offer great solutions (2) the system as designed supports hybrid / desktop appraisals, so if a loan does not qualify for a waiver we would then additionally have the borrower capture a video of their home and then have the home appraised remotely.

From a practical point of view, this means that when you’re ready to move into your new home, your mortgage is going to be there, guaranteed, waiting for you … whether you need your payments to start in 7 days or 70 days. As a borrower you’ll just download an app, give us permission to access your data, configure your loan, and boom … you’re good to go. Everything is automated.

What’s next?

This is a project that has the potential to impact us all, change the way we live, and change the way we view and interact with our largest asset. As such, with the release of this Litepaper, we are formally announcing our intent to build Pineapple in public (BIP).

We want to include everyone in the conversation, and we encourage all members of the community to reach out and contribute to the design and commercialization of Pineapple. It's your housing market, and your involvement can help bring Pineapple from idea to reality.

Our immediate next step is to bring all of this IP to market in the form of a delightful consumer product.

The initial value proposition we aim to provide is intentionally basic in a good way — you will be able to get a mortgage, at the best available rate, and service that mortgage through a simple mobile app. And we’re having fun with it! The interface is going to be GPT-based AI (we’ve named her ‘Arika’) who is basically the smartest LO you’ve ever met. And we’re collecting a giant knowledge base encompassing every home in the country, their neighborhoods, views, property values, and more, which will put the housing market into the palm of your hands.

We’re leveraging many cutting edge technologies, including smart contracts (obviously), large language models and chat interfaces, augmented reality + CV, and more. If you are a talented engineer who would like to get involved, DM our SVP of Fintech on twitter @garybasin. If you feel you could contribute to the project in an alternative capacity (UX, branding, marketing, etc.), please send over an email to xyz@pineapple.mortgage.

An aside …

The blockchain tech presented above is novel and, in our opinion, represents one of the first practical implementations of the technology. Its underlying protocol combines the best parts of traditional technologies and web3 philosophies (internally we actually refer to Pud-C as a piece of ‘web+’ tech) and could potentially be used to bring digital disruption to a number of highly regulated industries beyond mortgage — e.g. healthcare EMR, supply chain management, global payments settlement, insurance, etc — and lay the foundation for a new, more transparent web. Eventually we hope to publish / share the full extent of the IP to support other entrepreneurs pursuing use cases far and wide. If that’s you, please also feel free to reach out! We would be more than happy to chat philosophically on the subject in the interim.

PineappleLitepaper