Funding Societies Project

November 20, 2017 by Aaron Ong

This is a freelance proposal I sent to a Singapore-based SME called Funding Societies recently. While the deal eventually fell through due to budget constraints, I learned a fair bit drafting up the proposal. So I figured I should share what I have done, enjoy.

1. Project Overview

a. Objectives

Develop a web and mobile application targeted at SMEs:

Aggregate their financial information across corporate bank accounts.
Detect low working capital cycles.
Simplify the process of acquiring working capital.
Track their personal accounts alongside their corporate accounts.

b. Benefits to Funding Societies's Core Business

The financial aggregation allows Funding Societies to perform a faster and more complete analysis of an SME's financial position.
- SMEs are more likely to take on loans since the application process is simplified
Encourage SMEs to take on short-term working capital loans from Funding Societies when the need arises
Simplify the process of collecting financial information from the personal guarantor.

2. Context

a. Market Size

Number of Singapore-based SMEs: 200k - 400k

Primary market: approx. 70% (140k - 280k)

Subset of SMEs that will benefit from financial aggregation, i.e:

SMEs that own multiple corporate bank accounts.
SMEs that own a single corporate bank account but also operates from the personal accounts of one or more business owners.

Secondary market: approx. 30% (60k - 120k)

Subset of SMEs that do not require financial aggregation (i.e. own only one corporate bank account).

b. Market Need

SMEs continue to display a strong need for two financial products/services:

They require tools to facilitate their financial planning.
They require short-term loans during low working capital cycles.

Our product is well-positioned to target these market needs.

While the market is fairly saturated with products/services that provide either of the above-mentioned services, there is currently no solution that integrates both services on a single platform.
The platform offers the functionality to detect low working capital cycles.
The platform will complement Funding Societies's current unique selling point (incredibly simplified and expedited capital funding)

c. Market Competition

Xero and Quickbooks

For financial planning tools, Xero and Quickbooks are the forerunners in the Singaporean market. While Quickbooks is a global leader in the financial planning SaaS space, and Xero is gaining traction in Singapore due to their deep integration with local banks.

Xero is the only financial planning tool available in the market that has successfully integrated with DBS's SME banking backend. They are also intending to integrate with all 5 major Singapore-based SME banks in the coming year. Hence, Xero is able to receive bank feeds of their customers' corporate financial data and do not require repeated 2FA verifications to refresh financial data.

As DBS is the market leader in the SME banking space, Xero's DBS integration makes it the most convenient, secure, and therefore most naturally desirable SME financial planning tool in Singapore. Both Quickbooks and Xero are able to scrape financial data from personal bank accounts; neither has integrated with OCBC, UOB, Standard Chartered, or HSBC SME banking accounts.

Seedly

Seedly is an indirect competitor in the financial planning tools market. Like Quickbooks and Xero, they offer scraping of financial data from personal bank accounts, but they are postured mainly as a personal finance planning application. They offer no integration with corporate bank accounts. Corporate accounts aside, Seedly's simple UI, focused feature set, and free software model has attracted a large following. They are likely to be a viable threat should they venture into the SME market.

MoolahSense

For short-term working capital loans, MoolahSense is a direct competitor in the P2P lending space while SmartFunding.sg, and FundedHere are indirect competitors. None of our competitors in this space have developed any form of financial planning tools to complement their services.

3. Proposed Solution

a. Product Positioning

A key value proposition of our new product is the ability to aggregate financial information across corporate and personal bank accounts. Due to the dominance currently established by Xero in this area, we have to position/brand our product not as a financial accounting tool but as a financial tool catered towards managing and acquiring liquidity.

b. Feature Set

Aggregate corporate financial data (Account Balance, Inflows, and Outflows)
Aggregate personal financial data (Account Balance, Inflows, and Outflows)
Offer basic accounting ratios (focus on liquidity ratios)
Offer basic budget setting and tracking (A feature I found useful on Seedly)
Visualise financial data
Predict period of low working capital
Recommend loan quantum and duration
Integrate FS Bolt

4. Challenges and Recommendations

This section outlines the main challenges that have been considered along with recommendations to overcome them where applicable.

a. Market Challenges

The main market challenge is to break the dominance that Xero has on the market. Their plans to integrate bank feeds with all major SME banks in Singapore will only further propagate their market dominance in the coming years.

Recommendations

The product should be positioned as a financial tool catered towards managing and acquiring working capital. Within the Singapore market, Funding Societies is best positioned to address this problem. Tools such as this are absent in Singapore's market and we will have the first-mover's advantage.

However, while such a product will help our customers to acquire working capital through loans disbursed by Funding Societies, offering loans alone will not make us indispensible as a liquidity acquisition tool. Customers will be best served if we partner with some of our indirect competitors in the market to increase exposure and access to other means of acquiring liquidity.

SmartFunding.sg will allow customers to acquire working capital through selling their invoices. As there is a limited amount of working capital that our customers can generate through this method, partnering with SmartFunding.sg is unlikely to significantly affect the volume of loan requests Funding Societies receives.

CardUp is branded as a solution that allows its customers to earn more miles, cashback, and rebates through enabling payments through the credit line. A partnership with CardUp will allow customers to acquire working capital through fulfilling their payments using their credit line. As credit lines generally demand higher interest rates, our customers are unlikely to obtain working capital through credit lines for loans beyond one to two months.

While these partnerships would drive down the average loan quantum Funding Societies disburses per customer, the partnership is likely drive up the total loan quantum disbursed through reaching out to a wider market. While our largest threat in the financial planning domain is Xero and Quickbooks, it may be wise to partner with some of these smaller players to upset their dominance.

b. Legal and Security Challenges

MAS regulates financial data very stringently, thus we will need to demonstrate that we are managing our customers' financial data with the utmost care to gain the trust of the public and institutions.

Legal liability is another potential issue. Since our services will only obtain read-only access to our customers' bank accounts, our liability is limited to mishandling our clients' financial data. I am currently unsure of how much product owners will be liable for if this scenario occurs and I require Funding Societies's advice on this front.

Recommendations

Our legal challenges are primarily rooted in our product's security. Implementing the following security features well will help us remain compliant:

Provide a secure third-party authentication model
Manage our customers' access permissions stringently
Manage our backend and database security stringently

c. Secure 3rd Party Authentication

There are two 3rd party authentication models I am currently considering.

The first is to act as the middleman when performing authentication. Our clients input their credentials on our platform and we authenticate on their behalf.
The second is to redirect our clients to their bank site, and obtain the authentication token/handler from the bank site.

While the first option gives our users a more native experience on mobile platforms, the second is preferred from a security standpoint. Popular 3rd party authentication solutions such as Facebook, and Google all employ the second model. The second model is also likely to be more compliant with MAS's regulations, and customers are more likely to trust us if we use this approach.

d. Selecting our Financial Aggregation Method

First and foremost, we need to disambiguate between corporate financial data and personal financial data.

Personal financial data

While there are financial data aggregation APIs available in the personal banking space, no equivalent is available in the corporate banking space.

Two personal banking API services have been well-tested within Singapore. The first being SaltEdge, the API service employed by Seedly. It is extremely reliable and easy to use, but comes at a price of $500/month, hardly affordable in my opinion.

The second is Yodlee, the API service employed by Xero. I have encountered a single report regarding Xero not being able to connect to a DBS savings plus account, but I believe this to be an isolated incident as there was no follow-up. Yodlee's api service is thus just as reliable as SaltEdge's but comes at only $250/month.

Both API services provide additional features such as transaction categorization and takes the hassle out of maintaining our own web scraper. We need to discuss if we wish to employ an API service for our personal financial data aggregation or build our own web scrapers. This decision also depends heavily upon the types of information that we hope to obtain.

Corporate financial data

There are currently two options available to us for obtaining corporate financial data.

Build our own web scrapers
Build our platform on top of Xero's API (this will limit our market to individuals who are already on the Xero platform, so I believe this to be an non-option)

Another possible solution is to work with Moneythor on delivering an API service. The issue is - I have no visibility into the APIs that they offer. I have also contacted Moneythor to request for permission to use their API services, they have, however, denied my request.

Recommendations

I propose that we start with building web scrapers for the SME banking portals. Then, depending upon the perceived trade-offs in cost and development hours, decide between using scraping APIs or develop our own web scrapers for personal banking portals.

Scraping APIs are likely to be more reliable, trusted, updated, and might also lead to a lower maintenance cost. A drawback of using scraping APIs is that we are not able to authenticate our clients using the redirection method.

e. Maintaining Web scrapers

If we develop in-house web scrapers, there will be the additional costs to ensure that they remain updated.

Recommendations

Proper unit testing mechanisms and heartbeat algorithms will need to be developed to detect for downtime.

f. Using Bank Feeds

An alternative to developing and maintaining our web-scrapers is to obtain permission from the banks to use their bank feed APIs. Since Xero has already set the precedence for using bank feed APIs, it should be relatively easier to convince the banks to allow us to use their Bank Feed APIs.

Banks also wish to portray themselves as forward looking and supportive of innovation. But the convincing will be difficult from my end alone since banks are unlikely to trust an unestablished and inexperienced individual such as myself.

Recommendations

Building the webscrapers first and gaining a user base should be prioritized before approaching the banks to integrate their bank feeds. As most bank feeds are currently still unavailable, this is not likely to be a viable option for the coming year.

5. Quotes

Given the options made available in this proposal, We propose the following quotes. Note that the following quotes are given as a rough guideline and are subject to changes made in the requirements.

After the first on-site requirements gathering, we will revise and confirm the backend development and design price.
Frontend pricing will only be confirmed upon the completion of the design.
The quotes in this section will be given in broad strokes.
A more detailed breakdown of sprints and payouts will be decided in consultation with Funding Societies.
A 60-day support period is included for all products developed.

`Consulting - Lead Consultant (Aaron)`

Task	Payout
Project Proposal	xxx
Onsite meetings per pax per hour (+1 hour each session for traveling)	xxx
Initial Downpayment	xxx

`Backend - Lead Developer (Aaron)`

Proposed backend stack:

Backend - Node.js
Database - PostgresQL
ORM - Sequelize
Communications layer - GraphQL
Authentication - JWT
Password hashing - server-side bcrypt
Transfer protocol - HTTPS
Testing - Mocha/Expect

Proposed features:

Yodlee API integration for non-SME bank accounts
- It is infeasible and expensive to maintain our own scrapers.
- Yodlee integration with backend instead of frontend
- Improves our analytics.
- Prevents a 3-way coupling between our frontend/backend and Yodlee's API.
Web scrapers for SME bank accounts
- Includes unit testing.
- Includes heartbeat algorithm.
- Email notifications when heartbeat fails.
- Will produce an easily maintainable design.

Task	Payout
General backend implementation and integration (Aaron)	xxx
Serving on GraphQL (Aaron)	xxx
Developing Database Schema (Hui Yie)	xxx
Yodlee API integration (Hui Yie)	xxx
First SME Web scraper (Daniel + Aaron)	xxx
Subsequent SME Web scraper (Daniel)	xxx
working capital analytics (Hui Yie + Aaron)	xxx

`Design - Lead Designer (Kai)`

We understand that you may wish to employ your own in-house designer to achieve a consistent look and feel across your products. If that is the case, you are free to do so. Simply submit your design to us, and/or any non-sensitive frontend code/components that you have developed for your previous products. We will produce the front-end according to your specifications.

If you should choose to employ our design services, our requirements are as follows:

Designs will be delivered in four phases with limited revisions for each phase.
Phase 1: User stories and user flows. (1 revision)
Phase 2: Digital wireframes with layout and mock text content. (2 revisions)
Phase 3: Digital wireframes with colour/pictures. (2 revisions)
Phase 4: Final interactive prototype. (1 revision)
Additional revisions are possible but come at an increased cost and delayed timeline.

Task	Payout
Mobile app design (Kai Yi)	xxx
Responsive web design (Kai Yi)	xxx
Mobile + Responsive web design (Kai Yi)	xxx

`Frontend- Lead Developer (Zheng Wei)`

The frontend quotes are difficult to estimate at this point of time:

It depends heavily upon the confirmed design
It depends upon the level of support we require for different browsers
It depends upon the level of backward compatibility

The frontend will integrate with:

Our financial data backend
Funding Societies' backend
Potential partnerships will be discussed at a later date
Cost is likely to be borned by the other party or follow a mixed model

Task	Payout
React Native ($1000 discount if developed with other React technologies) (Jeremy + Gregory)	xxx
iOS (Swift) (Jeremy)	xxx
Android (Kotlin + Java) (Gregory)	xxx
React responsive web app (Zheng Wei)	xxx
Native Desktop (Electron + React) (Zheng Wei)	xxx

6. Timeline

`October`

As my team is currently occupied with a seperate project, we are only able to start working on this project on 1st November. From now up till November, my lead designer and I will be available for on-site discussions to gather the initial set of requirements. My designer will only be available for one visit, but I am available for more should we require it.

Contract will be signed by end October and downpayment will be made.

`November`

Design

Complete Phase 1.
Complete Phase 2.

Backend

Complete initial Database schema and GraphQL documentation.
- This helps align stakeholders around the project's technical scope.
- Documentation will be sent to Funding Societies for review.
- Documentation is likely to be further revised as the project progresses.
Develop a POC web scraper.
Begin working on backend boilerplate.
Familiarize with Yodlee API.

`December`

Design

Complete Phase 3.
Complete Phase 4.

Frontend

Will commence as soon as Phase 2 is complete.
The seperate Frontend projects will be developed in parallel but share a similar folder structure.
- I have a dedicated iOS, Android, and Web Dev ready.
50% of each frontend is likely to be completed by December.
Iterations of the frontend will be deployed on a regular basis.
Continuous feedback is accepted.
We will not deliver features that deviate from the agreed-upon design.

Backend

Deploy Relational Database.
Deploy a GraphQL server.
Complete Yodlee integration.
Complete two web scrapers.

`January`

Frontend

Initial draft of Frontend to be completed by January.
On-site demo will be scheduled at the end of January to receive critique.

Backend

Complete all required web scrapers.
Complete working capital analytics.
Complete GraphQL queries.

`February`

The February period is reserved to:

Account for slow sprint velocity
Address concerns discovered during on-site demo
Complete Unit and Integration testing

Product should be ready for UAT by end February. Product will be supported for any bug reports received through the end of April.

7. Complex Arrangements

`Mixed Ownership`

The above quotes are made with the assumption that it will be a pure software development contract made between my consulting company (yet to be incorporated), and Funding Societies. I would love to keep the discussion open regarding the mixed ownership model. Given the complex arrangements that the mixed ownership model could present, however, I would like to discuss this possibility on-site.

`Partnerships`

If Funding Societies is keen on exploring the partnerships suggested in Section 4C, I suggest doing so only after we have established the nature of our working relationship.

8. Closing Note

I believe this product can demonstrate significant value, and with Singapore’s growing support for the SME space, it will be only become more relevant as the barriers to entry for SMEs get increasingly lower.