Software Design Description

Anti-Money Laundering and Combating the Financing of
Terrorism System / AMLCFT/
< Project Name>

Software Design Description
< Client Organization >
Version: X.Y
Document Id: project id (sn-yy-pt) - sc-028
Information Network Security Agency (INSA)
Secured Information System Development Directorate
<Month Year>
Software Design Description for <Project> 2
Based on IEEE Std 1016TM-1998 document format
Template Code: SDD - TEMP – 028, Ver. 1.0 July 2013
Copyright © 2013 Information Network Security Agency (INSA)
No part of this publication may be reproduced in any form, in an electronic retrieval system or
otherwise, without the prior written permission of the publisher.
Note:
 Make sure this is the latest version while using this template
 User is strongly advised to read the SDD Recommended Practice before using this
document
Template Revision History

Software Quality Assurance Team
Date Name Reason For Changes Affected Version

Pages/Sections
07/08/2013 Eleni Yisehak First Release Draft
07/25/2013 Demiss Mammo Section 8 which is a security feature Section 8 1.0

added
Document Revision History
Date Name Reason For Changes Affected Version

Pages/Sections
Information Network Security Agency (INSA) <document Id>

TABLE OF CONTENTS
TEMPLATE REVISION HISTORY............................................................................................................................. 2
DOCUMENT REVISION HISTORY.......................................................................................................................... 2
EXECUTIVE SUMMARY........................................................................................................................................ 7
1 INTRODUCTION.......................................................................................................................................... 8
1.1 PURPOSE....................................................................................................................................................... 8
1.2 SCOPE...........................................................................................................................................................8
1.3 DEFINITIONS AND ACRONYMS............................................................................................................................8
1.4 REFERENCE MATERIAL......................................................................................................................................8
2 SYSTEM OVERVIEW..................................................................................................................................... 9
3 SYSTEM ARCHITECTURE............................................................................................................................ 10
3.1 ARCHITECTURAL DESIGN.................................................................................................................................10

3.2 DESIGN RATIONALE........................................................................................................................................10
4 DECOMPOSITION DESCRIPTION................................................................................................................ 11
4.1 SUBSYSTEM DECOMPOSITION..........................................................................................................................11

4.1.1 <Subsystem 1>........................................................................................................................................11
4.1.2 <Subsystem 2> and so on…....................................................................................................................12
4.2 DATA DECOMPOSITION..................................................................................................................................12
4.2.1 Data Description.....................................................................................................................................12
4.2.2 <Data Entity 1>.......................................................................................................................................12
4.2.3 <Data Entity 2> and so on…....................................................................................................................12
5 DEPENDENCY DESCRIPTION...................................................................................................................... 13
5.1.1 Subsystem/Process Dependencies..........................................................................................................13

5.1.2 Data Dependencies.................................................................................................................................13
5.1.3 Other Dependency..................................................................................................................................13
6 INTERFACE DESCRIPTION.......................................................................................................................... 14
6.1 SUBSYSTEM INTERFACES.................................................................................................................................14

6.1.1 Overview of User Interface.....................................................................................................................14
6.1.2 <Subsystem 1> Description.....................................................................................................................14
6.1.3 <Subsystem 2> Description.....................................................................................................................14
7 DETAILED DESIGN..................................................................................................................................... 15
7.1 SUBSYSTEM DETAILED DESIGN.........................................................................................................................15

7.1.1 Subsystem 1 Detail Design......................................................................................................................15
7.1.2 Subsystem 2 Detail Design......................................................................................................................15
7.2 DATA DETAILED DESIGN.................................................................................................................................15
7.2.1 Data Entity 1 Detail Design.....................................................................................................................15
7.2.2 Data Entity 2 Detail Design.....................................................................................................................16

7.2.3 Data Dictionary.......................................................................................................................................16
8 DESIGN SECURITY..................................................................................................................................... 17
8.1 SECURITY DESCRIPTION...................................................................................................................................17
APPENDICES...................................................................................................................................................... 17

List of Tables

List of Figures

Executive Summary
[Write a summary of the entire document – not more than two paragraphs.]

1 Introduction
1.1 Purpose
The design description defined in this document serves multiple purposes:
 To describe the functional structure, data and algorithms to be implemented.
 To identify required system resources.
 To be used to assess the impact of requirement changes.
 To assist in producing test cases.
 To be used to verify compliance with requirements.
 To aid in maintenance activities.
1.2 Scope
This Software Design Description (SDD) describes the detailed structure of the components of
the Anti-Money Laundering and Combating the Financing of Terrorism System / AMLCFT/ and
the precise implementation details required to satisfy the requirements as specified in the
Requirement Analysis document (RAD). It is assumed that the reader has read the RAD, since
this document also defines the implementation details of the desired behavior given the
requirements within it. This document will build heavily on the SDD and so knowledge of the
general system architecture is recommended prior to commencing this document.
1.3 Definitions and Acronyms

For a complete list of the definitions and acronyms used in the remainder of this
document, refer to the Glossary.
1.4 Reference Material

This section is optional.
List any documents, if any, which were used as sources of information including the SRS.

2 System Overview
Financial Intelligence Center (FIC)is governmental organization established in 2002 E.C. as per Council
of Ministers Regulation No.171/2009 to fight against Money laundering and Terrorist Financing activities
that could be carried out within the country. FIC collects report from different source and performs in-
depth and complex analysis on financial transactions conducted within the country. Currently, these
financial transactions are being collected from different Banks (private and governmental banks) as
primary source of data and it could expand its information source and will collect data from other
reporting entities like Insurance companies, NGO’s, Real state owners, Attorney’s, Brokers, etc. In
addition to this, FIC might communicate with other governmental organizations and similar foreign
countries’ organizations for information exchange.
After analyzing reports collected from reporting entities and performing different investigation, FIC
might create court case if law violation detected and passes it to court for accusation; or communicate
other legal bodies for further investigations if it found that an individual or entity is participating in
money laundering or terrorist financing activities.
Currently FIC is functioning through its Head Office in Addis Ababa and has not established branches
yet.
The following diagram shows the organizational structure of FIC and the directorate for which this
proposal is prepared is indicated in bold.
The current organizational structure of the IT department is not sufficient to accommodate the proposed
solution. So INSA strongly believe that a well-designed and equipped structure is required to run the
proposed solution more effectively.

3 System Architecture
3.1 Architectural Design
To show the overall PRMS architecture, the software design is organized in to layered system
Architecture. The following layers are identified in the software architecture. These are:
Presentation tier - This tier, which is built with HTML5, cascading style sheets (CSS) and
JavaScript, is deployed to a computing device through a web browser or a web-based
application. The presentation tier communicates with the other tiers through application program
interface (API) calls.
Application tier - The application tier, which may also be referred to as the logic tier, is written
in a programming language .NET and C# and contains the business logic that supports the
application’s core functions. The underlying application tier can either be hosted on distributed
servers in the cloud or on a dedicated in-house server, depending on how much processing power
the application requires.
Data tier - The data tier consists of a database and a program for managing read and write access
to a database. This tier may also be referred to as the storage tier and can be hosted on-premises
or in the cloud. Microsoft SQL Server is the database system we used for managing read/write
access.

Figure 1: System architecture of AMLCFT
3.2 Design Rationale

Here is the rationale for selecting three tire architecture
1. It gives you the ability to update the technology stack of one tier, without impacting other
areas of the application.
2. It allows for different development teams to each work on their own areas of expertise.
3. You are able to scale the application up and out. A separate back-end tier, for example,
allows you to deploy to a variety of databases instead of being locked into one particular
technology. It also allows you to scale up by adding multiple web servers.
4. It adds reliability and more independence of the underlying servers or services.

5. It provides an ease of maintenance of the code base, managing presentation code and
business logic separately, so that a change to business logic, for example, does not impact
the presentation layer.

4 Decomposition Description
As Described in the above section there are three subsystems in AMLCFT. These subsystems are
STR, CTR and CBTR Collection portal, Analysis and Visualization which are decomposed
according to their functionality they contribute to the whole system.
4.1 Subsystem Decomposition

4.1.1 CTR, STR and CBTR Collection
4.1.1.1. CTR, STR and CBTR Collection Feature

This feature helps Reporting entities and their Compliance to send their reports to FIC using the
portal or file upload mechanism. It also helps the compliance to view report for Accepted and
Rejected reports from he/she send to FIC .For reporting Entity Administrator (Intermediate
Administrator) it allows to Manage User and Branch
Use Case Name Use Case Description Responsible Class Responsible Method/s
Maintain STR, To maintain STR|CTR|CBTR ReportUI submitReport
CTR and CBTR Report into the system by filling
ReportBLogic submitTransaction
predesigned form (online) Report submitAccount
Transaction submitBeneficiary
Account submitInvolver
Beneficiary submitAddress
Upload STR| To maintain STR|CTR|CBTR ReportUI submitReport
CTR|CBTR Report into the system using file ReportBLogic submitTransaction
upload method Report submitAccount
Transaction submitBeneficiary
Account submitInvolver
Beneficiary submitAddress
Maintain User To maintain their Representatives UserUI saveUser
Account information into the system (online) UserBLogic saveRole
and To create Encoder Account and User saveRepresentative
Roles Role updateRepresentative
viewRepresentativ
Maintain To maintain New Reporting BranchUI saveBranch
Reporting Entities, branches BranchBLogic updateBranch
Entities, Branch deleteBranch
Branches viewBranch

Table 1: Report Collection sub-system feature detail description
4.1.1.2. Class Diagram
DataAccess
-connectio nString:object 1
-connectio n:object 1 1
-command:object getdata * 1
-reader:object 1
-dataAdapter:object
Representative
-flag:object
1
+DBC onnectionS tring():bool -representativeId:int
+GetData():void 1 -idCardNumber:string
1 1
1 -firstName:string
-middleName:st ring
1
GetData -lastName:string
-oth erName:string
* 1 +Insert():void
getdata
+Update():void
Branch +GetData():object
1 1
1 -branchId:int
-branchName:string
has 1 send
+Insert():void
+Update():void getdata
* 1
+GetData():object
* 1
Report
getdata
-ReportId:byte
1 1 -reportType:string
1 -reportDate:date
has reportS tatus:string
1 1 ReportingEntity *
reason:string
-reportingEntityId:byte +Insert():void
Adress +Update():void
1 -reportingEntityName:string
-businessType:string +Delete():void
AdreeId:byte 1
-registrationNumber:string +GetData():object
-country:string
-state:string +Insert():void 1 1
-subcity/zone:string +Update():void
-woreda:string +GetData():object
has
1 1 -town:string
-kebele:st ring 1
-houseNo:string has
1
-postalAddres:string
-businessM obileNo:string
-businessCon tactNo:string
-businessFaxNo:string
-residentialContactNo:string 1 1
-emailAddress:string
+Insert():void Transaction
+Update():void
Account
+GetData():object -TransactionId:byte
-AccountId:byte -transactionDate:datetime
1 1 -transactionCurrency:string
-accountNumber:string 1 *
-firstName:string -fundAmountInBirr:string
-middleName:string 1 -transactionType:string 1
* 1
-lastName:string as soci ationType:string
has
1 -accountType:string 1 remark:st ring
-dateOpened:daate +Insert():void
-dateClosed:date +Update():void
dateOfBalance:date +GetData():object
+Insert():void
+Update():void
+GetData():object
has 1 *
* 1
ownby
ownby
Business
1 *
Busi nessId:byte
-businessName:string
1
Person has -registrationNumber:string
1 -taxIdentificationNo:string
PersonId:byte -issui ngCountry:string
-firstName:string +Insert():void
middleName:string +Update():void
-lastName:string +GetData():object
-oth erName:string
1
-rin:string 1
-oin:string
* -birthDate:date 1
-sec:string
-passportNo:string
-countryResidence:string
-contryOrigin:string
occupationOfPerson:string
+Insert():void
+Update():void
+GetData():object
Figure 2: Class diagram of Report Collection sub-system

4.1.2 Analysis
4.1.2.1 Analysis Feature

This feature helps FIC Analysts to make different types of analysis like Link analysis, Rule
based analysis and Time Line analysis. It also helps FIC Director and Team leader to manage
STR reports through communicating with each other and with the analyst about the ongoing
analysis on specific STR report.
Assign STR To manage and Grantee a STR ReportUI assignReport
Report To team Reports to Specific Team Leader ReportBLogic sendRemark
Leader According to Crime Type Report updateStatus
Assign STR To manage and Grantee a STR ReportUI assignReport

Report to Reports to Specific analyst in ReportBLogic sendRemark
Analyst his/her Team Report updateStatus
Analyze To analyze different kinds of Report ReportUI timeLineAnalysis

Trend/Time Line Trends based on Time interval ReportBLogic
Report Report
AIR
Analyze Link To analyze the link between ReportUI linkAnalysis
Accounts and Account or account ReportBLogic
holder To account Report
AIR
Manage Alerts To Manage and prioritized alerts AlertUI saveAlert
triggered by the rules engine AlertBLogic saveRule
Alert updateAlert
Rule deleteAlert
viewAlert

4.1.2.2 Class Diagram
Analysis
Report Search
Data Access
ReportId: int SearchWord:string
Connectionstring: Object M1 M2 *
1 * ReportType: string 1 ParameterSearch:string
Connection : Object Get data TotalFillSearch:int
1 ReportDate:DateTime 1
Command: Object 1 1 * TotalFillFound:int
Status:String
1 Reader : Object -Display():string
StatusReason:
DataAdapter: Object -SortData():void
Flag: bool *
Generate() :void -BindData():void
-DBConnection string (): bool 1
Get data(): void Uses 1 1
* 1
Get data 1 1 Get Data
! * 1 1
Get data
1 1
Link TimeLine
Proximity
LInkId : int
* startingTime :Dateatime
* LinkType: string SearchQuery:string
EndingTime: DateTime 1
LinkSource: string 1 StartDatetime:DateTime
1 DevisionScale:int EndDateTime:DateTime
LinkWeight: double *
DivisionType: string DocumentRelevance:double
LinkLevel: byte
Destination: string -InitializeProximity():void
GenerateLink(): DrowTimeLine(): -CalculateProximity():void
Figure 3: The class diagram of Analysis sub-system

4.1.3 Visualization
Visualization subsystem is responsible for the process of representing Intelligence or
Knowledge or analysis output in different visualization techniques
 Time series View: - comprises methods for analyzing time series Accounts in
order to extract meaningful statistics and other characteristics of the Account. Time
series forecasting is the use of a model to predict future values based on previously
observed values.
 Link analysis view: - is a Transaction-analysis technique used to evaluate

relationships (connections) between different accounts activities. Relationships may
be identified among various types of nodes or transactions edges. Link analysis
presents on graphical and textual view
 Search/ Queries and matching: - The queries and matching component allows
users to enter requests for matches on a wide variety of criteria such as name,
address, country, account number, identification document number or type, etc.
There are a number of search options. Some are specific to the preferred search
criteria and full details or parts thereof can be entered. There is also a quick finder
option which essentially allows the user to Google© the entire database. After the
query is submitted the system returns a list of all entities matching the requested
criteria and links them, where links exist.
 Report: - This component allows statistical and general reports to be automatically
generated or ad hoc statistics to be obtained from the system to prepare reports on
all activities carried out within the System. Many different types of reports can be
produced.
Generate Report To generate different kinds of report ReportUI generateReport
about Reporting entities, accounts , ReportBLogic
accountholder and STR|CTR|CBTR Report
reports
Search To search Report information by ReportUI searchReport
giving different parameters (E.g. ReportBLogic
Account Owner name, Account Report

Number, Report type, date and

time)
Analyze To analyze different kinds of Report ReportUI drawTimeLineAnalysis
Trend/Time Line Trends based on Time interval ReportBLogic
Report Report
AIR
Analyze Link To analyze the link between ReportUI drawLinkAnalysis
Accounts and Account or account ReportBLogic
holder To account Report
AIR
4.1.3.1 Class Diagram
Visualization
Report
Data Access
ReportId: int
Connectionstring: Object
ReportType: string
Connection : Object 1 * ReportDate:DateTime 1
Command: Object Get data Status:String
Reader : Object 1 1 *
StatusReason:
DataAdapter: Object
Flag: bool
Generate() :void
-DBConnection string (): bool
Get data(): void
* 1 * 1
! *
1 1
1 *
Link
TimeLine
LInkId : int Search
LinkType: string
LinkSource: string startingTime :Dateatime SearchWord:string
LinkWeight: double EndingTime: DateTime ParameterSearch:string
LinkLevel: byte DevisionScale:int TotalFillSearch:int
Destination: string DivisionType: string TotalFillFound:int
-Display():string
DrowTimeLine():
GenerateLink():
Figure 5: The class diagram of Visualization sub-system
4.2 Data Decomposition

4.2.1 Data Description

<Explain how the information domain of your system is transformed into data structures.
Describe how the major data or system entities are stored, processed and organized. List any
databases or data storage items.>
4.2.2 Report Information

In Report Information entity the information of STR, CTR and CBTR will be stored. The
information includes date of the report and sender entity and branch detail.
4.2.3 Transaction Information

In this data entity Transaction information detail will be manipulated. This information includes
date of where the transaction is occurred, amount in both birr and other currency and other
details.
4.2.4 Account Information

In this data entity Account information detail will be manipulated. This information includes
Account Number, Account Owner Name and other details.
4.2.5 Beneficiary Information

In this data entity Beneficiary information detail will be manipulated. This information includes
Beneficiary name, Beneficiary Account and other details.
4.2.6 Business Information

In this data entity Business information detail will be manipulated. This information includes
Business registration number, business type and other details.
4.2.7 Person Information

In this data entity Person information detail will be manipulated. This information includes
Name, Sex, Passport Number and other details.
4.2.8 Address Information

In this data entity Address information detail will be manipulated. This information includes
Country, Woreda, HouseNo and other details.

5 Dependency Description
AMLCFT has ten entities these are: Reporting entity, Reporting entity branch, reporting entity
representative, Report Information, Transaction, Account, Beneficiary, Business, Person, and
Address. All these entities are related with each other’s. Report information is related with
Reporting entity, Reporting entity branch, reporting entity representative, Transaction
information is related with Report information, Account information is related with Transaction
information, Beneficiary information is related with Transaction information and address
information, Business information is related with Transaction information and Address
Information
5.1.1 Subsystem/Process Dependencies

As discussed in high level architecture of AMLCFT in section 3.1, the business layer contains
report Collection, analysis and Visualization sub system which depend up on the user
management and authentication sub system, this indicate that report Collection, analysis and
Visualization sub system will be handled after user management and authentication sub system
since users authentication is a must.
5.1.2 Data Dependencies

5.1.2.1 Data Flow Diagram
<Use data flow diagrams, DFDs show the flow of data from external entities into the system,
how the data moved from one process to another, as well as its logical storage and also help to
identify required resources>
5.1.2.2 Entity Relationships

<Use entity relationship (ER) diagrams since ER diagrams show the abstract representation of
data model; building blocks of the ER diagrams are entities, relationships and attributes. ER
diagrams show relationships and dependencies among different entities>
5.1.3 Other Dependency

<Describe any assumptions or dependencies regarding the software and its use, some of these
are mentioned on the SRS but if there is a need to refine them here is the place. These may
concern such issues as:
o Related software or hardware
o Operating systems
o End-user characteristics
o Possible and/or probable changes in functionality
o Data migration: how will data migrated from old system to the new>
6 Interface Description
6.1 Subsystem Interfaces

6.1.1 Overview of User Interface
<Describe how the user will be able to use your system to complete all the expected features
and the feedback information that will be displayed for the user.>
6.1.2 <Subsystem 1> Description

<Don’t really say “Subsystem 1” State the subsystem name>
6.1.2.1 Screen Images

<Display screenshots showing the interface from the user’s perspective of all the forms or major
forms in the graphical user interface with a reference to the functional requirements under each
subsystem. These can be hand drawn or taken from the prototype if there is any or you can use
an automated drawing tool (like Caretta GUI Design Studio Professional). Just make them as
accurate as possible.>
6.1.3 <Subsystem 2> Description

6.1.3.1 Screen Images

7 Detailed Design
<The detailed design section contains the internal details of each design entity. This description
contains the details needed by programmers prior to implementation. The detailed design
description can also be used to aid in producing unit test plans.
7.1 Subsystem Detailed Design

7.1.1 Subsystem 1 Detail Design
 Describe in detail the attributes and methods needed by each class (the
second and third "compartments" of the representation for each class in a class
diagram.)
 In describing the detail class design, show or identify also their corresponding
packages and the package’s corresponding sub system.
 For each method you must include the following information where
applicable:
 Method Name
 Parameters, each documented with its intended use
 Return Value, suitably documented
 Informal description of what the procedure does
 Data structure and tables it accesses
 Pre-conditions: Assumptions the method can make about the state of
the global data structures and database when it starts
 Validity Checks, Errors, and other Anomalous Situations: Validity
checks the method must make about the state of the global data
structures, the database, and its parameters, including the actions
that must be taken when such a check fails.
 Post-conditions: The changes the method is supposed to make to the
global data structures and database.
 Called by: The methods or events that call it
 Calls: The methods it calls and any events it causes.
 One general note: Make sure that you provide references back to your
Requirements specification document wherever possible.>
7.1.2 Subsystem 2 Detail Design

<Specify the actual subsystem name>

7.2 Data Detailed Design

7.2.1 Data Entity 1 Detail Design
<Don’t really say “Data Entity 1” State the data entity name>
For each global data structure and database you should include the following information where
applicable:
 Identify specific data elements and logical data groupings that are stored and processed
by the design entities.
 Outline data dependencies, relationships, and integrity rules.
Here any detail data design that is not mentioned under dependency description section and
crucial to the implementer should be specified.>
7.2.2 Data Entity 2 Detail Design

<Don’t really say “Data Entity 2” State the data entity name>
7.2.3 Data Dictionary

<Alphabetically list the system entities or major data along with their types and descriptions in a
tabular form, along with the content, structure, and use of all data elements >

8 Design Security
8.1 Security Description

< Implement security feature described on SRS document >
APPENDICES
This section is optional.
Appendices may be included, either directly or by reference, to provide supporting details that
could aid in the understanding of the Software Design Document.

Software Design Description

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Design Description

Uploaded by

Copyright:

Available Formats

Anti-Money Laundering and Combating the Financing of

Terrorism System / AMLCFT/

< Project Name>

Information Network Security Agency (INSA)

Secured Information System Development Directorate

Based on IEEE Std 1016TM-1998 document format

Template Code: SDD - TEMP – 028, Ver. 1.0 July 2013

Copyright © 2013 Information Network Security Agency (INSA)

Template Revision History

Date Name Reason For Changes Affected Version

07/25/2013 Demiss Mammo Section 8 which is a security feature Section 8 1.0

Document Revision History

Date Name Reason For Changes Affected Version

Information Network Security Agency (INSA) <document Id>

TEMPLATE REVISION HISTORY............................................................................................................................. 2

DOCUMENT REVISION HISTORY.......................................................................................................................... 2

3.1 ARCHITECTURAL DESIGN.................................................................................................................................10

4.1 SUBSYSTEM DECOMPOSITION..........................................................................................................................11

5.1.1 Subsystem/Process Dependencies..........................................................................................................13

6.1 SUBSYSTEM INTERFACES.................................................................................................................................14

7.1 SUBSYSTEM DETAILED DESIGN.........................................................................................................................15

Information Network Security Agency (INSA) <document Id>

7.2.3 Data Dictionary.......................................................................................................................................16

8.1 SECURITY DESCRIPTION...................................................................................................................................17

Information Network Security Agency (INSA) <document Id>

Information Network Security Agency (INSA) <document Id>

Information Network Security Agency (INSA) <document Id>

Information Network Security Agency (INSA) <document Id>

1.3 Definitions and Acronyms

1.4 Reference Material

Information Network Security Agency (INSA) <document Id>

Information Network Security Agency (INSA) <document Id>

Information Network Security Agency (INSA) <document Id>

Figure 1: System architecture of AMLCFT

3.2 Design Rationale

Information Network Security Agency (INSA) <document Id>

Information Network Security Agency (INSA) <document Id>

4.1 Subsystem Decomposition

4.1.1.1. CTR, STR and CBTR Collection Feature

Information Network Security Agency (INSA) <document Id>

Table 1: Report Collection sub-system feature detail description

4.1.1.2. Class Diagram

Figure 2: Class diagram of Report Collection sub-system

Information Network Security Agency (INSA) <document Id>

4.1.2.1 Analysis Feature

Assign STR To manage and Grantee a STR ReportUI assignReport

Analyze To analyze different kinds of Report ReportUI timeLineAnalysis

Information Network Security Agency (INSA) <document Id>

4.1.2.2 Class Diagram

Figure 3: The class diagram of Analysis sub-system

Information Network Security Agency (INSA) <document Id>

 Link analysis view: - is a Transaction-analysis technique used to evaluate

Information Network Security Agency (INSA) <document Id>

Number, Report type, date and

4.1.3.1 Class Diagram

4.2 Data Decomposition

Information Network Security Agency (INSA) <document Id>

4.2.1 Data Description

4.2.2 Report Information

4.2.3 Transaction Information

4.2.4 Account Information

4.2.5 Beneficiary Information

4.2.6 Business Information