In 2017, Australia’s Stake set out to build a website application that would let Australian investors buy US shares online. (It also supports customers in New Zealand, the UK, and Brazil.) Doing that meant integrating multiple services to handle identity management, to connect to the DriveWealth back-end brokerage platform, create bank accounts for international money transfer, and execute the actual transactions in the highly regulated securities industry.
For those to work, co-founder and COO Dan Silver says, Stake had to first understand the user flow—such as understanding the customer pain points of Australians buying US shares—and the business itself so when it was time to integrate, everything was ready to be connected and tested.
How Stake built its application: API-based assembly
It took Stake 12 months from setting up the company to having a first version of a marketable platform in 2017, which included negotiating contracts with providers, getting regulatory approvals, and building the platform. They also did testing such as penetration and user testing.
“The heavy lifting and the works are done up front when you’re doing the business case. The product design piece, that’s the most important part really,” Silver says.
Stake built some components internally, but the trading service was mostly based on the use of APIs to external services, including DriveWealth for brokerage functionality;
OFX, Macquarie, TrueLayer, Poli, and PinPayments for foreigh currency exchange (FX) and payment gateways; Trulioo and ProScore for instant identity verification; and Benzinga and Tiingo for stock-specific data, news, and analyst ratings. Amazon Web Services is the hosting provider, with data centres across the world, including Australia, the UK, and Brazil; Stake uses AWS services such as Elastic load balancers, Elastic Cloud Computig (EC2), Lambda functions, and Route 53.
As an example of such connections, the developers connect Stake’s onboarding system to Trulioo for electronic identity verification. Once data such as name, address, date of birth, mobile number and an ID number are entered, they are sent to the vendor’s database which is then compared against a global network of independent data sources.
To effectively use APIs, it is essential to work closely with the providers and understand the use cases, Silver says—otherwise, it won’t matter how good the API documentation is. “No matter how simple an API is, you still got to go and configure it correctly.”
Another good reason to keep those close relationships is that as vendor technologies change, you are ready for how those changes will impact your business and thus can be ready for them, he says.
Scaling for customer growth
Stake experienced a 129% growth in customer acquisition in the first six months of 2020 compared to the previous six months, a likely result of the COVID-19 pandemic and its prior marketing efforts.
An increase in customer numbers is great news but can come at a cost and result in more investment and upgrades to prevent issues such as outages. For that, Stake has auto-scaling hardware on AWS, and it works to optmise code and automate internal processes for better scale.
“For our platform, the major bottleneck in terms of user activity is right at market open, when everyone is often placing the highest number of trades. This is an area we had to give particular attention,” Silver says.
To do that, Stake removed a large dependency in the database by improving caching for user authentication, upgraded the database engine to enable it to scale and better handle the large CPU utilisation spike at market open, and enhanced the internal connectivity between its compute and storage resources to increase overall stability. Stake also implemented a cache-based locking mechanism to better manage thousands of specific concurrent requests and improved the deployment process to scale the infrastructure more efficiently.
“Our optimisations lead to an approximate five-time reduction in overall database CPU utilisation and overall latency, Silver says.
Next for Stake is the implementation of a microservices architecture across some back-end components to enable the business ot scale more efficiently and optimise its deployment processes to decrease the time taken to release new builds.