How EDA and Flow May Revolutionize How Money Moves

Fairly often a reader of Flow Architectures: The Future of Streaming and Event-Driven Integration will share something that indicates possible accelerated development of the World Wide Flow. One case in point is a tweet from John Tipper regarding a proposal from financial services consultancy, Atomic Wire, to rethink the way we settle cross-border payments across the world:

The quoted tweet links to a page where you can download a report Atomic Wire prepared for a hackathon put on by the Bank for International Settlements (BIS) and financial messaging services powerhouse, SWIFT. In the report, Atomic Wire (which I will abbreviate to AW) presents prototype that demonstrates rapid settlement of cross-border payments using unbounded streams and a protocol from the Bank of England.

OK, there is a lot to unpack there, but let me take a stab at breaking this down while pointing out how all of this aligns with the concept of the World Wide Flow.

First, speeding up settlements (without raising new risks) is very important. Atomic Wire points out that the world's banks carry around 9 trillion dollars every single dingle day. (I figure $9T is worth the extra "dingle"—no regrets.) If we can settle much more quickly, we can reduce the risk that one party in the transaction won't be able to complete its obligations. Furthermore, money won't be tied up as long in escrow accounts waiting for both parties to complete said obligations.

The basic process is demonstrated in the diagram below:

Atomic Wire's solution (and I'm sure there are others like it) promises to achieve this objective. The AW solution is essentially a Facilitator pattern service that uses the ISO 20022 standard for financial messages to enact the Bank of England synchronization protocol through an Apache Flink stateful stream processing infrastructure. In other words, it uses a common messaging protocol (ISO 20022) through a common interface (not clear to me, but either the Flink pubsub API or possibly SWIFT's messaging APIs?) on commodity software. The result is interesting for a number of reasons:

  1. This solution enables the settlements system to resolve settlements as soon as both parties confirm that their respective actions have been taken. No hold time for batch processing later.
  2. The solution AW demonstrated handled >100,000 atomic transactions a second on 32 processing cores (details are in the report). That is, according to AW, about 73% of the worlds total transaction volume. This is yet another example of how stateful stream processing can handle immense event volumes with surprisingly low hardware needs.
  3. The ISO 20022 standard is a great example of an existing industry standard for semantics and structure that could easily be adopted to use CloudEvents or a similar metadata standard in the future to create flow-compliant streams. Or, it is (remotely) possible that the World Wide Flow will be built off of portions of the ISO 20022 standard, given its prove use in a highly demanding domain.
  4. In the book, I called out the value of streaming solutions replacing batch solutions in many domains. In this example, it would replace a slower, less reliable real-time system that in turn replaced a batch processing system.
To be clear, the AW proposal itself is not an example of flow as I defined it. The standards used are too industry specific, and they are building plenty of custom code to connect to, consume, and publish to the streams involved. However, it is a great example of how stream interaction opens the door for flow standards in the future, as it both demonstrates the value of streams and seems relatively easy to adopt to flow as those standards emerge.

I get very excited when I see what really good, high scale stream processing systems can do. I will repeat the theme of the book: we are at the beginning stages of a huge change to the way we integrate our business systems. I hope you are getting excited as well.

Comments

Post a Comment

Popular posts from this blog

How AWS EventBridge API Destinations Are A Flow Innovation

Image
The new API destinations feature of AWS EventBridge introduces a simple mechanism for defining how events processed by EventBridge should be packaged and sent to third party web APIs using standard HTTP verbs, such as GET, POST, and others. (Most commercial APIs are REST APIs, which use these verbs.) By defining some basic connection, authentication, and data formatting information using straight forward wizards and templating mechanisms, EventBridge can automatically create the right HTTP calls every time it processes a relevant event. I highly recommend reading this blog post from AWS's James Beswick to get a better understanding of how this all works. Why is this important news? Because AWS has just made nearly the entire API economy a valid set of consumers for your event streams without requiring you to write any code. Do you want Twiilio to consume a customer's exceptions stream so that it can text them the information in a timely manner? Just create an API destinatio
Read more

Flow and the Future of Software Development

Image
Think about the ways in which the software development process resembles the flow of water running downhill. Ideas are the tiny drops of potential value that gather into features and architectures which then feed backlogs. From there, developers create code and configuration—thus adding value—which  then merges with other flows. Work done in the combined flow gains more and more value until it is presented to those that convert all that value into desired outcomes: profit, or perhaps mission success. OK, it's a bit of a corny analogy, but it represents my mental model of the challenges that developers face while creating any significant enterprise or commercial software system. First, the challenge is to convert potential energy (a worthy idea or demonstrated need) into kinetic energy (the increasing value of the solution to the end user) via a metaphorical force of gravity (the desire for the aforementioned profit or mission success). The other thing I picture is that water runnin
Read more

Two Ways To Evaluate Which Event-Driven Architecture is Right for Your Flow Systems

Image
The event-driven platforms market is a confusing place. In fact, there is an entire appendix in Flow Architectures: The Future of Streaming and Event-Driven Integration dedicated to evaluating much of that market and it's almost a third of the book. Thus, it is no surprise that developers and architects not experienced with eventing systems struggle to identify the best platform for their applications. I've identified one method for making a selection in the book, which I will update in this blog post to reflect what I have learned since the book came out. I used a model based on the types of event streams, which works extremely well if you are going to consume a stream over which you have little control. (It also works for selecting technologies within a scope you control, but I am more interested in how you "future-proof" your decisions for a flow future.)  Another interesting way to slice the market comes from researcher Jamie Brandon, who looked at the problem fr
Read more