An internal planning presentation (Jan 2007) on building a cash tracking system for the 800 Nemmadi telecentres in Karnataka, then operated by Comat. Since this plan was not implemented and Comat is no longer operating Nemmadi, I don't believe there are any concerns with releasing this document.

1. Namma Service
Cash Tracking System
Discussion on requirements, issues with data sources, technical
design for a flexible data holding framework, and work-in-progress
plans for a reconciliation engine.
Wednesday, January 31, 2007
Kiran Jonnalagadda <kiran.j@comat.com>
Requirements
Channelling Data
Blue Sky Plan
What’s wanted, what’s needed
Dealing with available information
Dreaming up what may be…

2. Requirements

3. Cash Tracking
Tra
n
sa
RDS/Bhoomi Records (SDC)
Telecentres
Cash Flow
Diagram
cti
on
Up
d
TC
Bank
Branches
ate
(D
ail
y)
Comat Records
TC
TC
TC
2pm next day
Paper PR
Records
BB
BB
TC
TC
TC
PR
BB
BB
TC
TC
TC
PR
BB
BB
Bank
Auditor
Back Office
Totals
Amount Collected
Via
T
onthly)
ce (m
Maintenan
IDTC (Daily)
Penalties
Incurred
)
in 2!
With since
days action
s
tran
(Monthly
3i Bank Account
Central
Bank
Accounts
IDTC
Recd.
Invoice
Refer to the printed copy
DM
TA Share
Area/District
Manager
GoK Share
C
Net MT
C min
us IDT
C
(Month
ly)
Legend:
Transaction Flow
Primary Information Flow
Reconciliation Information Flow
Cash Flow
Enhancemen
t
TC
Telecentre (physical structure)
TC
Records of telecentre (information structure)
(Quarterly)
GoK Bank
Account
Bank
Guarantee
Performance
Bank Guarantee
GoK
3%
t
(M o C
on MC
thl
y)
CMC
Account

4. Requirements
Analysis Using
User Stories
Actors
Activities
Defining system
requirements via
actors and their
activities, expressed
as “stories”
Stories

5. Available Data

6. Current Data Collection Processes
Transaction Reports
installed at the State Data
Centre provide a running
stream of transactions, but are
unreliable: if a certificate fails
to print, it is still recorded as a
successful transaction.
At least we’re assured they
didn’t miss anything.
Type of data:
individual transactions.

7. Current Data Collection Processes
Operators use the Intranet to
file daily reports.
Details are limited to what we
can expect to receive with a
reasonable level of accuracy.
Operators may not recall the
number of successful
transactions on a busy day,
for example, but can count
the cash at hand or the
number of wasted sheets.
Type of data:
daily totals and errors.
{

8. Current Data Collection Processes
The IDTC Transfer Grid, part
of the existing Transaction
Reports, records our transfer
to GoK and GoK’s transfer
back to us, with GoK’s Bank
validating the claimed figures.
What we need is similar
cooperation from our banks at
the individual branch level.
Any errors in transaction data
are propagated here.
Type of data:
daily total for per region.

9. Current Data Collection Processes
Our operations staff call
operators and area
managers every day to get an
update. While this gives us a
better sense of ground-level
activity than any automated
system, it is a laborious
process.
Any machine parseable data
currently being collected by
this process should be
replaced by software.
Type of data:
non-machine parseable
detail on operations.

10. Making Sense of It All
Putting Data on Rails

11. Double Entry Accounting
Ledger
RTC Service
Transaction
Split
(Income)
(Rs -15)
Transaction
Record
(Sum of Splits: Zero)
Ledger
Cash Collection
Transaction
Split
(Current Asset)
(Rs +15)
Well Defined
Transaction
From Data Streams
Split
To Transaction
Be Calculated
Record

12. Sample Ledger

13. Missing Data Streams
Ledger
RTC Service
Transaction
Split
(Income)
(Rs -15)
Transaction
Record
(Sum of Splits: Zero)
Ledger
Cash Collection
Imbalance
Transaction
Split
(To (Current Asset)
maintain integrity)
(Rs +15)
There is no data stream for the second split, so that must be
calculated and marked as such, for later reconciliation

14. Creating Balancing Splits
Ledger
RDS Services
(Reliable)
Ledger
RTC Service
(Unreliable)
n
tio
(Income)
Tran
s
c
sa
n
Tra
ile
acti
ons
Re
co
nc
Ledger
Cash
Collection
Operator’s
Stationery Error
Report Re
(Current Asset)
con
cile
Non-cash inventory ledger!
s
(Income)
Ledger
Wasted
Stationery
(Monthly Collections)
Re
con
cile
Operator’s
Collection
Report

15. Well Defined Data Types
Ledger
Ledger Group
Group
Membership
Ledger/Group
Value/Count
Total
Absolute or Period Totals
Reconciliation Set
Transaction
Transaction
Split
Reconciliation
Split
+ Flags
There are more, but these are the most critical data types

16. Blue Sky Plan
The Reconciliation Engine

17. Transactions and Deposits
Transactions
Rs 8,500
Deposits
Rs 6,375
Rs 4,250
Rs 2,125
Rs 0
1
2
3
4
5
6
7
8
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

18. 3-Day Moving Average
Transactions
Rs 4,000
Deposits
Rs 3,000
Rs 2,000
Rs 1,000
Rs 0
1
2
3
4
5
6
7
8
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

19. Security
Careful with the Details

20. Typical Security Model
Securing the Perimeter
The User Interface is the Perimeter
Once inside the Perimeter,
there’s no security. A single insecure entry
point compromises the entire system

21. Recommended Model
Security at the Core
User
& Machine Interface
Extended
API
Core
API
Core
Data

22. Recommended Model
Independent Modules Manage Their Own Security
Core
API
+C
Web Services
ache
Core
Data
Reconciliation
Engine
User Interface

23. Security
Framework
Users
Roles
Security is defined in
terms of Users, Roles,
Permissions and
Actions. Users have
Roles in specific
Contexts and Roles
have Permissions to
perform Actions.
Permissions

24. Contexts are
Ledgers and
Ledger Groups
Actions are
Pieces of
Code
Users are assigned roles in
particular contexts, such as
kiosk operators acquiring the
“Operator” role only in their
kiosk’s ledgers.
Each code function requires a
specific permission to be
used. Permissions are given
to roles, which in turn are
given to users.