A client has purchased this script and it does not meet their requirements in many areas. Script can be found at [login to view URL]
The application contains a number of useful functions but leaves the administrator with a number of manual tasks to complete.
Goal is to automate these tasks and enable third parties the ability complete their portion of the tasks.
The following are the required tasks.
Identification
Goal – Improve identification of members, current sign up method is incomplete. It simply verified e-mail. Collect additional identification information such as passport photo etc as well as improve on the verification beyond e-mail using Bank and Employment verification.
Employment:
Create Verified List of Employers- System should update each time someone enters a new employer. Create Employer verification table, e-mail address, fax and physical address. Once the employer is verified, Employee can be verified, systems generate messages to the employer by e-mail, fax or printed for verification of employment.
Bank:
System table contains banks with related branches and primary contact for identity verification as well as mode of confirmation, e-mail, fax or mail.
When customer selects bank, system should use selected method to contact bank for verification.
Verification and Transaction
Only verified members would be allowed to debit their bank accounts
Verified members will be able to transfer over (Variable) amount per day. As defined
To verify system selects verification mode selected, fax, e-mail or Manual Post
If fax or Mail, system generates form which can be faxed or Printed.
If e-mail same, systems sends
System records process
Each mode generates a reference number.
When the verifier receives communication, they log into a specified page and enter the referral code to verify.
When referral code is entered they are asked a simple question, “Is all the information we sent you correct” Verifier has the choice of Yes or No.
If Yes, verification is complete and customer flagged,
If No, Verifier is taken to a new page to enter problems with the form or comment “unable to verify”.
Verification Result is e-mailed back to the member and the appropriate status flag is set.
There is a different flag for bank verified and other verified.
Flag will determine transaction limits. (note system must be automated)
Primary information to verify
Name /Address/ Photo/ Signature and Account Number.
New Member Joining/Registration Process :
Currently system supports members and admin log in only
.New System should also support Bank Login, Agent login and SubAdmin Login,(sub-admin will have limited functions to perform like customer service)
Bank Function
Will have Primary Administrator who is responsible for defining users for the bank.
Banks have branches
Each branch will have its own login page with specified functions as defined by the bank administrator
Each branch will be able to see its own transactions such as payments made, deposits, withdrawals on behalf of customers
Head office will see transactions for each branch.
Branches cannot delete transactions.
When system has outstanding transactions for the bank, the person defined for the role will be e-mailed on the task to be performed.
If bank defines only one person to confirm transactions for all branches, system will enable all bank users to send messages to the confirmation officer.
Structure
Bank - Admin
Branch A - User A User B
Branch B - User A,User B
Each branch is given a daily transaction limit for deposits and withdrawals by the bank administrator further, each office is given a limit, limited by the aggregate branch limit
Note for the system, All banks and agents function the same way.
Members in the system that want to conduct a transaction should be able to search for banks and branches participating
Here are the roles of Agents, (Banks inclusive)
a. Confirming Agents – (CA)
i. Can confirm deposits,
ii. CA's may be given a credit line to confirm deposits or has money on deposit, manage.
iii. Whenever a CA confirms a deposit, his credit line is reduced by the same amount.
iv. Credit is replenished whenever CA pays System or payment was taken from existing deposit
v. Account aging is implemented for the CA to enable it track how long deposits are with the CA.
vi. As payments are made by the CA it is redeemed FIFO
b. Funding Agent – (FA) are account holders in the system and can use those funds to fund members, additional payment type to this category “Credit”. Administrator will define credit limit that will enable the agent to fund.
i. Against credit, Agents can fund members
ii. Credit limit is replenished when actual payments are made from Agent to System no other.
c. Withdrawal Agents (WA) – Pay out cash or issue cheques and wires to members.
i. System can owe WA's
d. Direct Deposit banks – DDB Can log in and process their own confirmations
e. Indirect deposit banks – System will queue transactions for IDB's until funds are received CA and FA can provide confirmations for IDB
Transactions
Deposits
The current system defines a number of ways to make deposits to a customers account. We have added deposit by a participating bank. The goal here is to add new functions and automate the current confirmation process. The bank or agent should have a module for updating the system. The current system has the agent sending an e-mail confirming the transaction. When customer sends a check or goes to a bank, bank should log in and confirm the payment using the transaction id. Unlike the current manual process, once the confirmation id is entered, customer transaction is removed from pending status.
When a customer chooses the deposit option, the customer is to be given a number of choices
1. Debit your account and fund, (Show only CA's and FA's)
2. Deposit by cash/e-cheque (Show only CA and FA's)
3. Deposit by mail – Customer Service Agent should log in as the instruments clear and release pending.
4. By Credit card/PayPal etc.
If the choice is 1 and 2, customer will then be offered the appropriate agent to conclude the transaction. Once the choice is made, the system pends the transaction for the customer until the agent is able to confirm the transaction. System should them provide the appropriate information to the CA and FA. Both of which can confirm if customer has deposited already or if customer hands them cash or debits their account.
This is to eliminate the administrative task of calling the banks to find out the status of the transfer. Once the member selects the TA, the system queues the transaction for the CA/FA to click on the confirm button. Once the click, the customer is funded and value is due from the confirming agent.
If customer hands over cash and did not do a deposit online then CA/DA should pay customer from their credit-line. Money will then be due to system from the CA/DA
System should generate a unique transaction id and send as part of confirmation e-mail.
Withdrawals
A customer may choose to withdraw funds by cash at a bank or agent, by Cheque, wire transfer, PayPal or withdraw and pay someone. Currently this process put a major burden on the system each has to be processed manually.
Changes:
When customer elects to withdraw cash at a bank, system should immediately prompt him to select a bank from the paying banks or Agent. Once customer does that follow procedure hereunder for disbursement agents.
A customer may withdraw funds the following ways
1. Credit back to bank account
a. Show direct deposit banks
b. Show Indirect deposit banks
If customer chooses a direct deposit bank, send the transaction to the bank module and queue. Bank should carry out the transaction and provide confirmation. If member does not see a confirmation, member can contact the bank.
2. Withdrawal by cash or Cheque – Choice is any WA
a. Member chooses a WA and proceeds with the withdrawal for cash.
b. System queues transaction at WA until member comes to collect.
c. When member goes to WA for withdrawals and payments
d. WA should not be able to search database for transactions, rather member will give WA system generated transaction reference number.
e. When WA enters number it prompts for customer selected security key.
f. When customer enters key, transaction is shown.
g. WA then confirms payment to member and status changes.
h. This is a security precaution to prevent bank employees for querying transactions and presenting fake beneficiaries with identification.
3. Withdrawal by mail / Wire transfer or Western Union
System sould generate transaction for Administrator
Administrator Panel should show pending transactions.
Customer Service Agent or (SubAdmin) logs in, is presented a schedule of outstanding which are then processed.
System should have option of sending task of writing checks or initating wires to a Direct Bank
For both deposit and withdrawal, customer can select to notified by SMS, (Confirmation/Cancellation)
All withdrawals must be cleared by Administrator
When a customer makes a request for withdrawal it is first queued for customer service before being released to an Agent
The page must show complete customer transaction history for fraud check.
Only when it is released does it go to an agent
For Cheques, system queues the transaction so that an officer of the payment process can view a list of cheques to be issued
Admin logs in, view checks to be issued, writes them and mails the check, system captures the information (no and date) and sends confirmation to the receiver.
Same for wire transfers and PayPal.
Key --- define table for withdrawal so that new withdrawal instruments can be defined and tracked.
*1 – Define table of agents where withdrawal is possible
To enable a western union type service so members can transfer funds to an agent and have another member collect it.
Funds are sent to account of receiver but can be paid out by agent, once agent pays it out, funds are credited to agent and debited to receiver.
Note that when receiver receives it he can assign a pass code which he gives to agent on a collection form to collect the money.
At agent, receiver must enter the code on agents window ****** as evidence so that agent cannot have someone else release the funds.
CHANGES TO EXISTING MENU'S
PAYMENTS
Modify Menu for Payment by adding bill payments in addition to the existing transaction types
• OVERVIEW
• SIMPLE PAYMENTS – Pay to e-mail or User name.
If member is not found, ask if payment is to a none member, if yes is selected, ask for e-mail/smsto send payment notification. Same for Mass Payments
new• THIRD PARTY – Cheque or Electronic Payment such as wire transfer, paypal etc, GIVE DETAILS
new • MOBILE PAYMENT – Pay by Mobile Phone takes you SMS Window enter number intl format, Amt and Description - Requires mobile number field in member database.
New • NONE MEMBER PAYMENT- E-Mail or Mobile
new • PAY A BILL – Introduce Bill Payment (example - Yahoo billPay)
• MULTIPLE PAYMENTS
• ESCROW TRANSACTION
new • UPCOMING PAYMENTS - member provides schedule and system can write cheques or assign to Direct Bank
new• SCHEDULE PAYMENT
new• PAYEE LIST - Payee List is made of two parts, System Payees and Member payees.
a. System Payees – known to the system -member has to just enter their account number and amount
b. For members payee – created by member - first time, member must provide complete address and other contact details
For all payments member can either select pay now or pay later. If member adds a pay later transaction, the member will then give the payment a date. There information will be shown in UPCOMING PAYMENTS as SCHEDULED
Upcoming payment Due Date/ Amount/ Status (Due/Reminder/Scheduled) /Action (Change/Cancel)
Member will also be able to see and search bill payment history
Current app supports payment to an e-mail address, upgrade should support payments to a mobile phone using sms. Introduce payment to a none member - System sends a notice (e-mail/sms) asking the receiver to join to get the money.
• PAYMENT HISTORY -- Payments sent and received and Bills Paid and Received
• EDIT PROFILE
new • EDIT IDENTIFICATION - customer to add info that can be verified such as passport photo
• EDIT PASSWORD
• CREDIT CARD
• BANK DETAILS
new • MESSAGES - allow all members to send messages to one another
new • CUSTOMER SERVICE – Integrate to Help Center Live
Transaction Mechanism
Member to Member transfers - Value is immediate.
Member to Merchant - Value is delayed as defined by administrator from 1 to 30 days
Can be released in batches with a percentage assigned to each batch e.g 5 batches 10/5, 20/10 = 10% of amount has value date in 5 days, 20% in 10 days another example 100/30 = 100% in 30 days.
Merchant will see payment and available days.
USER MENU
• DEPOSIT MONEY – Bank Account or Registered card, e-Cheque etc or bank teller No.
• SEND PAYMENT – E-mail, User Name, Mobile Number, Card
• MASS PAYMENTS – Same
• SEND REQUEST - Same
• WITHDRAW MONEY – Cheque, Wire, Cash at bank, Agent – give details
• ESCROW – Same add tracking window where seller can update shipping information, instead of sending e-mail.
• USE AGENT – when money is sent this way it is notified to receiver and he assigns code and then designates an agent from list, he goes to agent and enters code to collect , (works like Western Union, agent payment) *1
• PROGRAM DETAILS
• YOUR DOWNLINE
• ADVERTISING
• MEMBER DIRECTORY – Username/Full Name/City/State/Country
Provide support for online debit so that merchant can send data string for debit see format so that host can authorize transactions without logging on and transaction is posted to merchants account
Add New Process
Method for transferring money to someone that does not have a valid e-mail or mobile number on the system
Money sent to someone that does not exist should function like escrow.
It is stored under Pending transactions until released.
Under Payments window show “Pending” above Escrow.
Beneficiary will get an email message or sms messaging, informing them that they have received money from “full name”, they are then asked to log on to receive the money. they are required to register to get the money.
Register to get the money
When they register and put in the correct mobile number, they will see the transactions sent before they registered as “Pending” under payments. All they have to do is click button “Accept”, when they do, an e-mail is sent to the Sender saying that Recipient has signed up and is ready to release the money. Sender should go to pending transactions and confirm and the money is then available in the account of the Recipient. This is to verify the receiver
SMS message cannot be more than 160 characters so transaction and message must be limited to this unlike e-mail payment
When information is sent, system uses mobile gateway service to deliver message to the mobile number, when the phone owner receives it, it comes in the format
"Sender Username" has just sent you "Amount" to receive the money log into XXX and enter your username and password. If you do not have one, register to receive the money.
Comments
Because SMS messages are not free, we will charge a fee to send each sms message payable by the sender, so sender must have enough money for the transaction and the message. See [login to view URL] as preferred sms gateway.
Admin
Admin wants to restrict its services to monitoring so it will have additional reporting that shows a global view
Admin will be able to define agents
Agents will in turn be able to define users
In Admin, admin will be able to add banks by bank id and when a customer adds a bank that is in the bank list, system auto sends an e-mail with verification form – Bank verification. Once form is approved by bank it sets customer status to verified by bank and allows for debits and credits which will be accessible through the bank module