FI Card Data Architecture Document Ver 1.5.4.pdf - IDRBT
FI Card Data Architecture Document Ver 1.5.4.pdf - IDRBT FI Card Data Architecture Document Ver 1.5.4.pdf - IDRBT
Customer Card Data Architecture Version 1.5.4 Specification 10 3 Design Preamble 3.1 Data elements in Data Objects For the purpose of simplicity and ease of use, all the static nature of data elements have been stored in form of data objects in TLV structure. These data objects have been placed either directly under MF or under the respective DF. As these data objects are static in nature, must be protected from modification/deletion, once created initially. 3.2 Data elements in EF The data elements, which are dynamic and need modification at field, are stored in a protected EF. Access privileges for these EFs are defined and distributed only to authorized entities, in form of Master Keys. 3.3 Application Dedicated Files (DFs) Different FI Applications shall be residing as separate DF’s on the FICC, directly under the MF. The DF names shall be standard and if loaded, shall be loaded on the card with these names only. IBA-IDRBT Technical Committee on Open Standards for Financilal Inclusion January 2010
Customer Card Data Architecture Version 1.5.4 Specification 11 Following are few DF’s for different applications, Application Name DF Name Savings Account F1 00 Cash Credit F2 00 Demand Loan F3 00 Remittance F4 00 Insurance F5 00 Term Deposit F6 00 Recurring Deposit F7 00 SHG Savings Bank F8 00 Overdraft F9 00 Table 3: Lists of Applications with DF names These names are indicative for mapping in the smart card and do not change the characteristic or behavior of the bank’s respective schemes or products. The terminal application can be written for validating respective products. E.g., Savings account may have an in-built feature of an overdraft whereas some others may have it separately. The differentiation is to be handled by the terminal application. Any product(s) that vary from the standard names specified above may be bank specific definition which will not be treated as interoperable . However the repository of all such application DF’s shall be maintained by a central body for optimum utilization of name space and every bank, for a new application, shall obtain the DF name from this central body. The MF architecture of the card should comply with the structure as defined in this document. The Savings Bank application is mandatory for FI Bank Customer card and its architecture should comply with the structure as defined in this document. IBA-IDRBT Technical Committee on Open Standards for Financilal Inclusion January 2010
- Page 1 and 2: Customer Card Data Architecture Ver
- Page 3 and 4: Customer Card Data Architecture Ver
- Page 5 and 6: Customer Card Data Architecture Ver
- Page 7 and 8: Customer Card Data Architecture Ver
- Page 9: Customer Card Data Architecture Ver
- Page 13 and 14: Customer Card Data Architecture Ver
- Page 15 and 16: Customer Card Data Architecture Ver
- Page 17 and 18: Customer Card Data Architecture Ver
- Page 19 and 20: Customer Card Data Architecture Ver
- Page 21 and 22: Customer Card Data Architecture Ver
- Page 23 and 24: Customer Card Data Architecture Ver
- Page 25 and 26: Customer Card Data Architecture Ver
- Page 27 and 28: Customer Card Data Architecture Ver
- Page 29 and 30: Customer Card Data Architecture Ver
- Page 31 and 32: Customer Card Data Architecture Ver
- Page 33 and 34: Customer Card Data Architecture Ver
- Page 35 and 36: Customer Card Data Architecture Ver
Customer <strong>Card</strong> <strong>Data</strong> <strong>Architecture</strong><br />
<strong>Ver</strong>sion 1.5.4 Specification<br />
10<br />
3 Design Preamble<br />
3.1 <strong>Data</strong> elements in <strong>Data</strong> Objects<br />
For the purpose of simplicity and ease of use, all the static<br />
nature of data elements have been stored in form of data<br />
objects in TLV structure. These data objects have been placed<br />
either directly under MF or under the respective DF. As these<br />
data objects are static in nature, must be protected from<br />
modification/deletion, once created initially.<br />
3.2 <strong>Data</strong> elements in EF<br />
The data elements, which are dynamic and need modification<br />
at field, are stored in a protected EF. Access privileges for<br />
these EFs are defined and distributed only to authorized<br />
entities, in form of Master Keys.<br />
3.3 Application Dedicated Files (DFs)<br />
Different <strong>FI</strong> Applications shall be residing as separate DF’s<br />
on the <strong>FI</strong>CC, directly under the MF. The DF names shall be<br />
standard and if loaded, shall be loaded on the card with these<br />
names only.<br />
IBA-<strong>IDRBT</strong> Technical Committee on Open Standards for Financilal Inclusion<br />
January 2010
Change language