Twice I've sold an old car to somebody who answered my ad. I wanted cash on collection only, because I was selling the car to someone I didn't know, couldn't reliably trace and therefore could not trust. If they'd reversed the payment afterwards, I'd have been down a car.
Both parties to this kind of transaction understand why finality is required, and don't have a problem with it. It's a second hand "sold as seen" transaction. The buyer knows where the seller likely lives. The seller doesn't know anything about the buyer. Neither party typically carry that kind of cash around, so there are two trips to the bank (with their own risks) that could be saved if there were some sort of easier digital equivalent.
If they'd have turned the corner to see the engine fall out from underneath the car, while you'd have already strolled off the scene with the money, they suddenly wouldn't be so happy with finality. I think finality in transactions is more something about "the nominal case". If I'm a transaction processor with significant volume, I would like to reach some final state without too much intervention, but I can still handle the exceedingly-rare exceptions with (expensive) humans. Where that point lies differs per application, also dependent on what kind of service I'm wanting to deliver.
> If they'd have turned the corner to see the engine fall out from underneath the car, while you'd have already strolled off the scene with the money, they suddenly wouldn't be so happy with finality.
Maybe, but since I also wouldn't be too happy if they reversed the transaction after taking the car, we both agree in advance that the sale will not be reversible. For the payment, that's done by using cash (and the possession of it), and for the car, also just possession. I give the buyer the opportunity to inspect the car before committing to the sale, and then it is "sold as seen". Unless I committed fraud, the engine falling out from underneath the car will be the buyer's problem, including in law.
It is always possible to seek redress through the courts whether the financial transaction itself was reversible or not, so that's not relevant here. Neither is the fact that to do that knowledge of identity and evidence is required; those concerns also exist regardless of transaction reversibility.
That's why you test-drive a car and/or have it inspected. If it is a clunker and the price of the inspection approaches the price of the car you can just take the risk. In any other case an hours worth of time of a competent mechanic will tell you all you need to know. After that the risk is yours if you decide to go through with the purchase. If something does turn up that wasn't disclosed the seller will usually be happy to adjust the price. And if not you are only out the inspection fee. Typically $50 to $150 so well worth it on any vehicle purchase that is in the price range where 'engine fell out' feels like it isn't on the menu of expected events.
> If they'd have turned the corner to see the engine fall out from underneath the car, while you'd have already strolled off the scene with the money, they suddenly wouldn't be so happy with finality.
Which is exactly the point of the finality of the transaction. Private party car sales in the US typically are not warranted. The risk of maintenance on a used car is non-zero, and the buyer accepts this risk when buying a vehicle with no warranty.
But in all seriousness, if you are a vendor then any purchase by a customer that is not associated with a legally accountable entity must be settled with finality, because you have no way of preventing charge-back fraud yourself.
In cryptocurrency marketplaces, the customers vet the vendors, not the other way around. This is because the vendors have a higher upfront investment in their business and reputation. The customers are not expected to maintain a reputation (for sake of their privacy) or an investment (outside of an multisig escrow) so any attempt to vet them is prone to sybil attack.
The process of vetting customers is usually assumed by some monopolistic intermediary like PayPal. These companies are able to vet customers by implementing a mass surveillance system.
If you are a merchant selling goods and services for money, and had the choice between transactions with finality and without, you will always chose transactions with finality.
If customers demand reversible transactions, you will choose reversible transactions or you will not have customers.
There are, for instance, no longer many mainstream online merchants who accept only irreversible transactions. There once was a time when online transactions were primarily paid via money order, but PayPal and credit card processing has made that obsolete.
> If customers demand reversible transactions, you will choose reversible transactions or you will not have customers.
I think most customers pay with credit cards more because of convenience (or rewards, where applicable).
There's a myriad of QR payment systems popping up around the world (e.g. WeChat, UPI, PayNow) that are getting considerable adoption — and those aren't reversible. They're popular because customers don't have to worry about carrying enough cash with them.
You can't compare in-person and e-commerce payments in that way. The risk for the merchant and the customer is completely different:
A physical merchant usually has a storefront in a public place that they can't abandon on a whim, a reputation to lose etc, whereas the customer is usually anonymous and mobile. This is why customers are generally ok with paying using a (to them) irreversible/final payment method, and merchants will insist on it.
In e-commerce, the risk lies almost exclusively with the customer: An online store's reputation is not easy to judge (and brand impersonation is its own risk), and even at reputable merchants, the time between order and delivery is much longer, goods can usually not be inspected ahead of time etc.
Not coincidentally, the various card schemes' rules reflect this circumstance by assigning default liability for online payments to the merchant (or their acquiring bank, in case of a fraudulent or bankrupt merchant), whereas for in-person payments it lies with the cardholder (or in case of fraud with their issuer, in some circumstances).
The landscape of trust online is varied. Someone is likely to have lower trust for random website you’ve never heard of (which was most stuff in the early days) than an established business or one with a physical presence.
Now that online retail is mature and trust is high, credit cards are more for convenience, but this wasn’t the case in the early days… and still isn’t the case for lesser established sellers or marketplaces.
When was this time that online payments were done with money orders? Some of the earliest online merchants that were associated with AOL and Prodigy accepted credit cards. Amazon definitely accepted credit cards from day one.
In the mid to late 90s many retailers online operated like mail-order catalogs with catalogs delivered via http. Many of them were mail-order businesses first, and so they accepted payments for online purchases the same way they did for their majority of their customers.
This was also normal for eBay payments at the time.
There were, of course, a few that did accept credit cards, but many people were weary about using those features because very little of the web used HTTPS at the time. Even Amazon accepted money orders (and personal checks!) for this reason.
Not always. If customer fraud is low and customer wariness is high, you might well find that providing customers the safety of the option to reverse the charge gets you enough more money that it nets you more overall. Even more so if "finality" of the technology means that users instead turn to the courts to dispute your charges.
There is a narrow sense in which the merchant "always prefers finality" but it isn't the relevant sense.
Buying a house does not have 'finality' in that sense. This is why you buy title insurance - many things can happen where it turns out you don't own the house like you thought.
Happened recently, ordered pizza but they delivered to wrong address. Called them they wanted to deliver pizza again but it would have been too late. So they refunded the transaction, though seemed a little reluctant.
My guess is that if I had no option to do a chargeback, it would have been harder to get a refund then.
Then the dissatisfied customer throws a fit and warns their peers that the vendor isn't trustworthy.
There is an asymmetry here because anyone can be a customer but not everyone can be a vendor- that requires a certain level of reputation and upfront investment. So it is more risky for a vendor to scam a customer than the other way around.
I don't know, I hear all the time about people buying things on amazon or something and when it arrives it's just crap and you can't get a refund. At the end of the day, getting a refund is not about the payment method, it is about your business relationship with the vendor.
Cryptocurrency transactions require high trust in the sense that they cannot be refunded, but they also require low trust in the sense that the vendor cannot possibly steal any more money than what you sign them.
If you are going to argue by anecdote at least use a believable anecdote. Amazon have one of the most customer friendly refund policies and always offer a refund or replacement- obviously because they are just pushing it on to their sellers but still, they do.
> Amazon have one of the most customer friendly refund policies and always offer a refund or replacement- obviously because they are just pushing it on to their sellers but still, they do.
With an open season of friendly / chargeback fraud, customer lies, refund tricks, etc which customers keep doing every day and so on which too many of that and Amazon will ban your account and they should.
then the cook should be left uncompensated for their work? There is no "fair" outcome in this situation, so you should at least make the system fail in a reliable way.
Normally, with credit cards and stuff, the onus is on the vendor that made the sale, technically they should verify the Id of the user match with the name on the card and stuff.
Most don't do because convenience wins for the user and increases the value.
The user knows if something is wrong (like stolen funds, accounts etc) they will get their money back, and trusts the system so spends more.
İf you don't provide this trust system, they won't spend as much as they do.
This is why Plaid is so successful, it allows banks/fintech companies to validate that the information on the counterparty account matches what you claim, that it has sufficient amount, name and email matches.
The bank can also decide if he wants to deny an ACH debit or do a manual review of it, for example above a specific amount of if its the 1st ach debit.
Also the clearing days (when you will see money in your bank) will be different depending on different risk factors.
You can read more here about how to mitigate ACH fraud with tools such as Plaid - https://guides.unit.co/fraud-and-disputes/
disclaimer - I am an engineer at Unit.
Plaid also allows its customers to scrape 24 months of transaction data from bank accounts, and gain a constant stream of data about ongoing transactions from the bank account.
It’s a very intrusive data-mining service that should not be trusted with bank account credentials, at-least if you care about data privacy.
Change your bank account password, and you may even see Yodlee (like Plaid) trying to login to your bank account every night to scrape daily transaction data based on some ’bank verification’ you previously gave to some app or 3rd party.
Yeah, place many places where you can pay with ACH require validation that you have access to that account by making small transactions. Plaid will be "instant", but manual ACH will take a few days, even though manual ACH could be the same kind of "instant".
A feature is a data point to your model.
it can be as simple as the amount of a transaction (for a fraud detection model) or as complex as the avg_number_of_transactions_in_the_past_7_days_with_over_1k_in_amount_that_were_pending_review.
Since you have many features, and they constantly change and evolve and being consumed by many models you need a way to store them - thats how feature stores came to be.
I personalty never used.
Second this, his talks are very elaborate, has great pointers to reading material/coursework - as if you were sitting alongside the students in UCL.
Very involved though - if you have a 'day job'.
Hi, I am an engineer at Unit.co, a company that also builds Banking as a Service.
We use PostgreSQL as database, and currently thinking about adding ElasticSearch to allow our users to do text search.
Friend, its in poor taste to hijack a question about a competitors product to spruik your own - I would be less likely to consider Unit.co as a result of what you're doing here.
My answer was written with the intention of helping others and sharing my knowledge with fellow engineers, I enjoy talking about tech and engineering and even thinking of writing a blog post about it.
Friend, it's bad form to impute negative motives where (over)exuberance is a sufficient explanation. This guy cares a lot about the product he or she works on, simply move on if their comment is not for you.
Hi, I am an Engineer at Unit.co, a company that also builds Banking as a Service.
I can share that not only we do not use COBOL, but our entire backend is written in Pure Functional Scala (and typescript for UI).
I am one of the Engineers at Unit.co - we are also building a platform that allows developers to embed financial features into their product
Congratulations on the launch! the market is huge and competition is welcome :)
Column took a very interesting route, while we have Bank Partners that we develop with them, Column is also the bank , curies to know why they decided to take this route.
If you think Word2Vec is cool, you can try to google X2Vec with whatever X comes up to your mind. you can almost make anything into a vector using the right neural network.
At my previous job I created a LinkedPage2Vec and used it to find Look Alike people for B2B marketing and sales. I also played a bit with Code2Vec.
