One of the things I enjoy about internet, and blogs in particular is the continual surprise at the wealth of knowledge and opinion.  I actually lost the link for how I got here (apologies) but Jack, from Holland, writes a clear description of the circumstances to consider SOA vs EDA (Event Driven Architecture).

This is highly applicable to Banks because they are (generally) either Command and Control or siloed and this helps to determine whether SOA or EDA is applicable as an architecture strategy.  May be useful next time the IT folks promote one way of doing things.

If you are seeking to support strong cohesion in the business processes, situations where all process steps are under one control, SOA is the way to go. The command-and-control style of SOA – in general is applicable to:

• Vertical interaction between the hierarchical layers of functional decomposition 
• Functional request-and-reply processes such as man-machine dialogues; the user waits for an answer
• Processes with a transactional nature which require commit and rollback facilities
• Data enrichment in a message to be published to bring the message to its full content in a formal format

If you are seeking to support independency between business process steps, EDA is the way to go. This style of architecture is appropriate in federated and autonomous processing environments. Recognizable situations where EDA might be applicable are:

• Horizontal communication between tiers in a process chain
• Workflow type of processes
• Processes that cross recognizable functional organization borders, external (B2B) as well as internal

Source: SOA and EDA: How EDA extends SOA and why it is important