Financial Technology

FIN7208
Ts Dr Ahmad Shaharudin Abdul Latiff

Systems Supporting Buying & Selling

• Financial systems has similarities with commercial systems
• Financial systems support two systems for making money :-
• One way to make money is to buy first contracts at a low price and sell
them later at a higher price.
• If a trader has credit, he can first borrow contracts from someone,
immediate sell the contracts and then, at a later time when the contract
price is lower, buy the contracts back at a lower price (and return the
borrowed contracts back to the lender) ~ “short selling”.
• Sellers lock in prices by selling contracts for products, buyers purchase the
risks (and rewards) associated with a contract’s price fluctuation.
Transaction protocols
• Commercial and financial systems developed in parallel
• Initially, only one financial product was traded at the Amsterdam
Stock Exchange; shares of the VOC
• The transaction technology used at the Amsterdam Stock Exchange
was based on a “handshake protocol”, similar with what is used today.
• The difference is the handshake today are acted by computers.

Transaction protocols
• A protocol is a rule represented by a sequence of actions for two or
more actors, which specifies how a particular activity should be
performed.
• The “handshake protocol” for trading at the Amsterdam Stock
Exchange was discussed by Joseph de la Vega (1688)
• A member of the Exchange opens his hand and another takes it,
and thus sells a number of shares at a fixed price, which is
confirmed by a second handshake.
• After the confirmation handshake, the protocol commits the seller to
deliver the shares to the buyer.
Transaction protocol
• Trade execution date is referred to by the capital letter T.
• A goal of paperless clearing and settlement (also called straight
through processing (STP)) is to reduce this time.
• The handshake protocol is used to initiate and synchronise
communication.
• The Transmission Control Protocol (TCP), part of the Internet Protocol
(IP) governs reliable communication between “peer” computers on the
Internet by requiring computers to acknowledge each message sent to
each other.

Transaction protocol
• According to the Internet Standard RFC 1334:
• The Password Authentication Protocol (PAP) provides a simple
method for the peer to establish its identity using a 2-way
handshake.
• The Challenge-Handshake Authentication Protocol (CHAP) is used
to periodically verify the identity of the peer using a 3-way
handshake. This is done upon initial link establishment, and may
be repeated anytime after the link has been established.
Transaction protocol
• Another Internet Standard (RFC 3546) describes the Transport Layer
Security Handshake Protocol, which specifies how computers can
authenticate each other and negotiate a method for secure
communication before the actual transmission of information.

Business Process Management

• Banks’ strategies are achieved through the implementation of business
processes
• Business processes
• Define people’s functional roles
• Determine the activities they will perform
• Specify how tasks will be carried out
• Business processes implement financial controls
• Help prevent fraud
• To avoid risk-related losses, processes must be robust
• Serve as an institutional memory
• Record of how past mistakes could have been avoided
• Provide instructions for preventing them in the future
• Business processes’ execution has transitioned
• From manually performed activities
• To partially and fully automated IT systems
• Many products and services can be implemented entirely
electronically
• E.g. foreign exchange trading and online bill payment
• Processes can be fully automated using straight-through processing (STP)
• Straight-through processing
• Reduces processing time
• Allows greater volumes to be processed
• Reduces error rates

BPM Overview
• Business process management systems
• BPM functions are implemented using business process management systems
(BPMS)
• Orchestrate process activities performed by both people and IT systems
• Integrate the content of information contained in documents and data stored in IT
systems
• “Workflow” systems traditionally limited to
• People-to-people interactions
• Document-based activity management
BPM Overview
• Business process modeling
• Process modeling is critical for understanding
• What a process does
• How it implements its function
• Often this information is only available
• In peoples heads
• Buried in procedures manuals
• Embedded in software components

BPM Overview
• Business process modeling
• Benefits of process modeling
• Processes that can be visualized are easier to change
• Helps identify conflicting views and misunderstandings related to
process behavior
• Makes processes more portable
• Process knowledge can be transferred between people and
places more easily when their description is
• Complete
• Consistent
• Well-structured
BPM Overview
• Business process modeling

What makes this

style of process
information
presentation
easy or difficult
to understand?

BPM Overview
How does this
representation of
• Business process modeling the same
information
compare?
BPM Overview
• Business process modeling
▪ Sometimes it is
easier to start
capturing process
information by using
paper-based
methods
▪ Easier for many
people to see and
easily modify the
description
▪ No modeling tool
training or
knowledge required

© DBS Bank.
Reprinted with
permission.

BPM Overview
• Process analysis and solution design
• Determines how a process can best be implemented using
• Manual processing techniques
• Automated STP
• Evaluates system integration dependencies
• Cost-benefit analysis determines
• Where automation is practical
• Cost of labor is a major consideration
• Some processes may not occur frequently enough to justify automation
• Sometimes, avoiding or reducing manual processing errors alone may justify
automation
BPM Overview
• Business process execution
• Stateless process execution
• System-oriented processes
• Short lived transactions
• E.g. Generate and send payment instruction
• No need to persist process state
• Stateful process execution
• People-oriented processes
• Long lived transactions
• E.g. Process loan application
• Must persist process state for hours/days/months

BPM Overview
• Business process execution
• Distributed business process logic
• Is embedded in IT systems
• In business applications
• In “adapters” used to link business applications
• Centralized business process logic
• Is stored in a BPMS
• Or a rules engine linked to a BPMS
• Easier to see and understand end-to-end process
• Less work to maintain
• Few places where changes have to be applied and tested
BPM Overview
• Business process execution
• Process logic embedded in systems and adapters

BPM Overview
• Business process execution
• Centralized business process logic
BPM Overview
• Business process monitoring
• It is hard to improve what you do not measure
• Process improvement begins with process monitoring
• BPMS makes it easier to capture and analyze process
execution information
• Monitoring examples:
• Real-time monitoring of service levels
• E.g. transaction ID 2315 will exceed its processing time SLOA in less
than ten minutes
• Efficiency and performance monitoring
• E.g. there is a bottleneck at the credit verification step of the process

BPM Benefits
• Supports agile development
• Bridges the transition between business ideas and production
implementation
• Supports
• Capture and refinement of requirements
• Rapid prototyping
• Solution implementation
• The scope of processes’ execution can be gradually expanded
BPM Benefits
• Change impact analysis and management
• Modification of existing business processes is a major activity for financial
institutions
• Address new regulatory requirements
• Adapt to business environment changes
• Significant time, cost, and risk are involved with changing existing business
processes
• Process modeling helps identify which processes and systems will be affected
• BPMS support running new and old versions of processes simultaneously

BPM Benefits
• Process improvement
• Process modeling can be used to
• Document and analyze how incremental changes will be
implemented
• Define and communicate entirely new process designs
• Simulation can help determine the impact of changes
• Monitoring helps verify the effect of changes
BPM Benefits
• Process standardization
• Facilitates the definition and application of enterprise-wide “best practices”
• Helps create organizational blueprints that support growth
• Provides commonality and consistency between processes
• Make processes easier to learn and support
• Supports rationalization of processes
• E.g. stops the same process being implemented differently in various locations

BPM Benefits
• Helps manage complexity
• Process modeling helps make the complexity of end-to-end business-process
workflows visible
• Differences and similarities between processes can be more readily
understood
• Master, best practice processes can be defined
• To address special requirements, process variants may be implemented based
on the master process definition
BPM Benefits
• Reduces operational risk
• Process design visibility helps identify where internal controls may be weak or
bypassed
• BPMS helps ensure that processes are executed as designed
• Prevent users from skipping steps
• Report or alert when exceptions occur
• Enforce authorization and role based access control to information and functions

BPM Benefits
• Supports flexible sourcing and location operating models
• BPO and offshoring require that processes are “portable”
• Process modeling is essential for transferring work between locations
• BPMS helps coordinate activities that are performed in different locations at
different times
• Provides a repository for financial institutions’ knowledge capital
• Rather than have it embedded in individuals
• Easier to disseminate where and when required
Applying BPM
• Tactical and strategic implementations
• Tactical BPM
• Project- or department-level BPM implementation
• Little coordination required, but returns are limited
• Only basic capabilities used
• E.g. Process execution
• Strategic BPM
• Enterprise-wide BPM implementation
• Large investment and massive coordinate required
• Takes advantage of the full range of BPM capabilities
• I.e. process modeling, process execution, process monitoring, and simulation

Applying BPM
• Approach for building up BPM capabilities
• Stage 1: Use for allocation and tracking
• Wrap BPM around existing processes
• Stage 2: Use for routing of scanned images
• Manage information flow between process steps
• Stage 3: Route based on elementized information
• Utilize information content to automate decision making
• Stage 4: Rule consolidation and management
• Manage rules more effectively and leverage real-time monitoring capabilities
Applying BPM
• BPM and enterprise platforms
• BPM can help tie together
• Image capture systems
• Web browser interfaces
• Content management technology
• BPM implements logic and coordination functions
• Service oriented architecture (SOA) provides
• Connectivity
• Encapsulation of functions and services

Applying BPM
• Linking BPM with SOA
• Top down implementation
• Processes determine what services should be constructed
• Is the ideal case, possible with construction of new systems
• Bottom up implementation
• IT systems dictate what services will be available
• Often the case where existing systems are in place
BPM Example
• Syndicated lending
• A complicated, multiparty process
• Origination and fulfillment stages may take many days to complete
• A number legal documents must be communicated between the parties
• Multiple versions of the documents may exist during the negotiation process
• Status tracking is important to ensure that the process does not get delayed

BPM Example
BPM Maturity Model
• Maturity models help
• Identify target level of competence
• Assess current level of competence
• Enables a roadmap for moving from current level to target level to be
constructed
• Helps provide a clearer picture of existing capabilities
• Facilitates communication of goals and direction

BPM Maturity Model

Solutions Architecture
• IT architectures underpin solutions’ success
• IT architecture includes
• The organization of a solution and its components
• The relationships between components and the environment
• The principles guiding the design and evolution of a system
• IT architecture addresses important nonfunctional concerns
• E.g. integration and resilience
• IT architecture includes many different technical areas
• E.g. hardware, network, and security

Abstraction
• Enabling top-down planning
• Top-down planning process
• Begin with the most essential requirements
• Map onto the simplest design
• Gradually add more detail
• Only key concerns should be focused on when constructing a high-level
solution design
• Number of details can be overwhelming
• Considering all the details can result in “analysis paralysis”
• Abstraction helps hide unnecessary detail
Abstraction
• Controlling focus
• Decide which aspects should
be examined or
communicated
• Hide everything else to avoid
distraction from what is
important
• “Less is more”
• What are some issues with
this architecture diagram?

Abstraction
• Controlling focus
• References architectures
• Example of simplification for communication
Abstraction
• Facilitating communication
• It is often difficult to extract knowledge from front-line staff
• They do “not see the forest for the trees”
• Pay too much attention to details and do not appreciate the general situation
• It is easy to get information
• It is more difficult to extract knowledge
• Abstract helps convert information into something more useful

Abstraction
• Facilitating communication
• Business example
• Information collected
• The FET process matches the TRANS_ID field in each swap transaction record
to the 31a field in the SWIFT confirmation message.
• Abstracted translation
• There is a reconciliation process between the front office (trading) and back office (clearing).
Abstraction
• Facilitating communication
• Technology example:
• Information collected
• The CMPL system, which operates on a Sun Ultra 20 platform running Solaris 10, receives
SOAP messages over 10 GB Ethernet through a CISCO 2503 and converts the SOAP messages
to FIX messages that are transmitted using IBM MQ. The following messages are transferred
via SOAP: order request, order confirmation, order accepted, execution matches, and order
expiry value.
• Abstracted translation
• There is an order routing system that runs on a UNIX platform and makes use of various
middleware.

Abstraction
• Making use of multiple views
• There are many different ways to visually communicate information
• It is worthwhile to find the best form for communicating
• Specific information
• To a particular audience
• Example: communicating market data system interactions
• Business users may be more comfortable with process flow diagrams (e.g. BPMN)
• IT implementers may find sequence diagrams more useful
Abstraction
• Common views used to describe solutions
• Business process models
• Shows the overall logic and behavior of the system
• Logical diagram
• Shows the main functional modules and information flows
• Physical diagram
• Shows the servers and network hardware configuration

Abstraction
• Logical diagram example: channel-services architecture
Abstraction
• Abstraction example: channel-services architecture
• An example of a three-tiered architecture
• Helps identify and communicate where specific functions should reside
• Example: should a particular software module implement business logic or
channel logic?
• Should not include both
• Also useful for identifying which logical functions different software systems
provide

Abstraction
• Solution mapping to a channel-services architecture
Architecture Concepts
• An architecture roadmap describes
• Intended architecture end state
• The plan to get there based on the current state
• It also defines stages of development
• Set priorities
• Limit delivery scope for each phase

Architecture Concepts
• Guiding principles
• Avoid ambiguity
• Simplify decision-making
• Provide architectural consistency
• Make the rationale for core decisions clear in advance
• Avoid confusion and debate in the future
Architecture Concepts
• Patterns
• Common design structures
• Leverage known good patterns
• Avoid designing from scratch
• Do not rediscover known flaws and weaknesses
• Pattern example: adapter pipeline

Architecture Concepts
• Standards
• Specify the details of how solutions should be implemented
• Provide commonality across different solutions
• Examples
• Presentation: HMTL5
• Communications: SOAP over HTTP
• Data access: SQL
• Standards simplify design decision making
Solution Architecture Considerations
• It is critical that key solution architecture considerations be addressed
up front
• Resilience
• Scalability
• Security
• Performance
• Problems with these areas identified late in the development cycle
often lead to
• Redesign and reimplementation
• Project delays and cost overruns
• Unhappy business users and managers

Solution Architecture Considerations

• Resilience
• System failures can lead to both direct and indirect monetary losses
• Usually measured by required total uptime
• E.g. 99.99% availability
• Approximately 52 minutes of downtime per year
• System level resilience
• Active-passive
• Active-active
• Site-level disaster recovery (DR)
Solution Architecture Considerations
• Scalability
• The ability to increase a solution’s capacity to meet greater usage demands
• Types of capacity to be increased depends on solution’s usage context
• Examples:
• Increased transaction volumes
• Greater numbers of users
• More connections
• More locations

Solution Architecture Considerations

• Scalability design approaches
• Further discussion in Chapter 9
Solution Architecture Considerations
• Performance
• It is critical to determine
• Which types of performance are critical
• Performance thresholds that are important
• Ways to define performance requirements
• Throughput: transactions per time period
• Latency: time to complete a transaction
• Can be measured as
• Average
• Maximum allowable
• A variance threshold (e.g. 90% under 100 milliseconds)
• Poor performance is a common issue for many solution deliveries
• Should be considered in all stages of the development lifecycle
• Further discussion in Chapter 12

Solution Architecture Considerations

• Security
• Considerations
• Authentication
• Authorization
• Confidentiality
• Nonrepudiation
• Accountability
• Implementation of internal controls – fraud prevention
• E.g. separation of duties
• Further discussion of these topics in Chapter 17
Solution Architecture Considerations
• Auditability and data integrity
• A nonalterable record is kept to track important events or interactions after
they have occurred
• Common approaches
• Marking data records as deleted rather than actually deleting them
• Recording data modifications as a reversal of the original record and creation of the new
modified record
• Opposed to changing the data fields directly
• Identifying a “system of record” that is designated as the master source for specific types
of information
• Reconciling data records between the system of record and other systems
• Ensure intersystem data consistency and integrity

Solution Architecture Considerations

• Adaptability and maintainability
• Solutions ability to be changed and supported after they
have been deployed
• Business and technological evolution necessitates change
• Over time, most solution architectures become obsolete
Solution Architecture Considerations
• Geographic distribution
• An architectural concern for financial institutions that span multiple
geographies
• Common approaches
• Centralized
• Processing or data that is managed and maintained at a central location
• Federated
• Some functions managed centrally while others delegated to regional or local implementation
• Distributed
• Localities have full autonomy

Solution Architecture Considerations

• Cost
• Is usually necessary to design to budget
• Cost tradeoffs can vary significantly for different
architecture considerations
• Challenge: select the most effective tradeoffs
Enterprise Architecture
• Enterprise platforms can simplify solution design and implementation
• A reference data architecture helps govern the creation and use of data
• Enterprise data management systems
• Provide common mechanism for storing and managing reference data for applications
• Example: What IT system changes need to be made when a new stock symbol is
introduced by an exchange?

Enterprise Architecture
• Integration architecture
• Provides a common set of communication tools for sharing information
between systems
• Example:
• The front-office system provides trade details in real time using XML format via a
message queuing interface
• The back-office system imports trade details from a file on an end-of-day basis
• Integration architecture tools would be helpful to link the two systems together
Enterprise Architecture
• Solution-driven enterprise architecture
• Enterprise platforms are rarely purchased and deployed in their entirety to
begin with
• Is the ideal case, but difficult to achieve in practice
• Requires large upfront infrastructure investment
• How should different business units’ budgets be used to pay for enterprise-wide
capabilities?
• More often, enterprise platforms are initiated and enhanced over the course
of multiple projects
• Each stage provides a stepping stone for the next

Enterprise Architecture
Data Management
• Logistical management ensures that data can easily get to where it
needs to be used
• Data quality management ensures that the data is accurate,
complete, and consistent
• Data classification determines the sensitivity level of information
(e.g., secret, confidential, public)
• Segregation and protection of sensitive data helps support its
protection

Interfaces
• APIs reduce the effort required to integrate systems and replace them
over time
• API’s access methods and data structure are critical to their
effectiveness
• Which methods to expose?
• How granular should data access be?
• API “wrappers” can be used to provide an abstraction layer around
third-party APIs
• The trend for banks to provide open, public APIs is discussed in
Chapter 20
Using Cloud Services
• Factors affecting cloud usage
• Enterprise cloud computing strategy
• Purpose and users of the solution
• Dependencies on other internal systems
• Off-the-shelf resources and capabilities that can be leveraged either internally
or from a cloud environment
• Type of information to be stored in the cloud, i.e., account and/or personally
identifiable information

Using Cloud Services

• Factors vary depending on type of institution
• Fintech companies typically can leverage cloud services with minimal
complications
• Financial institutions often face more challenges (e.g. vendor
management processes, internal policies/guidelines)
• Important to have an enterprise-level cloud strategy to provide
guidance on when and how cloud services should be utilized
The Solution Architect
• Defines technical-scope boundaries
• Selects technical alternatives and manages tradeoffs
• Communicates and champions key architecture principles
• Reviews the solution implementation as it progresses
• Identifies key architectural risks and develops strategies to
mitigate them