MaxGabriel

1. Nested database transactions could exhaust the transaction pool and deadlock 2. Same as you described with doing eg HTTP during transactions

We now have a compile time guarantee that no IO can be done outside of whitelisted things, like logging or getting the current time. It’s worked great! Definitely a good amount of work though.

I think this is likely unnecessary for most use cases and is mostly a RAM saving measure, but could help in some cases.

* It's obvious from the schema: If there's a `deleted_at` column, I know how to query the table correctly (vs thinking rows aren't DELETEd, or knowing where to look in another table)

* One way to do things: Analytics queries, admin pages, it all can look at the same set of data, vs having separate handling for historical data.

* DELETEs are likely fairly rare by volume for many use cases

* I haven't found soft-deleted rows to be a big performance issue. Intuitively this should be true, since queries should be O log(N)

* Undoing is really easy, because all the relationships stay in place, vs data already being moved elsewhere (In practice, I haven't found much need for this kind of undo).

In most cases, I've really enjoyed going even further and making rows fully immutable, using a new row to handle updates. This makes it really easy to reference historical data.

If I was doing the logging approach described in the article, I'd use database triggers that keep a copy of every INSERT/UPDATE/DELETEd row in a duplicate table. This way it all stays in the same database—easy to query and replicate elsewhere.

We allow multiple security keys. You can add more here: https://app.mercury.com/settings/security

To be clear this is what we're trying to avoid. An easily typeable code like that can be typed into a phisher's website.

That said, our security team and I agree there is no security issue here. Mailgun already can see the text of the emails we send.

You shouldn’t get the device verification requirement if you’ve used the device before (we store a permanent cookie to check this) or for the same IP. Any chance your cookies are being cleared regularly?

We added this after attackers created clones of http://mercury.com and took out Google ads for it. When customers entered their password and TOTP on the phishing site, the phisher would use their credentials to login and create virtual cards and buy crypto/gold/etc. The phisher would also redirect the user to the real Mercury and hope they figured it was a blip.

This device verification link we send authorizes the IP/device you open it on, which has almost entirely defeated the phishers.

Since WebAuthn is immune to this style of phishing attack, we don’t require device verification if you use it. I highly recommend using TouchID/FaceID or your device’s flavor of WebAuthn if you can—it’s more convenient and more secure. You can add it here: https://app.mercury.com/settings/security

That said, we are talking internally about your post and we do recognize that as IPv6 gets more traction IPs will rotate much more regularly, so we’ll think if we should loosen restrictions on being a same-IP match.

Lemme know if you have any questions!

Should this be “an” in the page header?

(I helped make such a product 7 years ago)

https://github.com/orgs/community/discussions/36568

(This was an issue for us during the beta)

Edit: it’s fixed by requesting the desktop website.

You as the customer are the owner of record on the funds. The accounts are held by our partner banks at these other banks, as your agent and custodian (something like "Evolve Bank and Trust for benefit of Acme Corp).

The FDIC insurance applies to the business holding the funds; it is definitely not insuring Mercury itself.

You do need to use Mercury to withdraw the funds; we still run all the authorization and compliance rules around this, and there isn't a facility for you to go into eg United Texas Bank and ask for your money. That said, if Mercury were to go bankrupt tomorrow, your funds are held by our partner banks who have full KYC/KYB info on you would be able to access all your funds.

1. As others have said in the comments, I wouldn't assume all funds are 100% insured. It is trending that way but I think if you are a CFO managing 10s of millions, its responsible to consider other assets.

2. Our interest rates on Treasury are pretty competitive, up to 4.67% for the slightly-less-conservative fund MULSX (various conditions apply, depends on how much you hold in treasury, etc; see https://mercury.com/treasury for details).

We are OK not having the absolute highest interest rate offering. Our position is:

* The Mercury product is much better than what most banks offer, across features like searching transactions, WebAuthn logins, virtual cards, etc (You can try the whole website at https://demo.mercury.com/)

* Mercury is much better optimized for startups (eg compliance that understands startup needs, doesn't ask your CEO to go into a branch to send wires)

You can always get a higher interest rate by eg buying treasuries yourself. Our position is for most founders, investing in these mutual funds is a safe, no-brainer options that optimizes for safety while keeping the convenience of a single dashboard.

- We currently work with two partner banks, Evolve Bank and Trust and Choice Financial

- Both our partner banks operate or are part of a sweep network (https://mercury.com/blog/company-news/understanding-bank-swe...), where they can move funds into other banks. Each bank your money is in increases FDIC coverage by 250K.

- For customers on our partner bank Evolve, this was bumped from 1mm to 3mm as of this morning. You get this automatically if you have accepted the T&Cs for the sweep program already; if you haven't you can do so at: https://mercury.com/settings/vault

- For customers on our partner bank Choice, you're still at 1mm FDIC insurance. We are working on getting you an Evolve savings account (or getting increased coverage from Choice) by tomorrow morning, or you can keep excess funds in Treasury (see below)

# treasury

- We also have a product called Mercury Treasury. This allows you to invest in mutual funds, the safest of which is a Vanguard Treasury Money Market fund (VUSXX), which invests primarily in short-term U.S. Treasury bills https://investor.vanguard.com/investment-products/mutual-fun...

- These securities are held in your name at Apex Clearing, which is https://www.apexclearing.com/

- They're not part of any fractional reserve system like with banks; every share of a mutual fund you hold is in your name and Apex can't lend against it (unless you give them permission which would be weird)

- You can automatically sweep any funds between our treasury product and your savings account. Liquidity is about 3 to 4 days.

- All treasury funds are visible on your Mercury dashboard, so you don't have to manually manage fund movements or keep track of your total balance across websites

- You also earn interest on these

AMA if you'd like, though caveat I'm jumping between a lot of Slack messages right now (edit: probably bowing eat to eat lunch)

List of investors here:

https://mercury.com/about

This can be helpful for avoiding resource contention, or hitting an API limit.

I thought Vitalin Buterin had a really nice steelman of Bitcoin maximalism.

http://business.sos.ri.gov/CorpWeb/CorpSearch/CorpSearchRedi...

https://opencorporates.com/filings/1091852658

Does this sound correct to you / if so can you remedy it with Rhode Island? (edit: our onboarding team says you specifically want a Certificate of Good Standing from the state)

That said, this should have been communicated as a clear rejection reason—we'll work on that.

Neither. The funds are held by those banks, but you won’t ever deal with them directly nor have any login to them

> Would I need to fly to the US to get this started, or would a zoom session plus all the relevant ID's be enough?

You just sign up online and provide documents. No zoom sessions.

If you have the relevant documents signing up should take ~15 minutes

(CTO at Mercury)