1p impl_r3(id)_app_ap352_batch processing - casa v0.5

CIMB Niaga 1Platform R3 (Indonesia)

Functional Specification Design

Batch Processing – CASA & ISA

Workstream Deposit

Version 0.5

Release Status Draft

Release Date 3rd December 2014

This document is the property of CIMB Niaga and its contents may not be disclosed to any person, or company, unless they are employed by CIMB Niaga directly, or in a consultant or contractor capacity.

of 150

Version Control0.2 Document Information

Prepared By: Nelson Ng Weng Hwa

Prepared Date: 19th September 2014

Reviewed By: Chong Kok Wei

Review Date: 22nd September 2014

0.2 Version HistoryVersion Revision Date Updated By Summary of Changes0.1 19th September

2014Nelson Ng Weng Hwa

Initial Draft

0.2 20th October 2014 Nelson Ng Weng Hwa

1. Rectify document name2. Amendment for Section 2.33. Amendment for Section 84. Add a sentence for Section 9.15. Add a paragraph for Section 9.56. Amend Section 13.4 for clarity7. Change definition for Elapsed

Term in Section 14.38. Replace SOF with ISA in Section

14.49. Rephrase note for Section

14.4.1.210. Rephrase third paragraph in

Section 1511. Rephrase third paragraph in

Section 18


of 150

12. Remove Japanese Desk from Section 23

13. Correct typo error for PPWM in Section 23.1

14. Rephrase Section 23.1.315. Remove paragraph on RC Code

from Section 29.716. Reduce number of program

penalty from 10 to 917. Enhance solution for

Requirement ID 1PID_DP_01074

18. Add Requirement ID1PID_DP_000281PID_DP_00206 (enhanced)1PID_DP_002911PID_DP_00349

0.3 31st October 2014 Nelson Ng Weng Hwa

1. Rectify example for Withholding Tax in Section 7

2. Replace ‘Max Sum Assured’ with ‘Max Insurance Coverage’

3. Amendment for Section 13.1.44. Added a sentence and remove

example for Combined Statement in Section 23.1

0.4 16th November 2014

Nelson Ng Weng Hwa

1. Added example for Combined Statement in Section 23.1

0.5 3rd December 2014 Nelson Ng Weng Hwa

1. Added a sentence for the Multiplier in Program Penalty in Section 14.4

2. Amended example for Combined Statement in Section


of 150

23.1

0.3 DistributionSign Off List

Name Role Date

Reviewer ListName Role Date

0.4 Supporting Document


of 150

Table of Contents

Contents1 Statement of Purpose.............................................................................................................................12

2 Intended Audience.................................................................................................................................12

3 Assumptions / Scope..............................................................................................................................12

4. 24-hour Mode....................................................................................................................................13

5. Cycle Code.........................................................................................................................................16

6. Interest / Profit Processing................................................................................................................17

6.1 Balance......................................................................................................................................17

6.1.1 Ledger Balance...................................................................................................................17

6.1.2 Average Balance................................................................................................................18

6.1.3 Minimum Balance..............................................................................................................19

6.1.4 Accrual Balance..................................................................................................................19

6.1.5 Reserve Percentage...........................................................................................................21

6.2 Interest Rate..............................................................................................................................21

6.2.1 Reference Rate..................................................................................................................22

6.2.2 Flat Rate.............................................................................................................................22

6.2.3 Split Rate............................................................................................................................22

6.2.4 Tier Rate.............................................................................................................................23

6.2.5 Alternate Rate....................................................................................................................23

6.2.6 Tier Code............................................................................................................................23

6.2.7 Fixed Rate (for ISA)............................................................................................................24

6.3 Interest Computation Method...................................................................................................25

6.3.1 Simple................................................................................................................................25

6.3.2 Compounded.....................................................................................................................25


of 150

7. Withholding Tax Processing...............................................................................................................29

8. Zakat Processing................................................................................................................................31

8.1 Income.......................................................................................................................................31

8.2 Wealth (Zakat Mal)....................................................................................................................31

8.2.1 Zakat Deduction.................................................................................................................31

8.2.2 Payment Date....................................................................................................................31

9. Charges..............................................................................................................................................33

9.1 Waiver.......................................................................................................................................33

9.2 Product-based Charges..............................................................................................................33

9.2.1 Administrative Charge.......................................................................................................33

9.2.2 Service Charge...................................................................................................................33

9.2.3 Volume Charge..................................................................................................................34

9.3 Event-based Charges.................................................................................................................36

9.3.1 Dormant Charge.................................................................................................................36

9.3.2 Subsequent Dormant Charge.............................................................................................37

9.3.3 Statement Charge..............................................................................................................37

9.4 Transaction-based Charges........................................................................................................38

9.4.1 Cheque Book Request during Account Opening................................................................38

9.4.2 Cheque Book Request using eTP.......................................................................................38

9.4.3 Cheque Book Request via Clicks.........................................................................................38

9.5 Tiering Charge............................................................................................................................39

10. Owing............................................................................................................................................40

10.1 Creation of Owing......................................................................................................................40

10.2 Recouping of Owing...................................................................................................................40

11. Cash Back.......................................................................................................................................42

12. Amortization..................................................................................................................................45


of 150

13. Insurance.......................................................................................................................................49

13.1 Insurance Premium borne by bank............................................................................................50

13.1.1 Percentage of Regular Installment.....................................................................................50

13.1.2 Percentage of Target Balance............................................................................................51

13.1.3 Percentage of Average Balance or Ledger Balance (other than ISA)..................................52

13.1.4 Percentage of Accumulated Regular Installments.............................................................53

13.1.5 Percentage of Sum Assured (No Capping, per account).....................................................54

13.2 Insurance Premium borne by customer.....................................................................................54

13.2.1 Sufficient Fund for Installment Amount but Insufficient Fund for Insurance Premium.....54

13.2.2 Insufficient fund for Installment Amount but Sufficient Fund for Insurance Premium......54

13.3 Commission...............................................................................................................................54

13.4 Tax.............................................................................................................................................55

14. Penalty...........................................................................................................................................58

14.1 Default.......................................................................................................................................58

14.2 Delinquency...............................................................................................................................58

14.3 Product Penalty.........................................................................................................................59

14.4 Program Penalty........................................................................................................................61

14.4.1 Elapsed Term.....................................................................................................................62

14.4.2 Proportional Elapsed Factor...............................................................................................67

15. Dormancy......................................................................................................................................73

16. Auto Closure..................................................................................................................................75

17. Disposition.....................................................................................................................................76

18. External Account............................................................................................................................77

19. Forex Transaction Monitoring.......................................................................................................80

19.1 Initialization of accumulated USD equivalent............................................................................80

19.2 Initialization of Forex Transaction Monitoring History...............................................................80


of 150

20. Intraday Limit.................................................................................................................................81

20.1 Highest Negative Balance..........................................................................................................81

20.2 Total Negative Balance..............................................................................................................81

21. Message.........................................................................................................................................87

22. Passbook Compression..................................................................................................................88

23. Statement......................................................................................................................................90

23.1 Combined Statement.................................................................................................................91

23.1.1 Consolidated Combined Statement...................................................................................92

23.1.2 PPWM Statement..............................................................................................................92

23.1.3 Mailing Address.................................................................................................................92

23.1.4 Checksum...........................................................................................................................92

23.1.5 Exchange Rate information................................................................................................93

23.1.6 Statement information......................................................................................................93

24. AFT.................................................................................................................................................96

24.1 Number of Retries.....................................................................................................................96

24.2 Termination of AFT....................................................................................................................96

24.3 Transfer to Third Party Charge Code..........................................................................................96

24.4 Failed AFT..................................................................................................................................96

24.5 Allow Partial Transfer.................................................................................................................96

24.6 Priority.......................................................................................................................................97

24.7 Effective Date.............................................................................................................................97

24.8 Next Transfer Date.....................................................................................................................97

24.9 Expiry Date.................................................................................................................................97

25. Sweep............................................................................................................................................98

25.1 Contract Setup Fee....................................................................................................................98

25.2 Daily Sweep Charge...................................................................................................................98


of 150

25.3 Minimum and Maximum Charge per Cycle................................................................................98

25.4 Sweep Charge............................................................................................................................98

25.5 Priority.......................................................................................................................................99

25.5.1 Sequential..........................................................................................................................99

25.5.2 Highest Balance.................................................................................................................99

26. Product Conversion.....................................................................................................................105

26.1 Product Conversion due to Age...............................................................................................105

26.2 Product Conversion due to Customer Segment.......................................................................105

26.3 Product Conversion due to Customer’s Request.....................................................................105

27. Branch Transfer...........................................................................................................................106

27.1 Customer’s Request.................................................................................................................106

27.2 Bulk Branch Transfer................................................................................................................106

27.3 Branch Merger.........................................................................................................................106

28. Housekeeping..............................................................................................................................107

28.1 Transaction History..................................................................................................................107

28.2 Closed Account........................................................................................................................108

29. Other Applications.......................................................................................................................110

29.1 ATM / Debit Card.....................................................................................................................110

29.2 Bancassurance.........................................................................................................................111

29.3 CIF............................................................................................................................................111

29.4 Credit Card...............................................................................................................................112

29.4.1 EMS..................................................................................................................................113

29.4.2 FDS...................................................................................................................................114

29.4.3 Merchant Incentive..........................................................................................................116

29.5 Cross Product...........................................................................................................................117

29.6 E-Alert......................................................................................................................................118


of 150

29.7 GL.............................................................................................................................................119

29.8 Interface..................................................................................................................................124

29.9 Payments.................................................................................................................................129

29.10 Remittances.........................................................................................................................130

29.11 Loans....................................................................................................................................131

29.12 System Services...................................................................................................................132

29.13 UCP......................................................................................................................................133

29.14 Virtual Account....................................................................................................................134

29.15 Miscellaneous......................................................................................................................135


of 150

Table 1Interest Accrual (Ledger Balance)..................................................................................................18Table 2Interest Accrual (Average Balance)................................................................................................18Table 3Interest Accrual (Minimum Balance).............................................................................................19Table 4Minimum Accrual Balance.............................................................................................................20Table 5Maximum Accrual Balance.............................................................................................................20Table 6Reserve Percentage.......................................................................................................................21Table 7Compounded Interest....................................................................................................................26Table 8Withholding Tax.............................................................................................................................29Table 9Intraday (Beginning Credit Balance)...............................................................................................82Table 10Intraday (Beginning Zero Balance)...............................................................................................83Table 11Intraday (Beginning with Negative Balance without Deposit)......................................................84Table 12Intraday (Beginning with Negative Balance with Deposit)...........................................................85Table 13Intraday (Beginning with Credit Balance and OD Limit)...............................................................86


of 150

1 Statement of Purpose

This FSD documents the Batch Processing for Conventional as well as Islamic CASA and ISA. Processing for the following is Indonesia-specific:1. Point to Point Interest and Charge Cycles2. Tier Code3. Rate Review for ISA4. Withholding Tax 5. Zakat 6. Owing 7. Amortization 8. Insurance Premium, Commission and Tax9. Product Penalty and Program Penalty10. Suspicious Transaction11. Forex Transaction Monitoring 12. Intraday

Words denoting the singular shall, where applicable, include the plural and vice versa and words denoting the masculine gender shall, where applicable, include the feminine and/or neuter genders and vice versa. Reference to persons shall include corporations.

2 Intended Audience

This document is intended to be used by CIMB Business Users 1P Indonesia Team.

3 Assumptions / Scope

1P Batch Processing will be adopted for items not outlined above, unless otherwise specifically stated.


of 150

4. 24-hour Mode

The system is able to process transaction even when batch processing is in progress. The batch processing is divided into four zones:

1. Zone 1 – the system will verify the processing dates2. Zone 2 – the system is still in Day Mode and pre-batch charges will be debited to the

account. System will also back-up the files before switching to Night Mode3. Zone 3 – the system is in Night Mode and core processing is being run.4. Zone 4 – the batch processing for Day T has been completed and system is now in

Day T + 1 where it will process transactions or instructions that are due on Day T + 1. Examples are AFT, Effective Date of Interest Rate.

The following is a list of requirements that are related to batch processing for 24-hour mode.

Requirement ID Requirement Solution

1PID_DP_00516 System must able to process: Deposit detail balance checking Generator

This is related to Dual End of Day for which the status is pending.

1PID_DP_00517 System must able to process: Merge CD/DD/OD to Balance Checking Work File


1PID_DP_00518 System must able to process: Balance Checking Summary DD & OD


1PID_DP_00521 System must able to process: Checkbook file update for un-posted items

There will no longer be un-posted cheques because the file will be spooled by ACH. Thus, the status of the cheque will be updated automatically.

1PID_DP_01085 System must be able to cater CASA/TD account opening from e-Channel during 24hr mode

This requirement has been dropped.

1PID_DP_01090 24 mode transactions must be able to calculate available balance correctly,

Incorrect balances for 24 hour mode transactions occur in V2 because they are


of 150

including spooled transactions, system to-be-generated transactions.All system generated transaction can identify correct account balance to avoid transactions posted with error balance or amount (example: cause negative balance savings).

posted directly into the accounts during batch run.

In V10, a Batch Process is divided into four Zones. System will attempt to debit an account when the process is in Zones 2, 3 and 4.

Processing in Zone 2 happens when the system is still running in Day Mode. Pre-batch charges like Cheque Book Charge, Stop Payment Charge are debited in this Zone. If the balance in the account is insufficient to cover for the charges, the amount will go into Owing if it has been defined as ‘Y’ in the Owing field in the Demand Deposit Product parameter.

Transactions that are performed by the customer when batch processing is in Zone 3 will be logged into DDMEMO24 and reposted during Zone 4.

Processing Zone 4 happens when the previous day’s batch processing has completed and the system is up for the next day. At this time, the branch is still not yet opened for business. AFT will be processed in this Zone. AFT-related charges will go into Owing if there is insufficient fund in the account.

Account Balance will be correct in Zones 2 and 4. Incorrect Balance arises when the system is attempting to process charges such as Administrative Fee, Fall below Fee, Dormant Fee and Volume Charge when it is in Zone 3. It is recommended that these charges be processed in Zone 4.

It is also advisable to define a Minimum Maintaining Balance in the Product so that there will always be sufficient fund to


of 150

debit an account for charges.

(The rest of the page is intentionally left blank)


of 150

5. Cycle Code

A Cycle Code can be defined using the Cycle Code parameter. The defined Cycle Code can be applied on:

1. Charge Cycle2. Interest Cycle3. Statement Cycle

Example

On 4th January 2014, Cycle Code ‘31’ is defined to begin on 31st January 2014 with a monthly frequency. System will execute the Charges, Interest or Statement that have been defined with Cycle ‘31’ on 31st January 2014. System will roll the next Cycle Date for Cycle Code ‘31’ to 28th February 2014.

The following is a list of requirements that are related to batch processing for Cycle Code.


1PID_DP_00850 SIBS must support point to point interest cycle. For point to point method, interest cycle will start and end at the anniversary day from the account opening date instead of following interest cycle.

[Based on discussion on PID_DP_00281]

Cycle Code parameter is to be enhanced with an additional field:Day of Month for DefaultingDemand Deposit Product parameter is to be enhanced with an additional field:Auto Default Cycle Date (Y/N)

If a product’s Auto Default Cycle Date is defined as ‘Y’, Host Teller is to be enhanced to stamp the Interest and Charge Cycle Codes to the account, based on Date of Opening. If it is ‘N’, Host Teller is to stamp the Product’s Interest and Charge Cycle Codes to the account.

System is to execute the Charges and the Interest that are due on the Cycle Code.


of 150


of 150

6. Interest / Profit Processing

Interest or Profit is accrued on a daily basis using the formula:

P x R x T ÷ 365

P = Principal or Balance

R = Rate

T = 1

Note:

R will be (GYD * r) for Islamic, where r is the Ratio (customer’s). Ratio is commonly known as Nisbah in CIMB Niaga. GYD is Gross Yield Dividend.

Accruals are computed up to five decimals but passed to GL by rounding up the total accrual to two decimals. The daily accrual for GL is then computed by deducting the T2’s GL Balance from T1’s.

6.1 BalanceThere are three types of balances that can be defined at the product. The three tables below illustrate the difference.

6.1.1 Ledger BalanceInterest/Profit is computed on positive Closing Balance.


of 150

Day Ledger Balance GL Bal123 1,000,000.00 2% 54.79452 54.79452 54.79 54.794 2,000,000.00 2% 109.58904 ### 109.59 164.385 2,000,000.00 2% 109.58904 ### 109.60 273.976 2,000,000.00 2% 109.58904 ### 109.59 383.567 500,000.00 2% 27.39726 ### 27.40 410.968 500,000.00 2% 27.39726 ### 27.40 438.369 5,000,000.00 2% 273.97260 ### 273.97 712.33

10 5,000,000.00 2% 273.97260 ### 273.97 986.30

Interest Rate

Daily Accrual

Total Accrual

Daily GL Accrual

Table 1Interest Accrual (Ledger Balance)

6.1.2 Average BalanceInterest is computed on Average Credit Balance which is Aggregate Balance divided by Aggregate Days. Islamic products should be defined with Average Balance.

Ledger Balance Aggregate Bal Average Bal GL Bal

1 1,000,000.00 1,000,000.00 1,000,000.00 2% 54.79452 54.79452 54.79 54.792 2,000,000.00 3,000,000.00 1,500,000.00 2% 82.19178 136.98630 82.20 136.993 2,000,000.00 5,000,000.00 1,666,666.67 2% 91.32420 228.31050 36.53 228.314 2,000,000.00 7,000,000.00 1,750,000.00 2% 95.89041 324.20091 13.69 324.205 500,000.00 7,500,000.00 1,500,000.00 2% 82.19178 406.39269 -9.13 406.396 500,000.00 8,000,000.00 1,333,333.33 2% 73.05936 479.45205 -22.83 479.457 5,000,000.00 13,000,000.00 1,857,142.86 2% 101.76125 581.21331 19.57 581.218 5,000,000.00 18,000,000.00 2,250,000.00 2% 123.28767 704.50098 50.23 704.50

Aggregate Days

Interest Rate

Daily Accrual

Total Accrual

Daily GL Accrual

Table 2Interest Accrual (Average Balance)


of 150

6.1.3 Minimum BalanceInterest/Profit is computed on the lowest positive Closing Balance.

Day Ledger Balance123 1,000,000.00 1,000,000.00 1 2% 54.79452 54.79452 54.79 54.794 2,000,000.00 1,000,000.00 2 2% 109.58904 54.79452 54.80 109.595 2,000,000.00 1,000,000.00 3 2% 164.38356 54.79452 54.79 164.386 2,000,000.00 1,000,000.00 4 2% 219.17808 54.79452 54.80 219.187 500,000.00 500,000.00 5 2% 136.98630 -82.19178 -82.19 136.998 500,000.00 500,000.00 6 2% 164.38356 27.39726 27.39 164.389 5,000,000.00 500,000.00 7 2% 191.78082 27.39726 27.40 191.78

10 5,000,000.00 500,000.00 8 2% 219.17808 27.39726 27.40 219.18

Applicable Balance used

No. of days

Interest Rate

Total Accrual

Daily Accrual

Daily GL Accrual

GL Balance

Table 3Interest Accrual (Minimum Balance)

6.1.4 Accrual BalanceIt is possible to define a Minimum as well as a Maximum Ledger Balance for Accrual purpose. Table 4Minimum Accrual Balance illustrates the accruals if a Minimum Accrual Balance of 1,000,000 is defined.


of 150

Day Ledger Balance123 1,000,000.00 1,000,000.00 1,000,000.00 2% 54.79452 54.794524 2,000,000.00 1,000,000.00 2,000,000.00 2% ### ###5 2,000,000.00 1,000,000.00 2,000,000.00 2% ### ###6 2,000,000.00 1,000,000.00 2,000,000.00 2% ### ###7 500,000.00 1,000,000.00 - 2% 0.00000 ###8 500,000.00 1,000,000.00 - 2% 0.00000 ###9 5,000,000.00 1,000,000.00 5,000,000.00 2% ### ###

10 5,000,000.00 1,000,000.00 5,000,000.00 2% ### ###

Min Accrual Balance


Interest Rate

Daily Accrual

Total Accrual

Table 4Minimum Accrual Balance

Conversely, Table 5Maximum Accrual Balance illustrates the accruals if a Maximum Accrual Balance of 1,000,000 is defined.

Day Ledger Balance123 1,000,000.00 1,000,000.00 1,000,000.00 2% 54.79452 54.794524 2,000,000.00 1,000,000.00 1,000,000.00 2% 54.79452 ###5 2,000,000.00 1,000,000.00 1,000,000.00 2% 54.79452 ###6 2,000,000.00 1,000,000.00 1,000,000.00 2% 54.79452 ###7 500,000.00 1,000,000.00 500,000.00 2% 27.39726 ###8 500,000.00 1,000,000.00 500,000.00 2% 27.39726 ###9 5,000,000.00 1,000,000.00 1,000,000.00 2% 54.79452 ###

10 5,000,000.00 1,000,000.00 1,000,000.00 2% 54.79452 ###

Max Accrual Balance


Interest Rate

Daily Accrual

Total Accrual

Table 5Maximum Accrual Balance


of 150

6.1.5 Reserve PercentageIn addition, it is also possible to define whether a certain percentage of the ledger balance is to be made ineligible for interest / profit accrual.

Day Ledger Balance123 1,000,000.00 10% 100,000.00 900,000.00 2% 49.31507 49.315074 2,000,000.00 10% 200,000.00 1,800,000.00 2% 98.63014 ###5 2,000,000.00 10% 200,000.00 1,800,000.00 2% 98.63014 ###6 2,000,000.00 10% 200,000.00 1,800,000.00 2% 98.63014 ###7 500,000.00 10% 50,000.00 450,000.00 2% 24.65753 ###8 500,000.00 10% 50,000.00 450,000.00 2% 24.65753 ###9 5,000,000.00 10% 500,000.00 4,500,000.00 2% ### ###

Reserve Percentage

Reserved Amount

Net Accrual Amount

Interest Rate

Daily Accrual

Total Accrual

Table 6Reserve Percentage

6.2 Interest RateInterest Rate is defined as a Rate Number in the Interest Rate parameter. These Rate Numbers are then defined in the Product parameter and defaulted to the account. Changes in Interest Rate are to be updated in the Interest Rate parameter. These changes will be updated to the account automatically when batch processing is in Zone 4.

Accruals for Islamic accounts will be based on the previous month’s Gross Yield Dividend (hereinafter referred to as GYD). They will be dropped once the current month’s GYD is obtained, provided Recalculate has been defined as ‘Y’ in the Demand Deposit Product parameter. System will recalculate the accruals based on current month’s GYD.

There are three types of Interest Rate:

1. Flat 2. Split


of 150

3. Tier

6.2.1 Reference RateReference Rate can be defined as an Interest Rate Number in the Interest Rate parameter.

Example

Rate Number YYY

Reference Rate Number XXX

Variance / Variance Code +0.5%

If the Interest Rate for Rate Number XXX is 3.5%, the Interest Rate for Rate Number YYY will be 4.0%.

6.2.2 Flat RateWhen a Flat Rate is defined, this rate is applied for the entire balance of the account.

6.2.3 Split RateThe applicable interest rate of an account is split according to the balance of the account.

Example

Balance Greater or equal to Rate

10,000,001 3.5%

50,000,001 4.0%

100,000,001 4.5%

If an account’s balance is 105,000,000 the interest will be computed as follows:

First 10,000,000 0%

Next 40,000,000 3.5%


of 150

Next 50,000,000 4.0%

Remaining 5,000,000 4.5%

6.2.4 Tier RateThe applicable interest rate of an account is applied on the entire balance of the account.

Example

Balance Greater or equal to Rate

10,000,001 3.5%

50,000,001 4.0%

100,000,001 4.5%

If an account’s balance is 75,000,000 the applicable interest rate will be 4% on the entire balance.

6.2.5 Alternate RateSystem will accrue interest/profit using the Alternate Rate, if it has been defined in the Demand Deposit Product parameter. However, the daily accruals will not be posted to GL. The accrued amount will be capitalized to the account if the criteria defined for Alternate Rate is met. In this case, the amount that has been posted to GL under regular rate will be dropped.

6.2.6 Tier Code A new parameter, Tier Code, will be developed for a user to define the Interest Rate Numbers that are applicable for a particular Tier Code. The defined Tier Code is to be tagged to a Demand Deposit product. An account that is eligible for Account Pricing can be defined to be tagged to a particular Tier Code, subject to it being applicable for the product. The interest of an account with such Account Pricing will be accrued using the Interest Rate that is applicable for the Tier Code.


of 150

A Tier Code can be defined to be invalid at the account level based on:

1. Expiry Date2. Interest Capitalization

6.2.6.1 Expiry DateSystem will remove the Tier Code from the account at the defined Expiry Date. Thereafter, the account’s interest will be accrued at the product’s rate.

6.2.6.2 Interest CapitalizationSystem will remove the Tier Code from the account upon the capitalization of Interest. Thereafter, the account’s interest will be accrued at the product’s rate.

6.2.7 Fixed Rate (for ISA)There are two types of Interest Rate defined for an Installment Savings product.

1. Floating Rate – this is the Flat, Split or Tiered Rates that have been explained above

2. Fixed Rate – this is the Interest Rate that is fixed for an Installment Savings account depending on the tenure of the account. System will accrue interest using the Interest Rate that has been fixed for a particular period. Interest Rate changes to the corresponding Interest Rate Number does NOT apply to the account until the next Rate Review Date. Review Date is dependent on the tenure of the account, as per example below.

Example

Three Interest Rate Numbers have been defined for 36, 48 and 60 months.

Tenure Interest Rate Number12 month 61136 month 613


of 150

Based on the table above, the applicable Interest Rate Number for a customer who opts for the following tenure will be as follows:

Account Tenure

Applicable Interest Rate Number

Applicable Term

Applicable Rate on 1st Review Date

Applicable 1st Review Term

Applicable Rate on 2nd Review Date

Applicable 2nd Review Term

10 month Floating Rate 10 months - - - -12 month 611 12 months - - - -24 month 611 12 months 611 12 months - -36 month 613 36 months - - - -48 month 613 36 months 611 12 months - -50 month 613 36 months 611 14 months60 month 613 36 months 611 12 months 611 12 months

An ISA which is under Floating Rate can be changed to Fixed Rate and the Review Date will be at the expiry of the term under review, computed from the date of change.

6.3 Interest Computation MethodThere are two methods in which interest can be computed:

1. Simple2. Compounded

The accrued interest is stored in a field in the account’s master file and capitalized into the account on Interest Cycle date.

6.3.1 SimpleThe accrued interest is stored in a field in the account’s master file on a daily basis.

6.3.2 CompoundedThe accrued interest will be added to the balance for computation as illustrated in Table 7Compounded Interest.


of 150

Day Balance1 10,000,000.00 2% 547.94521 10,000,547.952 10,000,000.00 2% 547.97523 10,000,547.983 10,000,000.00 2% 547.97523 10,000,547.98

Interest Rate

Accrued Interest

Compounded Balance

Table 7Compounded Interest



of 150

The following is a list of requirements that are related to batch processing for interest accrual and interest capitalization.


1PID_DP_00036 System must support if Tier Rate code is selected and approved, interest tier will replace the default interest rate setting

As explained in Alternate Rate above.

1PID_DP_00053 System must support hold amount with differential interest rate:-a. different interest rate for hold amount for CASA compare to non-hold amountb. tiered interest rate for un-hold amountc. Treated CASA hold amount as cash collateralExamplea. Customer has Current Account balance IDR 10 Billion 1. IDR 2 Billion is hold due to cash collateral / LC 2. IDR 8 Billion is un-holdBusiness would like to have IDR 2 Billion to have interest rate 1% p.a., while the un-hold amount IDR 8 Billion follow standard rate 2.5% p.a.b. With same case above for the un-hold amount, customer will experience 1. First IDR 1-5 Billion get 2.5% p.a. 2. The next IDR 3 Billion (IDR 8 Billion – IDR 5 Billion) get 3.0% p.a.c. The IDR 2 Billion can be linked / recorded as cash collateral for a loan in SIBS

Two approaches have been proposed to the bank and at the time of writing, the preferred approach has not been confirmed.

1PID_DP_00502 System must able to process: Remove Overnight Records for Resending: Gen Summary Reversal Accrue Work File

This requirement is related to the CL program for LHBU file. It is no longer required as LHBU data will be extracted online in 1P.

1PID_DP_00852 If Current Account without OD facility maintain a negative balance at EOD, system must not automatically create OD/ loan

There is a mirror image of the Current Account in Loans module. It is possible to define whether non-OD protected


of 150

facility accounts are displayed in the Loans module when they are overdrawn, using the Negative Net Off field in the Demand Deposit Product parameter. The table below illustrates how an overdrawn account will appear when Negative Net Off is defined.

Negative Net Off

Ledger Balance

OD Balance

Y -1000 0N 0 1000

It is advisable to define Negative Net Off as N’ if the Product does not allow OD Protection.

Note:Debit Interest is computed by Loans module if Ledger Balance is Negative.

The solution to create an OD Facility is to be provided by Loans.

1PID_DP_00974 System must be able to calculate bonus for cashline Musyarakah account with positive balance and feed result as input for profit sharing module

Hibah or Bonus is valid for account with Al-Wadiah Concept Code. If the account is in credit, system will accrue bonus for it.

1PID_DP_01106 Daily accrual of interest must be calculated and posted to GL daily, by account (at account level)

As explained in Balance above.



of 150

7. Withholding Tax Processing

The Withholding Tax Code and its exempted balance are defined in Withholding Tax parameter. It will be available as pick list in Demand Deposit Product parameter. The defined Withholding Tax Code will be defaulted to the account when as account is opened. A different Withholding Tax Code can be made applicable to an account if the account holder is able to produce documents such as SKB (Surat Ketergangan Bebas Pajak) or COD (Certificate of Domicile). They can be maintained together with an Expiry Date using the CASA Withholding Tax Maintenance function.

System shall compute Withholding Tax based on the following:

1. Does the account earn any interest during the cycle?2. If yes, is the Average Balance of the account during the cycle greater than the

Exemption Amount?3. If yes, compute Withholding Tax based on the Withholding Tax Code that is

applicable for the account.

Percentage Average Balance Taxable? Interest Tax 0 0% 50,000,000.00 N N 125,000.00 0 2 20% 5,000,000.00 N N 12,500.00 0 2 20% 10,000,000.00 N Y 25,000.00 5,000.00 1 10% 10,000,000.00 Y Y 25,000.00 2,500.00

Withholding Tax Code

Valid SKB / COD?

Table 8Withholding Tax


of 150

If the account is in foreign currency, the Withholding Tax will be computed and debited to the account in the account currency. The GL Event Code will include both the foreign currency amount and the IDR equivalent amount. The IDR equivalent amount is computed by using the Withholding Tax Exchange Rate.

The following is a list of requirements that are related to batch processing for Withholding Tax.


1PID_DP_00501 System must able to process: Gen Detail Reversal Accrue Report (DD CD)

This requirement is about Year End Tax provision which has been dropped.

1PID_DP_00593 System must able to process: Get Data Pembayaran Bunga dan Pajak DD

As explained in Withholding Tax Processing above.



of 150

8. Zakat Processing

System is to compute Zakat if a customer opts for it. The percentage is defined in a parameter but the customer may opt for a different percentage at the account level. The Zakat Collection Account Number is defined in a parameter. There is only one Zakat Collect Account bank-wide. Zakat can be computed based on Income or Wealth.

8.1 IncomeZakat is to be deducted when Profit is capitalized into an account. If there is Withholding Tax, it is to be computed after Withholding Tax.

Zakat = (Profit – Withholding Tax) * y%

8.2 Wealth (Zakat Mal)The Wealth that is subject to Zakat is defined in Nisab parameter. A Nisab is to be defined for each currency. The date when Zakat Mal is to be paid is defined in Zakat parameter. Alternatively, a customer can also opt to pay Zakat Mal on his preferred date.

8.2.1 Zakat DeductionSystem is to group the accounts of similar currencies of the Primary CIF which have opted to pay Zakat on the same day and sum them up. If the summation exceeds the Nisab amount, system is to compute the Zakat for each account and deduct it from each account. The Zakat currency will be the account currency. If the account is denominated in foreign currency, the GL Event Code will include both the foreign currency amount and the IDR equivalent amount. The IDR equivalent amount will be computed using Buying TT Rate.

8.2.2 Payment DateIf a customer opts to pay Zakat on his preferred payment date, system is roll to the next Payment Date after Zakat has been deducted. The next Payment Date is to be computed based on Current Date plus the number of days in a Haul. Haul is defined in Zakat parameter.


of 150

The following is a list of requirements that are related to batch processing for Zakat.


1PID_DP_00032 System to add new field to capture Syariah Banking product details:- Nisbah/Bonus- ZakatNOTE: Zakat to be calculated and debited upon interest payment

As explained in Income above.



of 150

9. Charges

Charges can be defined by using the Charge Code parameter. Product-based Charges and transactions that require charges must be defined with a Charge Code. The former will be charged to the account when batch processing is in Zone 4 on the Charge Cycle Date. When an account is charged successfully, system will include the Charge Code as part of the GL Event Code for GFMS.

9.1 WaiverCharges can be waived based on the following criteria:

1. A specific Charge Code has been defined as Waive for Staff or certain segments.2. All Charges have been defined as Waive for a specific Product.3. A specific Charge Code has been defined as Waive for a specific account.4. All Charges have been defined as Waive for a specific account.

The Waiver will be uplifted on the Expiry Date if it has been defined as such for (3) and (4).

In addition, Service Charge can be waived for X Cycles.

9.2 Product-based ChargesThe following charges are defined at the Demand Deposit Product parameter and will be charged on their respective Charge Cycles.

9.2.1 Administrative ChargeThe Charge Code that has been defined for Administrative Charge will be executed on the Administrative Charge Cycle.

9.2.2 Service ChargeUp to five Service Charge Codes can be defined for a Demand Deposit Product. Charge Code that has been defined for Service Charge will be executed on the


of 150

Service Charge Cycle. It can also be defined to be exempted if there is certain balance in an account.

Example

Service Charge of Rp5,000 is applicable if the average balance of an account does not reach Rp5,000,000.

Average Balance Charge?Negative No

0 Yes4,000,000 Yes6,000,000 No

9.2.3 Volume ChargeUp to five Service Charge Codes can be defined for a Demand Deposit Product. The Charge Code that has been defined for Volume Charge will be executed on the Volume Charge Cycle. It can also be defined to be exempted if there is certain balance in an account.

Volume Charge can be defined as:

1. All2. Day 3. Each

9.2.3.1 AllCharge a fixed amount if the number of OTC transactions exceeds the threshold within the Volume Charge Cycle.Example

Charge Rp20,000 for OTC transaction above 5 times during Volume Charge Cycle


of 150

Number of transactions during Volume Charge Cycle: 8

Amount to be charged: Rp20,000

9.2.3.2 DayCharge X amount for all OTC transactions performed per day that has breached the threshold within the Volume Charge Cycle.

Example

Charge Rp20,000 per day for OTC transaction above 5 times during Volume Charge Cycle

Date Number of transactions Charge Amount1st to 20th August 2014 5 Nil21st August 2014 2 Rp20,00022nd August 2014 1 Rp20,000

9.2.3.3 EachCharge X amount for each OTC transaction above the threshold. Example

Charge Rp20,000 for each OTC transaction above 5 times during Volume Charge Cycle

Date Number of transactions Charge Amount1st to 20th August 2014 5 Nil21st August 2014 2 Rp40,00022nd August 2014 1 Rp20,000


of 150



of 150

9.3 Event-based ChargesThere are certain charges that are applicable when an event occurs, e.g. Dormancy, Statement-generation.

9.3.1 Dormant ChargeDormant Charge can be defined to be excluded for Affiliate Account. Dormant Charge can be defined to be charged on:

1. C – Cycle Code 2. D – Day turn Dormant3. M – Recurring at month-end4. A – Recurring at year-end

9.3.1.1 Cycle CodeA new field, Dormant Charge Day of Month, will be added in the Demand Deposit Product parameter to allow a user to define the day of month when Dormant Charge is to be charged.

Example

Dormant Charge Day of Month = 5th of the month

Date turned Dormant Dormant Charge31st December 2013 5th January 20144th January 2014 5th January 20145th January 2014 5th February 20146th January 2014 5th February 2014

9.3.1.2 Day turn DormantThe Dormant Charge will be charged on the day when the account becomes Dormant.


of 150

9.3.1.3 Recurring at month-endThe Dormant Charge will be charged at the end of every month so long as its Status remains Dormant.

9.3.1.4 Recurring at year-endThe Dormant Charge will be charged at the end of every year so long as its Status remains Dormant.

9.3.2 Subsequent Dormant ChargeSubsequent Dormant Charge can be defined to be charged on:

1. A – Anniversary2. M – Monthly3. E – Monthly Point to Point4. No Dormant Charge for Affiliate Account

9.3.2.1 AnniversarySubsequent Dormant Charge will be charged on the Anniversary Date of the Date turned Dormant, so long as its Status remains Dormant.

9.3.2.2 MonthlySubsequent Dormant Charge will be charged on a monthly basis so long its Status remains Dormant.

9.3.2.3 Monthly Point to PointSubsequent Dormant Charge will be charged on a monthly basis so long its Status remains Dormant. It will be charged on a monthly basis on the day of month when it turned Dormant.

9.3.3 Statement ChargeStatement Charge Code is defined in Demand Deposit Product parameter. System will debit the account when statement is generated. In case of multiple statements generated for one account, only one charge shall apply.


of 150

9.4 Transaction-based ChargesThere are certain charges that are charged during batch processing and are applicable when a transaction is performed, e.g. Cheque Book Request and Intraday.

Charge Code parameter will be enhanced to allow a user to define how a charge amount is to be split, for example, Charge Code Bilyet Giro can be defined with Printing Cost, Stamp Duty and Commission.

Cheque Book Processing Control parameter will be enhanced to allow a user to define the Charge Code that is applicable for Bilyet Giro / Cheque Book and Counter Cheque.

9.4.1 Cheque Book Request during Account OpeningSystem will debit the account during batch for Cheque Book requested during Account Opening.

9.4.2 Cheque Book Request using eTPSystem will debit the account immediately Cheque Book requested using eTP.

9.4.3 Cheque Book Request via ClicksSystem will verify that there is sufficient fund in the account when a cheque book is being requested via Clicks. The debiting will be done during batch.

The following is a list of requirements that are related to batch processing for Charges.


1PID_DP_01105 All charges and fees (bank income) must be posted to GL in IDR (local currency)

System will send the GL Event Code to GFMS in both foreign currency as well as IDR.


of 150


of 150

9.5 Tiering ChargeA customer who has opted for Tiering Charge is committed to maintaining a certain balance with the bank. System will charge the customer using the discounted charge for all eligible charge codes if the customer meets the criteria.

The following is a list of requirements that are related to batch processing for Tiering Charge.


1PID_DP_00349 System must support reversing tiered charging to normal charge for certain conditions not supported within xx days (days to be parameterized) based on options of (options to be parameterized):- committed balance (average or EOM balance)- # transaction by transaction type

The situation will not arise as the discounted charge is only given if the customer meets the criteria.


of 150

10. Owing

Charges that are allowed to go into Owing can be defined using the Charge Code parameter. Debit Interest is not allowed to go into Owing. Products that are allowed to go into Owing can be defined as ‘Y’ for the Owing field in the Demand Deposit Product parameter.

10.1 Creation of OwingWhen system attempts to debit an account for a Charge and there is insufficient fund for it, it will check:

1. Whether the Charge Code allows for Owing2. Whether the Product allows for Owing

If the answers are ‘Y’ for both, system will pass the amount into Owing together with a Date. GL Event Code will not be sent to GFMS.

10.2 Recouping of OwingSystem will debit the account for whatever available funds to recover the owed sum. The Owing Amount is to be recovered on a FIFO (First-In-First-Out) basis. Partial recovery is allowed. The recovered sum will be generated as a GL Event Code with its corresponding Charge Code.



of 150


of 150

The following is a list of requirements that are related to batch processing for Owing.


1PID_DP_00262 System must support creating Owing Maintenance with capability to:-- show total list of owing- total owing amount- waive owing either + one by one + total list in the owing list- ability to deduct owing amount when there is incoming fund into the owing account. Type of incoming fund allowed for owing deduction to be parameterized

This requirement has been deferred.

1PID_DP_00263 System must support option for calculation of Owing Amount either deduct Overdraft (OD) Facility or not

Charges, when computed, will be debited to the account based on the Available Balance. The amount goes into Owing if there is insufficient balance.



of 150

11. Cash Back

Cash-Back is an incentive that is credited to the account when certain criteria is met.

Example

Cash Back of Rp50,000 for every incremental increase of Rp1,000,000 in Average Balance.

Month Average Balance Cash Back1st 10,000,000 02nd 15,000,000 250,0003rd 14,000,000 0



of 150

The following is a list of requirements that are related to batch processing for Cash Back.


1PID_DP_00881 System must be able to support additional parameter setup DD Product for cash back of Air Asia Savers Product with details :1. additional monthly cash back (cash back amount as product currency setup)2. min avg balance (as product currency setup) 3. transaction remark (remarks of transaction that automatically shown in cust statement), 4. Sub Ledger number for cash back payment

The applicable GL Reference Number for Cash Back is to be defined in Charge Code parameter.The applicable Cash Back amount for every X incremental increase in Average Balance is to be defined in Demand Deposit Product parameter.A transaction code is to be allocated for Cash Back using Demand Deposit Host Transaction Code parameter. The description for this transaction code will appear in the customer’s statement.

System will be enhanced to store the monthly Average Balance of an account and compare the Average Balance of the current month with that of the previous month. If the incremental increase meets the criteria defined in the Demand Deposit Product parameter, the Cash Back will be computed.

1PID_DP_00883 System must be able to support Cash Back process of Air Asia Savers Product with details :1. cash back payment during EOM process as DD Product Parameter Setup, with journal : DR Sub Ledger as parameterized in DD Product set up CR Cust Account2. system will create remark on cash back payment transaction as parameterized in DD Product setup3. No withholding tax deducted for cash back trx

The applicable GL Reference Number for Cash Back is to be defined in Charge Code parameter.The applicable Cash Back amount for every X incremental increase in Average Balance is to be defined in Demand Deposit Product parameter.A transaction code is to be allocated for Cash Back using Demand Deposit Host Transaction Code parameter. The description for this transaction code will appear in the customer’s statement.

System will be enhanced to store the monthly Average Balance of an account and compare the Average Balance of the current month with that of the previous


of 150

month. If the incremental increase meets the criteria defined in the Demand Deposit Product parameter, the Cash Back will be computed. Withholding Tax will not be deducted from the Cash Back.



of 150

12. Amortization

When a benefit is given to a customer upfront, the cost of the benefit is to be amortized over the defined Amortized Term.

Gift Code parameter will be developed for a user to define the cost of gift as well as Amortized Term.



of 150

The following is a list of requirements that are related to batch processing for Amortization.


1PID_DP_00291 System must support automatic amortization in case of TD break or ISA break.

During break, all remaining unamortized amount of gift/ cash back will be journaled as bank expenses

At maturity, all remaining unamortized amount of gift/ cash back will be journaled as bank expenses

It has been confirmed subsequently that this would be handled by FRS.


of 150

1PID_DP_00848 For ISA and TD with gift, amortization of gift amount will only started after gift payment to the vendor has been done. So, system must have a mechanism to receive data upload regarding this payment.At account opening: no journaling need to be done regarding gift amountAt the 1st day (day of open) and the following day batch process:Dr: Branch's Cost of Fund (amt = X)Cr: Accrual GL account (amt = X)(amt X = daily accrual of gift amount as defined in gift parameter)When business team is about to pay the vendor (manually), team must upload the list of payment to SIBS. Data to be contained:- ISA/ TD Account - Real amount/ price of the gift (as to be paid to vendor)Based on this uploaded data, system will calculate and journal:Dr: Prepaid Expenses (amt = Z - X)Dr: Accrual GL account (amt = X)Cr: Pool account for vendor payment (amt = Z)(amt Z = real amount/price to be paid to vendor for each gift)After the process above has been done, at daily, system will do amortization as follows:Dr: Branch's Cost of Fund (amt = W)Cr: Prepaid Expenses (amt = W)(amt W = daily amortization of Prepaid Expenses (daily amort of amt Z - X)

The Cost of a Gift is defined in the Gift Code parameter. The defined Gift Code is then tagged to a Program Code. If a customer opts for a particular Program Code during Account Opening, system will amortize the cost of the gift over the defined Amortized Term.

ExampleCost of Gift = 7,500,000Amortized Term = 100 daysDaily Amortization = 7,500,000 ÷ 100 = 75,000

System will send the remaining unamortized amount to GFMS if an account that has opted for a particular Program Code closes prematurely.

ExampleCost of Gift = 7,500,000Amortized Term = 100 daysDaily Amortization = 7,500,000 ÷ 100 = 75,000Amortized amount after 60 days = 60 * 75,000 = 4,500,000Remaining unamortized amount = 7,500,000 – 4,500,000 = 3,000,000

1PID_DP_00916 For ISA and TD with gift, amortization of gift amount will only started after gift payment to the vendor has been done. So, system must have a mechanism to receive data upload regarding this payment.At account opening: no journaling need to be done regarding gift amountAt the 1st day (day of open) and the following day batch process:

This is a duplicate of Requirement ID 1PID_DP_00848.


of 150

Dr: Branch's Cost of Fund (amt = X)Cr: Accrual GL account (amt = X)(amt X = daily accrual of gift amount as defined in gift parameter)When business team is about to pay the vendor (manually), team must upload the list of payment to SIBS. Data to be contained:- ISA/ TD Account - Real amount/ price of the gift (as to be paid to vendor)Based on this uploaded data, system will calculate and journal:Dr: Prepaid Expenses (amt = Z - X)Dr: Accrual GL account (amt = X)Cr: Pool account for vendor payment (amt = Z)(amt Z = real amount/price to be paid to vendor for each gift)After the process above has been done, at daily, system will do amortization as follows:Dr: Branch's Cost of Fund (amt = W)Cr: Prepaid Expenses (amt = W)(amt W = daily amortization of Prepaid Expenses (daily amort of amt Z - X)NOTE: in the condition where program penalty is charged (delinquencies occurs), daily amortization keep running as it is.


13. Insurance

Insurance is a feature of a product. The Insurance Premium can be borne by either the bank or the customer. There is a Maximum Sum Assured per CIF. A customer may have a regular savings account like Junior Savings, an Installment


of 150

Savings Account as well as a Time Deposit product like Power Deposit, all of which offers insurance as a product feature. However, these products may be assigned with different Insurance Coverage Group Code.

This can be illustrated as follows:

Example

Max Insurance Coverage per CIF defined in Insurance Premium Computation Method parameter

Insurance Code Max Insurance Coverage per CIFAIA 100,000,000Allianz 150,000,000

The pro-rated insurance coverage for a CIF that has three accounts in two branches as per table below.

Account Branch Group Code Ledger Balance Pro-rated Coverage1 A AIA 75,000,000 (75,000,000 ÷ 160,000,000) * 100,000,000 =

46,875,0002 B AIA 85,000,000 (85,000,000 ÷ 160,000,000) * 100,000,000 =

53,125,0003 A Allianz 200,000,000 150,000,000


of 150

13.1 Insurance Premium borne by bankThe Insurance Premium is to be borne by the Account Owning branch. A total amount is to be computed per Insurance Code and credited to the Insurance Company’s account at the end of the month. The Insurance Company’s account number is defined in CMS Application under a Contract Number. This Contract Number will then be defined in Insurance Premium Computation Method parameter. There are five methods of insurance premium computation if it is borne by the bank.

13.1.1 Percentage of Regular InstallmentThis is applicable for ISA will be computed as follows:

Percentage: x%

Installment Amount: y

Insurance Premium = x% * y

In case of Max Insurance Coverage being defined in Insurance Premium Computation Method parameter, this will be computed as follows:

Max Insurance Coverage per CIF 50,000,000

Insurance Premium percentage 0.0087%

CIF A Installment Amount Insurance PremiumAccount A1 10,000,000 10,000,000 * 0.0087% = 870Account A2 20,000,000 20,000,000 * 0.0087% = 1,740

CIF B Installment Amount Insurance PremiumAccount B1 30,000,000 (30,000,000 ÷ 70,000,000) *

50,000,000 * 0.0087% = 1,864.29Account B2 40,000,000 (40,000,000 ÷ 70,000,000) *


of 150

50,000,000 * 0.0087% = 2,485.71

13.1.2 Percentage of Target BalanceThis is applicable for ISA and will be computed as follows:

Percentage: x%

Target Balance: y





CIF A Target Balance Insurance PremiumAccount A1 100,000,000 100,000,000 * 0.0087% = 8,700Account A2 200,000,000 200,000,000 * 0.0087% = 17,400

CIF B Target Balance Insurance PremiumAccount B1 300,000,000 (300,000,000 ÷ 700,000,000) *

500,000,000 * 0.0087% = 18,642.86Account B2 400,000,000 (400,000,000 ÷ 700,000,000) *

500,000,000 * 0.0087% = 24,857.14



of 150


of 150

13.1.3 Percentage of Average Balance or Ledger Balance (other than ISA)This is applicable for accounts other than ISA and will be computed as follows:

Percentage: x%

Average Balance or Ledger Balance: y


Note:

Average Balance = Month-To-Date Average




CIF A Average Balance / Ledger Balance

Insurance Premium

Account A1 100,000,000 100,000,000 * 0.0087% = 8,700Account A2 200,000,000 200,000,000 * 0.0087% = 17,400

CIF B Average Balance / Ledger Balance

Insurance Premium

Account B1 300,000,000 (300,000,000 ÷ 700,000,000) * 500,000,000 * 0.0087% = 18,642.86

Account B2 400,000,000 (400,000,000 ÷ 700,000,000) * 500,000,000 * 0.0087% = 24,857.14


of 150


13.1.4 Percentage of Accumulated Regular InstallmentsThis will be computed as follows:

Percentage: x%

Accumulated Regular Installment: y

Ledger Balance: z


Note:

Accumulated Regular Installment excludes Initial Deposit and Top-Ups.


Max Insurance Coverage per CIF (per month) 5,000,000


Account A: Monthly Installment = 4,000,000

Month Accumulated Regular Installment

Premium

1 4,000,000 4,000,000 * 0.0087% = 3482 8,000,000 8,000,000 * 0.0087% = 6963 12,000,000 12,000,000 * 0.0087% = 1,044

Account B: Monthly Installment = 6,000,000

Month Accumulated Regular Installment

Premium


of 150

1 6,000,000 5,000,000 * 0.0087% = 4352 12,000,000 10,000,000 * 0.0087% = 8703 18,000,000 15,000,000 * 0.0087% = 1,305

13.1.5 Percentage of Sum Assured (No Capping, per account)This method is not in use and will not be provided.

13.2 Insurance Premium borne by customerThe Insurance Premium is computed as a Percentage of Regular Installment and debited to the SOF account on the Installment Due Date, after the Installment has been debited successfully.

The amount is to appear as one single line in the customer’s statement.

13.2.1 Sufficient Fund for Installment Amount but Insufficient Fund for Insurance PremiumSystem will debit the SOF account for the Installment amount. The Insurance Premium will be sent to Owing, assuming Owing is defined for Insurance Premium.

13.2.2 Insufficient fund for Installment Amount but Sufficient Fund for Insurance PremiumBoth the Installment amount and the Insurance Premium will be sent to Owing, assuming both have been defined for Insurance Premium.

13.3 CommissionA Charge Code can be defined for Commission on Insurance Premium using Charge Code parameter. It can be defined in Percentage instead of absolute amount.

The Commission is to be computed as a Percentage of the Insurance Premium that has been debited from the customer’s account.

Example

Insurance Premium = 870

Commission = 20% = 174


of 150


13.4 TaxThe percentage of Tax can be defined as a Sub Charge Code for Commission on Insurance Premium using Charge Code parameter. It can be defined in Percentage instead of absolute amount.

The Commission is to be computed as a Percentage of the Commission.

Example

Insurance Premium = 870

If Commission and Tax are defined as 20% and 10% respectively

Commission = 870 * 20% = 174

Tax = 174 * 10% = 17.4

The following is a list of requirements that are related to batch processing for Insurance premium and commission.


1PID_DP_00611 System must able to process: Asplus Acc Collector

The Payee’s Profile is to be defined in CMS Application.

1PID_DP_00721 System must able to process: Niaga Dollar Premium(Insurance) Calculation - Detl

This requirement is to be dropped.

1PID_DP_00722 System must able to process: Niaga Dollar Premium(Insurance) Calculation - Summ


1PID_DP_00723 System must able to process: Otomation This requirement is to be dropped.


of 150

Process Insurance Plus Niaga IDR

1PID_DP_00724 System must able to process: Otomation Process Insurance Plus Niaga USD


1PID_DP_00888 System must be able to do insurance premium calculation for Junior Product in EOM with details:-1. Formula of premium calculation is (daily avg bal x premium rate set up in parameter) x 122. The calculation will be performed for the account with min daily avg bal as setup in parameter3. The system will create auto accounting entries: Db. 27807520 – Prepaid Interest – Direct gift of Junior Saving Cr. Insurance Provider Account ( insurance payment and insurance premium journal Db. 33408520 - Direct Promotion of Junior Saving Expenses (Interest Expense). Cr. 27807520 - Bunga dibayar dimuka – Hadiah Langsung Tabungan Junior (Insurance premium prepaid settlement journal)

As explained in Percentage of Average Balance or Ledger Balance (other than ISA) above.

Note:Item 3 will be duly removed.

1PID_DP_00890 System must be able to calculate premium amount proportionally in EOM, for example :

| A1 B=A1@Cab/A2 C D E=(BxCxD)/12 || Renkening | Total SRH | %Komposisi SRH | Premi (pa) | Cap SRH | Cost Premi || Di Cabang A | 50.000.000 | 33,33% | 0.07% pa | 100.000.000 | 1.944,44 || Di Cabang B | 75.000.000 | 50,00% | 0.07% pa | 100.000.000 | 2.916,67 || Di Cabang B | 25.000.000 | 16,67%

As explained in Percentage of Average Balance or Ledger Balance (other than ISA) above.


of 150

| 0.07% pa | 100.000.000 | 972,22 || A2 | 150.000.000 | 100,00% | | | 5.833,33 |

1PID_DP_00891 System must be able to perform automated premi payment to insurance company account monthly basis based on code "Group Product CA/SA for insurance covered"

As explained in Insurance Premium borne by bank above.

1PID_DP_00892 System must be able to perform insurance premi payment accounting entries as follows :Dr. Cerdik Promotion Charge (Tabungan Junior)Cr. Insurance Account(insurance premi paid every End of Month)

System will compute Insurance Premium at the end of month for all accounts that opt for Insurance Plus = N.

System will send the GL Event Code to GFMS which will pass the accounting entries accordingly.

1PID_DP_01008 Power Deposit will have insurance feature where the insurance premium will be paid by bank to insurance company monthly.There will be a limit to define maximum insurance coverage per-CIF as defined in parameter.In the case where a customer has multiple power deposit account with insurance feature, the total coverage must not exceed the limit. If exceeding, system must proportionate the insurance premium payment[Proportion = max coverage limit / total balance]. This validation must be done cross product types (include CA/SA/TD/ISA) where insurance benefit applied.Insurance premium calculation:[Insurance premium = Balance x insurance premium x proportion]




of 150


of 150

14. Penalty

Penalty is computed during batch processing. There are two types of Penalty:

1. Product Penalty2. Program Penalty

Product Penalty is applicable if an ISA is closed prematurely. Program Penalty is applicable if a customer has opted for a particular Program and the ISA becomes Delinquent or is closed prematurely, whichever is the earlier.

14.1 DefaultSystem will increase the Default Count if it is unable to debit the SOF Account after X number of retries. Number of Retries is defined in the Direct Debit parameter.

Example

Number of Retries: 3

Date Status Default25th August 2014 Fail No26th August 2014 Fail No27th August 2014 Fail Yes

14.2 DelinquencySystem will increase the Delinquency Count if there are X number of consecutive Defaults.

Date Default Delinquent25th August 2014 Yes No25th September 2014 Yes No25th October 2014 No No25th November 2014 Yes No25th December 2014 Yes No25th January 2014 Yes Yes


of 150

Note

System will debit the SOF account for all outstanding installment amount due. In this example above, the ISA has two outstanding installments before 25th October 2014. System will attempt to debit the SOF account for the total of the three installment amounts on 25th October 2014. However, if the SOF account only has sufficient balance for one or two full installment amounts, system will debit the SOF for these amounts. System will not debit the SOF in settlement of an installment amount partially.

14.3 Product PenaltyProduct Penalty is applicable if an ISA is closed prematurely. There are three methods for computing Product Penalty, as defined in the Product Penalty parameter:

1. Percentage of Balance by Elapsed Term, subject to a Minimum and Maximum Penalty Amount

2. Fixed Amount by Elapsed Term

Note:

The Penalty Percentage to be applied depends on whether the Interest Rate for ISA is fixed or not. Elapsed Term is defined as Today’s Date – First Installment Date.

Example 1

Product Penalty parameter by Percentage of Balance is defined as per table below

Elapsed Term(<=)

Penalty Percentage for Fixed Rate

Penalty Percentage for Floating Rate

Minimum Penalty

Maximum Penalty

12 3.75 3.00 50,000 200,00024 3.25 2.00 50,000 200,000


of 150

36 3.00 1.75 50,000 200,00048 2.50 1.25 50,000 200,00060 1.00 1.00 50,000 200,000

Account Elapsed Term

Fixed Rate? Ledger Balance Product Penalty

A 25 Y 1,000,000 1,000,000 * 3% = 30,000 but a minimum of 50,000 will be charged

B 26 Y 5,000,000 5,000,000 * 3% = 150,000C 27 Y 10,000,000 10,000,000 * 3% = 300,000 but a

maximum of 200,000 will be chargedD 28 N 1,000,000 1,000,000 * 1.75% = 17,500 but a

minimum of 50,000 will be chargedE 29 N 5,000,000 5,000,000 * 1.75% = 87,500F 30 N 20,000,000 20,000,000 * 1.75% = 350,000 but a

maximum of 200,000 will be charged

Example 2

Product Penalty parameter by Fixed Amount is defined as per table below

Elapsed Term(<=)

Fixed Amount

12 200,00024 150,00036 100,00048 50,00060 50,000

Account Elapsed Term

Penalty

A 12 200,000B 13 150,000C 25 150,000D 38 50,000


of 150

14.4 Program PenaltyProgram Penalty applies if a customer opts for a particular Program and the ISA:

1. Is closed prematurely2. Becomes Delinquent

Program Penalty is computed during batch and stored in a field. It will be sent to BDS for display if the ISA is to be closed prematurely. System will debit the ISA account for Program Penalty if the ISA becomes Delinquent. If there is insufficient fund in the SOF account, system will debit the ISA account.

Once an ISA becomes Delinquent, system will set the Penalty field of the account to ‘Y’. System will no longer compute Program Penalty once the Penalty field of the account is ‘Y’. System will resume the computation of Program Penalty when it is reset to ‘N’.

There are nine methods for computing Program Penalty, as defined in the Program Penalty parameter:

1. Fixed Amount by Elapsed Term2. Percentage of ISA Balance (either Average or Ledger Balance) by Elapsed Term3. Percentage of Remaining Total Installment by Elapsed Term4. Percentage of Remaining Target Balance by Elapsed Term5. Percentage of Sum Assured by Elapsed Term6. Gift Amount by Proportional Elapsed Factor7. ISA Balance by Proportional Elapsed Factor8. Percentage of ISA Balance (either Average or Ledger Balance) by Proportional

Elapsed Factor9. Percentage of Sum Assured by Proportional Elapsed Factor


of 150

Note:

Average Balance is the Average Balance of the previous month

If there is a Multiplier, the computed Penalty Amount will be multiplied with the Multiplier.

14.4.1 Elapsed TermElapsed Term is computed as follows:

Open date : 15th January 2014Tenure : 36 monthsFirst Monthly ISA Date : 20th January 2014Maturity date : 20th January 2017Initial Deposit : 10,000,000Monthly ISA : 1,000,000Gift Amount : 7,500,000Break date : 25th June 2016Elapsed Term in Days : Break Date – First Monthly ISA Date (25 June 2016 – 20 Jan 2014) = 887 days Elapsed Term in Months : 887/365*12 = 29.16 months

14.4.1.1 Fixed Amount by Elapsed TermA Fixed Amount will be charged to the account based on the elapsed number of months.

ExampleProgram Penalty parameter is defined as follows:

Elapsed Term(<=)

Fixed Amount

24 months 10,000,00025 – 48 7,500,000


of 150

months>48 months 5,000,000

Based on the example above, an account that is opened on 15th January 2014 and closed prematurely on 25th June 2016 has elapsed 887 days which is equivalent to 29.16 months. In this case, the Penalty Amount will be 7,500,000.

14.4.1.2 Percentage of Balance by Elapsed TermA Percentage of the ISA Balance will be charged to the account based on the elapsed number of months.


Elapsed Term(<=)

Penalty Percentage

24 months 6%25 – 48 months

4%

>48 months 2%

Based on the example above, an account that is opened on 15th January 2014 and closed prematurely on 25th June 2016 has elapsed 887 days which is equivalent to 29.16 months. In this case, the Penalty Percentage will be 4%.

Penalty Amount = 39,000,000 * 4% = 1,560,000

NoteLedger Balance of 39,000,000 is assumed by multiplying the monthly installments of 1,000,000 by 29 months and adding the Initial Deposit of 10,000,000. Top-ups and interests have been excluded for this example.


of 150


14.4.1.3 Percentage of Remaining Total Installment by Elapsed TermA Percentage of the Remaining Total installments will be charged to the account based on the elapsed number of months.


Elapsed Term(<=)

Penalty Percentage


4%

>48 months 2%


The account is supposed to have a total installment of 36,000,000 but by 25th June 2016, the expected installment should be 29,000,000. Defaulted installment(s) is to be included in the expected installment.

Penalty Amount = (36,000,000 – 29,000,000) * 4% = 280,000



of 150


of 150

14.4.1.4 Percentage of Remaining Target Balance by Elapsed TermA Percentage of the Remaining Target Balance will be charged to the account based on the elapsed number of months.


Elapsed Term(<=)

Penalty Percentage


4%

>48 months 2%


The account is supposed to have a Target Balance of 10,000,000 + (1,000,000 * 36) = 46,000,000 but the Ledger Balance is only 39,000,000 at the time of closing.

Penalty Amount = (46,000,000 – 39,000,000) * 4% = 280,000



of 150

14.4.1.5 Percentage of Sum Assured by Elapsed TermA Percentage of the Sum Assured will be charged to the account based on the elapsed number of months.

Sum Assured is computed as Installment Amount * Fixed Number * Tenure, where Fixed Number is defined in the ‘Multiplier’ field in Gift Code parameter.


Elapsed Term(<=)

Penalty Percentage


4%

>48 months 2%


Sum Assured = Installment Amount * Fixed Number * TenureSum Assured = 1,000,000 * 6 * 36, assuming the Fixed Number is 6Sum Assured = 216,000,000

Penalty Amount = 216,000,000 * 4% = 8,640,000



of 150


of 150

14.4.2 Proportional Elapsed FactorProportional Elapsed Factor is computed as follows:

Open date : 15th January 2014Tenure : 36 monthsFirst Monthly ISA Date : 20th January 2014Maturity date : 20th January 2017Initial Deposit : 10,000,000Monthly ISA : 1,000,000Gift Amount : 7,500,000Break date : 25th June 2016

Proportional Elapsed Factor : (Maturity Date – First Installment Date) – (Break Date – First Installment Date)

(Maturity Date – First Installment Date)

: (20 th January 2017 – 20 th January 2014) – (25 th June 2016 – 20 th January 2014) 20th January 2017 – 20th January 2014

: 1096 – 887 = 0.19 1096

14.4.2.1 Gift Amount by Proportional Elapsed FactorGift Amount is defined in Gift Code parameter.

Based on the example above, an account that is opened on 15th January 2014 and closed prematurely on 25th June 2016 has a Proportional Elapsed Factor of 0.19.

Penalty Amount = Gift Amount * Proportional Elapsed FactorPenalty Amount = 7,500,000 * 0.19 = 1,425,000


of 150

14.4.2.2 ISA Balance by Proportional Elapsed FactorBased on the example above, an account that is opened on 15th January 2014 and closed prematurely on 25th June 2016 has a Proportional Elapsed Factor of 0.19.

Penalty Amount = ISA Balance * Proportional Elapsed Factor

Penalty Amount = 39,000,000 * 0.19 = 7,410,000

14.4.2.3 Percentage of ISA Balance by Proportional Elapsed FactorThe Percentage and the ISA Balance (either Average or Ledger Balance) are defined in the Program Penalty parameter. Let’s assume the Penalty Percentage is 10% and Ledger Balance is defined.


Penalty Amount = ISA Balance * Penalty Percentage * Proportional Elapsed Factor

Penalty Amount = 39,000,000 * 10% * 0.19 = 741,000

NoteLedger Balance of 39,000,000 is assumed by multiplying the monthly installments of 1,000,000 by 29 months and adding the Initial Deposit of 10,000,000. Top-ups and interests have been excluded for this example.



of 150


of 150

14.4.2.4 Percentage of Sum Assured by Proportional Elapsed FactorA Percentage of the Sum Assured will be charged to the account based on the Proportional Elapsed Factor. Let’s assume the Penalty Percentage is 10%.

Sum Assured is computed as Installment Amount * Fixed Number * Tenure


Penalty Amount = Sum Assured * Penalty Percentage * Proportional Elapsed Factor

Penalty Amount = (1,000,000 * 6 * 36) * 10% * 0.19

Penalty Amount = 4,104,000



of 150

The following is a list of requirements that are related to batch processing for Program Penalty.


1PID_DP_00169 Program Penalty (Penalti Program) Charge Calculation method:-1. Non-proportional charge based on on-going term (defined in nominal amount)2. Non-proportional charge based on on-going term (defined in percentage of ISA balance). Type of balance that can be chosen: ledger balance, available balance, average balance3. Non-proportional charge based on on-going term (defined in percentage of remaining amount of targeted fund/Target Dana). Where remaining amount = targeted fund - current ISA ledger balance4. Non-proportional charge based on on-going term (defined in percentage of amount of remaining accumulated monthly installments)5. Proportional based on gift amount6. Proportional based on ISA balance. Type of balance that can be chosen: ledger balance, available balance, average balance7. Proportional based on percentage of ISA balance. Type of balance that can be chosen: ledger balance, available balance, average balance8. Non-proportional based on on-going term (account age) on sum assured o Defined in percentage for each range of account age o E.g. 1 to 6 months, charge 1% of sum assured; 6 to 12 months, charge 1.5% of sum assured o Parameterized, to be inputted at program code level9. Proportional charge based on on-going term on sum assured: * (remaining term ÷ ISA term) × y%×regular installment amount × ISA term× [fixed number]

As explained in Program Penalty above.

Note:

Fixed Number is defined in the ‘Multiplier’ field in Gift Code parameter.


of 150

* ‘y’ is parameterized, also to be inputted at program code level10. Non-proportional fixed percentage on sum assured z%×regular installment amount × ISA term×[fixed number] ‘z’ is parameterized at program code levelNOTE:* all these setting is defined in Program Code level* Proportional formula is: (tenure - on-going term) / tenure* there must be a parameter to define how many delinquency to apply program charge

1PID_DP_00269 System must be able to automatically charge delinquency penalty once the delinquency pass grace period

Program Penalty is defined in Program Penalty parameter and tagged to Program Code parameter. Number of Defaults to consider Delinquent is defined in Program Code parameter.

System will compute Program Penalty during Batch Processing and store the computed amount in a file.

If a customer opts for a particular Program and the account becomes Delinquent subsequently, system will charge the account for Program Penalty.

1PID_DP_00286 Program Penalty (Penalti Program) Charge Calculation method:-1. Non-proportional charge based on on-going term (defined in nominal amount)2. Non-proportional charge based on on-going term (defined in percentage of ISA balance). Type of balance that can be chosen: ledger balance, available balance, average balance3. Non-proportional charge based on on-going term (defined in percentage of

This requirement has been superseded by Requirement ID 1PID_DP_00169.


of 150

remaining amount of targeted fund/Target Dana). Where remaining amount = targeted fund - current ISA ledger balance4. Non-proportional charge based on on-going term (defined in percentage of amount of remaining accumulated monthly installments)5. Proportional based on gift amount6. Proportional based on ISA balance. Type of balance that can be chosen: ledger balance, available balance, average balance7. Proportional based on percentage of ISA balance. Type of balance that can be chosen: ledger balance, available balance, average balance 8. ...% x (monthly ISA x tenor x ... Parameterize)9. ...% x ... % x (monthly ISA x tenor x ... Parameterize)NOTE: * all these setting is defined in Program Code level* Proportional formula is: (tenure - on-going term) / tenure



of 150

15. Dormancy

A Product can be defined to turn an account into Dormant if there is no activity that updates either the Date of Last Activity or Date of Last Contact of the account after X days.

Transactions that update Date of Last Activity are defined in the Demand Deposit Host Transaction Code parameter.

An Inquiry that is initiated by a customer via other channels constitutes a valid identification of the customer and it will update the Date of Last Contact of the account.

System will change the Status of the account from ‘1 – Active’ to ‘9 – Dormant’ after X days from the Date of Last Activity or Date of Last Contact, whichever is the later, subject to the following:

1. Exclude OD2. Exclude Non-Individuals

If a Dormant Account is Re-activated to allow for certain BDS transactions to be processed during the day, the Status of the account will be reverted to Dormant during batch processing if the transaction is not one that had been defined to update Date of Last Activity.



of 150

The following is a list of requirements that are related to batch processing for Dormancy.


1PID_DP_00600 System must able to process: Extract Text File of Dormant Account by Call Center

CASA Reactivation Maintenance is to be enhanced with a new field, Date Last Contact that is defaulted to system date.

Call Center is to perform CASA Reactivation Maintenance when a customer calls up to the Call Centre to activate his account. System is to change the account status from ‘9’ to ‘1’ and update the Date of Last Contact with the system date.

The extraction of file that contains Reactivated Accounts will be handled by Interface.

1PID_DP_01114 System must provide process to automatically close dormant account which are:• Not registered as source account/ credit account on any facility• Account balance is below the specified balance limit (as defined in product code parameter)NOTE: Applicable for CA/SA

Demand Deposit Product parameter can be defined to close a Dormant Account with less than X balance.



of 150

16. Auto Closure

A Product can be defined to be auto-closed based on the following conditions:

1. Zero Balance account after X days2. New account with Zero Balance after X days3. Dormant Account below X balance

The above conditions do not apply to Affiliate Account.

The following is a list of requirements that are related to batch processing for Auto Closure of Account.


1PID_DP_00215 System must support closing account for "Rekening Penampung" with parameterized conditionsNoteCurrent condition:- Balance = 0- Product Reference = "9X"

Demand Deposit Product parameter can be defined to close Zero Balance account after X days.

1PID_DP_00404 System must close account automatically if there is no first placement after 7 days from opening account in bulk account opening

Deferred but use 1P feature with no difference in treatment for bulk account opening



of 150

17. Disposition

The proceeds of an ISA will be disposed to its SOF account on its Maturity Date. If the ISA is denominated in IDR but the SOF account is denominated in non-IDR, the proceeds will be converted using TT Sell Rate. If the ISA is denominated in non-IDR but the SOF account is denominated in IDR, the proceeds will be converted using TT Buy Rate.

The following is a list of requirements that are related to batch processing for Disposition.


1PID_DP_00198 System must support setting Installment Savings Disposition / Account - Account to Account Relationship (ATAR) Maintenance. NoteCurrent ISA ATAR fields are as follows:- Relationship code- Priority seq No- Transfer percentage must be full transfer- Set Account Type- Set Account Number

It has been decided that the proceeds of the ISA will be transferred to the SOF account on maturity.

1PID_DP_00206 System must support ZBT to accounts with different currency (dual currency)-ZBT from USD to IDR , use TT Buy Rate-ZBT from IDR to USD , use TT Sell Rate-Like/Same Currency - use Book RateNotes: Only for Insurance plus

As explained in Disposition above.



of 150

18. External Account

An account will be automatically tagged with an ‘External Account’ Condition Code during account opening if the Nationality of the primary account holder is not Indonesia.

There will be a parameter to define the threshold limit (currently IDR 500 million) that can be credited into an IDR-denominated External Account per CIF bank-wide. System will accumulate the amount that is credited into all IDR-denominated External Account, including Time Deposit accounts of a CIF but excluding transfers within the same CIF. The transaction amount will be earmarked automatically should it breaches the threshold limit. This transaction is known as Suspicious Transaction.

There will be a Maintenance screen to maintain the Underlying WNA Document for Suspicious Transaction. There will also be a parameter to define the Grace Period for the maintenance of this document. System will release the earmarked amount when an Underlying WNA Document is provided for the Suspicious Transaction. If the Underlying WNA Document is not provided at the end of the Grace Period, the earmarked amount will be released but the amount will be debited to the account and refunded to the depositor / remitter. In case where the depositor/remitter is unknown, the amount will be credited into the Escrow Account defined in Central Bank parameter.



of 150

The following is a list of requirements that are related to batch processing for External Account.


1PID_DP_00046 System must support Underlying WNA requirement(awaits for documents from business/IT)1. To provide a parameter to define the Transaction Limit for External Account and defined the grace period when the Underlying Document is to be provided. 2. System to tag a Condition Code ‘External Account’ to the account based on one of the following conditions:a. Foreigner: Issuance country - INA, ID Type - KITAS, Residence - Y, Nationality - Not INA = WNA (Warga Negara Asing)b. Foreigner: Issuance country - Not INA, ID Type - Passport, Residence - N, Nationality - Not INA = WNAc. Foreign legal entities or other foreign institutions: Classified via manual tagging from CIFd. Indonesian citizen who have permanent residence status in another country and not domiciled in Indonesia (local not residence): Issuance country - INA, ID type - KTP, Residence - N, Nationality - INA = WNI (Warga Negara Indonesia)d. Bank branch in oversea and headquarter of the bank is in Indonesia: Classified via manual tagging from CIFe. Company office in oversea (foreign company) and legal status company is in Indonesia: Classified via manual tagging from CIF.

* For rules number a, b, and d will be auto flagging for underlying when create new CIF* For rules number 3,5, and 6 will be manually flagging for underlying when create & maintenance new CIF3. To accumulate IDR credits into External

As explained in External Account above.


of 150

Account per CIF per day. System to prompt a message to inform that the External Account Transaction Limit has been breached but the transaction will be allowed to go through and duly validated with the customer’s account number.4. To provide Suspicious Transaction Maintenance/inquiry/dual control approval. 5. All Suspicious transactions that are transferred to a GL will be pending input of Underlying Document Number in the External Account Document Maintenance screen.

1PID_DP_01047 System must apply external account validation and suspect transaction maintenance on transactions triggered by LMS module (for batch fund sweep/ ZBT, AFT, sweep back)

As LMS can be catered for sweeps within different CIFs, the amount that breaches the threshold limit when it is swept up to an IDR External will be earmarked automatically and will not be swept back to the secondary account.



of 150

19. Forex Transaction Monitoring

Any IDR that is used for credit into an account denominated in Foreign Currency is to be converted to USD equivalent on a per transaction basis and accumulated for a month (parameterized). These transactions are stored in a file and the transaction that breaches the Threshold Limit (parameterized at USD 100,000 per CIF per month) must be provided with a Document Number.

19.1 Initialization of accumulated USD equivalentThe accumulated USD equivalent is to be initialized at the beginning of each Calendar month.

19.2 Initialization of Forex Transaction Monitoring HistoryTransactions that breach the Threshold Limit must be provided with a Document Number by performing Forex Transaction Monitoring Document Maintenance. Transactions from the 1st to the 25th of the month will be backed-up and initialized at the beginning of next Calendar month.

Example

1st January 2014 – Initialize transactions from 26th November to 25th of December 2013

1st February 2014 – initialize transactions from 26th December 2013 to 25th January 2014

The following is a list of requirements that are related to batch processing for Forex Transaction Monitoring (locally known as Underlying VALAS).


1PID_DP_01119 System must be able to display underlying transaction from date X in the previous months.

As explained in Initialization of Forex Transaction Monitoring History above.


of 150

20. Intraday Limit

Intraday Limit is a functionality that is given to certain customers of the bank. Commission instead of interest is chargeable. The Commission is to be computed based on:

1. Highest Negative Balance2. Total Negative Balance

These figures will be provided by Deposit Application to the Loans Application which will then compute the Commission. The Commission amount will then be passed to Deposit Application for debiting to the account.

20.1 Highest Negative BalanceThis will be the retrieved from the Highest Negative Available Balance for the day. Negative Balance from the previous day is to be excluded, except when there is a credit transaction that settles the previous day’s Negative Balance.

20.2 Total Negative BalanceThis will be the total transaction amount for the day that causes the balance to become Negative.



of 150

Example

Scenario 1 – Beginning Credit Balance

Ledger Balance 50,000,000.00 Hold Amount - Float - OD Limit -

Trxn Transaction Amount Ledger Balance Available Balance1 (60,000,000.00) (10,000,000.00) (10,000,000.00)2 (130,000,000.00) (140,000,000.00) (140,000,000.00)

Table 9Intraday (Beginning Credit Balance)

Highest Negative Balance = 140,000,000 (row 2 in Available Balance)

Total Negative Balance = 140,000,000 (60,000,000 + 130,000,000 – 50,000,000)



of 150

Scenario 2 – Beginning Zero Balance

Ledger Balance - Hold Amount - Float - OD Limit -


Table 10Intraday (Beginning Zero Balance)


Total Negative Balance = 140,000,000 (10,000,000 + 130,000,000)



of 150

Scenario 3 – Beginning Negative Balance without OD Facility and without Deposit

Ledger Balance (10,000,000.00)Hold Amount - Float - OD Limit -


Table 11Intraday (Beginning with Negative Balance without Deposit)

Highest Negative Balance = 140,000,000 (row 2 in Available Balance minus – 10,000,000)

Total Negative Balance = 140,000,000 (10,000,000 + 130,000,000)



of 150

Scenario 4 – Beginning Negative Balance without OD Facility but with Deposit that pays off the previous day’s outstanding balance

Ledger Balance (10,000,000.00)Hold Amount - Float - OD Limit -

Trxn Transaction Amount Ledger Balance Available Balance1 (10,000,000.00) (20,000,000.00) (20,000,000.00)2 30,000,000.00 10,000,000.00 10,000,000.00 3 (130,000,000.00) (120,000,000.00) (120,000,000.00)4 20,000,000.00 30,000,000.00 30,000,000.00 5 120,000,000.00 130,000,000.00 130,000,000.00

Table 12Intraday (Beginning with Negative Balance with Deposit)


Total Negative Balance = 130,000,000 (row 3 in Transaction Amount)



of 150

Scenario 5 – Beginning with Credit Balance and OD Limit

Ledger Balance 50,000,000.00 Hold Amount 10,000,000.00 Float 5,000,000.00 OD Limit 100,000,000.00

Trxn Transaction Amount Ledger Balance Available Balance1 (10,000,000.00) 40,000,000.00 125,000,000.00 2 (130,000,000.00) (90,000,000.00) (5,000,000.00)

Table 13Intraday (Beginning with Credit Balance and OD Limit)


Total Negative Balance = 5,000,000 (125,000,000 – 130,000,000)

The following is a list of requirements that are related to batch processing for Intraday for Deposit application.


1PID_DP_00277 System must support calculation of charges based on two methods:-1. Daily utilized amount (Total Negative Balance)2. Highest amount for the day (Highest Negative BalanceCommission/ Charge to be calculated as owing in case of designated account balance has no sufficient fund for intraday account charge.In current system, sometimes highest negative balance calculation is incorrect

As explained in Forex Transaction Monitoring above.


of 150

21. Message

A Junior Account may have been opened when the customer was eligible for it. System will write information into the account when the customer passes the eligibility age. This will appear as a message in BDS after a transaction has been performed. In eTP, it will appear in red at the Alert Bar.

The following is a list of requirements that are related to batch processing for Messages.


1PID_DP_00282 System must provide flag of Junior Account (Junior Account Flag will be automatically flagged when the customer has surpassed eligibility age). When customer doing transaction at branch or inquiry or maintenance of account, BDS (or eTP) will prompt message that customer has surpassed and need to change the product code of account to general SA.

As explained in Message above.

1PID_DP_00844 If customer has submitted SKB (Surat Keterangan Bebas Pajak) or COD (Certificate of Domicile) and those letter has expired, system will prompt message mentioning that customer's tax document has expired and must be resubmitted immediately.The message to be prompted during customer transaction, account inquiry, partial withdrawal/ break, and account maintenance.Those document will be expired if the year of today is greater than the year of the document inputting process

Host Teller will be enhanced to prompt a message in BDS after a transaction has been performed.


of 150

22. Passbook Compression

Transactions that have not been updated to the passbook can be defined to be compressed into a single line each for debits and credits. System will compress the transactions on the scheduled days if there are X number of transactions that have not been updated into the passbook.

The following is a list of requirements that are related to batch processing for Passbook Compression.


1PID_DP_01107 System must support another mechanism of merging unprinted transaction. Transactions will be merged based on how long (parameterized) customer hasn't print the passbook. Example:-# of day before merging defined as 30 days in parameter.Thus, merging process will be done every 30 calendar days since the last passbook printing date.If customer don't print passbook for 30 days or more, system will merge/ summarize all unprinted transactionsTransaction summary to be separated between credit and debit summary.Scenario:• Customer printed at 1 May 2012. Then customer do the next printing at 5 June 2012, so printed items are:-ü for period 1 May to 30 May: transaction summary ü for periode 31 May – 5 June: transaction

Adopt 1P to define up to four times per month for x number of records


of 150

detailIf at 1 May all transactions has been printed, then merge period will be from 2 May to 31 May 2012Detailed transactions will be printed for the period of 1 – 5 June 2012.• Customer printed at 1 May 2012. Then customer do the next printing at 10 July 2012, so printed items are:ü for period 1 May (unprinted transactions) - 29 June 2012: transaction summaryü for period 30 June - 10 July: Transaction detailIf at 1 May all transactions has been printed, then merge period will be from 2 May to 30 June 2012Detailed transactions will be printed for the period of 1 to 10 July 2012NOTE: currently this merging method is used solely for accounts using passbook detail



of 150

23. Statement

System shall generate statement if Print Statement is ‘Y’ in the Demand Deposit Product parameter. There shall be two different Statement Cycles, one each for Individual and Non-Individual. Statement can be defined to be generated on another date if the number of transactions is fewer than X. The statement will be generated as a data file and sent to the vendor who will do the formatting.

Notwithstanding the above, an account may request for additional statement via Statement Frequency Maintenance. Statement shall be generated on the specified frequency, in additional to the monthly statement. The additional statement shall be chargeable as per Statement Frequency Processing Control parameter.

Mailing Codes can be defined in a CIF parameter and the following codes have been agreed:

1. B – Collect at Branch – system shall provide an indicator to the vendor to enable the statement to be generated and delivered to the branch for customer’s collection.

2. E – Electronic – system shall provide an indicator to the vendor to enable the statement to be generated and delivered to the customer’s email address. If the Delivery Mode is E-mail, system will provide the Date of Birth of the Primary Holder in the data file.

3. N – Normal Mail – system shall provide an indicator to the vendor to enable the statement to be generated and delivered to the account address.

4. S – Suppress – system shall provide an indicator to the vendor.5. Y – Hold – system shall provide an indicator to the vendor to enable the

statement to be generated and delivered to the branch.If the Mailing Code in the Statement Frequency Maintenance is different from that of the Account Static Information Maintenance, the former shall be used for the mailing of statement whereas the latter shall be used for all other correspondences.


of 150

23.1 Combined StatementCombined Statement can be defined at either CIF or Account level. However, if it is defined in both CIF and Account, Combined Statement will be generated for all accounts under the CIF on the CIF Combined Statement Cycle Date.

Combined Statement will be generated for both Conventional and Islamic accounts. There is no need to provide an indicator to distinguish between the two. It will include CASA, Time Deposit and Overdraft. Time Deposit includes Market-Linked Deposit. Combined Statement for Loans will be generated by Loans application.

There are two types of Combined Statement:

1. Consolidated Combined Statement2. PPWM Combined Statement

Both statements will consist of a Summary page and a Details page. The Summary page will include Checksums. All accounts of the CIF will be summarized in the Combined Statement, regardless whether one or more of the accounts have opted for Combined Statement. If a CIF has opted for Combined Statement, the statements of all the accounts under this CIF will be mailed together with the Combined Statement.

CIF A Account Combined Statement

Mailed with Combined Statement

A1 Y YA2 N NA3 Y Y

CIF B Account Combined Statement

Mailed with Combined Statement

B1 Y Y


of 150

B2 Y YB3 Y Y

23.1.1 Consolidated Combined StatementConsolidated Combined Statement is meant for regular customers who opt for Combined Statement. This indicator will be provided to the vendor.

23.1.2 PPWM Statement PPWM is meant for preferred customer. The data file that is generated to the vendor shall include an indicator that it is PPWM. Data from Loans will also be included.

23.1.3 Mailing AddressThe name and address of the statement shall consist of:

Name Line 1 Name 1 (40A)

Name Line 2 Name 2 (40A)

Name Line 3 Name 3

Name Line 4 Name 4

Address Lines 1 to 7

QQ Name is not required to be printed.

In case of Joint Account, the Address will be that of the pre-determined address of one of the CIFs if only one CIF has opted to receive statement. If one or more joint holders have opted to receive the statement, the Addresses will be those of the defined addresses of the individual holders as maintained in CASA Relationship Maintenance.

23.1.4 ChecksumA checksum will be provided for number of transactions and total ledger balance by:

1. Current Account and Savings Account


of 150

2. Overdraft 3. Installment Savings Account

23.1.5 Exchange Rate informationSystem will also provide Exchange Rate information of each currency in the data file. The Exchange Rate will be the Closing Rate at the time of statement generation.

23.1.6 Statement informationThe transactions that will be included in the statement will be those from the Last Statement Date up to and including statement generation date.



of 150

The following is a list of requirements that are related to batch processing for Statement and Advice.


1PID_DP_00028 Statement of joint account must be able to be delivered to all owner of the joint account

As explained in Mailing Address above.

1PID_DP_00562 System must able to process: Print and update Advice Statement

Bank-initiated transaction Advice – BDSNameAddressDateTransactionRemarksGL Reference Number

EOD – DEVCC print report (TMTRAN)Report DDI482C is not in RRDBank to confirm whether still needed.On-Demand

1PID_DP_00563 System must able to process: Format customer name & address


1PID_DP_00876 System must be able to provide currency conversion rate information (JHFXRT), sent to combine statement, This combine statement will be created by report engine Integration Type : SIBS to Engine StatementInterface Description : SIBS to send JHFXRT to Engine statementInterface Type : batchIntegration Frequency (for batch) : N/A

As explained in Exchange Rate information above.

1PID_DP_00977 System must be able to generate and send data of email addresses (multiple) and date of birth for customer who chooses to have consolidated statement.Email addresses that will be sent are addresses that have been defined as e-

As explained in Statement above.


of 150

statement address.This data is to be sent to Statement EngineThis data will be needed for PPWM Combined Statement that are sent via email.There must be a user interface to trigger the processIntegration Type: SIBS and Engine StatementInterface Description: SIBS to send list of email addresses and DOB to Engine Statement for PPWM Combined e-Statement generationInterface type: BatchIntegration Frequency (for Batch): User triggered

1PID_DP_01095 Account statement processing is executed in non-critical batch process, and must be finished in not very long time. Current v2 process may take until next batch run to finish.

The situation will not arise as DD4600 is running N-Way during non-critical batch processing.



of 150

24. AFT

AFT is an instruction to transfer a fixed amount from a Transferor account to a Transferee account within the bank on a fixed frequency basis.

AFT Control parameter allows a user to define the following:

1. Number of Retries2. Number of Consecutive NSF3. Transfer to Third Party Charge Code4. Failed AFT Charge Code5. Allow Partial Transfer

24.1 Number of RetriesSystem shall attempt to debit the Transferor account on the next day should the first attempt fail due to NSF (Non-Sufficient Fund). The number of retries shall be determined by the AFT Control parameter. There shall be no retry for failure due to non-NSF reasons.

24.2 Termination of AFTSystem shall terminate the AFT Instruction should it fail to execute the AFT on X number of consecutive times, as defined in the AFT Control parameter.

24.3 Transfer to Third Party Charge CodeSystem shall debit the Transferor account for the amount defined in Third Party Charge Code if the Transferee is not the same CIF.

24.4 Failed AFTSystem shall debit the Transferor account for the amount defined in Failed AFT Charge Code should there be insufficient fund for installment amount after X retries.


of 150

24.5 Allow Partial TransferSystem shall debit the Transferor account for the amount available in the account even if it is less than the AFT amount.

24.6 PriorityThe sequence of AFT execution for AFTs that fall on the same day shall be dependent on the Priority Sequence Number. System shall execute the AFT in order of Priority Sequence Number after the night’s batch has been completed. The Next Transfer Date shall be bumped if the AFT is successful. A failure in an antecedent priority shall not prevent the system from executing subsequent priorities.

24.7 Effective DateThe AFT will be executed on the morning of the Effective Date.

24.8 Next Transfer DateSystem will update the Next Transfer Date once an AFT is executed successfully.

24.9 Expiry DateSystem will no longer execute the AFT when it has reached its Expiry Date.

The following is a list of requirements that are related to batch processing for AFT.


1PID_DP_00068 System must shows Purpose field to be printed in passbook / statement NoteThis requirement to show customer the details of their AFT

‘Payment to’, ‘Credit of’ and ‘Policy No.’ can be specified during AFT Instruction creation. This information will be made available in the passbook or statement if the account is under Detail Passbook or Detail Statement.

1PID_DP_00197 System must be able to automatically stop AFT in condition that # successful AFT = # Payment Term and produce report to head office (CLS group)

As explained in Termination of AFT above.


of 150

NoteThis requirement is to automate releasing AFT after installment savings account are fully installed

25. Sweep

Sweep is function which enables the funds from a defined account to be transferred to another account in case of shortfall in a specific transaction. The eligible transaction must be defined accordingly.

Fund Sweep Control parameter allows a user to define:

1. Contract Setup Fee2. Daily Sweep Charge Code 3. Minimum and Maximum Charge Code per Cycle4. Charge Code for each Sweep

25.1 Contract Setup FeeThis one-time fee, if defined, will be debited to the Recipient Account when a Sweep Contract is setup for the first time.

25.2 Daily Sweep Charge The amount defined for this Charge Code will be debited to the Recipient Account when there is one or more Sweep transaction for the day.

25.3 Minimum and Maximum Charge per CycleThe amount defined for the Minimum Charge Code will be debited to the Recipient Account when there is fewer than or equal to X number of Sweeps to the account during the Cycle.


of 150

The amount defined for the Maximum Charge Code will be debited to the Recipient Account when there is more than X number of Sweeps to the account during the Cycle.

25.4 Sweep Charge The amount defined for the Charge Code will be debited to the Provider Account for each Sweep made.

25.5 PriorityIt is possible to specify more than one Provider Account for Sweeping to one Recipient Account. In this case, the sequence of sweeping shall be dependent on the Priority Sequence Number. There are two types of Priority Sequence Number:

1. Sequential2. Highest Balance first

25.5.1 SequentialThis type of priority is defined as ‘10’, ‘20’, ‘30’ etc. at the Sweep instruction level. System will debit the available balance from the Provider Account by Priority Sequence Number. If the amount is still insufficient fund to cover for the shortfall, system will debit the remainder from the next Provider Account.

25.5.2 Highest Balance This type of priority is defined as ‘999’ at the Sweep instruction level. System will go through all the Provider Accounts and debit from the account that has sufficient balance to cover for the shortfall. If there is no Provider Account that has sufficient balance to do so, it will debit the available balance from the Provider Account with the highest balance and proceed to the next account with the next highest balance until the entire shortfall is covered.


of 150



of 150

Example

Recipient Account balance = 1,000,000

Specific transaction amount = 5,000,000

Provider Account Priority Sequence Available Balance Sweep Amount1 10 1,000,000 1,000,0002 20 2,000,000 2,000,0003 30 3,000,000 1,000,000

Provider Account Priority Sequence Available Balance Sweep Amount1 999 1,000,000 02 999 2,000,000 1,000,0003 999 3,000,000 3,000,000



of 150

The following is a list of requirements that are related to batch processing for Sweep.


1PID_DP_00061 System must support service charge for sweeping facility (to be parameterized). Parameters including options of:- charge apply when sweeping is executed, either successful or not- charge applied on monthly basisNoteCurrent sweeping charge is charged when transaction is successfully executed

As explained in Contract Setup Fee, Daily Sweep Charge, Minimum and Maximum Charge per Cycle, Sweep Charge above.

System will not charge for unsuccessful Sweep.

1PID_DP_00364 System must support creating Auto Sweeping from Savings Account (SA)/Current Account (CA) to Time Deposit (TD) product with parameters as follows:- CASA Balance indicator (balance to be used as sweep trigger, can select available balance, ledger balance, collected balance, or minimum balance).- Minimum TD placement amount- TD Tenor (overnight, 1-w, 2-2, 1-m etc.)- TD cycle- TD disposition (if TD disposition is not defined, Principal + interest will remain in its account)- Automatic Rollover (Y/N)TD will be automatically created if:- SA/CA amount surpass the "Max CA/SA Balance"

- The excess CA/SA amount shall be more than "Min TD placement amount"- The TD created will follow tenor, cycle and disposition set up-front.Amount to be swept/create new TD placement is based on incremental parameter. The amount should be multiplies of incremental parameter value.


1PID_DP_00638 Add CASA Cover From TD (Auto TD)System must support creating Auto Sweeping



of 150

from Time Deposit Account to Current Account (CA) / Saving Account (SA) product (online) with parameters as follows :- Primary account is CASA- Secondary account is TD (can be more than 1 account)- Transaction trigger : debit transaction in CASA Account that impact Non Sufficient Fund (NSF)- Type of transaction that can trigger sweep. (Can certain transaction or all transaction)- CASA Balance indicator (balance to be used as sweep trigger, can select available balance, ledger balance, collected balance, or minimum balance).- System will automate debit TD account and credit CASA Account- System able to recalculate the interest rate calculation for TD account due to the movement of fund- System provide parameter for TD interest rate (can be fixed or tiering)- Effective and Expire date.- Incremental Parameter.- Ceil and Floor parameters- Sweep Charges (can be selected to charge monthly, or each time perform sweep).Notes: incremental parameter is used to determine how many amount to be swept. The amounts of fund to be swept should be the multiples of the incremental parameter value.

1PID_DP_00973 System must support identifying source of fund account for installment debiting have sweep facility or not.If source of fund account have insufficient funds and also have sweep facility, system will grab fund from sweep source account, then perform payment.

The transaction code that is used for transfer from SOF account to ISA must be enabled for Sweep.

The instruction to Sweep from a Provider Account to the SOF account in case of shortfall must be created using CASA Sweep Maintenance.

System will create a Direct Debit Instruction when an ISA is opened. System


of 150

will Sweep from the Provider Account in case of shortfall in the SOF account if the above has been setup.

1PID_DP_01050 At the End of Day, if CASA Account with CASA TD Sweep facility (batch) is below floor limit, then this scenario will be followed:- Amount to be swept to CASA is calculated based on incremental parameter.- If amount to be swept is zero (0), then sweep will not be performed.- System will debit the SoF to cover primary CASA account as sequence priority (set on sweep facility setting).- If first SoF if not enough for cover the swept amount to primary CASA account, then system will debit the second SoF, and so on.- The debited TD Account will be treated as Partial Withdrawal (partial break).- TD balance cannot below the minimum placement after redeemed. e.g.: Balance indicator: Available Balance Effective/Expire Date: 1 Jan'13/1 Mar'13 Floor limit: 5 mio Ceil limit: 10 mio TD amount: 10 mio Min TD Placement: 8 mio 5 Jan'13 at EoD, CASA avaible balance is 1 mio. Then TD will be redeemed 2 mio, and the rest is from other SoF and follow same rules. If first TD account is enough to cover sweep amount, then only first TD account will be redeemed.- If all provider accounts balance still not enough to cover Sweep amount, then the provider accounts balance still will be debited. e.g.: Balance indicator: Avaible Balance Effective/Expire Date: 1 Jan'13/1 Mar'13 Floor limit: 50 mio Ceil limit: 100 mio TD1 amount: 10 mio



of 150

Min TD1 Placement: 8 mio TD2 amount: 20mio Min TD2 placement: 15 mio TD3 amount: 20 mio Min TD3 placement: 10 mio At EoD 5 Jan, CASA avaible balance is 5 mio, then it needs 45 mio to cover the CASA. Avaible amount from provider accounts is (TD1: 2 mio, TD2: 5 mio, TD3: 10 mio) total 17 mio. Then 17 mio will be swept to CASA.

1PID_DP_01052 If affiliated TD account for sweep facility is matured, then the facility will be automatically closed (For CASA TD Sweep batch and online).




of 150

26. Product Conversion

An account’s Product can be changed due to the following reasons:

1. Age2. Change of Customer Segment3. Customer Request

26.1 Product Conversion due to AgeThe age eligibility of a Product is defined in Product Eligibility parameter. System will convert an account’s Product to another one when the customer reaches a specific age. This is not applicable for CIMB Niaga and system will be enhanced not to do so.

26.2 Product Conversion due to Customer SegmentCertain products may be eligible for certain types of customer Segment only, for example, Preferred. The Segment eligibility of a Product is defined in Product Eligibility parameter. System will convert an account’s Product to another one when the customer is upgraded or downgraded to another Segment. Do not define the parameter if it is not applicable for CIMB Niaga.

26.3 Product Conversion due to Customer’s RequestA customer may also request for the Product of his account to be changed to a different one. This can be done by performing CASA Product Change Maintenance. The change will be effected during batch processing.



of 150

27. Branch Transfer

An account’s Owning Branch may be transferred due to one of the following reasons:

1. Customer Request2. Bulk Branch Transfer3. Branch Merger

In all cases, the Owning Branch and all the accompanying GL positions will be transferred as follows:

1. Effective Date – transfer of Owning Branch2. Effective Date + 1 – transfer of accompanying GL positions

27.1 Customer’s RequestA customer may request for his Owning Branch to be transferred to another one that is more convenient or suitable for him. This can be done by performing CASA Account Branch Transfer Maintenance.

27.2 Bulk Branch TransferA department in the Head Office may prepare a file that can be uploaded for replacing the Owning Branch of the listed accounts.

27.3 Branch MergerWhen a situation warrants the collapsing of a branch and merging it with another branch, the bank must define the Status of the collapsing physical branch as ‘Closed’ in the Branch parameter, followed by defining the effective date of the merger in the Transfer of Branch parameter. System shall replace the Account Branch (except Closed Accounts) of the collapsing branch with that of the Surviving Branch on the effective date, in all data files.


of 150

Account Branch of the collapsing branch shall be replaced with that of the surviving branch on the Effective Date.Accruals belonging to the collapsed branch shall be transferred to the surviving branch on Effective Date + 1.

Although only the physical branch is maintained as ‘Closed’ in the Branch parameter, all accounts in the Conventional as well as its corresponding Islamic branch shall be transferred to the surviving Conventional and Islamic branches respectively.

28. Housekeeping

It is necessary to perform Housekeeping for a more optimal system performance.

28.1 Transaction HistoryTransaction History shall be retained as defined in ‘Days to Retain History’ in the Product parameter. Thereafter, it shall be purged as follows:

1. Transaction History shall not be deleted for a Statement-based account if the transaction date is greater than the Last Statement Date.

2. The deleted record shall be stored in the archive file.

Example

Assuming the ‘Days to Retain History’ is defined as 365.

If the transaction date is 29th February 2012, the purging of this history shall be on 29th February 2012 + 365 days, i.e. 28th February 2013.



of 150


of 150

28.2 Closed AccountThe frequency with which a closed account is purged is set in the system. During the purging process, system shall remove the account from its related master file and other related files. The following files will be archived into the backup file during purging:1. CFAGRP – Account Profile2. DDMAST – Account Master FileThe archived files will be kept for one end-of-day.

A small data file shall be retained for user inquiry. These data include:

Account number Account type

Account currency Account nameBank Number Branch NumberOpened date Closed dateClosed reason code Purging datePrimary CIF No Primary CIF Name (40 character)Primary CIF ID No (20 character) Secondary 1 CIF NoSecondary 1 CIF Name (40 character) Secondary 1 CIF ID No (20 character)Secondary 2 CIF No Secondary 2 CIF Name (40 character)Secondary 2 CIF ID No (20 character) Account ModeProduct Type (for CA/SA only) Teller IDAccount Last Balance


of 150

The following is a list of requirements that are related to batch processing for Housekeeping.


1PID_DP_00504 System must able to process: Purge tier history record

This is supported, assuming it is the housekeeping of Accrual History.

1PID_DP_00592 System must able to process: PPh Housekeeping DD

PPh is Withholding Tax and it is part of CASA Transaction History (DDHIST). Its purging criteria is stated in Transaction History



of 150

29. Other Applications

This section discusses the batch processes that are to be handled by other applications.

29.1 ATM / Debit Card

The following is a list of requirements that are related to batch processing for ATM or Debit Card.


1PID_DP_00541 System must able to process: ATM Acquirer Merging Transactions

This requirement is to be handled by online interface application.

1PID_DP_00680 System must able to process: Debit CARD CITYNET EXTRACT ITM


1PID_DP_00683 System must able to process: City Net - Debit Card Extraction Issuer ITM ADDLIB


1PID_DP_00684 System must able to process: DEBIT CARD MASTER ITM ISSUER


1PID_DP_00789 System must be able to interface with CMS to receive fee/ charges posting related to card change activityIntegration Type: SIBS and CMSInterface Description: SIBS to receive fee charging instruction from CMS and return transaction result to CMSInterface type: OnlineIntegration Frequency (for Batch): N/A



of 150

29.2 Bancassurance

The following is a list of requirements that are related to batch processing for Bancassurance.


1PID_DP_00612 System must able to process: Redundant record processing

Not applicable anymore. This requirement is to be dropped.

1PID_DP_00613 System must able to process: Tapend information searcher


29.3 CIF

The following is a list of requirements that are related to batch processing for CIF.


1PID_DP_00866 System must support update of CIF information (including CIF number, Customer name etc.) at account level, if CIF relationship is changed

The Account Name will be the QQ Name for CIMB Niaga. Short Name can be edited by performing Account Name Maintenance.

1PID_DP_00919 General requirement for AOVI:-System must support purging/ housekeeping of AOVI registration data that has been fetched from AOVI server to SIBS, but haven’t been process to finish.Retention period is parameterized(program: CF6010HC, CF6010HK)

CIF’s parameter, CFPARZ will be enhanced to allow a user to define when the housekeeping of AOVI data is to be performed.



of 150


of 150

29.4 Credit Card

The following is a list of requirements that are related to batch processing for Credit Card.


1PID_DP_00679 System must able to process: City Net - Credit Card Extraction Acquire

This requirement is to be handled by Batch Interface Application.

1PID_DP_00681 System must able to process: City Net - Credit Card Extraction ITM CASH ADVANCE


1PID_DP_00682 System must able to process: CREDIT CARD cash adv CITYNET EXTRACT ITM


1PID_DP_00685 System must able to process: CASH ADVANCE MASTER OFFUS EXTRACT


1PID_DP_00686 System must able to process: CASH ADVANCE MASTER OFFUS EXTRACT FLAT FILE


1PID_DP_00687 System must able to process: City Net - Credit Card (Structure to Flat)




of 150

29.4.1 EMS

The following is a list of requirements that are related to batch processing for Expert Monitoring System (EMS).


1PID_DP_00688 System must able to process: Daily Update for Hand Phone and Email Add


1PID_DP_00942 System must be able to send static data to EMS via FTP. Data to be sent are card numbers, latest 10 Cellphone numbers, correspondence address. File name must contain date for troubleshooting. The details are as follows:-1. Implementation -able to query CIF, card number and account number provided by ITM -able to send data provided by ITM to EMS via FTP tobe saved by EMS2. daily update for new card -able to query new card data and CIF provided by ITM -able to send data provided by ITM to EMS via ETP to be replaced old data by EMS3. daily update for cellphone and correspondence address change -able to query changing of cellphone number and correspondence address provided by ITM -able to query card number of data changing from ITM -able to send changing data provided by ITM to EMS via ETP to be replaced old data by EMS4. able to generate report that contains numbers of data sent by system to EMS via FTP. Report periods monthly



of 150

29.4.2 FDS

The following is a list of requirements that are related to batch processing for Fraud Detection System (FDS).


1PID_DP_00696 System must able to process: Daily Update extract PGM control


1PID_DP_00697 System must able to process: FDS extract daily: Daily Update xtract PGM to generate Party info


1PID_DP_00698 System must able to process: FDS extract daily: Daily Update extract PGM for Party address info


1PID_DP_00699 System must able to process: FDS extract daily: Daily Update xtract PGM for Account info


1PID_DP_00700 System must able to process: FDS extract daily: Daily Update extract PGM for Account address info


1PID_DP_00701 System must able to process: FDS extract daily: Daily Update extract PGM for Party Account info


1PID_DP_00702 System must able to process: FDS extract daily: Daily Update extract PGM for CIFCC info


1PID_DP_00934 System must be able to received data from ITM to do account blocking of CASA suspect. Data that to be blocked will be generated by Fraud Detection System (FDS). Blocking facility using TLASTS (existing program JHS 102)



of 150

1PID_DP_00935 System must be able to daily extract data to FDS system (DDY630CB), with details: 1. Party2. Party Address3. Account4. Account Address5. Party Account6. CIFCC (CIF, Credit Card No, Credit Card status, creation date, update date, closing date)


1PID_DP_00936 System must be able to extract data to FDS system-for migration (DDY630CA), with details: 1. Party2. Party Address3. Account4. Account Address5. Party Account6. CIFCC (CIF, Credit Card No, Credit Card status, creation date, update date, closing date)


1PID_DP_00937 System must be able to send extract data to FDS via FTP.Integration Type : SIBS to FDS to send extract dataInterface Description : FDS to to receive detail from SIBSInterface Type : batchIntegration Frequency (for batch) : daily and one time



of 150

29.4.3 Merchant Incentive

The following is a list of requirements that are related to batch processing for Credit Card Merchant Incentive.


1PID_DP_00703 System must able to process: MERCHANT INCENTIVE SCHEDULER

This requirement is to be handled by Credit Card Application.

1PID_DP_00704 System must able to process: MERCHANT INCENTIVE : MAPPING ASCEND FILE TO SIBS'S


1PID_DP_00705 System must able to process: MERCHANT INCENTIVE (MINCV) MAIN PROGRAM


1PID_DP_00706 System must able to process: MERCHANT INCENTIVE : MAPPING SIBS FILE TO ASCEND'S


1PID_DP_00707 System must able to process: Program Log process Merchant Incentive


1PID_DP_00708 System must able to process: Program Log Process Merchant Incentive (EOM)




of 150

29.5 Cross Product

The following is a list of requirements that are related to batch processing for Cross Product.


1PID_DP_00074 System must provide a field to maintain “Offset Minimum Balance”. This is to be used for loans that are tied to CASA for pricingNoteIn Loan process of Maintain Offset Against Deposit Account, System must be able to validate that only CASA with the following condition:- CASA has offset minimum balance set.

This requirement is to be handled by Cross Product Application.

1PID_DP_00986 System must be able to have function to Xtra Manfaat CASA auto mapping parameter.If Account Loan Xtra Manfaat is paid off then system will change CASA Product automatically that set in this parameter.Parameter is - From product CASA- To Product CASA

This requirement is to be handled by Cross Product Application.



of 150

29.6 E-Alert

The following is a list of requirements that are related to batch processing for e-Alert.


1PID_DP_00201 System must be able to provide notification to customer for conditions as follows:-- every delinquency that has passed grace period (for ISA).- second delinquency that has passed grace period (for ISA). Contain information that program penalty will be charged- X months before ISA maturity (X is parameterized)- After CASA account turns to dormant status- X days before SDB maturity (X is parameterized)- the day of SDB maturity- SDB has been closed before maturityIntegration system: SIBS & e-Notification systemInterface description: Send notification message to customer mobile numberInterface type: BatchIntegration frequency (for batch): TBD

This requirement is to be handled by e-Alert Application.

1PID_DP_00695 System must able to process: Enot for clicks EOD proses: e-Not Daily File Purging

E-not is an SMS notification from Clicks. This requirement is to be handled by e-Alert Application.



of 150

29.7 GL

SIBS will generate GL Event Code to GFMS for every transaction. GFMS is to generate the accounting entries based on the convention decided for the GL Event Code. The structure of a GL Event Code for GL and Teller Application is as follows:

1. Application Code (2A)2. Debit / Credit Indicator (D or C) 3. Source ID, comprising Source (1A), Target(1A), Channel (3A) and Payment

Mode (5A)4. Charge Code (5A), default to ***** if it is not a Charge Event

The structure of a GL Event Code for other Applications is as follows:

1. Application Code (2A), e.g. CD for Time Deposit and DD for Demand Deposit2. IFC (3A)* 5. Source ID, comprising Source (1A), Target(1A), Channel (3A) and Payment

Mode (5A)3. Charge Code (5A), default to ***** if it is not a Charge Event4. Contract

a. * for local currencyb. C for cross currenciesc. N for non-contractedd. Y for contractede. Z for like currencies

5. Status (1A) for Y (NPL) and N (non-NPL)

For example, a Cash Deposit into a Savings Account will comprise of two Events:

1. Cash Event2. Account Event


of 150

The GL Event Code for the Cash Event and the Account Event will be TLDSSBDSPNC******* and DD002SSBDSPNC*******, respectively.

GFMS will then generate the following entries based on the GL Event Code:

Cash Event

Debit Cash

Credit ISC

Account Event

Debit ISC

Credit Savings Account

A movement file will be generated and it shall consist of Bank Code + Branch Code + Responsibility Centre (RC) of the transacting branch. The RC of the transacting branch is based on Teller ID. BDS is to send the Teller ID to Host so that Host will be able to generate the movement file. Other channels are to send the RC to Host. The Summary of the movement is generated in a Balance Code file.

* IFC 001 and 002 are used to denote Debit and Credit, respectively if the Affect Code is ‘B – Balance’.

IFC 016 and 017 are used to denote Debit and Credit, respectively if the Affect Code is ‘I – Interest’.



of 150


of 150

The following is a list of requirements that are related to batch processing for General Ledger and GFMS.


1PID_DP_00500 System must able to process: PPX Inactivate Status & Purging Data: Gen Detail Reversal Accrue Work File

This requirement is to be handled by GL Application.

1PID_DP_00506 System must able to process: GFMS Deposit Accrual File Generator


1PID_DP_00508 System must able to process: Post DD Accrue Transaction to DRCR Accrue File


1PID_DP_00509 System must able to process: Post OD Accrue Transaction to DRCR Accrue File

Loans Application will generate a GL Event Code with IFC 016.GFMS will base on the GL Event Code to pass the following entries:Dr Interest ReceivableCr Interest Income

1PID_DP_00510 System must able to process: GFMS Deposit DR/CR File Generator


1PID_DP_00511 System must able to process: Extraction the Event Code Transaction to GL in GFMS


1PID_DP_00512 System must able to process: SIBS GFMS - Closing Rate Downloading – Gen + FTP


1PID_DP_00513 System must able to process: SIBS GFMS - Send text file to oracle


1PID_DP_00514 System must able to process: GFMS Deposit Balance Checking Generator


1PID_DP_00519 System must able to process: Convert DDBCWF from -ve to +ve


1PID_DP_00560 System must able to process: Oracle Dr/Cr Generating Program *Batch



of 150

1PID_DP_00610 System must able to process: Process GL IFC for Account Segment Code Change


1PID_DP_00643 System must maintain information below used by GFMS:-1. Company2. Branch3. KioskExample: AS-IS GFMS maintains mapping between Kiosk and Branch to get the branch code. For TO-BE, Finance requires this mapping to be maintained in 1P and 1P provides only the branch code & RC to GFMS.NOTE: There are many mapping currently done in GFMS today that Finance would require to be done in 1P. Finance will provide the full list of mapping done in GFMS


1PID_DP_00644 All system performing financial transaction using GL number code must change GL Number to follow LoVs from GFMS.1. BDS2. SIBS, example for Host Teller for GL number of each ATM Teller ID (AS-IS File: TLTEL, Field Name: TLCSHA)


1PID_DP_00646 All financial transaction posting involving SIBS must carry GL reconciliation number. Format of GL reconciliation number will be defined later.Impacted system: SIBS and all system performing financial transaction posting with SIBS.


1PID_DP_00657 System must define transaction charges to be booked under owning branchCurrently transaction charges are booked under Maker Branch (branch where the transactions happened) -> (subject to Management Approval and require alignment to GFMS project)



of 150

1PID_DP_00709 System must able to process: PPX Settlement; PPX Automation Amortization


1PID_DP_00967 For CASA to GL transactions, system must bring transaction remark to detail data sent to GFMS




of 150

29.8 Interface

The following is a list of requirements that are related to batch processing for the various Batch Interfaces.


1PID_DP_00580 System must able to process: Down Load Base PRK (Bulanan)


1PID_DP_00581 System must able to process: MR DAILY REG UPLOAD MODUL


1PID_DP_00582 System must able to process: MR DAILY DOWNLOAD MODUL


1PID_DP_00583 System must able to process: MR MONTHLY DOWNLOAD MODUL


1PID_DP_00584 System must able to process: TELESALES DAILY REG UPLOAD MODUL


1PID_DP_00585 System must able to process: Download Telesales – Bill payment (Monthly)


1PID_DP_00586 System must able to process: Download Telesales - DD (Daily)


1PID_DP_00587 System must able to process: Download Telesales - Tapen/Mapan (Monthly)


1PID_DP_00588 System must able to process: Download Telesales - TD (Daily)


1PID_DP_00589 System must able to process: Download Telesales - DD (Monthly)



of 150

1PID_DP_00882 System must be able to support auto registering to internet banking system (CIMB clicks) for account opening of Air Asia Savers. if the registering fail because of customer hasn't registered yet, system must retry in next batch processIntegration Type : SIBS to Internet BankingInterface Description : Internet Banking to receive detail from SIBSInterface Type : batchIntegration Frequency (for batch) : daily


1PID_DP_00884 System must be able to provide avg balance data of Air Asia Saver Account, with status: Tidak Tutup (unclosed). Data to be provided are CIF number, account number, cust number, product code, avg bal Integration Type : SIBS to PGS system to be passed to Promo EngineInterface Description : PGS before received by Promo engine to receive detail from SIBSInterface Type : batchIntegration Frequency (for batch) : monthly


1PID_DP_00885 System must be able to provide new opening account data of Air Asia aver Account. Data to be provided are CIF number, account number, cust number, product code, branch code, ID number, mailing address, cellphone numberIntegration Type : SIBS to PGS system to be passed to Promo EngineInterface Description : PGS before received by Promo engine to receive detail from SIBSInterface Type : batchIntegration Frequency (for batch) : daily



of 150

1PID_DP_00920 SIBS to send list of values for fields included in the account opening process.Integration system: AOVI ServerInterface description: to send list of values (pick-list) of fields included in account opening processInterface type: batchIntegration frequency (for batch): dailyFiles: SIBS Product Code DDPAR2 SIBS Currency Code JHFXRT SIBS Title Before Code CFGLAR position = FSIBS Title After Code CFGLAR position = BSIBS ID Type Code CFIDDF SIBS Country Code JHCOUN SIBS Religion Code JHCOUN SIBS Postal Code JHPARZ SIBS Customer Sub-Type ( occupation) CFYPSC SIBS BI Industry Code BIPARP Level = 3SIBS Marketing Information Code 10 CFPAR6 CP6MIC = 10SIBS Source Of Fund CFYSOF SIBS Objective Of Bank CFHMHB SIBS Objective Of Account CFHTPD SIBS Normal Transaction Activity Code CFHATN SIBS Kios Code JHDATK SIBS Sales Code SALECH

SIBS Officer Code JHOFFR SIBS DATI JHPARA Cabang JHDATA



of 150

1PID_DP_00939 System must be able to provide checksum for total statement record and total amount for :- Current account saving account checksum- PRK current account checksum- Saving installment checksum- Combine statement checksum- Total checksum- Loan extra dinamis checksum - Non extra dinamis checksum


1PID_DP_01111 To support CBO Auto Reconcile Process, system must be able to generate account transaction history files with user defined criteria as followsa. Account number to be included: more than 1 accounts can be definedb. Transaction code to be included: record to be retrieved can be filtered by TLTXc. Extraction method:i. Ad-hocii. Batchd. FOR Ad-hoc, transaction time to be included:i. In range defined from starting date-time to end date-timee. FOR Batch, cut-off time: can be defined as daily, monthly, or weekly.i. If daily, can be defined to run at specified time (hh:mm:ss), will include all transactions made in the day (starting from the previous cut-off time to current cut-off time).ii. If monthly, can be defined at what date of the month (1-31) and what time (hh:mm:ss), will include all transactions starting from the previous cut-off time to current cut-off time.f. Information/ Fields to be included:i. Transaction Dateii. MTCN Numberiii. Transaction reference number iv. Debit/ Creditv. Transaction amountNOTE: Multiple instance of data download



of 150

setting (as described above) can be created and processed.



of 150

29.9 Payments

The following is a list of requirements that are related to batch processing for Payments.


1PID_DP_00564 System must able to process: Download Bill Payment data Main Program

This requirement is to be handled by Payments Application.

1PID_DP_00570 System must able to process: VOSTRENCRY Encrpyt


1PID_DP_00603 System must able to process: Purging Billing History File


1PID_DP_00607 System must able to process: Processing Transaction History (Batch)


1PID_DP_00678 System must able to process: Reject By System Automatic (Un-responded > 5days)


1PID_DP_01112 System must be able to extract biller payment transaction data (program: DDI396)Extraction process configurable by parameter (program: ISPPM)




of 150


of 150

29.10 Remittances

The following is a list of requirements that are related to batch processing for Remittances.


1PID_DP_00522 System must able to process: Generate G/L Reversal Txn For Credit Note

This requirement is to be handled by Remittances Application.

1PID_DP_00542 System must able to process: CLP PURGING DDYCNP(HAVE NO PAIR IN RMMAST)


1PID_DP_00543 System must able to process: Credit Note Purging After 14 days, CNATYP=H,D,S,T.


1PID_DP_00544 System must able to process: CLP LIST OF DDYCNP PURGED(HAVE NO PAIR)


1PID_DP_00545 System must able to process: LIST OF Purged Credit Note(CNATYP=H,D,S,T)


1PID_DP_00546 System must able to process: CLP PURGING RMMAST & DDYCNP(always in a pair)


1PID_DP_00547 System must able to process: purge RMMAST & DDYCNP after 14 business days


1PID_DP_00548 System must able to process: CLP LIST OF RMMAST PURGED(HAVE PAIR IN DDYCNP)


1PID_DP_00549 System must able to process: LIST OF RMMAST RECORD PURGED(HAVE PAIR IN DDYCNP)


1PID_DP_00550 System must able to process: CLP LIST OF DDYCNP PURGED(HAVE PAIR IN RMMAST)


1PID_DP_00551 System must able to process: LIST OF DDYCNP RECORD PURGED(HAVE PAIR IN RMMAST)


1PID_DP_00552 System must able to process: CLP PURGING RMMAST(HAVE NO PAIR IN DDYCNP)



of 150

1PID_DP_00553 System must able to process: Purging RMMAST records if have no pair in DDYCNP


1PID_DP_00554 System must able to process: CLP LIST OF RMMAST PURGED(HAVE NO PAIR)


1PID_DP_00555 System must able to process: LIST OF RMMAST RECORD PURGED(HAVE NO PAIR)


1PID_DP_00556 System must able to process: Purge JHYCNN and JHYCNO if have no pair in DDYCNP


1PID_DP_00557 System must able to process: PURGING JHYNUM FOR INCOMING REMITTANCE VALAS


1PID_DP_00558 System must able to process: Interface Housekeeping Main Program Multicurrency

Move to archive as per 1P (Remittances)

1PID_DP_00559 System must able to process: Purge remittance records from work file


29.11 Loans

The following is a list of requirements that are related to batch processing for Mikrolaju and Spekta.


1PID_DP_00172 Fund that is credited by Mikrolaju unit to a CA/SA account can only be debited for Mikrolaju loan payment purpose.

It is proposed that credits into Mikrolaju be performed using Loans Payment function in BDS. Loans Application will be able to apportion it as Advance Payment if the amount is greater than the Billing Amount.

1PID_DP_00599 System must able to process: FTP Download/Upload Parameter SPEKTA

This requirement is to be handled by Loans Application.


of 150


of 150

29.12 System Services

The following is a list of requirements that are related to batch processing for Interest Rates and Exchange Rates.


1PID_DP_00505 System must able to process:

Tier rate changed record

Interest Rate that has been changed will become effective on Zone 4. Thereafter, interest will be accrued on the new rate.

1PID_DP_00944 System must be able to provide audit log file to maintenance special rate Valas for e-channel. Minimum information is:-1. User ID2. Currency3. Channel ID4. Start Time: Time when special rate updated (automatic by system, not inputted by user)5. Start Date: Date when special rate updated (automatic by system, not inputted by user)6. End Time7. End Date8. Lowest limit for each tier (in Valas and IDR) also BPS Buy and BPS Sell

It is 1P standard to provide Audit Log for every maintenance. The previous and current value of the change will be logged together with User ID, Source ID and Date and Time.

1PID_DP_01078 System must support NWAY > 25 JOBS in EOD batch processcurrently system can support up to 625 jobs

Job Name will be 7A and NWAY is 3,0.



of 150

29.13 UCP

The following is a list of requirements that are related to batch processing for User IDs.


1PID_DP_00810 Need to be able to generate: Branch User Login on eTPList of information : Login Date/Time, User ID, Log Out Date/Time

The log is stored in UCP. This requirement is to be handled by UCP Application.

1PID_DP_01074 System must be able to delete TELLER ID/USER ID that has not been used in 30 days automatically, except new user ID

This requirement is to be handled by UCP Application.UCP will auto suspend the User ID if it has not been logged in more 30 days. It is up to the IT Security to delete a Suspended User ID manually.



of 150

29.14 Virtual Account

The following is a list of requirements that are related to batch processing for Virtual Account.


1PID_DP_00601 System must able to process: Purging history VA trans (Driver)


1PID_DP_00602 System must able to process: Purging history VA trans (Copy Replace)


1PID_DP_00604 System must able to process: Purging deleted VA master file (Copy Replace)


1PID_DP_00605 System must able to process: Purging VA deletion Log File (DDVTACAD)


1PID_DP_00606 System must able to process: Purging VA upload Log File (DDVTACAU)


1PID_DP_01010 System must support calculation of charges to be applied to customer account that is using Virtual Account feature.The charges will be calculated using parameters of cycle, type of transaction, charges amount, multiplier, and have discount using count of transaction or total charges amount, apply by account.The amount charged will be collected to produce report.


1PID_DP_01013 System must be able to identify unsuccessful post debits related to VA corporate charges.System will collect the data and produce report at month end.Report can be printed Ad-Hoc anytime in a year.



of 150

29.15 Miscellaneous

The following is a list of requirements that are related to batch processing for other processes not classified elsewhere.


1PID_DP_00520 System must able to process: Update retention periodk;C014


1PID_DP_00571 System must able to process: CL for file down load NIAGAEFFICient


1PID_DP_00572 System must able to process: Pembentukan Working File untuk NIAGAEFFICient


1PID_DP_00609 System must able to process: Handle Segment Code Change For Related File

This requirement is to be dropped because Segment Code will be replaced by SBU.

1PID_DP_00614 System must able to process: Return Last processing date from DDPAR1


1PID_DP_00694 System must able to process: Advance/Sub Months from a given date


1PID_DP_01019 System must not allow "account in use" error for all MFTS transactions and batch posting transactions

In order to reduce the number of occurrence of Account Lock phenomena, Host Teller program will be enhanced to send ‘T’ for MFTS and batch posting transactions.



of 150

1p impl_r3(id)_app_ap352_batch processing - casa v0.5

Documents