> Unfortunately people are not 100% trustable, devices are not 100% secure and code is not 100% perfect.
- which is actually why you use crypto.
> If someone steals my credit number, I will likely not be on the hook for the money and will not lose anything.
- because the bank guarantees the safety of the payment means you use. The fact that you don't have to pay (as a private customer) doesn't mean that stolen credit card numbers and fraud transactions don't cost money. Someone has to pay somewhere in the chain. If the principal is recovered (the stolen money), then someone still has to pay for the overhead of recovering the money (for you). There're insurance and liability-shift mechanisms in place, but the money transfer would be much safer, faster, and cost-efficient if crypto was in place.
> If I make a mistake during banking, I can turn to people at the bank about it.
- So? It's not because your infrastructure uses crypto that you give up of customer support.
which is why (in my viewpoint) it matters a great deal, and there's just no way back. Trust is required for monetary exchange, but not only. It also matters where very strong guarantees are needed, which is everywhere, e.g., when setting up contracts or when making statements (expert or regulated) about a product, service, or a status. Trust matters because then the whole value-chain gets more efficient, rapid, and cost-effective.
For a few years I worked on a startup that aimed to address fraud management in e-commerce from a quantitative risk modelling perspective. And when Stripe released radar 2.0, I went through their docs. I was impressed by Stripe's marketing (docs) and UI—they're knowingly good for that, but I was much less impressed by radar 2.0's feature-set and product. The biggest issue for me was their "one-size-fit-all" approach, because that just does NOT work in what I've seen, i.e., both billion- and million-euro businesses.
From a risk management perspective, a 2-7% gross margin e-commerce manages risk totally differently than a 50%+ gross margin e-commerce. For one, the false negative (i.e., a fraud gets through) is super-expensive. For the other, a false positive (i.e., a real client is stopped) is super expensive. And I did not see anywhere in their docs how they integrated the cost-imbalance of the risk for each of their client (you), and event less for each of their client's clients! It's possible to do, but it's hard.
Of course, like any fraud prevention system, radar 2.0 allows clients to add rules and lists to customise their logic, but these mechanisms are difficult to setup when you start processing payments, because you don't have yet any payment history, as well as when your e-commerce gains in velocity and complexity, because you don't necessarily have the in-house resources or skills to keep your rules and lists up to date and well maintained.
And in the lucky case that one just feels happy with Stripe's radar 2.0 system, then how do you know that you're not loosing customers? Having no risk of chargeback is very easy, just don't accept any payment and you've a risk-free e-commerce! In my experience, we increased sales by 7% (a few tenths of millions of euros) by just re-parameterising how fraud was managed. I don't see anywhere anywhere in the docs why and how I should trust radar 2.0 for the specifics of e-commerce A, B, and C. One-size-fit all just doesn't work.
As a former startup founder in that area, I still see we're a long way towards personalised risk management in e-commerce services, that would help owners throughout the different stages of their e-commerce, i.e., idea, proof of concept, scaling, growth... sounds similar?
- How did you guys scale that much w/o a bootloader before?
That's what I don't get. All the design patterns are those of Unix. You boot the kernel with a ... bootloader. Then you've the kernel with all the system's params (call it ECS). Then each process is a child of the root process. And when you get by whatever mean the news that your app's source code has changed, you pull that code and start running it, while still having the old one live. Once the fork of the new code returns a proper response code, you kill the old one and set the new app live, otherwise you stay live with the old version.
I have a dataset management mechanism (delete, copy, duplicate, etc.) where dataset attributes are tagged as PII (personally identifiable information), and where generic filters are then applied to obfuscate PII for datasets that'll be used by non-privileged users, e.g., data science.
- It's not bullet proof, but it achieves what I'm looking for.
+1, tomasdpinho. Yes to everything, and notably the queues everywhere, versioning the models, and the issue to mix sync and async (go for queues).
As a scientist designing risk management systems, I also like to:
. avoid moving the data;
. bring the (ML/stats) code to the data;
. make in-memory computations (when possible) to reduce latency (network+disk);
. work on live data instead of copies that drift out-of-date; and
. write software to keep models up to date because they drift with time too and that's a major, operationally un-noticed, and extremely costly problem.
I'm not yet into Tensor/ML-Flow, but I use R, JS, and Postgres, thereby relying on open-source eco-systems (and packages) that are:
. Tesla claims:
A 40% crash rate reduction with the autopilot
as compared to no autopilot, over an 18 month period [1].
. If this is true—and we could imagine it is (at least
partially?)—then Elon's remark to journalists would make
sense:
"It's [..] irresponsible [..] to write an article
that [..] lead people to believe that autonomy is
less safe,” [..] “Because people might actually
turn it off, and then die" [1]
* * *
But to have an opinion about the autopilot's risk statistics I would also need to know:
a) What populations (data) they compare;
b) How each population is defined (inclusion and exclusion criteria);
c) What's the sample size (18 months, and?);
d) Who makes these calculations (to clearly identify possible conflicts of interests).
- Not sure if this type of data is publicly available?
* * *
Actually the National Highway Traffic Safety Administration (NHTSA) seems to indicate[1]:
1) that the data comes from Tesla—cf. point d) => conflict of interest;
2) Autopilot on/off was NOT used for the risk statistics—although it's central (point a);
3) instead the "40%" would measure the "number of airbag deployments per million miles" which is a proxy-metric that's not directly related to car accidents.
- Hey, this is odd (it's definitively not a Science or Nature method protocol).
* * *
. "The Insurance Institute for Highway Safety suggests:
A "13%" reduction in collision claim frequency, indicating
sedans with Autopilot enabled got into fewer crashes
that resulted in collision claims to insurers."
However it's a small difference and there're possible confounders like social status (a "Tesla driver"), gender, geographical area, and usually the confounders have a large influence on experiments, so it's unlikely that this (small) 13% difference would remain if we adjust for confounders...
Yes, I read something like that too :-) It's definitively not clearly mentioned and we could (still) qualify the procedure as 'obscur'. Though the same would hold for France- or Delaware-based comps.
Generally:
- on boarding is easy and relatively cheap,
- off boarding is more difficult.
And if you want to close then:
1) you better do it right—it's a process with rules that can take weeks if not months;
2) you gotta pay unless you declare the business bankrupt;
3) it takes a lot of off-the-path back-and-forth exchanges with people that have limited incentive to help you.
And back to LHV, I've seen the PayPal account verification deposit (two payments of a few cents made to one's account) appear extremely fast on the account—I think it was less than one hour.
I'm within the 1st year of e-residency + incorporation.
Here're a few of my experiences.
1. Setup is not as straightforward as they claim, but it's still quite easy. It compares well to what I've seen in France (LegalStart, CCIs, etc.) and the USA (Clerky/C-corp, Delaware, etc.). Actually there's no (printed) paper work because all is digitally signed with your e-residency card—only that is a big plus.
2. Running the company is similar to a C-corp but it's 10x easier than an SAS in France—where you've to register for, know about, and manage nearly 10 different tax agenda. It's also 2x to 5x cheaper to run than in USA and France.
3. However, it's true that banks are lagging a little behind but to their defence they face AML/KYC requirements, and e-residency is a lot of randomness for them—needless to say (?) that banks are risk averse.
For comparison, note that Clerky was launched in 2013 to streamline the legal paperwork for C-corps when e-residency started in 2014. And see how long it took before Stripe partners with Silicon Valley Bank (SVB) for its Alpha program.
- So I feel like banks do a good job although there's room for improvement.
4. Internationalisation of some institution's websites has bugs—basically your preference for english is reset to Estonian once in a while, but most of it is translated in English (and Russian and Finish?).
5. Some institution's websites are old looking but it's not worst than in Delaware or in France. So far, institution's websites are quite clear. For comparison: when paperwork in e-Estonia is done with digital signing, in 2017 I still had to (surface) mail or fax documents to France's and Delaware's institutions, sometimes with credit card number written in clear, or with a check enclosed—this is prehistory.
6. For the legal setup and accounting, I use LeapIN. So far they're very professional, their website has an extensive Q&A and knowledge-based section—that I read. Their pricing segments are clear. And they seem to have a growth mindset—reach out for more advice on how to onboard and their price.
7. Money-wise I was unaware of the 50% social capital requirement left on your account at the end of the fiscal year (note that it also exists in France and, by inference, probably in some other European countries)—maybe they could communicate more on that, it's not nice to figure that out later.
- Still, so far I feel I've got value for my money and I can pull out if needed—no commitment which isn't the case of many B2B SaaS solutions with long term contracts (if we compare).
LHV is for the merchant account, it's needed for EveryPay.
Their price structure is not fully pay as you go:
- there're no setup fees; but
- there's a fixed monthly fee—a so called terminal fee of 20EUR; and
- then there're the transaction fees—about 2.2% which is much less (!) competitive than Stripe's fees in the EU—1.4%.
Although I like what I've seen so far, as an app-developer, the fixed monthly fee wasn't acceptable. Plus, interaction with LHV was kind of painful (in this particular case, english was an issue).
- which is actually why you use crypto.
> If someone steals my credit number, I will likely not be on the hook for the money and will not lose anything.
- because the bank guarantees the safety of the payment means you use. The fact that you don't have to pay (as a private customer) doesn't mean that stolen credit card numbers and fraud transactions don't cost money. Someone has to pay somewhere in the chain. If the principal is recovered (the stolen money), then someone still has to pay for the overhead of recovering the money (for you). There're insurance and liability-shift mechanisms in place, but the money transfer would be much safer, faster, and cost-efficient if crypto was in place.
> If I make a mistake during banking, I can turn to people at the bank about it.
- So? It's not because your infrastructure uses crypto that you give up of customer support.