Few industries pose tech professionals with projects as complex and impactful as fintech, an industry that requires both innovation and a customer-first mindset. Successful teams are nimble and responsive while simultaneously navigating regulatory requirements — and ensuring that no bugs make it into production that might mess with a user’s money.
With a ton of features rolling out throughout the year, few fintech companies have mastered this balance better than SoFi. Founded in 2011 to provide students with more affordable loans, the company has expanded its suite of services to include everything from credit cards to cryptocurrency.
“Working at SoFi is like working at a VC with a handful of startups under it,” Senior iOS Engineer Michael Sacks told Built In. “We have the benefits of a stable company, minimal processes so we can move quickly, and we control the future of what the product is.”
The company’s overall product strategy is governed by what it calls a “financial services productivity loop,” which seeks to build products in a way that gives users additional value for every new SoFi product they adopt. To learn what the strategy looks like in action, we asked three members across SoFi’s engineering, product and design organizations to give us a peek at recent projects they’ve worked on.
SoFi’s product bundles are an example of its productivity loop strategy in action. In building different discount bundles, the team’s goal was to deepen the company’s relationship with members and increase the proportion of users who consider SoFi to be their primary financial institution. However, bundling two products that have historically operated independently created some engaging challenges for Hinkle’s team.
Describe the back-end technology that powers the SoFi Lending bundle from a technical perspective. What kind of solution did you need to build?
The product is built off many technologies. The entry point is a redirect to a web view of a React app specifically created to enable SoFi Money onboarding. We use a microservice architecture powered by Kotlin and Spring Boot back-end services to determine eligibility before a member even applies, reducing friction and promising a good user experience. We also use Postgres as our data store and Kafka for asynchronous communication between products.
“To solve these kinds of technical challenges, we created a finite state machine that the applications can move through.”
What was your biggest technical challenge during this project, and how did you overcome it?
This bundle is a cross-team promotion that requires constant synchronization between two historically vertical products. One of the consequences of this is that there are certain processes that are common among both products that can be delegated to one or the other in order to reduce duplicated work. However, this can lead to challenges as these processes can have different architectural properties in their respective verticals.
For example, the “Know Your Customer” (KYC) process only needed to be completed once, and the results could be used for both products. The issue was that KYC was completed at different stages for each product. To solve these kinds of technical challenges, we created a finite state machine that the applications can move through, along with associated permissions at each stage, which gives the member a better experience, yet still complies with all regulatory requirements.
SoFi’s Cryptocurrency Investment Platform
Earlier this year, SoFi updated its crypto trading platform — internally dubbed Crypto Dust — allowing users to redeem funds from their SoFi accounts into 28 different blockchain-based currencies. The project brought together members from SoFi’s Credit Card, Member and Invest teams. Although, as Brennan explained, many were working with cryptocurrency for the first time. A big piece of the project involved building an internal fulfillment module in an order management system (OMS), for which the team had to make sure that each account holder had access to the most recent information in the fast-moving world of cryptocurrency trading.
Prior to launching this project, what experience did your engineers have in working with cryptocurrency?
I don’t think many of us had prior experience working with cryptocurrency. However, we did have the benefit of working with Coinbase, which was able to bring its expertise and experience to help us decrease the technical scope of what was business-critical to know about working with crypto.
What were the biggest difficulties associated with building an internal fulfillment module in the Invest-OMS service, and how did you overcome them?
When multiple processes are attempting to update holdings on a single account, we have to take special care to accurately know that what we’re acting on is the most up-to-date information. For instance, if multiple nodes are adding funds to a firm account and our trader is trading against that firm account at the same time to liquidate its shares, we need to make sure that we have the most up-to-date and correct information on that account so our books balance at the end of the day.
“Sometimes creative solutions are necessary in order to improve user experience, especially when our external partners have limitations to what they can offer with their APIs.”
What did you learn from your experience working on SoFi's cryptocurrency investment platform?
I learned that sometimes creative solutions are necessary in order to improve the user experience, especially when our external partners have limitations to what they can offer with their APIs. Also, small amounts of crypto can turn into large dollar amounts very quickly!
Is this the first such feature of its kind? And what models or examples did you have to work from when designing this feature?
We did in part build off previous patterns we used with how we allocate Bitcoin bonuses to our users. We often offer a bonus paid in Bitcoin when a user makes their first trade and allocate the balance in their account. Dust works in a very similar way, except in reverse! Rather than withdrawing money from the firm account, we are actually depositing crypto into it as we fulfill each Dust trade.
When a company goes public, its starting price is fixed in place before trading begins. Large institutions are able to buy shares at the starting price, while the average investor is only able to buy after trading has begun and the price sometimes pops. SoFi built its IPO Investing platform to give individual traders the same public offering price access as institutional investors. The project involved building a user experience across mobile and web, and developing back-end systems to process the user experience, facilitate member communication and orchestrate orders, trades and allocations.
Describe the back-end technology that powers IPO Investing from a technical perspective. What kind of solution did you need to build?
The back-end used for IPO Investing is similar to the back end that powers most of our investment services. It’s a Java service that is connected to multiple other microservices within SoFi Invest. The biggest difference with the IPO Investing build was the need to be very flexible with the customer experience because we were learning new requirements on the fly. As a result, we built it so that as much of the content and copy was served up from the back end as possible. Today, we have the member home feed, which is powered by a homegrown CMS. This project highlights the need for SoFi to invest in this platform in order to power more surfaces dynamically.
“Throughout the project, we were thrown curveballs.”
Did you build this feature from the ground up, or were there existing SoFi platforms and technology that you were able to incorporate into this product?
IPO Investing was built from the ground up. We leveraged existing internal tools to facilitate content, copy and configuration and to move IPOs through their processes. IPO investing is also integrated with some of our existing vendors like Apex, which handles trading, clearing and custody, and Xignite, a market data management platform.
Describe the process your team used to deal with ambiguity when designing IPO Investing.
That’s a tough one. Throughout the project, we were thrown curveballs. We had a daily sync to start the day with the cross-functional team. We had a centralized document to work through open questions, assigned ownership and pushed until we were able to resolve the issues. From a technology perspective, our strategy was to build as much flexibility into the system by constructing much of the experience in WebViews so we weren't constrained to the native release cycle. Additionally, we didn’t automate some processes at the outset, knowing that they would change.