People underestimate how difficult it was to transfer money before Pix, even between local banks. The process was hard to use, it could take days and the fees were huge, depending on your bank. Pix solved all these problems.
What happens also is that many sellers provide discounts when using Pix, because you dodge the expensive fees charged not only by Visa and MasterCard, but the fees operators (banks, fintechs) charge to provide the infrastructure (PoS machines, financing for installments, etc, the last one being quite common in the country) to use these networks.
I think we need to put this in context for folks who are not from Brazil.
Comparatively, a domestic bank wire in Brazil before Pix was already easier and faster than one in the US today. I don't recall the bank fees being bad either.
The issue is that bank wires were never designed for buying lunch at the food court. They're not instant and not user friendly to set up.
Pix is alien technology next to the stuff we have in the US.
The entire problem solved by Pix is an artificially created obstacle put in place so banks can charge for something they do for free.
The article doesn't mention China's digital renminbi, but it is similar, including the aspect of being offered by the country's central bank.
Rather than this looking like "Alien tech" in the US, it's just another example of things in the US looking more like stone age tech to the rest of the world.
Like banned chinese EVs, and a pushback on solar electricity generation, all of these are manifestations of the US government primarily making it easier for multi-billion $$ multi-national corpses to filch the general population.
This isn't just the orange cheato, it's been the policy of every modern US administration, with the backing of the majority of the legislature.
And for some reason, the plurality of voters seem to be in favor.
It’s a distributed transaction, which is what makes it complicated. You need to atomically remove money from an account in one database and add money to an account in a totally separate database.
There’s a bunch of weird corner cases that come with that. What if the receiving account ID doesn’t exist, or the recipients bank flags the transaction, or the sender closes their account before the recipients bank has applied their end of the transaction.
I think some of these transfer systems are simpler because they’re global so both records are in the same database. Transactions can be technically atomic rather than organizationally atomic (ie atomicity is present in the technology, rather than approximated by processes).
It sounds a bit like the Dutch Tikkie with the QR codes and instant transfer. Of course, in the EU most bank wires are already free when using SEPA, and often nearly instant as well. This Tikkie thing is a way to easily create a payment request for people who can't be arsed to simply carry cash (and raise the country's resilience to system failure in the process).
Brazilian living in NL, experienced in both. I think biggest difference is Tikkie doesn't give you an easy identifier. Great for privacy, but being able to send money to your email/phone number makes a difference for some real time use cases. QR code helps, but it is not the same.
Since last year, all EU banks have to support SEPA Instant Transfer, both receiving & sending, at the same price as a usual transfer (Instant Payments Regulation 2024/886)
If only https://en.wikipedia.org/wiki/EPC_QR_code supported a sepa instant bit so that one could just show a qr code, scan it with whatever payer banking app and authorize the sepa instant payment.
This is what Ideal/Wero does. Because this is the standard for webshops in the Netherlands (and rapidly expanding to the whole EU) the only gap left to fill was that of consumer-to-consumer transfers with just a QR code to scan. Tikkie I mentioned above solves that well enough in the Netherlands, although that bank-run app is horribly laden with stupid ads and deals you can't seem to turn off.
Pix is ok - but it’s clunky to use and has a single point of failure.
On the former - paying is:
Unlock phone
Launch app
Authenticate
Choose to pay with pix
Scan QR code
Enter amount
Authenticate again
Wait
Payment made
Show cashier your phone
Which is considerably more involved than a contactless payment.
On the single point of failure side of things - I was at an event in Brasilia a month or so back, pix grinds to a crawl, taking 10+ minutes per transaction, and the drinks queues rapidly got out of hand. As nobody accepts cash any more, and because nobody has a card any more, this meant they sold practically no drinks.
So it ain’t bad but tbh passing bits of paper back and forth is still easier.
There's Pix contactless payment. Both Samsung and Google wallet support. Samsung added a few weeks ago. Google added 1 or 2 years ago.
You can actually pay QR Code Pix now with Samsung by just opening the camera too.
Apple refuses to implement Pix on Apple Pay, and regulatory agencies are trying to change that...
Pix integration with Google Pay it's just amazing.
Imagine the situation in the US as if every app or website magically used Google Pay.
Well, that's Brazil now if you use Android. Because as soon as you copy a Pix code, it will prompt Google Pay :) And every service in Brazil have Pix... Even international ones as Stripe supports...
USD is a hard currency unlike the BRL. It is not supposed to move that fast by design. Google “Regulation E”. Brazil has no such strong provisions for protecting unauthorized transfers out of your account
Doesn't seem too different from QRIS in Indonesia, authentication is relatively painless since some apps offer either pin or fingerprint. Being open standard (multiple banks, electronic wallet and payment gateways support it, multiple payment apps support it, all interoperable) probably help since there's never any delay I've experienced for years, and this system is handling from small payment on roadside hawkers to electronic purchase in large stores both offline and online.
More fancy payment flow are also available, such as vendors generating one-time QR code that already include the payment amount, and the user apps generating one-time QR code that the vendor scan, thus switching some of user steps to the vendor.
In most cities I've lived and visited, using QR is far more convenient than paper. Good luck using contactless when most phones don't support it, and even when Visa & MasterCard pushed their contactless standard, I never encounter a single vendor with a working machine (this range from small shops to large hypermarket). Maybe because they have bigger MDR than QR, but from customers PoV contactless simply don't work, until QRIS also adopt NFC and suddenly it's workable (but not widespread yet since most phones still don't)
Speaking as a non-expert, I think Pix has much bigger scope. Pix is account-to-account. One can buy real estate, pay bills, make person-to-person and business-to-business transactions, government payments, recurring payments. The funds also settle instantly.
Most people don't experience the full scope of Pix which is impressive.
Sounds like pix is very similar to the Swedish swish. Phone numbers are used for identity, payments are instant, businesses often have qr codes with their identity etc..
As is the dominant e-ID platform, because our politicians are fond of bank cartels.
It kind of works and Swish does too, unless they're down which happens every now and then, but there is room for improvement that would be easier realised as a public sector endeavour.
The credit card companies really missed the boat here to become the standard for consumer to consumer payments. Of course, from their perspective, they know that people would not accept having to pay for this service so the companies won’t go near it.
I worked in a bank in Brazil in the early 2000s. Bank transfers were always easy and relatively quick. At worst, transfers would happen overnight during a national event called bank compensation where all banks would sync up with the Central Bank.
Pix solved a bunch of problems and made all of the above quicker and easier, but Brazil has been at the forefront of banking systems for a long time.
We had TED, but it was not instant, nor was it free. It only worked on working hours and took a maximum of 1h, still better than American banks, though. QR Codes is also a big deal.
The deployment of PIX was also really well executed, if it took too much I'm 100% sure that Visa and Master would've made it worse. Being quick was a wise decision
> We had TED, but it was not instant, nor was it free.
Not instant, but pretty close for the time. It might not have been free but most basic bank packages had a bunch of TED transfers included. For everything else, there was still DOC which would happen overnight and was either free or cheaper than TED.
I'm not dissing Pix in any way. Pix is probably the most advanced transfers and payments system in the world, and I'm 100% with you on how well it was (and still is) executed.
I was mostly responding to:
> how difficult it was to transfer money before Pix, even between local banks.
It was certainly not.
I remember being in the UK a couple years after I was on that bank, and being shocked at how primitive everything related to banking was. Transfers would take days or even weeks and would be incredibly awkward to make. Cheques were the quickest way to transfer money between people - other than cash, obviously, but that was not always desired.
A few years later I visited the US and it was even more retrograde than what I had seen in the UK all those years before.
Several backs had a good amount of TED limit. Although everything changed when Nubank launched, giving unlimited TEDs to everyone. Most banks followed at the time, so basically around 2015~ several big banks had unlimited TEDs.
The problem with TED it's just how hard it was to send money.
You had to insert, if I recall right:
- Person full name
- Social security number
- Select the Bank Name
- The type of account (savings or checking account)
- Agency and account number
This basically means that TED was used as a serious payment thing, like money you receive from your company, etc.
I won't dispute you or even cassianoleal, but compared to how was US in 2005 (just barely finishing check/que digitalization), Brazil is indeed faster in this forefront (and it enabled the creation of Pix in the first place).
Speaking of the forefront the UK has had interbank realtime payments (Faster Payment) since 2008. It also used to have something like Pix, i.e. bank account referenced by user's phone number called Paym from 2014, until it was discontinued due to lack of demand in 2023. Faster Payments is still operational.
When I tell that I used to withdraw cash at the ATM in one bank, cross the street, deposit the CASH in another bank ATM people think I am crazy. But I was doing monthly that circa 2014, all to avoid paying ~3 USD transfer fee (what was called a DOC/TED).
In Brazil your employer kinda chooses which bank they use and you kinda have to open a bank account with them to get paid, but it is hardly worth it to move your credit card to another bank. This is why my salary came in one bank and my credit card bills came in another.
Sorry that you wasted time but - it was wasted time!
"Salary portability" is ensured in Brazil by the Banco Centra, at least since 2006. Employees can receive salary in any bank account they choose, even if their employer processes payroll through a different bank.
> People underestimate how difficult it was to transfer money before Pix, even between local banks. The process was hard to use, it could take days and the fees were huge, depending on your bank. Pix solved all these problems.
Nearing 17:00 in a bank: Does anyone here need to do a TED or a DOC? Come to attendant now before the system shuts down for the day!
When debugging something, I often remember the the quote, often misattributed to Einstein: "Insanity is doing the same thing over and over again and expecting different results". Then I remember about bitflips, and run a second, maybe a third time, just expecting the next bit to flip to not be in the routine I'm trying to debug.
To anyone into knots, I recommend Knots 3D on Android. It is really handy because most people keeps the phone with them all the time. Beautiful and well maintained app. It's not overwhelming, in the sense that it doesn't try to add every existing knot in the same database, it has usage, which gives context, history and specially related knots, which makes it possible to compare different related knots that are usually used for the same thing.
Code review is another sacred process that seems too good not to have, but many teams use it as a "we care about quality" stamp when in fact they do not. Used for just nitpicking code style (important but not the whole reason to have CR, and there are tools for this), issue comments like "LGTM" and approve whatever arrives at the pull request anyway.
I've not yet seen code review implemented in a good way in places I have worked. It's not really considered "real work" (may result in zero lines of code change) and it takes time to properly read through code and figuring out where the weaknesses might be. I just end up being forced to skim read for anything obvious and merging, because there is not enough time to review the code properly.
As a manager, code review has two benefits that typically matter to me: (a) cost: it's cheaper to fix a defect that hasn't shipped (reading tests for missing cases is a useful review, in my experience); (b) bus-factor: make sure someone else has a passing familiarity with the code. And some ancillary (and somewhat performative benefits) like compliance: your iso-27001, soc-2 change control processes likely require a review.
It's hard, though, to keep code reviews from turning into style and architecture reviews. Code reviewing for style is subjective. (And if someone on the team regularly produces very poor quality code, code review isn't the vehicle for fixing that.) Code reviewing for architecture is expensive; settle on a design before producing production-ready code.
My $0.02 from the other side of the manager/programmer fence.
ISO-27001's change management process requires that [you have and a execute a change management policy that requires that] changes are conducted as planned, that changes are evaluated for impact, and are authorized. In my experience, auditors will accept peer-review as a component of your change management procedure as a meaningful contributor to meeting these requirements.
"All changes are reviewed by a subject matter expert who verifies that the change meets the planned activity as described in the associated issue/ticket. Changes are not deployed to production environments until authorized by a subject matter expert after review. An independent reviewer evaluates changes for production impact before the change is deployed..."
If you are doing code review already, might as well leverage it here.
Code review where I worked seem to either in practice be rubber stamping or back scratching. Never once have I felt the need for it. If people are unsure about a change they ask usually.
If teams care about each other’s code, they ought to collaborate on its design and implementation from the start. I’ve come to see code reviews (as a gate at the end of some cycle) as an abdication of responsibility and the worst possible way to achieve alignment and high quality. Any team that gets to the end of a feature without confidence that it can be immediately rolled out to create value for users has a fundamentally flawed process.
> they ought to collaborate on its design and implementation from the start
That's exactly right. After said process, it comes down to trusting your coworkers to execute capably. And if you don't think coworker is capable, say so (or if they're junior, more prudently hand them the simpler tasks — perhaps code review behind their back and let it go if the code is "valid" — even if it is not the Best Way™ in your opinion.)
I've installed flatpak to install VSCode/Codium to have an usable debugger for a Python project I'm working on. After some time tweaking VSCode/Codium trying to get the debbuger to work, just realized flatpak could be the problem. After another considerable amount of time trying different flatpak permissions, realized this is not a good use of my time. Installed the same packages from snap, and everything worked OK.
That's what many OEMs have been doing for decades and this is exactly what many SDV have been trying to get rid of, since integrating many different products from many different manufacturers are slow, let alone iterating and designing new features.
Related to CAN, the bus is standard, but the thing is, CAN is just a bus, not a protocol. There are many ways you can have two ECUs (vehicle's modules) talking in incompatible ways.
It's possible to create a custom network for libvirt, but you have to add a static route to in the router for the other hosts in your LAN to see the VMs.
Using virsh, you can dump the default network with net-dumpxml, which is the default bridge libvirt creates, modify it and create another network. Add the modified file with net-create (non-persistent) or net-define.
This way the VMs can participate in the LAN and, at the same time, the LAN can see your VMs. Works with wifi and doesn't depend on having workarounds for bridging wifi and ethernet. Debian has a wiki entry on how to bridge with a wireless nic [0] but I don't think it's worth the trouble.
What happens also is that many sellers provide discounts when using Pix, because you dodge the expensive fees charged not only by Visa and MasterCard, but the fees operators (banks, fintechs) charge to provide the infrastructure (PoS machines, financing for installments, etc, the last one being quite common in the country) to use these networks.
reply