inmygarage
Joined 17 years ago
Joined 17 years ago
We had four revenue streams (interchange, instant send, credit card loads, and float on deposits) but IMO to really make this work it needs to have a subscription fee as well. That's a whole OTHER controversial topic in payments, but outside the scope of this discussion thread :)
To address your points:
1. The ownership of funds is mapped pro-rata to every user's contribution. If three people contribute $10, $10 and $20 dollars, and then the pool gets spent down to $10 total, the technical per-dollar ownership is $2.50, $2.50, $5. It was critical to have a down-to-the-cent mapping of individual ownership of every dollar in our system at all times. While funds availability is dictated by Federal Law (Reg CC), funds ownership was something we were allowed to establish in our own Terms of Service. It's still live and available to read here (Section 4): https://braid.co/legal/tos if you'd like. Funds ownership was not related to spending permissions, which could be decided by the pool admin (for example, maybe you want all users to be able to spend all available funds, that's up to you).
2. Every individual who signed up for Braid went through our KYC/CIP process. We had a very robust (and expensive) waterfall to verify every indiviual, and screened the entire customer base every time the OFAC list was updated. I was never on board with concept of "treat the group as a single entity" for exactly this reason. For consumers, a group is not a business or an entity, it is a group of individuals and should be treated as such. There are always false negatives and these systems aren't perfect, but if you're on the OFAC list you wouldn't be able to simply sign up for Braid and slosh money around. That's illegal.
3. We built from-scratch internal anti-money-laundering software that was designed to catch exactly the kind of money laundering that could only happen in a pooled account structure, in addition to all the standard money laundering tactics (circular transfers, flow-through, structuring, transaction frequency, and more)
4. From my perspective, a product like this makes sense within the existing regulatory environment IFF the startup (us) was willing to do the hard work to figure it out. We absolutely were and had the time and money to get it right. But yes, it was very complex and at times infuriating.
5. As noted in the piece, the bank off-boarded every fintech they had -- debit cards for college kids, small business banking apps, neobanks for different consumer groups. I know this because we had a phone chain/support group by the end of it. It wasn't about our business model, it was about getting out of fintech sponsorship entirely.
6. We've gone through detailed compliance reviews with multiple banks, and worked with a handful of well-known legal experts (at least that's how they billed). Especially by the end, we had a good sense of the regulatory constraints and what the regulators care about these days. I've met with the OCC personally a couple times and gotten their perspective as well. FINRA regulates investment products, not deposit accounts.
In sum, while there is no such thing "move fast, break things" in fintech, the idea that we shouldn't fight for what consumers want and do the hard regulatory work to make it happen is too depressing for me. I have to believe new products are possible, and still do.
We are building a group account with a debit card and permissions. It eliminates the need to track expenses after-the-fact (no more spreadsheets) and hopefully makes shared spending easier. The only product for this currently is a joint bank account, but that’s not ideal for a bunch of reasons. In the app, you can set permissions to specify who can spend the money and how, and use the unique account/routing numbers and virtual cards to pay for shared expenses.
Some usage we've seen so far from early users: -Couples using it as a lightweight joint account -Roommates using it as a house account -Sharing money with family members as a way to help/support everyday expenses -Divorced co-parents who share childcare expenses -Social envelope budgeting
The product is totally free. U.S. only for now. Would love to hear your feedback.
Compound is a new P2P payments app currently in stealth. We are building a brand-new P2P payments network from scratch, and have designed the product to target pain points real people face when sharing money. We believe there should be more flexibility, personalization, and transparency in the financial products we all use each day.
Tech Stack: Our frontend is React Native for mobile, and we’re experimenting with React Native Web on the web side. Our backend is currently Java deployed using kubernetes, but we have a polyglot approach to problem solving, and we will likely end up with a backend that reflects that.
Check out our Key Values profile for more about us: https://www.keyvalues.com/compound
Hiring software engineers of all levels in SF.
Link to apply: https://hire.withgoogle.com/public/jobs/compoundco/view/P_AA...
ap [at] amandapeyton [dot] com