BIAN Board Members · 2020-06-16 · BIAN’s API Initiative represented a shift of focus from...

BIAN Webinar“Implementing the BIAN Specifications by

using the Semantic API User Guide"

April 29th, 2020

Copyright BIAN 2020 | Banking Industry Architecture Network

A Warm

Welcome

to YOU –

Dialing in

From all

around the

globe!

2

A Warm

Welcome to

YOU –

Dialing in From

all around the

globe!


On Today’s

Webinar

Guy RackhamBIAN Lead Architect

Hans TesselaarBIAN Executive Director


To provide the world with the best banking inter-

operability architecture. To be the banking

technology standard.

Central objectives for IT in the banking industry are

to lower the IT and operational costs of the bank

and help banks mitigate the risks associated with

technology innovation. To provide a trusted

roadmap for constant innovation.

By collaborating and sharing in an open way, the

best expertise across our global ecosystem of

leading banks, technology providers, FinTech

players, academics and consultants to define a

revolutionary banking technology framework that

standardizes and simplifies the overall banking

architecture.

Introduction | Mission


Introduction | BIAN & Financial Institutions


Introduction | BIAN & Partners


Introduction | BIAN & Academic, Standard Bodies and

Training Partners

BIAN Webinar April 2020

BIAN Semantic API Practitioner Guide – Overview


Copyright BIAN 2020 | Banking Industry Architecture NetworkCopyright BIAN 2020 | Banking Industry Architecture Network

Target Audience

Who should read this guide?

5-10 Minutes for questions at the end…

The latest revision of the BIAN approach, with specific emphasis on its adoption for

the development of open banking APIs

This Practitioner Guide is currently available in draft form for members for comments.

The general release to BIAN.org is planned to be before the ‘summer break”…

❑ Technical Architects and Development Team Leaders – who don’t need to

become experts in the BIAN techniques (i.e. to be able to create new BIAN

specifications and content) but knowledgeable enough to define solution

architectures that correctly interpret the published BIAN content.

❑ Upcoming - API Developer’s Cookbook – a pattern/framework that sets out the

typical facilities and approaches needed for developers to create production

software. As this will be site specific, the cookbook will outline approaches in general

terms with examples from BIAN member deployments where appropriate

BIAN Semantic API Practitioner Guide – Webinar April 2020

Background


As always, banking is subject to multiple forces for change. But it seems that right

now these forces are reaching unprecedented levels…

...major changes are either already happening or seem pretty much inevitable

Why are things happening now?

Factors driving the changes in the industry

Technology is Both a Constraint and an Enabler of Change

COVID - 19

FinTechs &

RegTechsNew

Regulations

Advanced

Technologies

Legacy

Replacement


Background


Too many times in the past major advances in technology have failed to deliver the

anticipated benefits...

... perhaps it has not been a problem with the technology itself, instead it has been the

way we have applied it to the business operations

A Little Context

BIAN’s API Initiative represented a shift of focus from interoperability alone…

The BIAN Approach Applies a Specific Perspective of Business

❑ About 2 Years Ago the BIAN Board Shifted Focus to APIs – switching from from

using a service oriented architecture (SOA) to improve interoperability within the

bank to defining standards based external access APIs (B2B&C) and a little later

expanding this to include internal (A2A) API connectivity

❑ The BIAN Semantic API Practitioner Guide – covers the changes and extensions

to the BIAN standard that have resulted so far. It also presents some key

observations and initial deployment guidelines that have emerged from the first

adoption projects carried out by BIAN members.

❑ It is Just the Beginning – we are at the start of a technological transition. Early

signs of the potential are positive, but there is much still to learn. BIAN will continue

to play its role as a ‘clearinghouse’ for techniques that support the adoption of the

BIAN standard


Background


BIAN Defines the Standard Components for Banking...

Key Observations/Messages so Far

The key points from feedback from our members

The Headlines

The Practitioner Guide reflects the current viewpoint and will be constantly updated

❑ Semantic definitions not an implementation specification – the BIAN Semantic

APIs provide unambiguous descriptions of the business context, purpose and the

key information exchanged in a service interaction. This ’statement of requirements’

still needs to be extended to define physical implementation specifications

❑ Component model impact – there are significant benefits from adhering to a

business component model that are not necessarily obvious at the outset. There is a

learning curve for developers to understand a component representation of business

activity

❑ Scaling up implementation – we are still learning what the overall requirements are

in terms of training, tools and procedures for effective adoption for different roles.

This will be an evolving process relying on feedback from members/users

❑ Adoption can be incremental – once the basic architectural building blocks are

established, conventional development approaches still apply and minimum viable

solutions can establish a stable foundation for continued component based

development


Background


Guide Contents

What is in the guide?

5-10 Minutes for questions at the end…

The ~ 80 page Guide is set out in four sections

This Practitioner Guide is currently available in draft form for members for comments.

The general release is planned to be before the ‘summer break”…

The four sections are as follows – we will next highlight the key content:

1. Introduction – a short section that defines the business/market context for adoption of a

new component business model view comparing finance with other industries

2. Design Concepts - outlines the key motivation for the adoption of a component model and

explains by example how the model view used differs from more conventional approaches. It

also summarizes the key properties of the core building block of the model: the BIAN Service

Domain

3. Specifications – presents a detailed breakdown of the interlinked design artifacts that make

up the standard – it includes an explanation as to how the BIAN semantic specifications

have been represented using the prevailing RESTful architectural style

4. Implementation Approaches – introduces a simple framework to differentiate between

different types of solution and outlines how to extend the standard to physical

implementation level detail. It also highlights key systems impacts of a component

architecture and presents some early insights into deployment patterns – in particular types

of external access that support open banking.


Selected Extracts from the Guide


A common industry ‘blueprint’ allows participants to specialise in different

components. The industry can collectively assemble far more sophisticated products

than any one provider could hope to develop alone.

Once an industry is componentised it can adapt to radical changes and leverage new

opportunities far more effectively…

Manufacturing:

The Auto Industry…

…defines the different parts

that are assembled in a car

Change: Electronics

Media:

The Film Industry…

…agrees specialist roles

involved in making a film

Change: Digital Media & CGI

Financial Services:

Banking…

…what model defines the

financial services ‘components’?

Change: FinTechs & Technology

Custody &

PaymentsLoans &

Investments

Financial Risks

Guide Section 1 - Introduction

Key point from the Introduction section:

Implementation of a business component model of banking




Section 2 - Design Concepts

1. Why bother with BIAN?

2. Explaining an Asset Leverage Model

3. Example comparing a component model to a process model of business activity

4. High-level Service Domain definition with explanatory examples

❑ Functional Patterns & Asset Types

❑ The Control Record

❑ Action Terms

5. Summary Properties of a component architecture

Guide Section 2 - Design Concepts

Key points from the Design Concepts section:

The outline for the Design Concepts section is





The benefits mostly accrue over time


1 - Why Bother With BIAN?

Adoption requires additional work on behalf of the technical team. How is this

justified? The guide describes three primary implications

❑ Service Domains Support Containerization &

Operational Re-use – they define discrete business

capabilities that can be re-engaged in many different

contexts…

❑ Stable Over Time for Incremental Development &

Adoption – they define what a business needs to do, rather

than how it must do it. The how can be implemented in

stages and evolve to support new practices

❑ Canonical (the same for everyone) – facilitating higher

degrees of interoperability between solution providers and

industry participants

e.g. Party

Authentication

Evaluations

==

=




The BIAN standard has been developed by applying a specific partitioning technique

to identify the discrete business capability components

The technique is empirical – defining candidate partitions that are then refined in

practice by modelling real-world situations

This Technique Defines a Type of Service Oriented Architecture


1 - What is an Asset Leverage model?

… in order to

create commercial

value.

Local State

Full

Lifecycle

InstancesO

ffere

d

Serv

ices

Co

nsu

med

Serv

ices

The Bank has

resources, tangible

& intangible…

…that it controls or

leverages in

various ways…Service Domain

Customer

Relationships

Employee

Commitments

Knowledge &

Knowhow

Production

Capacity

Servicing

Capacity

Reputation &

CapitalManage

Administer

Analyze

Track

Process

Fulfill

Operate

Design

Components/Service

Domains are generic

and stable over time




The difference between a conventional process perspective and a component model

In the component model each component governs its own discrete view of business

information and details are passed by ‘value’ between components

Components Represent Discrete/Autonomous Business Partitions


2 - An Example - comparing process and component views

Traditional business models are process

oriented. Business activity is viewed as a

series of linked decisions and actions…

…and the design usually assumes

access to a common ‘shared’ view of

all processing data

Shared Database

BIAN uses a specific type of service

based design to isolate discrete and

autonomous business functions…

…the connections between components use

a common business vocabulary, but each

‘encapsulates’ its own processing data

InternalData

InternalData

InternalData

InternalData

InternalDataShared

Message

Vocabulary





An example shows the different model views for a mortgage application. The bank and

customer first agree general terms and formalise details when a property is found…

Many possible variations in the component view use the same components

Mortgage loan

application

Gather customer

& loan details

Negotiate and

agree terms

Check credit

worthiness

Notional

Agreement

Check ability to

fund the loan

Get underwriting

decision

Value the

property

Review Product

Terms/Selection

Confirm

Eligibility

Process/finalize

all documents

Establish loan &

disburse funds

Complete Loan

Application

Abandon

Application

Shared Database

Customer

Details

Application

DetailsProduct

Details

Credit Administration

Credit Analysis

Customer Offer Processing

Offer Details

Underwriting Decisioning

Cashflow Analysis

Collateral Asset Administration

Collateral Details

Customer Data Management

Customer Details

Product Directory

Product Details

Document Services

Document Registry

Mortgage Fulfillment

Mortgages

Vs

Components Can Collaborate in a Loose Coupled Manner


2 - An Example - comparing process and component views




The main properties of a Service Domain are defined using examples…

The key aspects:

1. It combines a single Functional Pattern

& Asset Type

2. Service Domain Information profile

and the Control Record

3. Exchanges characterized by Action

Terms

Each Aspect is Next Explained In More Detail


3 - Introducing the Service Domain – some high level design properties


Credit Analysis


Offer Details


Cashflow Analysis


Collateral Details


Customer Details

Product Directory

Product Details

Document Services

Document Registry


Mortgages




CREATE

Make plans,

design,

solutions

INITIATE

Process

work,

Operate

tooling for

support and

product/servi

ce delivery

REGISTER

Catalogue

and enroll

EVALUATE

Perform test,

checks and

analysis

PROVIDE

TRACK Maintain a log of transactions or activity, typically a financial account/journal or a log of activity to support behavioral analysis.

ANALYSE To analyse the performance or behavior of some on-going activity or entity.

MONITOR To monitor and define the state/rating of some entity.

OPERATE Operate equipment and/or a largely automated facility.

DIRECT Define the policies, goals & objectives and strategies for an organizational entity or unit

MANAGE Oversee the working of a business unit, assign work, manage against a plan and troubleshoot issues.

CATALOG Capture and maintain reference information about some type of entity.

ADMINISTER Handle and assign the day to day activities, capture time worked, costs and income for an operational unit.

AGREE TERMS Maintain the terms and conditions that apply to a commercial relationship.

ENROLL Maintain a membership for some group or related collection of parties.

ALLOCATE Maintain an inventory or holding of some resource and make assignments/allocations as requested.

ASSESS To test or assess an entity, possibly against some formal qualification or certification requirement.

DESIGN Create and maintain a design for a procedure, product/service model or other such entity.

DEVELOP To build or enhance something, typically an IT production system. Includes development, assessment and deployment

MAINTAIN Provide a maintenance service and repair devices/equipment as necessary.

PROCESS Complete work tasks following a procedure in support of general office activities and product and service delivery functions.

DescriptionFunctional Pattern

ADVISE Provide specialist advice and/or support as an ongoing service or for a specific task/event

FULFILL Fulfill any scheduled and ad-hoc obligations under a service arrangement, most typically for a financial product or facility.

TRANSACT Execute a well bounded financial transaction/task, typically involving largely automated/structured fulfillment processing.

A Service Domain implements a pattern of behavior (functional pattern) to instances of

a specific type of asset

The Service Domain uses instances of a ‘Control Record’ to keep track of each

time/instance it executes its responsibilities for a complete lifecycle

19 standard functional patterns of commercial

behavior have been identified and refined in

use

Bank Facility

Operations • Trading floor

• Dealing position • Branch • Location

• Teller/Position • Call center

• Servicing position • IVR

• ATM

• E-Branch • Social Network

Financial Facility • Credit/debit card • Current account • Corporate current

account • Credit line

• Line of credit

Information Provider • Credit agency • Market research • International standards

• Financial market reference

• Financial market research • Finncial market

analysis • News

Financial Transaction • Payment • FX Exchange • Loan

• Syndicated loan • Leasing

• Deposit • Bearer document • Letter of credit

• Bank guarantee • Factoring

• Stock lending/Repo

Traded Instrument • Price/quote • Order • Trade

• Matching • Confirmation

• Clearing • Settlement • Custody

Financial Market

Access • Price/quote reporting

• Deal capture • Deal matching • Deal reporting

• Deal booking

Financial Service • Brokered product • Trust • Remittance

• Advisory • Public offering

• Private placement • Cash management • Direct debit

• Investments • Trade finance

• Project finance

Information Switch Product/Service

Operations • Accounting

• Commissions • Payments • Valuations

• Underwriting • Collateral

• Fraud detection • Transaction orchestration

• Transaction consolidation

• open item • Booking • Documents

Reputation/

Recognition • Goodwill

• Brand

Capital • Cash • Fixed assets

Support services

• Legal • Audit • Process

• Product • Security

• Finance/AML • Human resources • Training

• Product • Applications

• development • Systems production

Committed cash

flows • Income/revenue

• Expenses

Assets & Liabilities • Balance-sheet • Off balance-sheet Business

Development • Sales& marketing

• Advertising • Prospect campaign portfolio

• Internal campaign portfolio

Asset Types

Production Capabilities e.g. fulfillment, distribution & sales

Distribution Capability Product Delivery Capability

Central Resources e.g. H.O, fixed assets & capital

Intellectual Property e.g. knowhow &

knowledge

Finances Enterprise Resource

Financial Analyses • Market risk • Counterparty • Capital

Relationships e.g. employees &

partners

Employees • Directors • Managers • Staff

Customer • Prospect • Consumer • HNW

• Corporate • Multinational

• Institutional • Counterparty • Syndicate

Business Units • Profit centers • Cost centers • Project teams

Authority • Regulator • Auditor • Legislator

Partner • Supplier • Product service provider

• Broker • Custodian

• Correspondent • Agency • Investor

External Parties

Workforce

Equipment • Office equipment • Fleet/distribution • Consumables

Building • Offices • Ops canters • Branches

Systems • IT Platforms

• Development Environment

• Processing & Storage

• Communications

• Deployment • Certification

• Installation

Buildings & Equipment

Product/Service • Product • Product bundle

Model • Financial

• Quant

• Market risk • Instrument valuation

• Credit risk • Liquidity risk

• Business • Behavioral

• Operational • Rating

Procedures • Business • Operational • Management

Applications/IP • Technique/method • Standard • Business achitecture

General Market • Market insights • Competitor insights • Location

Knowhow

Knowledge

Head Office • Board of Directors • Business Model • Corporate

Communications

Enterprise Analyses • Segment • Product • Customer

• Branch • Channel

• Property

Customer Servicing • Orders • Issues

Instrument

Maintenance

Product Inventory • Materials • Tokens

Production Analysis • Product/service • Counterparty risk • Composite position

• Gap • Compliance

• Contribution

Channel Operations • Cross channel services • Branch network • PBX/VRU

• ATM network • E-Branch network

• Internet gateway • Correspondence

Physical Distribution • Warehousing/storage • Archive services • Distrubution fleet

Campaign • Advertising • Prospect • Customer

Selling

Sales & Marketing

Surveys

Assets are identified using a “MECE” decomposition

hierarchyOne Asset

Type

One

Pattern

Service Domain

Full

Lifecycle Instances

Offe

red

S

erv

ice

s

Co

ns

um

ed

S

erv

ice

s

… in order to create commercial

value

Full Lifecycle

Instances

Offe

red

Se

rvic

es

Co

ns

um

ed

Se

rvic

es

The Bank has resources, tangible

& intangible…

…that it controls or leverages in

various ways… Service Domain

Customer

Relationships

Employee

Commitments

Knowledge &

KnowhowProduction

CapacityServicing

Capacity

Reputation &

Capital

Manage

Administer

Analyse

Track

Process

Fulfill

Operate

Design

It applies the functional pattern to the asset for the full lifecycle






The Control Record Captures the Key Business Information



The Information Profile for the Service Domain includes Control Record instances

that manage its execution lifecycle each time it performs

Service Domain

Resource Plans &

Activity Records

Reference Details

Configuration & Status

Work Space Records

Control Record

Control Record

Control Record

Control Record

▪ Service Reference/Name

▪ Servicing Unit Budget & Organization

▪ Servicing Unit Resource & Activity Plans

▪ Unit Activity & Performance Analysis Reports

▪ Reference Data Sources and Update Schedule

▪ Reference Data

▪ Reference Data Usage

▪ Service Definitions

▪ Service Configuration & Status

▪ Service Access and Usage Records

▪ Control Record Portfolio Analysis & Reporting

▪ Individual Control Record Content

▪ Artifact Reference Details

▪ Set-up/Parameters

▪ Transaction/Activity Records




Each Service Operation Applies a Single Action Term



Actions to assign, set-up and configure a production capability

Actions to extract/subscribe to recporting

Description

Ser

vice

D

om

ain

(PU

T,P

OS

T)

Actions that trigger the generation of a new control record instanceIn

stan

tiat

ion

(PO

ST

)R

epo

rtin

g(G

ET

)

Action Terms

Actions that act upon an active control record instance(s)In

voca

tio

n(P

UT

,PA

TC

H)

Retrieve Return information/a report as requested

NotifyProvide details against a predefined/subscribed to notification agreement

ConfigureChange the operating parameters for a service/capability –applies to defaults and active instances

ActivateAssign/establish a production capability (applies to all Service Domains

FeedbackCapture performance feedback. Note this can be at a Service Domain, Control Record or lower level

Initiateinitiate a defined action: e.g. an operating session; procedure; set up a facility; or, a transaction

RegisterClassify and capture details of an entity in a reference directory

EvaluatePerform an evaluation, including: a measurement; test/check; and, an analysis (can be on-going)

ProvideAssign or allocate resources or facilities from an inventory of available/tracked resources

CreateCreate a new strategy, plan, approach, or develop a new design/model or solution

Change the value of some (control record) propertiesUpdate

Execute an automated/structured a task or action on an established facility/control record instanceExecute

Request a task that involves judgement/decisions/workflow against an established facility/instanceRequest

GrantSeek authority/grant to perform an action or use a resource that is overseen/governed by the SD

ControlRequest for the processing to perform in a specific way e.g. block/suspend/skip/prioritise an action

Capture transactional activity details against an instance: e.g. log an event/action, record usageCapture

ExchangeProvide input into the handling of an instance, typically in response to a question from processing

Exchanges between Service Domains are characterized by a standard set of

Action Terms


Credit Analysis


Offer Details


Cashflow Analysis


Collateral Details


Customer Details

Product Directory

Product Details

Document Services

Document Registry


Mortgages




The first is that the Service Domain design results in a high degree of information and

logic encapsulation

The above example is an extract from other BIAN training materials

The Exchange is Targeted and Adopts a Suitable Protocol


4 - To conclude – two important architectural properties

MessageHistory

CustomerReference Data

PositionKeeping

Correspondence

CustomerAgreement

PaymentOrder

Cards

Product Specification

Card Transaction Records

Billing & PaymentRecordsCustomer

Terms & Conditions

Cust Ref. Data

SelectedTerms

Postings

TransactionRecords

Envelope & Content

Postings

PaymentDetails

CustomerReference

Highly targeted

information

extracts




The other is that many exchanges can be sustained by an agreement of the semantic

content of the information as opposed to requiring precise machine-readable data

This is particularly the case where one or both involved parties are cognitive

Most ‘High Value’ Business Exchanges Involve Cognitive Entities


4 - To conclude – two important architectural properties

Service Domain

Market

Research

Service Domain

Product

Design

Service Domain

Product

Fulfillment

Semantic

Agreement of

Terms

Common Data

Types

Shared Actual

Data Values

Shard

Semantic

Vocabulary

Shared Data

Schema

Common

‘Database’

Vocabulary

Shared Data

Schema

Some exchanges require semantic alignment (e.g. topics covered by research). Others need the data defined precisely (e.g. a payment transaction)




Section 3 - Design Artifacts

1. Service Landscape

2. Service Domain

❑ Functional Patterns & Asset Types – together define the scope of the Service Domain

❑ Action Terms & Behavior Qualifiers – define type of access and scope of interest

❑ Control Records Broken Down using Behavior Qualifier Types

3. Business Scenarios & Wireframes

4. Service Operations/Action Terms mapped to REST

The Guide Includes Updated Specifications Of Most BIAN Artifacts

The different BIAN Artifacts described in this Section are

Guide Section 3 - Design Artifacts

Key Content of the BIAN Standard




The Service Domains are organized in two different Service Landscape formats

Draft Value Chain Layout – V8.0Finance & Risk Management

Operations Products

Business Development

Customers Channels

Financial Control

Group Treasury

Credit Risk

Regulatiory Compliance

Market Risk

Operational Risk

Solution Devel.

Marketing & Development

Product Management

Channel Management

Models & Analytics

Financial Statements

Financial Control

F inancial Compliance

Enterprise Tax Admin

Approved Supplier Directory

Company Billing & PaymentsCorporate T reasury Analysis

Corporate T reasury

Asset Securitization

Bank Portfolio Analysis

Bank Portfolio Admin

Guideline Compliance

Regulatory Compliance

Compliance Reporting

Gap Analysis

Credit/Margin Management

Production Risk Models

Operational Risk Models

Economic Capital

Business Risk Models

Regulatory & Legal Authority

Regulatory ReportingCredit Management

Limit & Exposure Mgmt

Position ManagementCounterparty Risk

Fraud Resolution

Market Research

Customer Portfolio

Segment Direction

Market Analysis

Competitor AnalysisProduct Portfolio

Branch Portfolio

Channel Portfolio

Market Risk Models

Liquidity Risk Models

Systems Administration

IT Stds & Guidelines

Development Environment

System Development

Production Release

Fin Inst.Valuation Models

Contribution Analysis

Resource Management

Business Direction

IP & Knowledge

Unit Management

Business Unit F in Analysis

Business Unit F inancial Ops

Business Unit Accounting

Business Unit Direction

Business Unit Management


Site Operations

Site Administration

Equipment Administration

Equipment Maintenance

Utilities Administration

Building Maintenance

Procurement

Fixed Asset Register

Platform Operations

System Deployment

Systems Operations

Platform Operations

Systems Help Desk

Systems Assurance Internal Network Operation

Human Resources

Employee Assignment

Employee Data Mgmt

Empl/Contractor Contract

Employee Certification

Employee Evaluation

Empl Payroll & Incentives

Travel & Expenses

Employee Access

Employee Benefits

Workforce T raining

Recruitment

Business Direction

Corporate Relations

Corporate Services

Organizational Direction

Property Portfolio

Internal Audit

Legal Compliance

Asset & Liability Mgmt

IT Systems Direction

HR Direction

Corporate Strategy

Corporate Policies

Product & Service DirectionContinuity Planning

Corporate Communications

Corp Alliance/Stakeholder

Corporate Relationship

Investor Relations

Security Advisory

Security Assurance

Credit Risk Models

Customer Behavior Models

Fraud Models

Business Architecture

Management Manual

Intellectual Property Port

Knowledge Exchange

Contribution Models Trading Models

Channel Activity Analysis

Financial Message Analysis

Central Cash Handling


Brand Management

Advertising

Promotional Events

Prospect Campaign Mgmt

Prospect Campaign Design

Customer Campaign Mgmt

Customer Campaign Design

Customer Surveys

Case Root Cause AnalysisSales Planning

Contact Center Management

Product Inventory Item Mgmt

Branch Network Mgmt

E-Branch Management

Advanced Voice Svs Mgmt

AT M Network Mgmt

Branch Currency Mgmt

Product Design

Product Deployment

Product T raining

Product Quality Assurance

Information Provider Admin

Servicing Activity Analysis

Branch Location Mgmt

Quant Model

Market Data Switch Adm

Product Directory

External Agency

Commission AgreementSyndicate Management

Sub Custodian Agreement

Product Broker Agreement

Product Service Agency Contractor/Supplier Agmt

Corresp Bank Rel Mgmt

Interbank Relationship Mgmt

Custody, Collateral & Documents

Document Services

Archive Services

Custody Administration

Collateral Allocation Mgnt

Collateral Asset Admin

Collections

Account Recovery

Accounting Services

Financial Accounting

Customer Tax HandlingPosition Keeping

Accounts Receivable

Account Reconciliation

Fraud Evaluation

Reward Points Account

CommissionsCustomer Position

Clearing & Settlement (Payments)

Order Allocation

Settlement Obligation Mgmt.

Payments Execution

Transaction Engine

Correspondent Bank

Cheque Processing

Corresp.Bank Data Mgmt

Payment OrderCounterparty Administration

ACH Fulfillment

Card F inancial Settlement

Card ClearingCard eCommerce Gateway

Corporate Banking

Corporate T rust Services

Credit Facility

Cash Mgmt & Account Svs

Cheque Lock Box

Factoring

Direct Debit Mandate

Direct Debit

Project F inance

Corporate Current Account

Trade BankingLetter of Credit

Bank Guarantee

Trade Finance

Bank Drafts & Trvl. Checks

Market Operations Market Trading

Stock Lending/Repos

Securities Fails Processing

Trade/Price Reporting Corporate Events

Financial Inst ValuationSecurities Dlvry & Rcpt Mgmt

Trade Confirmation Matching

Trading Book Oversight

Dealer Workbench

Market Making

Program Trading

Traded Position Mgmt

Market Order

Quote Management

Suitbility Checking

Credit Risk Operations

Market Order Execution

Advisory ServicesInvestment Products

Corporate F inance

M&A Advisory Corporate Tax Advisory

Public Offering

Private Placement

Mutual Fund Administration

Hedge Fund Administration

Unit T rust AdministrationECM/DCM

Consumer Advisory Services

Consumer Banking

Currency Exchange

Payment InitiationBrokered Product

Current Account

Sales Product

Trust Services

Service Product

Investment Svs

Investment Portfolio Planning

Investment Portfolio Analysis

Investment Portfolio Mgmt

eTrading Workbench

Consumer Investments

Party ReferenceParty Data Management

Location Data Management

Custmer Ref Data Mgmt

Relationship MgmtCustomer Relationship Mgmt

Cust Prod./Service Eligibility

Customer Agreement

Customer Event History

Customer Behavioral Insights

Customer Credit Rating

Sales Product Agreement

Customer Proposition

SalesCust Campaign Execution

Party Lifecycle Management

Product Matching

Customer Offer

Product Expert Sales Support

Lead/Opportunity Mgmt

Product Sales Support

Spec/Discount Pricing Conds

Prospect Campaign Exec

Distribution

Correspondence

Branch Currency Distribution

Product Inventory Distribution

Servicing

Servicing Issue

Contact Center Operations

Point of Service

Interactive Help

Servicing Event History

Informtn. Providers

Information Provider Ops

Market Information Mgmt

Financial Market Analysis

Financial Market Research

Market Data Switch Ops

Financial Instr Ref Data Mgmt

Public Reference Data Mgmt

Cross Channel

Channel Activity History

Customer Profile

Contact Routing

Contact Dialogue

Party Authentication

Transaction Authorization

Customer Access Entitlement

Contact Handler

Customer Workbench

Channel Specific

Financial Gateway

Branch Location Operations

E-Branch Operations

Advanced Voice Svs Ops

AT M Network Operations

Card Terminal Operation

Card Terminal Admin.

CardsCredit/Charge Card

Card Authorization

Card Capture

Merchant Relations

Card Billing & Payments

Merchant Acquiring

Card Network Participant

Loans & Deposits

Deposit Account

Loan

Leasing

Syndicated Loan

Leasing Item Administration

Underwriting

Corporate Loan

Corporate Lease

Consumer Loan

Merchandising Loan

Fiduciary Agreement Savings Account

Mortgage Loan

Corporate Deposits

Operational Services

Issued Device AdminOpen Item Management

Disbursement Rwd Points Awards & Red.

Customer Billing

Issued Device Tracking

Product Combination

Card T ransaction Switch

Delinquent Account Handling

Card Collections

Fraud Decisioning

Customer Orders

Customer Case Mgmt

Customer Case

Card Case

Servicing Order

Servicing Mandate

Investment Account

Securities Position Keeping

Business SupportRisk & ComplianceOperations & Execution

Product Specific fulfillment

Non IT and HR Enterprise Services

Business Analysis

Bank Portfolio & Treasury

Regulations & Compliance

Models

IT Management

Trade BankingLetter of Credit

Bank Guarantee

Trade Finance

Corporate Financing & Advisory Services

Corporate F inance

M&A Advisory

Corporate Tax Advisory

Public Offering

Private Placement

Investment Management

Investment Portfolio Planning

Investment Portfolio Analysis

Investment Portfolio Mgmt

Investment Account

Consumer Services

Currency Exchange

Payment Initiation

Corporate T rust Services

Brokered Product

Bank Drafts & Trvl. Checks

Consumer Investments

CardsCredit/Charge Card

Card Authorization

Card Capture

Merchant Relations

Card Billing & Payments

Business Command & Control

Business Unit F inancial Analysis

Business Unit F inancial Ops

Business Unit Accounting

Organizational Direction

Business Unit Direction

Business Unit Management

Finance Financial Statements

Financial Control

F inancial Compliance

Enterprise Tax Administration

Buildings, Equipment and Facilities

Property Portfolio

Site Operations

Site Administration

Equipment Administration

Equipment Maintenance

Utilities Administration

Building Maintenance

Internal Audit

Procurement

Fixed Asset Register

Legal Compliance

Approved Supplier Directory

Company Billing & Payments

Market Research

Customer Portfolio

Segment Direction

Market Analysis

Competitor Analysis

Product Portfolio

Branch Portfolio

Channel Portfolio

Stock Lending/Repos

Corporate T reasury Analysis

Corporate T reasury

Asset Securitization

Asset & Liability Management

Bank Portfolio Analysis

Bank Portfolio Administration

Guideline Compliance

Regulatory Compliance

Compliance Reporting

Market Risk Models

Gap Analysis

Credit Risk Models

Customer Behavior Models

Credit/Margin Management

Production Risk Models

Operational Risk Models

Fraud Models

Liquidity Risk Models

Economic Capital

Business Risk Models

Systems Administration

IT Systems Direction

IT Stds & Guidelines

Development Environment

System Development

Production Release

System Deployment

Systems Operations

Platform Operations

Systems Help Desk

Systems Assurance

Internal Network Operation

Human Resource Management

Business Direction

Knowledge & IP Management

Corporate Relations

Document Mgmt & Archive

HR Direction

Employee Assignment

Employee Data Management

Employee/Contractor Contract

Employee Certification

Employee Evaluation

Employee Payroll & Incentives

Travel & Expenses

Employee Access

Employee Benefits

Workforce T raining

Recruitment

Corporate Strategy

Corporate Policies

Product & Service Direction

Business Architecture

Continuity Planning

Management Manual

Intellectual Property Portfolio

Knowledge Exchange

Corporate Communications

Corporate Alliance/Stakeholder

Corporate Relationship

Regulatory & Legal Authority

Investor Relations

Document Services

Archive Services

Correspondence

Security Advisory

Security Assurance

Financial Inst.Valuation Models

Regulatory Reporting


Contribution Analysis

Contribution Models

Loans & Deposits

Current Account

Deposit Account

Loan

Leasing

Credit Facility

Cash Mgmt & Account Svs

Cheque Lock Box

Factoring

Direct Debit Mandate

Direct Debit

Syndicated Loan

Credit Management

Limit & Exposure Management

Project F inance

Market OperationsMutual Fund Administration

Hedge Fund Administration

Unit T rust Administration

Order Allocation

Settlement Obligation Mgmt.

Securities Fails Processing

Trade/Price Reporting

Custody Administration

Corporate Events

Financial Instrument Valuation

Securities Dlvry & Receipt Mgmt

Trade Confirmation Matching

Customer Tax Handling

Wholesale Trading Trading Book Oversight

Dealer Workbench

Market Making

ECM/DCM

Program Trading

Traded Position Management

Market Order

Quote Management

Suitbility Checking

Credit Risk Operations

Market Order Execution

Trading Models

Fraud Resolution

Corporate Current Account

Corporate Loan

Corporate Lease

Consumer Loan

Merchandising Loan

Fiduciary Agreement

Savings Account

Mortgage Loan

Consumer Advisory Services

Trust Services

Service Product

Sales & Service

Marketing

Servicing

Customer Mgmt

Sales

Channel Specific


Brand Management

Advertising

Promotional Events

Prospect Campaign Mgmt

Prospect Campaign Design

Customer Campaign Mgmt

Customer Campaign Design

Customer Surveys

Servicing Issue

Customer Case Management

Case Root Cause Analysis

Customer Case

Card Case

Customer Relationship Mgmt

Prospect Campaign Execution

Customer Campaign Execution

Party Lifecycle Management

Commission Agreement

Commissions

Product Matching

Sales Planning

Customer Offer

Underwriting

Product Expert Sales Support

Contact Center Management

Branch Currency Distribution

Product Inventory Item Mgmt

Product Inventory Distribution

Branch Network Mgmt

E-Branch Management

Advanced Voice Services Mgmt

AT M Network Management

Contact Center Operations

Branch Location Operations

E-Branch Operations

Advanced Voice Services Ops

AT M Network Operations

Branch Currency Management

Cross Channel

Point of Service

Servicing Activity Analysis

Contact Routing

Contact Dialogue

Interactive Help

Servicing Event History

Servicing Order

Party Authentication

Transaction Authorization

Payment Order

Branch Location Management

Sales Product

Customer Prod./Service Eligibility

Lead/Opportunity Management

Product Sales Support

Customer Agreement

Customer Access Entitlement

Customer Event History

Customer Behavioral Insights

Customer Credit Rating

Account Recovery


Contact Handler

Customer Workbench

Reference Data

Product Management

Market Data

Party

External Agency

Product Design

Product Deployment

Product T raining

Product Quality Assurance

Discount Pricing

Information Provider Admin

Party Data Management

Customer Profile

Syndicate Management

Correspondent Bank Data Mgmt

Sub Custodian Agreement

Product Broker Agreement

Product Service Agency

Contractor/Supplier Agreement

Correspondent Bank Rel Mgmt

Information Provider Operation

Market Information Mgmt

Financial Market Analysis

Financial Market Research

Quant Model

Market Data Switch Adm

Market Data Switch Ops

Financial Instr Ref Data Mgmt

Public Reference Data Mgmt

Counterparty Administration

Location Data Management

Interbank Relationship Mgmt

Product Directory

Special Pricing Conditions

Custmer Reference Data Mgmt

Customer Proposition

Card Terminal

Card Terminal Operation

Merchant Acquiring

Card Network Participant

Corporate Deposits

Servicing Mandate

eT rading Workbench

Cross Product Operations

PaymentsPayments Execution

Collateral Admin.Collateral Allocation Mgnt


Collections

Account Management Operational Services

Transaction Engine

Position Keeping

Position Management

Accounts Receivable

Account Reconciliation

Fraud Evaluation

Reward Points Account

Issued Device Admin

Counterparty Risk

Open Item Management

Disbursement

Channel Activity Analysis

Rewards Points Awards & Red.

Customer Billing

Leasing Item Administration

Issued Device TrackingFinancial Message Analysis

Financial Gateway

Correspondent Bank

Cheque Processing

Central Cash Handling

Channel Activity History

Product Combination

Customer Position

ACH Fulfillment

Card eCommerce

Card T ransaction Switch

Card Clearing

Card F inancial Settlement

Delinquent Account Handling

Card Collections

Fraud Decisioning

Securities Position Keeping

BIAN Service Landscape V8.0

Business Areas Business Domains

Service DomainsMatrix layout Value Chain layout

The Value Chain Layout is Most Popular with Practitioners


1 - The BIAN Service Landscape




Practitioners Do Not Usually Need to Define Service Domains

A Service Domain Specification combines several elements…


2 - The BIAN Service Domain - Functional Patterns & Asset Types

BIAN Service DomainDefines a discrete functional

component

Action Terms16 generic action terms – each

characterizes an exchange

Asset TypesGeneric assets – tangible and

intangible found in a bank

Control RecordUsed to track the working of a

Service Domain

Behavior QualifiersBreak down the Control Record

into its constituent parts

Functional Patterns19 generic patterns of business

behavior

Service OperationsAn action term that accesses a

control record or its partitions

CREATE

Make plans,

design,

solutions

INITIATE

Process

work,

Operate

tooling for

support and

product/servi

ce delivery

REGISTER

Catalogue

and enroll

EVALUATE

Perform test,

checks and

analysis

PROVIDE

TRACK Maintain a log of transactions or activity, typically a financial account/journal or a log of activity to support behavioral analysis.

ANALYSE To analyse the performance or behavior of some on-going activity or entity.

MONITOR To monitor and define the state/rating of some entity.

OPERATE Operate equipment and/or a largely automated facility.

DIRECT Define the policies, goals & objectives and strategies for an organizational entity or unit

MANAGE Oversee the working of a business unit, assign work, manage against a plan and troubleshoot issues.

CATALOG Capture and maintain reference information about some type of entity.

ADMINISTER Handle and assign the day to day activities, capture time worked, costs and income for an operational unit.

AGREE TERMS Maintain the terms and conditions that apply to a commercial relationship.

ENROLL Maintain a membership for some group or related collection of parties.

ALLOCATE Maintain an inventory or holding of some resource and make assignments/allocations as requested.

ASSESS To test or assess an entity, possibly against some formal qualification or certification requirement.

DESIGN Create and maintain a design for a procedure, product/service model or other such entity.

DEVELOP To build or enhance something, typically an IT production system. Includes development, assessment and deployment

MAINTAIN Provide a maintenance service and repair devices/equipment as necessary.

PROCESS Complete work tasks following a procedure in support of general office activities and product and service delivery functions.

DescriptionFunctional Pattern

ADVISE Provide specialist advice and/or support as an ongoing service or for a specific task/event

FULFILL Fulfill any scheduled and ad-hoc obligations under a service arrangement, most typically for a financial product or facility.

TRANSACT Execute a well bounded financial transaction/task, typically involving largely automated/structured fulfillment processing.

The BIAN Functional Patterns

Bank Facility Operations•Trading floor•Dealing position

•Branch•Location

•Teller/Position•Call center•Servicing position

• IVR•ATM

•E-Branch•Social Network

Financial Facility•Credit/debit card

•Current account•Corporate current

account•Credit line•Line of credit

Information Provider•Credit agency

•Market research• International standards

•Financial market reference•Financial market

research•Finncial market

analysis•News

Financial Transaction•Payment

•FX Exchange•Loan

•Syndicated loan•Leasing•Deposit

•Bearer document•Letter of credit

•Bank guarantee•Factoring•Stock lending/Repo

Traded Instrument•Price/quote

•Order•Trade

•Matching•Confirmation•Clearing

•Settlement•Custody

Financial Market Access•Price/quote reporting•Deal capture

•Deal matching•Deal reporting

•Deal booking

Financial Service•Brokered product

•Trust•Remittance

•Advisory•Public offering•Private placement

•Cash management•Direct debit

• Investments•Trade finance•Project finance

Information SwitchProduct/Service Operations•Accounting•Commissions

•Payments•Valuations

•Underwriting•Collateral•Fraud detection

•Transaction orchestration

•Transaction consolidation•open item

•Booking•Documents

Reputation/Recognition•Goodwill•Brand

Capital•Cash

•Fixed assets

Support services•Legal

•Audit•Process

•Product•Security•Finance/AML

•Human resources•Training

•Product•Applications•development

•Systems production

Committed cash flows• Income/revenue•Expenses

Assets & Liabilities•Balance-sheet

•Off balance-sheetBusiness Development•Sales& marketing•Advertising

•Prospect campaign portfolio

• Internal campaign portfolio

Asset Types

Production Capacitye.g. fulfillment, distribution & sales

Distribution CapacityProduct Delivery Capacity

Central Resourcese.g. H.O, fixed assets & capital

Intellectual Propertye.g. knowhow &

knowledge

FinancesEnterprise Resource

Financial Analyses•Market risk

•Counterparty•Capital

Relationshipse.g. employees &

partners

Employees•Directors

•Managers•Staff

Customer•Prospect

•Consumer•HNW

•Corporate•Multinational• Institutional

•Counterparty•Syndicate

Business Units•Profit centers

•Cost centers•Project teams

Authority•Regulator

•Auditor•Legislator

Partner•Supplier

•Product service provider

•Broker•Custodian•Correspondent

•Agency• Investor

External Parties

Workforce

Equipment•Office equipment

•Fleet/distribution•Consumables

Building•Offices

•Ops canters•Branches

Systems• IT Platforms

•Development Environment•Processing & Storage

•Communications

•Deployment•Certification•Installation


Product/Service•Product

•Product bundle

Model•Financial

•Quant•Market risk

•Instrument valuation•Credit risk

•Liquidity risk

•Business•Behavioral

•Operational•Rating

Procedures•Business

•Operational•Management

Applications/IP•Technique/method

•Standard•Business achitecture

General Market•Market insights

•Competitor insights•Location

Knowhow

Knowledge

Head Office•Board of Directors

•Business Model•Corporate

Communications

Enterprise Analyses•Segment

•Product•Customer

•Branch•Channel•Property

Customer Servicing•Orders

• Issues

Instrument Maintenance

Product Inventory•Materials

•Tokens

Production Analysis•Product/service

•Counterparty risk•Composite position

•Gap•Compliance•Contribution

Channel Operations•Cross channel services

•Branch network•PBX/VRU

•ATM network•E-Branch network• Internet gateway

•Correspondence

Physical Distribution•Warehousing/storage

•Archive services•Distrubution fleet

Campaign•Advertising

•Prospect•Customer

Selling

Sales & Marketing

Surveys

A high level decomposition of the Objects

Any bank has a collection assets that it can own or

have some influence over e.g. a customer relationship, cash, or a payment facility. The asset

needs to have an associated use or purpose

Top Level BIAN Asset Types




An Action Term and Behavior Qualifier Define a Service Operation


2 - The BIAN Service Domain - Action Terms and Behavior Qualifier Types

A Service Domain Specification combines several elements…


component





Control RecordUsed to track the working of a

Service Domain




behavior



TRACK Log Record Events Customer life event, Servicing event

ANALYSE Analysis Algorithms Average balance calculation, Propensity to buy

MONITOR State Measures Composite position, Customer alert

FULFILL Arrangement Features Current account standing order

TRANSACT Transaction Tasks/Steps FX pricing, market trade, clearing & settlement

OPERATE Operating Session Functions Message capture/routing

DIRECT Strategy Goals Increase market share

MANAGE Management Charter Duties Relationship development, Troubleshooting

CATALOG Directory Entry Properties Product pricing rules, Customer reference details

ADMINISTER Administrative Plan Routines Time-sheet recording

AGREE TERMS Agreement Terms & Conditions Required disclosures,

ENROLL Membership Clauses Qualification/membership purpose

ALLOCATE Allocation Criteria Staff assignment, Facility allocation

ASSESS Assessment Tests Password verification

DESIGN Specification Aspects Business requirements

DEVELOP Development Deliverables Functional module specifiation

MAINTAIN Maintenance Arrangement Tasks Preventive maintenance task

PROCESS Procedure Worksteps Invoice generation

Generic ArtifactFunctional Pattern Behavior Qualifier Type

Example

ADVISE Advice Topics Tax advice, Corporate finance

The BIAN Functional Patterns, Generic Artifacts and Behavior Qualifier Types


/customer reference data/{cr-reference-id}/reference/{bq-reference-id}/address/{sq-reference-id}/execution

Behavior

Qualifiers

Business ObjectsAction

TermReference, Configuration & Transactional Data

Request Payload

Response Payload

Service Domain/

Control Record

Sub

Qualifiers

(Optional)

Concatenation?

The Layout of the REST Endpoint is Assembled from the Control Record



The Meaning of a Service Operation is the Same At Lower Levels


2 - The BIAN Service Domain – The Control Record (broken down by behavior

qualifier) A Service Domain Specification combines several elements…

The Behavior Qualifier breaks the Control Record down as a fractal pattern


component





Control RecordUsed to track the working of

a Service Domain




behavior



As

sig

ne

d R

ec

ord

s

Re

fere

nc

e D

eta

ils

Co

nfi

gu

rati

on

&

Sta

tus

Wo

rk S

pa

ce

Rec

ord

s

Beh

avio

r Q

ualifi

er

Beh

avio

r Q

ualifi

er

Beh

avio

r Q

ualifi

er

Beh

avio

r Q

ualifi

er

Service Domain

Resource Plans &

Activity Records

Reference Details


Work Space Records

Control Record

Control Record

Control Record

Control Record

Resources

Reference Details


Control Records

Assigned Records

Reference Details

Configuration &

Status

Work Space Records

Sub Qualifier

Sub Qualifier

Sub Qualifier

Sub Qualifier

Resources

Refe

rence

Deta

ils

Config

uratio

n &

Sta

tus

Contr

ol

Records

Resources

Refe

rence

Deta

ils

Config

uratio

n

& S

tatu

s

Contr

ol

Records

Reso

urces

Refe

rence

Detai

ls

Conf

iguration

&

Stat

usCont

rol Reco

rds

Behavior

Qualifiers

Su

bQ

ua

lifi

ers

Sub Sub

Qualifiers

Su

b S

ub

Su

bQ

ua

lifiers

❑ The use of behavior qualifiers

ensures the purpose of a service

operation stays consistent when

applied at finer levels of detail




A Component Design Combines The Dynamic and Static Views

The Business Scenario captures the archetypal flow for a business event

The Wireframe is a framework showing the available connections of interest


3 - The BIAN Business Scenario and Wireframe

Customer Reference Data

Management

CustomerOffer


Product Directory

Document Services

Collateral Asset

Administration

Mortgage Loan

Underwriting

Retrieve

Retrieve

Retrieve

Create

Register

Initiate

Evaluate




The Wireframe for an Area Can Appear Complex at First Glance…

Typically a Wireframe is assembled for a group of related Business Scenarios to reveal

the structure of a business area of interest

e.g. the Wireframe for Customer Servicing


3 - The BIAN Business Scenario and Wireframe

Card CaptureContact

Routing

Customer

Offer

Channel

Activity Analysis

Channel

Activity History

Contact

Dialogue

E-Branch

Operations

Contact

Handler

Point of

Service

Customer

Workbench

Regulatory

Compliance

Correspon-

dence

Credit

Administration

Prospect

Management

Customer

Agreement

Customer

Profoile

Customer

Access Entitlement

Sales Product

Agreement

Mortgage

Loan

Customer

Event History

Servicing

Event History

Party

Authentication

Collateral

Allocation Management

Collateral

Asset Administration

Position

Keeping

Underwriting

Advanced

Voice Svs Ops

Product

Directory

Customer

Product/ServiceEligibility

Execute

Execute

Execute

Execute

RetrieveRetrieve

Execute

Execute

Evaluate

Initiate

Execute

Document

Services

Transaction

Authorization

Fraud

Detection

Fraud Models

Fraud/AML

Resolution

Register

Evaluate Record

Retrieve

Request

Retrieve

Execute

Retrieve

Retrieve

Provide

Execute

Provide

Retrieve

Configure

Execute

Execute

Record

Retrieve

Create

Party Data

Management

Location Data

Management

CustomerReference

DataManagement

Retrieve

Retrieve

Record Retrieve

Retrieve

Evaluate

Record

Retrieve

Retrieve

Initiate




In Mapping BIAN to REST Several Refinements Have Been Made

The Service Domains and their service operations have been mapped to the REST

architectural style as this is the prevailing approach for APIs


3 - Service Domain Service Operations

Functional Pattern Generic Artifacts Matched to the REST Archetype

Generic ArtifactFunctional Pattern

DIRECT

ASSESS

MAINTAIN

MANAGE

ADMINISTER

CATALOG

DESIGN

DEVELOP

TRACK

ANALYSE

MONITOR

OPERATE

FULFILL

TRANSACT

AGREE TERMS

ENROLL

ALLOCATE

PROCESS

Strategy

Assessment

Maintenance Arrangement

Management Charter

Administrative Plan

Directory Entry

Specification

Development Project

Log

Analysis

State

Operating Session

Fulfillment Arrangement

Transaction

Agreement

Membership

Allocation

Procedure

ADVISE Advice

Mapped RESTful Archetype

Document

Document

Document

Document

Document

Controller

Controller

Controller

Controller

Controller

Controller

Controller

Collections

Collections

Controller

Document

Document

Document

Document

Example URI

http://api.example.com/enterprize-management/responsibilities/{strategy-Id}

http://api.example.com/business-management/responsibilities/{management-plan-Id}

http://api.example.com/administration-management/responsibilities/{aministrative-plan-Id}

http://api.example.com/model-design/customer-models/{model-Id}

http://api.example.com/application-development/retail-projects/{project-Id}

http://api.example.com/back-office/payments/customer-billing

http://api.example.com/production/ATM-network/operation

http://api.example.com/systems/computer/{id}/maintenance

http://api.example.com/consumer-products/current-account/{id}/arrangement

http://api.example.com/wholesale-products/equity-trade/{id}/transaction

http://api.example.com/wholesale-products/corporate-finance/{id}/advice

http://api.example.com/customer-relations/{id}/customer-history/log

http://api.example.com/products-and-services/{id}/product-specifications

http://api.example.com/syndicated-loans/syndicate-members

http://api.example.com/customer-relations/{id}/state

http://api.example.com/issued-devices/device-type/{id}/{allocation-Id}

http://api.example.com/customer-relations/{id}/{agreement-Id}

http://api.example.com/products-and-services/{id}/{assessment-Id}

http://api.example.com/customer-relations/{id}/profitability-analysis/{analysis-id}

/customer reference data/{cr-reference-id}/reference/{bq-reference-id}/address/{sq-reference-id}/execution

Behavior

Qualifiers

Business ObjectsAction

TermReference, Configuration & Transactional Data

Request Payload

Response Payload

Service Domain/

Control Record

Sub

Qualifiers

(Optional)

Concatenation?

The Layout of the REST Endpoint is Assembled from the Control Record

❑ Service Domains can be

related to the REST

Archetypes

❑ Service Operations map

to the HTTP Methods

commonly used by REST

❑ The REST endpoint is

derived from the Control

Record




Section 4 - Implementation Approach

1. Key Properties of components

❑ Components & Componentization

❑ Information Architecture

❑ Communications

2. Adding Implementation Detail

❑ BIAN defines Conceptual Designs – Mapping to ISO 20022 Business Model (conceptual

object model) and the BIAN BOM

❑ Externalization – Example of Customer Offer

❑ Logical Design Extensions

❑ Variations, Design options, Organization, Non-functional requirements

❑ Application “Clusters”

❑ Scope of BIAN - Conceptual/Logical/Physical

3. Implementation Approach

❑ Legacy wrapping

❑ Type 1,2,3 Access API usage patterns

Content Has Only Been Recently Available, Experience is Limited

The considerations and observations from deployments amongst member firms are

Guide Section 4 - Implementation Approaches

Implementation Considerations




The Two Selected Combinations Cover Most Initiatives

Three considerations combine to define the scope of an implementation project

Two combinations are explored in the Guide: legacy repurposing of back office

transaction processing systems & container based new development of front office

customer interaction systems


Solution Implementation Considerations

Problem

Resolution and

Exceptions

Processing

Applications

Decision

Support and

Customer

Interaction

Applications

Product

Transaction

Processing

Applications

Self

Service/Automati

c Fulfillment

Applications

Monolithic

Process Oriented

Architecture

Component/

Container Based

SOA

Back-Office

Product

Fulfilment

Front-Office

Customer

Interaction &

Decisioning

Technical

Approach

Area of

Focus

❑ Monolithic/process

automation Vs Component

based service enabled

❑ Back office transaction

processing Vs Front office

customer interactions

❑ Legacy re-purposing Vs New

systems build




For both legacy renewal and new development, the business component model can be

used to identify opportunities for operational re-use

In a typical standalone application 80-90% of the logic could be re-used if correctly

designed

Operational Reuse with Support for Incremental Adoption is Key…


1 - Key Properties of Components - Components & Componentization

A Stand-alone Consumer

Loans System

Consumer Loans

Transaction Processing

Cu

sto

mer

Inte

rfac

eService Configuration


Customer File Transaction LogMaster File

Pro

du

ction

Services

Customer Reference

Data

OfferProcessing

ProductSpecification

Accounting

Cu

stom

erC

redit

Ratin

g

Cu

stom

erP

references

Cu

sto

mer

P

oin

t o

f S

ervi

ce

DocumentServices

ConsumerLoan

Fulfillment

Transactions

A Consumer

Property Insurance System

Consumer Insurance

Transaction Processing

Cu

sto

mer

Inte

rfac

e

Service Configuration


Customer File Transaction LogMaster File

Pro

du

ction

Services

CustomerReference

Data

OfferProcessing

ProductSpecification

Accounting

Cu

stom

erC

redit

Ratin

g

Cu

stom

erP

references

Cu

sto

mer

P

oin

t o

f S

ervi

ce

DocumentServices

Insurance Policy

Transactions

Claims Processing

Components wrapped/built for one system canbe reused inanother...

Unique

components




The significant majority of systems design have been based on a process oriented

representation of business. Good process based design can be very effective…

...but for some requirements an alternate component based model can be more

appropriate – BIAN employs a component view

What is one Key Limitation of Process Design?

Eliminate redundant

steps

Automatemanualtasks

Reduce number of variations

Do more things

in parallel

Leverage shared

services


1 - Key Properties of Components - Information Architecture




Process designs typically employ a common data store that is usually optimized for

performance of the specific business activity being addressed…

...coordination between different processes that share information is complicated

when processes are developed at different times, by different people…

Systems Developed to Automate Processes Have Narrow Context

Automated Production Process

Integrated, High-performance

Database






Coordinating between related processes quickly becomes complicated as processing

dependencies and data synchronization requires myriad connections…

For shared databases the data definitions must be consistent

Problem is Compounded Because Processes Constantly Evolve…

Shared

databases

can help






A typical large bank will support many hundred or thousands of production processes.

It is perhaps not surprising that 60-90% of many large bank’s IT budget goes towards

maintaining existing production systems

A Component Business Model can help Address this Complexity…






KEY:Legacy systems capabilities

There Must be a Better Way…

An enterprise database works with limited scope but introduces latency/inconsistencies

Enterprize Database…?






Fixing a few Choke Points can Provide Significant Early Benefits

Component solutions can be integrated and built incrementally within legacy systems

Analysis of the elements is used to target those areas that are the main bottlenecks…


Targeted and ‘wrapped’ solutions seed the migration




e.g. Party

Authentication

Evaluations

Each Service Domain Encapsulates its own

Information





Stabilized Service Domains wired into re-purposed legacy

Stabilized Service Domains operating as a service network

And Further Improvements are Incremental

As Service Domains are stabilised behind service boundaries, new areas are added






In Time the Legacy Mess Melts Away…

Over time more of the legacy is wrapped, replaced or rendered obsolete










In the End Only a Few Legacy Systems May Remain

Eventually the migration replaces the significant majority of the portfolio.










For both legacy renewal and new development, the standard service boundaries and

connections support many aspects interoperability

The semantic definitions are intended to be sufficiently detailed to be unambiguous.

Local mapping changes should not destabilize other established connections


1 - Key Properties of Components - Communications

❑ Canonical Services Domains/service operations – can be used to define

standard service/message classifications for both external B2B/C and internal A2A

connectivity

❑ Semantic Definitions – are sufficient to define the context, purpose and content of

the exchange in unambiguous terms. They will need to be extended to map to the

local physical representation (and to add operational/security capabilities etc.).

❑ Information Governance – by their design the Service Domains define the

governance context for all business information. This can be used to ratify

responsibility for information integrity across the application portfolio




The BIAN control record attributes are mapped to the ISO 20022 Business Model

where possible. BIAN has suggested extensions and enhancements in cases

As the ISO model does not cover all banking activities BIAN is also developing its own

business object model to ensure the consistent definition of business information

BIAN will Map to Other Information Models when Possible


2 - Adding Implementation Detail – Mapping to ISO20022 & the BIAN BOM

❑ Mapping to ISO20022 – as the ISO 20022 Business Model is the

prevailing industry standard for many banking activities, BIAN maps to

and adopts the same terms where appropriate. BIAN has also

proposed significant enhancements to the ISO model

❑ Parallel Definition of the BIAN BOM – as the BIAN model seeks to

cover all banking activity and given the unique structure of the BIAN

control record – BIAN is also developing its own business object model

(BOM)




Both when mapping to legacy applications and scoping out new developments, it is

important to ensure the scope of responsibility is correct for a Service Domain

The process of ‘externalization’ ensures that internal functionality is focused on the

control record life cycle and that all supporting activities are properly delegated

Externalization is Key to Proper Encapsulation


2 - Adding Implementation Detail – Externalization

The customer and bank have agreed to process the mortgage application. Available customer reference data is obtained and the Product Directory referenced to see what the offer processing requirements are.

The customer’s current bank credit assessment is obtained.

Next the details of the property being mortgaged are captured, including the current valuation

The gathered details are used to obtain an underwriting decision

The offer and all other related documents are classified and recorded in the document archive

Finally the mortgage facility is initialized

BIAN Business Senario: Customer Mortgage Application

Bank

Customer Reference Data Management

Check knowncustomer

and retrieve

referencedatat

Retrieve

Customer Offer Credit Administration

Product Directory

Document Services

Get the rules and guideliens

for processing the mortgage offer

Retrieve

Retrieve the current credit assessment

for the customer

Retrieve


Mortgage LoanUnderwriting

Create a new collateral asset record (includes valuation)

Create

Set up the underlying transaction log for the new current account facility

Register

Initiate a withdrawal from the main current account

Initiate

Transfer funds from the main current account to the new facility

(Note this can be a one-off transsfer, a sweep arrangement or standing order as appropriate)

Evaluate

Mortgage application captured as a BIAN business scenario ❑ Customer Offer orchestrates the

offer process but only contains

details of the offer itself

❑ Related activities are delegated

to other specialist Service

Domains (externalization)

❑ Proper ‘externalization’ ensures

that the focus of the Service

Domain is solely on the life-cycle

of its own control record

Customer Offer

orchestrates

processing

And delegates to

other specialist

Service Domains




The conceptual designs define high-level business requirements. This is intended to

be in sufficient detail to define the primary role of the Service Domain unambiguously

The high-level conceptual requirements needs to be extended to implementation level

logical (and physical designs)

BIAN Hopes to Maintain a Repository of Mapped Physical Designs


2 - Adding Implementation Detail – Logical Design Extensions

❑ Variations - adding detail that may be specific to support advanced or

differentiated behaviors, detail to take account of scale requirements (for larger

enterprises), detail to handle geopolitical specific needs

❑ Design Options – selecting between the possible working approaches

available such as support for interactive versus off-line processing, or the

support for different delivery channels ❑Organizational Arrangements – handling

the particular geographic distribution and

different lines of business that make up an

enterprise (note the example)

❑ Non-functional Requirements – target

goals can be defined for the application

covering properties such as performance

and security




The scope of a new application will typically include several Service Domains

Local Service Domain proxies are needed for performance and security purposes

BIAN Does Not Prescribe Specific Clusters for Applications


2 - Adding Implementation Detail – Application Clusters

Key - the Service

Domain’s Role:

Service Domain

Service Domain

Service Domain

Service Domain

Core = Service Domain

wholly contained within

cluster

Proxy = Local instance

synchronised with

master

External = First order

service operation

connections

Peripheral = Second

order dependencies – for

reference

Utility = Local instance,

no need to synchroniseService Domain

Cross-product Processing

Product Fulfillment

Customer Reference

Current Account

TermDeposit Position Keeping

Party Data Management

Customer Reference Data

Management

Savings Account

RetirementAccount

Transaction Engine

Customer

Interaction

Product Support Facilities

Product Management

Customer Contract

Customer Offer

Payment Order

Product Portfolio

Contact Dialogue

Customer Order

Customer Agreement


Correspon-dence

Issued DeviceAdministration

Market Data Switch

Operation

Product Directory

Systems Operations

Product Design

Initiate

Issued DeviceTracking

Customer Access

Entitlement


Execute

Retrieve

Retrieve

ExecuteUpdate

Execute

Update

InitiateUpdate

Update

Update

Execute

Execute

Retrieve

Payment Execution

Execute

Record

ExecuteRetrieve

Retrieve

Retrieve

Document Services

Retrieve

BIAN Service

Operation ‘Action’

Term

Application Cluster showing Core/Utility/Proxy Roles




The scope of BIAN Specifications mapped to levels of design detail. Examples of

physical implementation may be cross-referenced

BIAN is a High Level Conceptual Design of Mainstream Functions


2 - Adding Implementation Detail – Summary Scope of BIAN

Conceptual Requirements

Logical

Designs

Physical

Specifications

▪ BIAN Service Landscape

▪ Service Domain Definitions

▪ Business Scenarios & Wireframes

▪ BIAN BOM (mainstream coverage)

▪ Service Domain Design Extensions (additional detail +)▪ Advanced/Differentiated Features

▪ Geopolitical/Scale Variations

▪ Error & Exception Handling

▪ Non Functional Requirements (Performance & Security)

▪ Organizational Distribution

▪ Data Definitions (comprehensive coverage)

▪ Technical Specifications & Configuration

▪ Software Specifications (Code)

▪ Database Schema

▪ Communications Platform

▪ Etc.

Referenced

Implementation

Library

(future option)




The BIAN Semantic APIs have only been developed recently, it is too early to define

deployment approaches, but there are guidelines and early observations

Additional techniques and examples will be captured from members

As Implementation Experience is Gained This Section will Expand


3 - Implementation Approach – Legacy Wrapping

❑ Application Clusters – the same

mechanism used to scope out new

development can be adapted for legacy

❑ Wrapping & Service Enablement –

wrappers that mitigate shortfalls in the

legacy systems and define

standard/reusable services

❑ Migration Strategies – the ‘parallel

core’ approach can be considered using

Service Domains as a framework

❑ Shared Platform – an approach where

the conceptual service exchanges are

eliminated in practice by mapping the

underlying data to a shared platform

Conceptual

Requirements

Logical

Designs

Physical

Specifications

Service Exchanges Aligned at the Conceptual Level and Interpreted Internally

Semantic

Agreement

Conceptual

Requirements

Logical

Designs

Physical

Specifications

Conceptual

Requirements

Conceptual

Requirements

Logical

Designs

Logical

Designs

Physical

Specifications

Conceptual Service Exchanges are ‘Eliminated’ By Physical Data Concurrence

Shared

Data




Experience supporting external access to the banks internal systems has revealed

three main approaches:

External Access (e.g. FAPI/OIDC) a Critical Aspect of Open Banking


3 - Implementation Approach – Type 1,2 & 3 Access APIs

Type 1. Direct to Core

API Service

Description

Read only or simple ‘atomic’

update transactions

supported by a single host

system. The solution is likely

to be host application specific

Type 2. Wrapped Host

Enhanced ‘simple access’ services

aligned to established standards.

Wrapping may enhance service

capabilities and some hosts may

support more complex exchanges

Type 3. Component Architecture

Support for flexible and complex

interactions involving multiple business

activities and processing/decision

chains

Examples

◆ Retrieve a

balance/account

statement

◆ Reference a

product/service directory

◆ Initiate a payment

◆ Prospect on-boarding and origination

◆ Customer dispute/case resolution

◆ Customer relationship development/up-

sell/cross-sell campaigns

◆ Third party service integration

Business

Drivers

Provide application based

access to an

established/existing type of

customer exchange

Provide application based access

with a high degree of standards

alignment. Mask/augment

host/legacy system limitations.

◆ Support sophisticated interactions

◆ Support new business models

◆ Support for 3rd party integration

◆ Leverage advanced

technologies/architectures

Message conforms to industry

standards (e.g. ISO20022)◆ Retrieve a balance/account statement

◆ Reference a product/service directory

◆ initiate a payment

◆ Customer on-boarding/offers

Definition

The API routes direct to the

core system providing the

service. Intermediate channel

based access control and

‘buffering’ is required

Integrating service middleware – a

service bus – ‘wraps’ the host

systems. The service bus can offer

various host access mitigation

capabilities/enhancements

The host services are implemented as

loose coupled micro-services with

complex interactions supported by

sophisticated connective middleware

Pros &

Cons

Pro - Easy to implement

Pro - Re-uses interfaces

Con - Can’t do multi-phase

Con - Not handle automation

Pro - Reuses legacy capabilities

Pro - Mitigates some shortfalls

Con - Limited for multi-phase

Con - Limited for access controls

Pro - Supports sophisticated interactions

Pro - Supports flexible models

Con - Complex to implement

Con - Operational overheads




Most banks are likely to need to support combinations of the different types of access.

Alignment to the BIAN Service Domains/service operations ensures consistency



BANK

CUSTOMER

3rd PARTY

PROVIDER

BIAN Semantic Service Directory

API GatewayAuthentication

Service (Customer & TPP)

Resource Access

Authorization (Customer & TPP)

Type 1

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service DomainService Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Business ApplicationsService

Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Rationalised Business

Applications

Type 2

DATA DATA

Service Domain

Service Domain

Service Domain

Service Domain Service

Domain

Service Domain

Service Domain Service

Domain

External Access PlatformService Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Autonomous Service Center Business Applications(+A2A Services Platform)

Service Wrapper

Host

Mitigation

Host

Mitigation

Host

Mitigation

Host

MitigationType 3



For open banking, the difference between Type 1 Vs Type 3 access has far reaching

implications for the role the bank can play

BIAN is building out the specification of the Type 3 interface in a PoC with FDX

BANK





Settling for a Type 1 Interface Gives Away Control of the Exchange

CUSTOMER

3rd PARTY

PROVIDER




Resource Access


Service Domain

DATAService Domain

DATA

Service Domain

DATAService Domain

DATA

Service Domain

DATAService Domain

DATA

Service Domain

DATAService Domain

DATA

Service Domain

DATAService Domain

DATA

Service Domain

DATAService Domain

DATA

Service Domain

DATAService Domain

DATA


Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Type 1Type 3

Servicing

Order


TPP

‘Keyhole’

Access

Authentication &

Consent Authorization


For open banking, the difference between Type 1 Vs Type 3 access has far reaching

implications for the role the bank can play

BIAN is building out the specification of the Type 3 interface in a PoC with FDX

BANK

Case Management

InstitutionalRelations





Settling for a Type 1 Interface Gives Away Control of the Exchange

CUSTOMER

3rd PARTY

PROVIDER




Resource Access


Service Domain

DATAService Domain

DATA

Service Domain

DATAService Domain

DATA

Service Domain

DATAService Domain

DATA

Service Domain

DATAService Domain

DATA

Service Domain

DATAService Domain

DATA

Service Domain

DATAService Domain

DATA

Service Domain

DATAService Domain

DATA


Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Service Domain

Type 1Type 3Customer

Campaigns

Collateral & Cash Flows

Credit & Underwriting

Merchant Campaigns Suitability

&Eligibility

RelationshipManagement

Servicing

Order

Authentication &

Consent Authorization


TPP

‘Keyhole’

Access

BIAN Webinar April 2020

BIAN Semantic API Practitioner Guide – Overview




Freemium

BIAN’s Internal Wiki and Official Homepage

59 Copyright BIAN 2020 | Banking Industry Architecture Network


▪ Fees (annual membership)

▪ Software / Tech vendors / Integrators

(250 employees or more)

▪ EUR 30.000,-

▪ Banks / FI’s that are not vendors

▪ EUR 20.000,-


(less than 250 employees)

▪ EUR 10.000,-

▪ Federal Banks / Central Banks

▪ EUR 10.000,-


(less than 50 employees)

▪ EUR 5.000,-

▪ Academic Partners

▪ EUR 0,-

Member driven organization


Upcoming Webinar

BIAN and ArchiMate; a Focus on Information Architecture

May 11th, 3pm Central European Time

61


62

Questions?

Please stay muted and type your

Questions in the righthand bar, or

send them to [email protected]

Date post:	19-Jun-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	1 times