Req.

No Requirement

FR.BAM.01 The system should enable CRUD (create, read, update and delete)
operations on the Account. These operations should be available
via APIs and GUI. The system should produce audit logs for any of
these operations performed.
This functionality should only be available based on the user role
and permissions.

FR.BAM.02 Every account should have a unique identifier and uniqueness

should be maintained across multiple instances of the applications.

FR.BAM.03 The system should allow configurable definitions for the account
and for other values which are system generated e.g. customer ID,
product ID, account ID etc.

FR.BAM.04 Apart from the primary account identifier, it must be possible to

store multiple other identifiers provided by other applications.

FR.BAM.05 The system should support attributes related to the customer

profile, billing profile, customer segment, credit limit, tax attributes
and other information required for the billing processes.

FR.BAM.06 The system should allow definition of custom attributes related to

the account.

FR.BAM.07 All account related attributes either available out of box or custom
attribute should be available for searches, reports and other default
system functions.

FR.BAM.08 The account shall have different states which will define its lifecycle
(e.g. active, grace, suspended, terminated etc). It should be
possible to configure additional states for the account based on
internal policies, service category, payment type etc.

FR.BAM.09 It should be possible to transition states using APIS or GUIs.

FR.BAM.010 It should be possible to define the lifecycle of the account and

transition it independently of other objects in the billing system.
The system should provide the flexibility to change the account
state manually and automatically (based on configurable rules).

FR.BAM.011 The lifecycle state transition should also be possible based on

external events.

FR.BAM.012 The system should support the configuration of rule both pre and
post lifecycle state transition and take actions as per the defined
rules.
 Req. No Requirement

FR.BAM.013 It should be possible to publish notifications of the lifecycle state

transitions to customer and other applications. The content and
metadata of the notification should be configurable.

FR.BAM.014 It should be possible to define relationship between accounts

resulting in hierarchies. These hierarchies represent real life
scenarios pertaining to customer, SMB, corporate segments.

FR.BAM.015 The system should allow definition and maintenance of N level

hierarchies for mobile, home and corporate business units.

FR.BAM.016 The system should allow for account to be moved across

hierarchies, in and out of hierarchies.

FR.BAM.017 The system should enable splitting and joining of hierarchies.

FR.BAM.018 The system should allow introduction of aggregators accounts to

assist in managing the hierarchy.

FR.BAM.019 The system should provide bulk tool to support operations in

managing individual account or hierarchies. The tools could be
used to update account attributes or states. The tool should also
support splitting and joining of hierarchies.

FR.BAM.020 The system should support an identifier for hierarchies available at

account level.

FR.BAM.021 The account hierarchy should enable the system to define rules for
charge redirection in the hierarchy based on event type, time of
day, geographical location and other parameters.

FR.BAM.022 It should be possible to generate invoices at different levels in the

hierarchy for all three markets (mobile, home and corporate).

FR.BAM.023 The solution should support relationship with other entities like
products, balances, invoices, billed and unbilled usages.

FR.BAM.024 It should be possible to share balances, discounts both monetary

and non-monetary across the users in an hierarchy or across
different hierarchy.

FR.BAM.025 The system should provide the flexibility to configure share bucket /
wallet to be used across different access media (e.g. same voice
wallet shared across mobile and fixed line).

FR.BAM.026 The system should provide the flexibility to configure any wallet to
 Req. No Requirement

be used for any services. For example, SMS mobile wallet to be

used for fixed line voice calls.

FR.BAM.027 The system should allow to associate and account with one or more
products or contracts.

FR.BAM.028 The system should allow association between account and multiple
individual or shared balances.

FR.BAM.029 The system should support audit logging of all events and
transaction related to accounts.

FR.BAM.030 It should be possible to export details of all account and their

attributes.

FR.BAM.031 It should be possible to export details of all accounts of in an

hierarchy or which share a balance group.

FR.BAM.032 The system should enable fund transfer between account marked
as either post-paid or prepaid.

FR.BAM.033 The system must support mobile number portability (MNP).

FR.BAM.034 The system should support bill cycle movement of account or

account hierarchy.

FR.BAM.035 The system should support change of the account agreement

liability.

FR.BAM.036 The system should allow account to be maintained in multiple

currencies.

FR.BAM.037 Whenever a new line/account is created, the system should attach

a default credit limit to the account in the case credit limit is not
provided during creation. The default credit limit should be a
configurable parameter.