Hacker News new | past | comments | ask | show | jobs | submit login

> Create account numbers that point to a single bank account and create specific permissions and limits for each one.

I love that; there are so many places that give a 6% discount for using ACH but I don't want to give out my bank account details willy-nilly

---

If you have influence over it, I wouldn't recommend having https://status.column.com/uptime default to "Sandbox" since I doubt seriously that's what anyone would care about when going to an uptime page, and can also mislead a reader in a hurry if the Sandbox environment is having woes but Production is fine

nit: I would guess you meant "sweep" not "sweet" on https://column.com/bank-accounts

> We support FBO, sweet, clearing and custom account types — all FDIC insured.




I'm glad you noticed the account numbers as pointers concept - we think its pretty cool. I think there's some rad use cases that people will come up with!

Thanks on the typo...deploying now :0


One that I recently found out about is reconciliation from https://bam.kalzumeus.com/archive/a-game-that-intentionally-...


This is great. I designed a similar system at Simple and it pained me that it never got implemented.


Thank you for being so responsive in this comments thread.

One other minor (accessibility) thing on the Status page: The dropdown (Sandbox/others) doesn't get hinted with Vimium (a keyboard accessibility add-on for fox and Chrom) or also with qutebrowser (a keyboard-first browser)

There's some info about it here, but it's basically it's made as a <div>

https://stackoverflow.com/questions/53918093/how-can-i-make-...


We have been looking for a US banking provider that could handle this. Woo hoo.

In RoW they are called virtual IBANs. Numerous use cases.


Some context: Patio11 wrote a bit about how businesses can use virtual account numbers this week:

> This is generally done via a mechanism called Virtual Bank Accounts (VBAs), which are a product available from the banking industry in Japan, the U.S., Mexico, Brazil, and many other countries. You contract with your financial institution of choice to reserve a block of bank account numbers corresponding to a far smaller number of actual bank accounts. You give out those numbers to your customers rather than giving out your “real” bank account number. You then take action based on which account number your customers use.

> Due to technical and social issues within the financial industry, the banks offering VBAs generally expect you to bring your own implementation work at this point. Should you e.g. re-use VBAs within your block? They probably don’t have a straightforward answer to that question; up to you. Should you treat them as secrets? Up to you. Should you share them between customers? Up to you. What should you do once you know one of your VBAs has received a transfer? The bank will give you your money, what you do with the data is up to you.

> Stripe does basically the simplest thing that works: give each customer/business pairing a unique VBA, shared across all invoices for that pairing (to avoid e.g. a customer not updating their supplier management system with the new bank account number on the second month’s invoice). Use ability to introspect invoices (and their open/closed/etc state) and inferences to tie incoming payments to the invoice they’re most likely associated with. Kick all the exceptions to a human or computer system, whichever the user specifies.

https://bam.kalzumeus.com/archive/a-game-that-intentionally-...


Wow that was depressing. Even back in the era before online banking and e-billing, in Finland an invoice would include a barcode you could scan that would auto-fill a reference number on the payment (with a checksum to minimize corrupt input).


Credit card networks offer a similar thing. They call it payment network tokens. Basically, the network gives the merchant/processor/store/etc a Uuid string that's an identifier for your credit card. Then the merchant sends that UUID string (the token) to the network and the network sends the real credit card details to the issuer for authorization.

So instead of giving merchants real financial info, they just get a pass to charge your credit card without the details of it.


Yes, I've been making heavy use of that over the years, from Amex's early offering through Privacy.com and now Capital One's anemic offering

There's still quite a few merchants which give it the evil eye since evidently one can distinguish them from "real" credit cards if the processor chooses to look, but it's better than nothing

Column is the first I've ever heard of a bank offering this level of financial firewalling


Yeah, I use Privacy extensively and on rare occasions have been rejected by merchants because of their no gift cards allowed policy. So apparently that is the category Privacy virtual cards come under.


That changed recently. As part of the migration, they had to reissue all cards, but they’re now charge cards instead of prepaid debit. https://news.ycombinator.com/item?id=29432683




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: