'Perpetual Motion in Financial Products'

1. Perpetual Motion in Financial Products
Mark Norton
IDIOM Limited

2. Business Agility in Action – business led policy improvement
Actual Use Case – One of top 4 Australasian insurers
Actuary identifies opportunity to reduce the referral rate for automated insurance underwriting
Working alone, develops adjustment to credit policy to mitigate unnecessary referrals
Verifies improvement and ensures no unintended consequences by testing the challenger vs
incumbent policies across the full product portfolio (>500k policies)
Generates new Credit Policy narratives for Board and APRA approval
Submits new policy to production – automated overnight process
ALL WITHOUT IT INVOLVEMENT
ALL IN TWO WEEKS ELAPSED
ONLY ONE PERSON END TO END

3. Business Agility in Action – nimble, continuous, perpetual
Actual Use Case – One of top 4 Australasian insurers
SME team takes custody of product definitions for high-end, tailored insurance products
Including data schemas, life-cycle decisions, forms, business documents, reference data
50-60 large, maximum complexity products (thousands of risks, multi-billions cover per policy)
100’s of active underwriters
Continuous, perpetual versioning of schemas, rules, forms, documents, reference data
Continuous total portfolio testing (policy simulations, what-if, regression)
Automated pipelining* of schema changes
Automated deployment cycle with single manual step to verify deployment process compliance
ALL WITHOUT IT INVOLVEMENT
DAILY RELEASE CYCLE FOR INSURANCE PRODUCTS BY PRODUCT SMEs

4. What is the matter with IT
High cost, high risk, long time for systems that are too inflexible
Requirements* that start badly as narrative and get worse through multiple one-way
transformations to executable code
What is a requirement (singular)? A process? A transaction?
No party can confirm what is written as computer code matches what was intended by the narrative
Deliberate subjugation then assimilation of business concepts into IT concepts
Business reality is subsumed in IT jargon that has no business relevance (objects, components, layers,
standards, notations, processes, etc.)
So that business concepts are suffused throughout the code base
Losing their identity, integrity, and coherence
Technical and business concepts are fused into one single system image
Result: Every business change is a full scale IT construction project
* Requirements: http://www.modernanalyst.com/Resources/Articles/tabid/115/ID/1354/Requirements-and-the-Beast-of-Complexity.aspx

5. Agile Improves, but does not Solve the Problem
Speed to market is a critical business KPI for development of business products + services
Our business users have backlogs for IT resources measured in months to years
- assume a current backlog of 6 months
Assume a product change takes 1 month to develop and test under waterfall SDLC
Assume that agile improves waterfall SDLC by 50%
How much better off is the business in terms of its critical KPI? ~8%
Agile is a business issue more than an IT issue
Speeding up financial product delivery is the objective, not speeding up the SDLC per se
Ergo, we need to remove / reduce IT role in financial product + service delivery

6. Our upside down world
“Externalities” are real, perpetual, and mutable, and exist irrespective of any system
Real things, real data, real events, real policies
e.g. Loans, Policies, Claims, Patients, Passengers, Taxpayers, etc
“Internalities” are the IT things that are unseen in the real world
E.g. objects, components, layers, standards, notations, processes, etc
Systems: a simulacrum* of business reality that is abstract, transient, rigid
[*a mere image that does not represent the reality of the original]
Much treasure is spent injecting externalities into internalities !
What is real, perpetual and mutable is embodied in something that is abstract, transient, and inflexible
We need to reinvent this process – internalities and externalities must be discrete and independent
So that what is real, perpetual, and mutable stays real, perpetual, and mutable within systems that are
abstract, transient, and inflexible

7. Build an Agile System, not an Agile Development Process
AGILE helps when it addresses the Externalities more than the Internalities
Agile must be measured in terms of business agility, not development agility
Building systems that fuse externalities / internalities faster and at less cost still = failure
Deliver a system that allows business SME’s to build and maintain financial products
Separation of concerns – separate externalities and internalities
Retain distinct ownership, custodianship, and management of each
Business ownership of externalities / IT ownership of internalities
Build models of the externalities to be executed directly by the internalities
Externalities exist independently before, during, and after internalities
Semi-rigid Internalities service agile externalities subject to periodic wholesale replacement
Make the relationship between Externalities and Internalities explicit
Use meta data to ‘late-bind’ Externalities and Internalities

8. Externalities
Financial Products and Services are Externalities that can be represented by 4 models
1. Data that represents each real world entity and holds its current state (ENTITY DATA)
2. Policies that govern the life-cycle of each entity by controlling the entity’s state transitions (POLICIES)
3. Policy aware event pathways that drive the state transitions for each entity (EVENTS)
(forms for human users, services for automated systems)
4. Complex representations of the entity state for external actors (DOCUMENTS / MESSAGES)
Entity data is large and complex (e.g. >100k normalised data nodes)
Policies come from many sources – distilled into decisions / rules
Regulatory – legal, industry best practice
Contractual – policies agreed with third parties, contracts
Internal – the product and service definitions of the model owner
Process Management driven by ‘best, next’ decisions – BINARY BPM
Decision driven, just-in-time, dynamic selection of ‘best-next’ activity or process
Models of Externalities are not bound to execution technology, location, or platform

9. Internalities
Can be hidden behind a generic transaction container
– providing a ‘virtual transaction platform’ for any/all Externality models
Includes BAU IT standards, platforms, and infrastructure
Security, authentication and authorisation
Event management, transaction invocation, transaction resourcing
Persistence, record location, record retrieval
Routing, communications, message delivery
Includes all specialist activities that are defined by technology
Web services, communication devices, machine interfaces, etc. (e.g. Send SMS, Address lookup)
Scope of internalities is relatively minor
Total number of discrete activities is < a few hundred for a large corporate (source: major UK Bank)
Total number of LOC is <20% of the complete system image
Internalities are not aware of the nature of any business entity or policy
Externalities and Internalities only aware of each other via meta data

10. One System Image but Two Systems

11. Generic Database Persists Externalities

12. Generic Business Transaction Executes Externalities

13. Benefits of Abstracted, Decision Centric Transactions
Workflow Efficiency – use policy defined decisions to generate Workflow meta-data
“Binary BPM” – the best-next-step determined just-in-time every-time
‘Automate the now’, not the future or the past
Align entire universe of dependent systems and actors with new state
Timeliness and Accuracy
The right question at the right time; followed by the right decisions; and timely, decision
controlled follow-up – every where, every time
Ease of Use
Forms and processes dynamically optimised for different user needs including customers,
back-office & administrators, third parties
Expanded Transaction Scope
Fewer transactions needed because the transaction addresses the entire entity life cycle, not
specific state changes

14. Benefits of Abstracted, Decision Centric Transactions
Auditable and Transparent – full audit trail for all data, processes, decisions
Business/Systems Alignment – apply the correct business policies for every event, every time
Determine whether to offer/allow any product or service, under what terms and conditions, with
what costs/charges, then control all downstream consequences
– all exactly in accordance with business policy
Perpetual Agility
Allow improvements to be implemented by SMEs by adjusting the Externalities continuously
(without code changes) as the organisation learns
Extensible
Externalities inherently allow plug’n’play products and services
Legacy Rejuvenation
Embed transaction container into Legacy systems to enhance capability / extend life

15. Business Transaction Cycle (Part 1)
Event triggers transaction
Web service, communication device, machine interface, etc
The Internalities (the IT cycle – part 1)
Ø Identify the event and initiate response
Ø Locate an existing entity record or instantiate a new one
Ø Acquire event data for the transaction
Ø Instantiate the relevant ‘policy life cycle’ transaction in the container
Ø THE INTERNALITIES ARE NOT TRANSACTION AWARE
The Externalities (the business cycle)
Ø Receive and validate the event data against the current entity state
[Cycle the event data through a form or service until acceptable]
Ø Transform the event and entity data into the policy idiom
Ø Execute the business policy and determine the new entity state
Ø Change the state and all state dependent attributes (cost, terms, etc)
Ø Prepare vectors to align all external systems
Ø Prepare workflow data to drive activities and future events

16. Transaction Cycle (Part 2)
The Internalities (the IT cycle – part 2)
Ø When the transaction is completed, receive the entity data in its new state
Ø Persist the new state and archive the old state
Ø Inspect the state meta data for Bringups, Actions, Vectors for secondary events
Ø Extract the workflow meta data and use to drive the activities and secondary events
Result
Entity state is updated
Current and future workflow is actioned
All internal and external systems are aligned with this new state
STILL ONE SYSTEM IMAGE – NOW IN 2 DISCRETE PARTS

17. Thanks for listening…
Mark Norton
IDIOM Limited