If you want througput, Kafka is the better option. Use a message queue for transaction processing against a specific target, where it is a requirement for you to have guaranteed, one-time and one-time only delivery, and possibly that its secret and should only be delivered to one target. You should conceptualize Kafka as being a tool to maintain a sort of distributed, global state. A message queue is more like getting served to go to court.

Technically, Kafka is an event stream, not a message queue (this can be confusing because event streams are often implemented at a surface level like message queues). The difference between an event and a message on a conceptual level is important though. There's plenty of good literature out there if you want to dig deep into the difference.

As far as message queues go for something like the federal reserve, IBM MQ is really the only option that wouldn't raise a lot of eyebrows in the industry. The Fed is not the kind of institution that I think people would be lenient on for being open and innovative with their software solutions, banks really need to know that this thing is going to work and they all run IBM MQ themselves already. Not to mention the integration possibilities with Db2 and IMS, which are both huge in finance.

My only complaint is that it is very expensive. That's the story with most of the kind of hardcore technical products IBM sells that are likely to wind up near mainframes. I'd imagine the Fed gets a sizeable discount though.