Ebury Company Entity Branches
Problem Description
Ensure that our accounting, finance and regulatory obligations are accurate to local accountancy requirements, tax reporting obligations and aligned to our transfer pricing model taking under account our systems and legal entities.
In order to provide further context, we summarize the role of Company Entities, and then introduce the new 'Branches' extension.
Company Entities
By definition the so called Ebury 'Company Entities' are legal instances having a well-defined geographical location and specific Terms and Conditions (T&C) each. Every single Ebury Client belongs to a Company Entity defined at on-boarding time, signing the Entity's T&C.
Ebury also has obligations based on a Company Entity's T&C-s. Typically adjustments on certain processes (Client Communications for example).
Furthermore, Company Entities play a particularly important role in Reporting. Every Ebury transaction that is to be reported on, has to be uniquely linked to a Company Entity, and reported accordingly.
So far so good, sounds simple. Financial transactions should belong to the Company Entity of their Client.
This all gets real tricky once a Clients could move from one Entity to another. Exactly how it happened at Brexit.
Ebury transactions (trades, payments, money workflows, etc.) aren't instantaneous. In fact some of them could extend over a year. Thus it may easily occur that a client started a (forward) trade before -- yet finished after moving Entities. Within this time frame numerous additional transactions may appear on this trade... With non-trivial heuristics regarding Entity relations.
There is a sophisticated logic in place to track these links correctly. Links are set on transactional objects at creation time.
The Source of Truth for Company Entity information is Salesforce.
Branches
Company Entities can have "sub-entities", so called Branches, which have to be added to Ebury Systems. Which means that we need to introduce a new component, in a hierarchical-relational structure.
Similarly to Entities, Branches also need to have a legal address and have their Terms and Conditions. However since Clients sign the Entity's T&C, NOT the Branch's T&C, therefore Branches T&C apply no obligations on Ebury (for the time being).
To give a real-life example of an Entity-Branch use-case: Ebury has a Company Entity in Belgium, that has a Branch in France. French Clients will be (generally) registered with the Belgian Entity and the French Branch, signing the T&C of the Belgian Entity. Ebury will adjust Client Communications to the French Client according to the Belgian Entity's T&C, and make sure that reports on financial transactions indicate the "whereabouts" of each transaction highlighting the relation to the Belgian Entity and the French Branch within.
Now, more-or-less all that's in place for Company Entities will have to be applied on Branches (linking, show in reporting, etc.)
Core rules are:
- There is no Branch without a parent Entity -- however Entities without Branches may exist
- in this case the Entity is taking over the place of the Branch as well.
- A Branch can only have one parent Entity -- however an Entity may have any number of Branches associated
- (i.e. one-level tree structure).
- A Branch is linked to the same entity throughout its lifetime -- however an Entity may have new or deleted Branches.
The Source Of Truth for Branch information and Entity-Branch relationships is Salesforce.
Business Impact
Branches are critical components for Business, for Legal Regulatory and Auditory purposes.
Though the main deadline is to have it all in place by 2021, in reality Branches have to be fully functional for Ebury rather ASAP.
Solution
Being in a transition phase between Ebury 1.0 and 2.0 there are a number of options how new projects could be implemented. The main difference between these solutions is
- delivery time
- long-term usability
Solution: Tactical
Clearly the most cost-efficient implementation of an extension of an already-existing component is within the space where its parent component and related logic already resides.
Even more, the parent's data models were pro-actively designed in a way to be ready to hold the one-level tree relation structure of functionally replaceable objects. This means that no data model (DB) changes are required for the new Branch component, nor for the Entity-Branch relation.
Though generally data recursion is not recommended, it can be accepted as part of
a cost-efficient tactical solution, representing strictly one-level hierarchy.
The parent link provides a unique distinction between Branches and Entities, acting as a flag.
Though this solution could allow to re-use already-existing relation links (fields), sadly tecnical issues do not make this possible. Primarily since relation links were not accessed via well-established interfaces, but direct references... Hard-coded on far too may occurances than what would allow to keep such an intervention save.
Therefore new relation links have to be introduced per object, despite the slightly redundancy. Consistency will be assured on a database level.
Salesforce synchronization --already available for Entities-- have to be extended for Branches. However, since Salesforce is (also) using the same data structure for both Entities and Branches, this only involes updating the current synchronization mechanism with the Entity-Branch relation (which then also serves as a flag to differentiate between Entity and Branch objects).
Once Salesforce syncronization is available, data have to be pulled from the Source Of Truth. (Additionally, historical data has to be also loaded into the database covering the financial year. Source Of Truth for this operation is provided by Data Team).
Pros:
- can be implemented and deployed in a 2-4 weeks
- (as) efficient (as it can get in the legacy frame)
- fits in the already-existing (legacy) structure
Cons:
- tactical solution, i.e. will have to be re-engineered in a long term
Alternative 1.: Hybrid Implementation
In case we would like to take this opportunity to move towards an Ebury 2.0 architecture realistically (see Alternatives) we could implement a hybrid structure.
Meaning that we could implement certain components as "new-style", while keeping others in the old structure.
Since none of the required service frames exist in Ebury 2.0 yet, we would be the pioneers to initiate those efforts. Therefore we should limit ourselves to simple, low-complexity components in order to keep delivery dates still preferable for Business.
Obvious candidates could be Salesforce synchronization and a new Client Service with Entity-Branch data structures. (For more information on these components, see the Alternatives section). Relation between transactional objects would reach across old and new architectures.
Applying the long-term solution, the Client Command Service would be responsible to hold the "canonical" version of the Company Entity and Branch data and relation, using separate data models. This data should be replicated to the Legacy System so that Legacy Services can keep continuing their functionality with no interruption.
Pros:
- partially long-term solution
- initiation of Ebury 2.0 services (that must be built anyway)
Cons:
- vaguely estimated timescale is 2-3 months, with a number of "unknown"-s
- complex
- numerous new data constructs and migrations
- high amount of (new) solutions to be put in place
Given the significantly higher cost, combined with uncertaininty in time estimations, the contrast between the naturally starightforward and time-efficient Tactical Solution, and the Hybrid solution is turning the tide towards the former.
Alternative 2.: Ebury 2.0
Technically, of course we could implement the whole project in the scope of the new Ebury 2.0 Architecture. However, given that it would require us to set up a the initial structure for a number of services (with numerous "unknown"-s), time estimations scale up, and may get unreliable.
Nevertheless, we present how we are planning to move the same structures and Business Logic modules to the new architectural frame.
Salesforce synchronization should be automated using event subscriptions. These events would be published on every data change.
Client Command Service would be responsible to hold authoritive Entities and Branches data.
Various FX Command Services would hold a replicated copy of the Entity and Branches data, to facilitate data retrieval both for internal logic, and efficient output data serialization. These services would also hold the Business Logic relating to each transaction type.
Whenever a transactional object is created (or updated), corresponding Command Services publish the corresponding events. Consumer services (reporting, etc.) would subscribe to these notifications, and receive all necessary information about the new (updated) objects for further usage.
Caveats
Time estimations on brand-new services and communication flows in the "unexplored" new architecture.
Operation
No additional impact with Legacy solutions.
As for (partially) Ebury 2.0: monitoring and alerting must be put i place for the new services.
Security Impact
No particular security considerations if staying within the boundaries of the Legacy Systems, using well-established already-existing patterns.
In case setting up new services: of course security considerations must apply.
Performance Impact
All proposed solutions provide an efficient solution for the task.
Clearly, distributed solutions (parallel execution, "well-organized" local data replicas, etc.) are more efficient than synchronous Legacy Systems.
Developer Impact
Code Owners for new services...?
Data Consumer Impact
Regarding the Legacy Solution: data workflows are all well-established.
As for (partially) strategic solutions: it may be helpful for numerous upcoming Ebury 2.0 services, to have an initiative already established for Salesforce data changes notifications/consumption.
Deployment
All potential new services must come with a well-defined Deployment Plan.
Dependencies
Legacy dependencies, if Tactical Solution is chosen.
None otherwise (Salesforce contribution perhaps, for Salesforce synchronization?)