Banco Central do Brasil | Brazil | REMOTE | Full-time | BRL280k

Embark on a journey with the Central Bank of Brazil (Bacen), the global epitome of innovation in central banking.

We proudly stand as the world's most innovative central bank. Bacen, the visionary creator and operator of the PIX payments system, leads the charge in financial technology innovation.

Position: Software Engineer

Location: Remote within Brazil

Contribute to cutting-edge financial technology projects.

Embrace the flexibility of remote work, allowing you to code from any corner of Brazil.

With 50 open positions and the potential for an additional 50, we present a rare opportunity for a hundred exceptional individuals to be part of our groundbreaking initiatives.

Selection Process: Entrance exam (concurso público) serves as the gateway to joining our team.

Visit https://www.bcb.gov.br/acessoinformacao/concursospublicos for comprehensive details.

Your chance to be a catalyst in the evolution of finance awaits. Join Bacen and redefine the future of financial technology with us!

You have to pay R$ 150 up front to take the exam, and prepare yourself to questions about administrative law! It doesn't matter if you're Donald Knuth, the average joe that knows administrative law will take the place.

Trust me, invest your time on learning how to find cycles in a linked list and get a job in a FANG.

Only 5 points out of 200 are about administrative law.

Pretty sure Leetcode subscription costs more than R$150 :) .

But yeah, if you are Donald Knuth, you can probably make more money in other places... if its important for you.

That's Brazil for you. Source: I'm one.

> This creates another attack avenue, that is, you don't attack the results of the ballot, but you attack the entire system. You discredit the system because it is complicated, you use the limited understanding of the voter base to invalidate the results.

That is exactly what Bolsonaro did. He effectively proved the system is vulnerable to a trust attack... it does not matter if the system is safe from tampering if a significant part of the voters do not trust the system.

But this issue has become so politicized in Brazil that it has become impossible to discuss it reasonably. Pointing out any flaws in it is interpreted as an "attack to democracy".

first, paper ballot suffer the exact same problem..

In fact i strongly believe that Bolsonaro would do the same thing regardless of the system, if we had paper ballots he would complain it is not electronic.

The same trust attack you can do on electronic system you can do on analogical systems. Anything you do will be subject to this problem

second, the truth is that electoral system does not care if people trust in it or not. Even with Bolsonaro attacks and a massive distrust by the right wing on the system it was still used and the results accepted.

The only thing that matter is whatever you can prof in the electoral court if there was fraud and no one was able to do it, not even bolsonaro.

The main point is that it is a lot easier to trust something you can understand than some black-box machine certified by experts. Thus, eletronic voting systems are more vulnerable to trust attacks.

i agree that not understanding something make it easier to mistrust, but understanding does not ensure it will be trusted.. the same way not understanding something does not necessary mean people will not trust it..

paper ballots are easy to understand but it is know to have many vulnerabilities thus it suffer from trust attacks the same way..

On the other side, i think a good example is that most people do not understand 1% about how modern cars work yet many people trust then with their life daily..

I personally would not trust a 100% analog election with paper ballots and manual counting of the votes like old ages, but i do see the value on adding paper ballots on top of modern electronic voting system as another layer of audition.

You use the physical paper ballot that will be manually counted but digitally printed by the machine and thus could have an electronic signature to validate making it impossible to create fake votes. You could even have automated counting of those votes if you some qr code and only manually count the paper ballots in some cases.

all a person could do it trash some votes, but then the count between the paper ballots and the electronic consolidation would not match.

The election system in Brazil is so perfect that you might go to jail if you say otherwise.

I would argue that an election system in which fraud is easy but obvious for everyone when present is more robust than a system in which fraud is hard but impossible for anyone to see.

Calling this guy a hacker is a joke... as is this whole story. He is a scammer who got famous for accessing phone numbers of authorities using tricks he learned while scamming bank clients.

But the question is: did Bolsonaro think he was a hacker?

That he did is the most revealing...

Allegedly :-)

Shameless plug... Having worked on such systems, I recently wrote an article explaining real-time payment systems, some of which use real-time gross settlement:

https://luizlaydner.substack.com/p/how-do-instant-payment-sy...

If anyone from the FED is reading this I have this advice: don't use ISO20022! (I've been working on the brazilian instant payments project, known as PIX). It's an overly-complicated-try-to-solve-everything standard that promises interoperability but only delivers pain and misery. Since each country has its own standards for person and account identification, in dealing with these local realities, the ISO20022 adds quite a lot of complexity. But all this cost does not result in interoperability. In fact, each payment scheme end up with a localized version of the standard, incompatible with others. What could have been a clean API, ends up a mess.

I actually do work at the New York Fed and saw this announcement recently myself. I was wondering about that standard and started looking at the website, but it seemed a bit light on information, which made me suspicious. At least I know my instincts may have been on the right track.

Unfortunately, I'm much too far removed to influence anything. The Federal Reserve System is massive and distributed into many large silos (Reserve Banks & The Board of Governor's) that prevent power from being too centralized in a single bank, but also make it difficult to work with anyone that's not in your bank. Interestingly, this is by design! Anyways, this work is primarily driven by the Board of Governor's and I'm at FRBNY, so I'll probably be getting most of my information from press releases like this one.

I'm also working with Brazilian instant payments schema, aka PIX. We've simply created a mapping layer to convert all ISO messaging to json.

Internally all our logic runs on json. It works because at the end of the day, payments only need a few fields to work: Source, Destination, Amount.

Even the BCB itself has this ISO20022-xml to simpler-schema-in-json mapping layer.

>json

I hope you aren't using floats for cents!

Honest question. Would it differ if one used floats in json rather than floats in XML?

I wouldn't think so, the issue is not so much float in the storage layer (although precision in converting to and from the storage layer can make for interesting complications) it's floats in the applications layer.

No it would not, but you could use decimals in xml.

Edit: looks like there is no float in xml.

Nor are there floats in JSON! Json numbers are stored in decimal with varying lengths.

Yes, but almost any standard JSON package will map a number with decimals to their internal float.

While alternative parsers exists (javascript has LosslessJSON for example), they're a pain to use.

Using strings for floats only has a tiny overhead, but it allows users to use standard JSON parsers and it signals a good practice.

If you use JSON numbers to serialize money, you create a situation where the path with the least friction is the incorrect one.

> While alternative parsers exists (javascript has LosslessJSON for example), they're a pain to use.

FWIW in Python that's as uncomplicated as

    json.loads('1.1', parse_float=decimal.Decimal)

though of course it helps tremendously that `decimal` is part of the stdlib.

Numbers in JSON are stored as strings. So as long as encoder/decoder is storing them in suitable format e.g BigDecimal no precision need be lost.

That may be technically true, but decoding sad encoding JSON without reading numbers as doubles is a special feature.

what do you guys think of https://mojaloop.io/ vs ISO?

Quite scary to run financial transactions using an untyped format.

You'd be surprised just what kind of stuff goes through JSON to be parsed by unreliable Javascript engines 9ver software that doesn't correctly implement the JSON standard

>.<

Everything is JSON these days, unfortunately.

You can apply schemas and force integers although. You also have typed serialization formats such as protobuf.

Not a good start.....

To support these goals, the service will use the widely accepted ISO 20022 standard and adopt other industry best practices, that would remove barriers to interoperability, in order to avoid unnecessary and burdensome incompatibilities, to the extent the existing private-sector service also uses publicly available, widely accepted standards.

And I got downvoted for predicting this a few weeks ago.

Not today! ISO20022 is indeed a mess

Congrats on predicting it, but if you don't have any proof, you look exactly the same as all the crazies spreading unjustified rumors.

Without proof (or at least some great reasoning), I think downvotes of "predictions" are correct.

Just need to look at all the other instances.

Incidentally, the Australian equivilant of this (NPP) is going with ISO20022.

Canada is too

What would be an alternative?

A brand new protocol.

A standard backed by the US government isn't going to be just another standard.

Yeah, there is an amazing amount of power to force adoption if the Fed tells banks, that to continue to be banks, they must adopt this data standard.

Why don't just copy what's in use in other countries? For example, sending and receiving money in the EU is pretty simple, you only need their IBAN, and maybe their name (AFAIK some countries require it). I'm not even aware of what's going on in the background, but from the user perspective its easy and free.

Well "what's going on in the background" is exactly what's being discussed here. End users will never be exposed to any of it.

No. They didn’t say build a new protocol to rule them all.

On the contrary the argument was to build a locally minimal, but sufficient, protocol that doesn’t try to compete with other locally suitable protocols.

People are taking the parent comment very seriously.

Well documented json

Any protocol with schema is better than well documented anything.

I’d pick protobuf. Or json with schema if json is preferred.

Schema works on machines, good documentation is work for humans.

But you can aut-generate the docs from code/schema!

What alternative do you suggest? Keeping in mind all the parties that will be involved, besides your project.

Create a fit to purpose, simpler, protocol using a good interface specification language (OpenAPI or protocol buffers). Maybe borrow concepts and patterns from the ISO standard, but not adopt it. It will not deliver its promise of interoperability. It might actually make it harder to interoperate with other payment schemes.

Interledger Protocol (ILP, ILPv4).

Interledger Architecture:

https://interledger.org/rfcs/0001-interledger-architecture/#... :

> For purposes of Interledger, we call all settlement systems ledgers. These can include banks, blockchains, peer-to-peer payment schemes, automated clearing house (ACH), mobile money institutions, central-bank operated real-time gross settlement (RTGS) systems, and even more.

[...]

> Interledger provides for secure payments across multiple assets on different ledgers. The architecture consists of a conceptual model for interledger payments, a mechanism for securing payments, and a suite of protocols that implement this design.

> The Interledger Protocol (ILP) is the core of the Interledger protocol suite. Colloquially, the whole Interledger stack is sometimes referred to as "ILP". Technically, however, the Interledger Protocol is only one layer in the stack.

> Interledger is not a blockchain, a token, nor a central service. Interledger is a standard way of bridging financial systems. The Interledger architecture is heavily inspired by the Internet architecture described in RFC 1122, RFC 1123 and RFC 1009.

[...]

> You can envision the Interledger as a graph where the points are individual nodes and the edges are accounts between two parties. Parties with only one account can send or receive through the party on the other side of that account. Parties with two or more accounts are connectors, who can facilitate payments to or from anyone they're connected to.

> Connectors [AKA routers] provide a service of forwarding packets and relaying money, and they take on some risk when they do so. In exchange, connectors can charge fees and derive a profit from these services. In the open network of the Interledger, connectors are expected to compete among one another to offer the best balance of speed, reliability, coverage, and cost.

ILP > Peering, Clearing and Settling: https://interledger.org/rfcs/0032-peering-clearing-settlemen...

ILP > Simple Payment Setup Protocol (SPSP): https://interledger.org/rfcs/0009-simple-payment-setup-proto...

> This document describes the Simple Payment Setup Protocol (SPSP), a basic protocol for exchanging payment information between payee and payer to facilitate payment over Interledger. SPSP uses the STREAM transport protocol for condition generation and data encoding.

> (Introduction > Motivation) STREAM does not specify how payment details, such as the ILP address or shared secret, should be exchanged between the counterparties. SPSP is a minimal protocol that uses HTTPS for communicating these details.

[...]

  GET /.well-known/pay HTTP/1.1
  Host: example.com
  Accept: application/spsp4+json,  application/spsp+json

Seems like all tools in this space (IT service management) are terrible. At work I have to use HP Service Manager. Just thinking of it makes me nervous. Made for bureaucreats by bureaucreats!

Looks a lot like what VoltDB has for stream processing. Will definitely make developing streaming apps a lot easier.