pc

I don't think that customers or businesses should see Tempo very much. In the success case, Tempo is a platform like SWIFT or ACH that others employ behind the scenes to orchestrate transactions. "Decentralized, internet-scale SWIFT" isn't exactly the right analogy (there are clearly lots of differences), but it's not totally wrong either.

Why are businesses finding crypto easier/faster/better?

Yeah, I think this is the natural follow-up question. The answer differs a bit based on the use-case, but there are a few common reasons:

* Instant on-chain transfers avoiding trapped liquidity. If you're transferring money from financial institution A to institution B, and the transfer takes a day, you're either slowed a day in taking the next step or you have to somehow cover that float. Depending on your movements and their predictability, that can require big buffers.

* Fees that are lower than cards. Card payments are instant, which is often valuable (and superior to many bank transfers), but card transactions are also expensive relative to stablecoins. (And while card authorization is instant, settlement is not.)

* Reliability. This sounds funny, but, when sending money between countries, there are many more manual processes involved at the associated financial institutions than one might think. Money is frequently just... lost, and humans are required to hunt for it. (We see this all the time at Stripe.) Crypto is punishing if you make a mistake, but, if you do things correctly, reliability is all-but guaranteed.

* Fewer currency conversions. Wholesale FX for major currencies is very cheap, but minor currencies can have bigger spreads, and the actual fee incurred by a regular customer (e.g. with their bank) can be significant. Stablecoins often make it possible to skip conversions that would otherwise happen.

* Access to USD-based functionality. The US is the world's most sophisticated financial services market. Having a stablecoin means "having an on-chain asset", but it also typically means "having a USD asset", and a lot of major parts of the ecosystem (e.g. US equities and credit markets) primarily, or only, deal with US dollars.

Acknowledging the obvious, a reflexive answer frequently invoked here is "it's regulatory arbitrage", but I think this is some combination of misguided and incurious as an explanation. First, stablecoins are now formally regulated in the US (with the GENIUS Act) and in Europe (under MiCA), so their use is now very explicitly regulated. Secondly, it implicitly assumes that the only reason one would seek an alternative to the traditional ways of doing things is because someone is doing something illegitimate. I think this usually indicates a lack of understanding of the challenges, complexities, and costs associated with high-volume cross-border money movement. Indeed, and somewhat ironically given the claim, one of Bridge's large customers is the US government.

Importantly, none of these businesses are using crypto because it's crypto or for any speculative benefit. They're performing real-world financial activity, and they've found that crypto (via stablecoins) is easier/faster/better than the status quo ante.

That said, I'm somewhat skeptical of the safety argument, which I often hear. For example, 60 workers were apparently killed during the construction of the World Trade Center[0] -- 4x more deaths than occurred during the construction of the Empire State Building. Nor is it a priori clear to me that safety and speed would necessarily be in opposition -- maybe better planning causes both more safety and more speed, for example. I'd certainly be interested in a more comprehensive investigation of this question.

I'm also somewhat doubtful of cost-of-labour explanations. Wouldn't it be rational for some organizations to pay a lot more to get people to work longer hours if that's all that's going on? (It would almost certainly be cheaper to do that than to have the project take twice as long in total.) And why did many of the instances enumerated on the page happen in relatively high cost (for the time) locations, like New York, DC, and San Francisco, rather than in cheaper places?

I do believe that state/military intervention clearly plays some role in a few, but there are certainly plenty of examples of remarkably slow military projects, and many of the projects on the page have nothing to do with the military. (Empire State Building, Golden Gate Bridge, Boeing 747, NYC Subway.)

So, I haven't found a satisfying explanation, and I'd be curious to read other analyses or diagnoses.

[0] https://en.wikipedia.org/wiki/Construction_of_the_World_Trad...

We obviously never intentionally ghost companies, “mine them for information”, etc. The ecosystem is small and we wouldn’t be able to invest in and acquire companies if we didn’t have a reputation for good behavior. (And we’ve invested in dozens.) But maybe some communication got dropped in some particular case or something? I don’t know.

All of that said, I’d appreciate hearing from any founders who feel mistreated as part of an acquisition process. We make a fairly significant number of acquisitions and have never heard this directly before.

More than 10,000 people have interviewed at Stripe so far this year, so "several sigma bad" still happens to an unfortunate number of people. That said, we want those who interact with Stripe to come away having been treated professionally and respectfully, and our recruiting team cares about fixing our process failures. On behalf of Stripe, I apologize.

(There is proof that significant financial resources aren't needed to do great work in a lot of personal websites. Most recent example I came across: https://bruno-simon.com.)

With regard to the last part of your comment — absolutely. This is a final recourse when the system breaks, not a part of the system that we hope you ever have to use.

Ugh, apologies. Something very clearly went wrong here and we’re already investigating.

Zooming out, a few broader comments:

* Unlike most services, Stripe can easily lose very large amounts of money on individual accounts, and thousands of people try to do so every day. We are de facto running a big bug bounty/incentive program for evading our fraudulent user detection systems.

* Errors like these happen, which we hate, and we take every single false rejection that we discover seriously, knowing that there’s another founder at the other end of the line. We try to make it easy to get in touch with the humans at Stripe, me included, to maximize the number that we discover and the speed with which we get to remedy them.

* When these mistaken rejections happen, it’s usually because the business (inadvertently) clusters strongly with behavior that fraudulent users tend to engage in. Seeking to cloak spending and using virtual cards to mask activity is a common fraudulent pattern. Of course, there are very legitimate reasons to want to do this too (as this case demonstrates).

* We actually have an ongoing project to reduce the occurrence of these mistaken rejections by 90% by the end of this year. I think we’ll succeed at it. (They’re already down 50% since earlier this year.)

> A concrete suggestion: make it possible for businesses to choose whether they have access the raw data, and expose the choice to the end user in the Stripe Identity flow. Ideally, businesses that want the raw data would be subject to security compliance requirements. This is an opportunity for Stripe to be a leader in setting high standards on how this type of data should be handled.

Yes, per GP comment, I think this is a good idea. I suspect we'll do it.

> Considering that Stripe was originally known for letting websites accept credit card payments without seeing your credit card number, one might assume that Stripe Identity only allows websites to see the verification result, and not your selfies and scans of your identity documents.

A few points:

- Fundamentally, Identity makes it possible to choose how much of this data traverses / is stored on your servers, just as Stripe did with card numbers.

- There's a basic difference between card numbers and identity verification. With card numbers, you (generally) don't really care about the number -- you just want the payment. With ID verification, however, many businesses have good reason to want more than just the verification result. For example, they are often subject to compliance requirements that mandate that they themselves possess or have access to the raw information. They may need or wish to perform additional checks on their side. Etc.

- The relevant UI in Identity is deliberately very clear on this points in order to avoid the assumption you're stating. The flow explicitly says "Stripe and [Business] may each use your data." Even though an end user might consider it suboptimal for the business to have their data, we still view it as an improvement to the usual status quo, where this data is frequently stored in very ad hoc fashion and without rigorous security protections.

- While many of the businesses initially building on Identity wanted access to the raw information, it may well make sense for us to enable them to restrict themselves in the future. In this world, Stripe could tell their customers that the business doesn't have access to the raw details. (This might even make sense for Stripe payments in the future.) As a philosophical matter, we consider ourselves to serve the business, which means that limiting access to what we consider to be the business's own information feels a bit strange. That said, it might sometimes be in the interests of the business to allow them to limit themselves in this fashion (especially as Stripe's brand recognition among consumers grows).

- There's a separate concern about compromise of the business's credentials leading to inadvertent disclosure of this information (a situation analogous to an S3 bucket key getting leaked). This is of general concern to us in lots of situations, not just with Identity. We have some new functionality on the way here.

* Uses various sophisticated heuristics to detect real vs fake IDs.

* Matches the ID to the human face.

* Detects whether the human face is live or not.

* Dynamically requests more or less information depending on the confidence level.

It also gets better over time based on the attacks and fraud attempts that Stripe itself sees.