diff --git a/.coverage b/.coverage
new file mode 100644
index 0000000..7083ad2
Binary files /dev/null and b/.coverage differ
diff --git a/.env b/.env
new file mode 100644
index 0000000..55fd343
--- /dev/null
+++ b/.env
@@ -0,0 +1,100 @@
+# AI4Org Environment Configuration
+# Copy this file to .env and update with your actual values
+
+# ===========================
+# Security Configuration
+# ===========================
+# Admin PIN for accessing admin dashboard (CHANGE THIS!)
+ADMIN_PIN=9999
+
+# ===========================
+# Model Configuration
+# ===========================
+# Generator model (TinyLlama or other HuggingFace model)
+GEN_MODEL=TinyLlama/TinyLlama-1.1B-Chat-v1.0
+
+# Discriminator model
+DISC_MODEL=distilbert-base-uncased
+
+# Sentence transformer for embeddings
+EMBEDDING_MODEL=sentence-transformers/all-MiniLM-L6-v2
+
+# ===========================
+# Device Configuration
+# ===========================
+# Device to use: cuda, cpu, or auto (auto-detect)
+DEVICE=auto
+
+# Specific GPU devices (comma-separated, e.g., "0,1")
+CUDA_VISIBLE_DEVICES=0
+
+# PyTorch CUDA memory configuration
+PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True
+
+# Disable tokenizer parallelism warnings
+TOKENIZERS_PARALLELISM=false
+
+# ===========================
+# Data Paths
+# ===========================
+# Path to corpus file
+CORPUS_PATH=data/processed/corpus.txt
+
+# Path to QA pairs
+QA_PATH=data/qa/qa.json
+
+# Path to raw data directory
+RAW_DATA_DIR=data/raw
+
+# Path to save trained models
+SAVE_DIR=saved_models_improved
+
+# ===========================
+# Training Configuration
+# ===========================
+# Supervised Fine-Tuning
+SFT_EPOCHS=4
+SFT_BATCH=1
+SFT_LR=3e-5
+
+# Discriminator Training
+DISC_EPOCHS=4
+DISC_BATCH=2  # Reduced from 8 to 2
+DISC_LR=2e-5
+
+# Reinforcement Learning
+RL_EPOCHS=4
+MC_ROLLOUTS=6
+GEN_LR=1e-5
+
+# ===========================
+# Inference Configuration
+# ===========================
+# Maximum tokens to generate
+MAX_GEN_TOKENS=64
+
+# Minimum tokens to generate
+MIN_GEN_TOKENS=10
+
+# Number of documents to retrieve for RAG
+TOP_K=3
+
+# ===========================
+# Frontend Configuration
+# ===========================
+# Frontend window dimensions
+WINDOW_WIDTH=1400
+WINDOW_HEIGHT=900
+
+# Minimum window size
+MIN_WIDTH=800
+MIN_HEIGHT=600
+
+# ===========================
+# Logging Configuration
+# ===========================
+# Log level: DEBUG, INFO, WARNING, ERROR, CRITICAL
+LOG_LEVEL=INFO
+
+# Log file path
+LOG_FILE=logs/ai4org.log
diff --git a/.env.example b/.env.example
new file mode 100644
index 0000000..9256805
--- /dev/null
+++ b/.env.example
@@ -0,0 +1,100 @@
+# AI4Org Environment Configuration
+# Copy this file to .env and update with your actual values
+
+# ===========================
+# Security Configuration
+# ===========================
+# Admin PIN for accessing admin dashboard (CHANGE THIS!)
+ADMIN_PIN=9999
+
+# ===========================
+# Model Configuration
+# ===========================
+# Generator model (TinyLlama or other HuggingFace model)
+GEN_MODEL=TinyLlama/TinyLlama-1.1B-Chat-v1.0
+
+# Discriminator model
+DISC_MODEL=distilbert-base-uncased
+
+# Sentence transformer for embeddings
+EMBEDDING_MODEL=sentence-transformers/all-MiniLM-L6-v2
+
+# ===========================
+# Device Configuration
+# ===========================
+# Device to use: cuda, cpu, or auto (auto-detect)
+DEVICE=auto
+
+# Specific GPU devices (comma-separated, e.g., "0,1")
+CUDA_VISIBLE_DEVICES=0
+
+# PyTorch CUDA memory configuration
+PYTORCH_CUDA_ALLOC_CONF=expandable_segments:true
+
+# Disable tokenizer parallelism warnings
+TOKENIZERS_PARALLELISM=false
+
+# ===========================
+# Data Paths
+# ===========================
+# Path to corpus file
+CORPUS_PATH=data/processed/corpus.txt
+
+# Path to QA pairs
+QA_PATH=data/qa/qa.json
+
+# Path to raw data directory
+RAW_DATA_DIR=data/raw
+
+# Path to save trained models
+SAVE_DIR=saved_models_improved
+
+# ===========================
+# Training Configuration
+# ===========================
+# Supervised Fine-Tuning
+SFT_EPOCHS=4
+SFT_BATCH=1
+SFT_LR=3e-5
+
+# Discriminator Training
+DISC_EPOCHS=4
+DISC_BATCH=8
+DISC_LR=2e-5
+
+# Reinforcement Learning
+RL_EPOCHS=4
+MC_ROLLOUTS=6
+GEN_LR=1e-5
+
+# ===========================
+# Inference Configuration
+# ===========================
+# Maximum tokens to generate
+MAX_GEN_TOKENS=64
+
+# Minimum tokens to generate
+MIN_GEN_TOKENS=10
+
+# Number of documents to retrieve for RAG
+TOP_K=3
+
+# ===========================
+# Frontend Configuration
+# ===========================
+# Frontend window dimensions
+WINDOW_WIDTH=1400
+WINDOW_HEIGHT=900
+
+# Minimum window size
+MIN_WIDTH=800
+MIN_HEIGHT=600
+
+# ===========================
+# Logging Configuration
+# ===========================
+# Log level: DEBUG, INFO, WARNING, ERROR, CRITICAL
+LOG_LEVEL=INFO
+
+# Log file path
+LOG_FILE=logs/ai4org.log
diff --git a/.flake8 b/.flake8
new file mode 100644
index 0000000..1173d7e
--- /dev/null
+++ b/.flake8
@@ -0,0 +1,4 @@
+[flake8]
+max-line-length = 88
+extend-ignore = E203, E501
+exclude = .git,__pycache__,docs/source/conf.py,old,build,dist
diff --git a/.github/workflows/pre-commit.yml b/.github/workflows/pre-commit.yml
new file mode 100644
index 0000000..0b73acf
--- /dev/null
+++ b/.github/workflows/pre-commit.yml
@@ -0,0 +1,17 @@
+name: pre-commit
+
+on:
+  push:
+    branches: [main, master]
+  pull_request:
+    branches: [main, master]
+
+jobs:
+  pre-commit:
+    runs-on: ubuntu-latest
+    steps:
+    - uses: actions/checkout@v3
+    - uses: actions/setup-python@v3
+      with:
+        python-version: '3.10'
+    - uses: pre-commit/action@v3.0.1
diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
new file mode 100644
index 0000000..9eee47d
--- /dev/null
+++ b/.github/workflows/tests.yml
@@ -0,0 +1,23 @@
+name: tests
+
+on:
+  push:
+    branches: [main, master]
+  pull_request:
+    branches: [main, master]
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+    - uses: actions/checkout@v3
+    - uses: actions/setup-python@v3
+      with:
+        python-version: '3.10'
+    - name: Install dependencies
+      run: |
+        python -m pip install --upgrade pip
+        pip install -r requirements.txt
+        pip install pytest
+    - name: Run tests
+      run: pytest
diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
new file mode 100644
index 0000000..a8a949a
--- /dev/null
+++ b/.pre-commit-config.yaml
@@ -0,0 +1,45 @@
+repos:
+-   repo: https://github.com/pre-commit/pre-commit-hooks
+    rev: v6.0.0
+    hooks:
+    -   id: trailing-whitespace
+    -   id: end-of-file-fixer
+    -   id: check-yaml
+    -   id: check-added-large-files
+
+-   repo: https://github.com/psf/black
+    rev: 25.12.0
+    hooks:
+    -   id: black
+
+-   repo: https://github.com/pycqa/isort
+    rev: 7.0.0
+    hooks:
+    -   id: isort
+
+-   repo: https://github.com/PyCQA/autoflake
+    rev: v2.2.0
+    hooks:
+    -   id: autoflake
+        args: [--remove-all-unused-imports, --in-place]
+
+-   repo: https://github.com/pycqa/flake8
+    rev: 7.3.0
+    hooks:
+    -   id: flake8
+        additional_dependencies: [flake8-bugbear]
+
+-   repo: https://github.com/pre-commit/mirrors-mypy
+    rev: v1.19.1
+    hooks:
+    -   id: mypy
+        additional_dependencies: [types-PyYAML]
+        args: [--ignore-missing-imports]
+
+-   repo: local
+    hooks:
+    -   id: custom-hook
+        name: Custom Hook
+        entry: python3 pre_commit_hooks/placeholder.py
+        language: system
+        types: [python]
diff --git a/.vscode/settings.json b/.vscode/settings.json
index b9441e0..f7fc2b3 100644
--- a/.vscode/settings.json
+++ b/.vscode/settings.json
@@ -5,4 +5,4 @@
         "./ ",
         "./ "
     ]
-}
\ No newline at end of file
+}
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 0000000..8e90e29
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,612 @@
+# Contributing to AI4Org
+
+Thank you for your interest in contributing to **AI4Org**! We welcome contributions from the community to help advance hallucination reduction in Large Language Models. Whether you're fixing bugs, adding features, improving documentation, or proposing new ideas, your contributions are valued.
+
+---
+
+## 📋 Table of Contents
+
+- [Code of Conduct](#-code-of-conduct)
+- [How Can I Contribute?](#-how-can-i-contribute)
+- [Getting Started](#-getting-started)
+- [Development Workflow](#-development-workflow)
+- [Code Style Guidelines](#-code-style-guidelines)
+- [Testing Requirements](#-testing-requirements)
+- [Pull Request Process](#-pull-request-process)
+- [Issue Guidelines](#-issue-guidelines)
+- [Community](#-community)
+
+---
+
+## 🤝 Code of Conduct
+
+By participating in this project, you agree to maintain a respectful, inclusive, and collaborative environment. We are committed to providing a welcoming experience for everyone, regardless of background or experience level.
+
+### Our Standards
+
+- ✅ Be respectful and constructive in discussions
+- ✅ Welcome newcomers and help them get started
+- ✅ Focus on what is best for the community
+- ✅ Show empathy towards other community members
+- ❌ No harassment, trolling, or discriminatory language
+- ❌ No spam or off-topic discussions
+
+---
+
+## 💡 How Can I Contribute?
+
+There are many ways to contribute to AI4Org:
+
+### 1. 🐛 Report Bugs
+
+Found a bug? Help us fix it by:
+- Checking if the issue already exists in [GitHub Issues](https://github.com/merledu/ai4org/issues)
+- Creating a detailed bug report with:
+  - Clear description of the problem
+  - Steps to reproduce
+  - Expected vs actual behavior
+  - Environment details (OS, Python version, GPU)
+  - Error messages and stack traces
+
+### 2. 💡 Suggest Features
+
+Have an idea for improvement?
+- Open a feature request issue
+- Describe the problem it solves
+- Explain your proposed solution
+- Discuss alternatives you've considered
+
+### 3. 📝 Improve Documentation
+
+Documentation is crucial! You can:
+- Fix typos or clarify existing docs
+- Add examples and tutorials
+- Improve code comments and docstrings
+- Create guides for specific use cases
+- Translate documentation
+
+### 4. 🧪 Add Tests
+
+Help improve code coverage:
+- Write unit tests for untested modules
+- Add integration tests for workflows
+- Create regression tests for fixed bugs
+- Improve test documentation
+
+### 5. 🚀 Implement Features
+
+Ready to code? Areas where we need help:
+
+#### Hallucination Reduction Module
+- Improve discriminator architectures
+- Experiment with different RL algorithms
+- Optimize training efficiency
+- Add support for larger models
+
+#### Data Generation Pipeline
+- Support for more document formats
+- Improve Q&A quality validation
+- Add multilingual support
+- Enhance deduplication algorithms
+
+#### Frontend Application
+- UI/UX improvements
+- New visualization features
+- Performance optimizations
+- Cross-platform compatibility fixes
+
+#### Infrastructure
+- CI/CD pipeline improvements
+- Docker containerization
+- Deployment automation
+- Monitoring and logging
+
+---
+
+## 🚀 Getting Started
+
+### 1. Fork and Clone
+
+```bash
+# Fork the repository on GitHub, then clone your fork
+git clone https://github.com/YOUR-USERNAME/ai4org.git
+cd ai4org
+
+# Add upstream remote
+git remote add upstream https://github.com/merledu/ai4org.git
+```
+
+### 2. Set Up Development Environment
+
+```bash
+# Create and activate virtual environment
+python3 -m venv .venv
+source .venv/bin/activate  # On Windows: .venv\Scripts\activate
+
+# Install dependencies
+pip install -r requirements.txt
+
+# Install development dependencies
+pip install pytest pytest-cov black flake8 mypy
+```
+
+### 3. Verify Installation
+
+```bash
+# Run tests to ensure everything works
+pytest tests/
+
+# Check code style
+flake8 hallucination_reduction/ --max-line-length=120
+```
+
+### 4. Create a Branch
+
+```bash
+# Always create a new branch for your work
+git checkout -b feature/your-feature-name
+
+# Branch naming conventions:
+# - feature/add-new-discriminator
+# - fix/training-memory-leak
+# - docs/improve-readme
+# - test/add-rl-tests
+```
+
+---
+
+## 🔄 Development Workflow
+
+### 1. Keep Your Fork Updated
+
+```bash
+# Fetch upstream changes
+git fetch upstream
+
+# Merge upstream changes into your main branch
+git checkout main
+git merge upstream/main
+
+# Rebase your feature branch
+git checkout feature/your-feature-name
+git rebase main
+```
+
+### 2. Make Your Changes
+
+- Write clean, readable code
+- Follow the code style guidelines
+- Add tests for new functionality
+- Update documentation as needed
+- Commit frequently with clear messages
+
+### 3. Commit Messages
+
+Follow the [Conventional Commits](https://www.conventionalcommits.org/) format:
+
+```bash
+# Format: <type>(<scope>): <description>
+
+# Examples:
+git commit -m "feat(discriminator): add attention mechanism to factuality classifier"
+git commit -m "fix(rl): resolve NaN loss during REINFORCE training"
+git commit -m "docs(readme): add installation troubleshooting section"
+git commit -m "test(generator): add unit tests for SFT fine-tuning"
+git commit -m "refactor(retriever): optimize embedding computation"
+```
+
+**Commit Types:**
+- `feat`: New feature
+- `fix`: Bug fix
+- `docs`: Documentation changes
+- `test`: Adding or updating tests
+- `refactor`: Code refactoring
+- `perf`: Performance improvements
+- `style`: Code style changes (formatting)
+- `chore`: Maintenance tasks
+
+---
+
+## 📐 Code Style Guidelines
+
+### Python Code Standards
+
+We follow **PEP 8** with some project-specific conventions:
+
+#### 1. Formatting
+
+```python
+# ✅ Good: Clear, readable formatting
+def train_discriminator(
+    model: nn.Module,
+    tokenizer: AutoTokenizer,
+    texts: List[str],
+    labels: List[int],
+    device: str = "cuda",
+    epochs: int = 4,
+    batch_size: int = 8,
+    lr: float = 2e-5
+) -> nn.Module:
+    """
+    Train a discriminator model on text classification task.
+
+    Args:
+        model: The discriminator model to train
+        tokenizer: Tokenizer for text encoding
+        texts: List of training texts
+        labels: List of binary labels (0 or 1)
+        device: Device to train on ('cuda' or 'cpu')
+        epochs: Number of training epochs
+        batch_size: Batch size for training
+        lr: Learning rate
+
+    Returns:
+        Trained model
+    """
+    optimizer = torch.optim.AdamW(model.parameters(), lr=lr)
+    # ... implementation
+    return model
+
+
+# ❌ Bad: No type hints, no docstring, unclear parameters
+def train(m, t, x, y, d="cuda"):
+    opt = torch.optim.AdamW(m.parameters(), lr=0.00002)
+    # ... implementation
+    return m
+```
+
+#### 2. Naming Conventions
+
+```python
+# ✅ Good: Descriptive names
+hallucination_rate = 0.123
+factuality_discriminator = load_discriminator("distilbert-base-uncased")
+MAX_GENERATION_TOKENS = 64
+
+# ❌ Bad: Unclear abbreviations
+hr = 0.123
+fd = load_discriminator("distilbert-base-uncased")
+mgt = 64
+```
+
+#### 3. Docstrings
+
+Use Google-style docstrings:
+
+```python
+def retrieve_relevant_chunks(
+    query: str,
+    embedder: SentenceTransformer,
+    corpus_embeddings: np.ndarray,
+    docs: List[str],
+    top_k: int = 3
+) -> List[str]:
+    """
+    Retrieve the most relevant document chunks for a query.
+
+    Uses cosine similarity between query and corpus embeddings to find
+    the top-k most relevant documents.
+
+    Args:
+        query: The user's question or search query
+        embedder: Sentence transformer model for encoding
+        corpus_embeddings: Pre-computed embeddings for all documents
+        docs: List of document strings
+        top_k: Number of documents to retrieve
+
+    Returns:
+        List of the top-k most relevant document strings
+
+    Example:
+        >>> embedder = SentenceTransformer("all-MiniLM-L6-v2")
+        >>> docs = ["Policy document 1", "Policy document 2"]
+        >>> embeddings = embedder.encode(docs)
+        >>> results = retrieve_relevant_chunks(
+        ...     "What is the policy?", embedder, embeddings, docs
+        ... )
+    """
+    query_emb = embedder.encode([query], convert_to_numpy=True)
+    sims = cosine_similarity(query_emb, corpus_embeddings)[0]
+    top_indices = sims.argsort()[-top_k:][::-1]
+    return [docs[i] for i in top_indices]
+```
+
+#### 4. Imports
+
+```python
+# ✅ Good: Organized imports
+# Standard library
+import os
+import sys
+from typing import List, Dict, Tuple, Optional
+
+# Third-party
+import torch
+import numpy as np
+from transformers import AutoTokenizer, AutoModelForCausalLM
+
+# Local
+from .config import DEVICE, GEN_MODEL
+from .retriever import SimpleRetriever
+
+# ❌ Bad: Unorganized, wildcard imports
+from transformers import *
+import torch, numpy, os, sys
+from .config import *
+```
+
+### Code Formatting Tools
+
+```bash
+# Format code with Black
+black hallucination_reduction/ --line-length 120
+
+# Check style with flake8
+flake8 hallucination_reduction/ --max-line-length=120 --ignore=E203,W503
+
+# Type checking with mypy
+mypy hallucination_reduction/ --ignore-missing-imports
+```
+
+---
+
+## 🧪 Testing Requirements
+
+### Running Tests
+
+```bash
+# Run all tests
+pytest tests/
+
+# Run specific test file
+pytest tests/unit/test_discriminator.py
+
+# Run with coverage
+pytest --cov=hallucination_reduction --cov-report=html tests/
+
+# Run tests matching a pattern
+pytest -k "test_discriminator" tests/
+```
+
+### Writing Tests
+
+#### Unit Tests
+
+```python
+# tests/unit/test_retriever.py
+import pytest
+from hallucination_reduction.retriever import SimpleRetriever
+
+
+def test_retriever_initialization():
+    """Test that retriever initializes with documents."""
+    docs = ["Document 1", "Document 2", "Document 3"]
+    retriever = SimpleRetriever(docs)
+    assert retriever.docs == docs
+    assert len(retriever.docs) == 3
+
+
+def test_retriever_empty_docs():
+    """Test that retriever handles empty document list."""
+    with pytest.raises(ValueError):
+        SimpleRetriever([])
+
+
+@pytest.mark.parametrize("top_k", [1, 3, 5])
+def test_retriever_top_k(top_k):
+    """Test retrieval with different top_k values."""
+    docs = [f"Document {i}" for i in range(10)]
+    retriever = SimpleRetriever(docs)
+    results = retriever.retrieve("test query", top_k=top_k)
+    assert len(results) == top_k
+```
+
+#### Integration Tests
+
+```python
+# tests/integration/test_training_pipeline.py
+import torch
+from hallucination_reduction.main import main
+
+
+def test_full_training_pipeline():
+    """Test complete training pipeline runs without errors."""
+    # This test may take several minutes
+    try:
+        main()
+        assert True
+    except Exception as e:
+        pytest.fail(f"Training pipeline failed: {e}")
+```
+
+### Test Coverage Requirements
+
+- **New features**: Must include tests covering main functionality
+- **Bug fixes**: Should include regression tests
+- **Minimum coverage**: Aim for 70%+ coverage on new code
+- **Critical paths**: 90%+ coverage for core training/inference logic
+
+---
+
+## 🔍 Pull Request Process
+
+### Before Submitting
+
+- [ ] Code follows style guidelines
+- [ ] All tests pass locally
+- [ ] New tests added for new features
+- [ ] Documentation updated
+- [ ] Commit messages follow conventions
+- [ ] Branch is up to date with main
+
+### Submitting Your PR
+
+1. **Push your branch**
+   ```bash
+   git push origin feature/your-feature-name
+   ```
+
+2. **Open Pull Request on GitHub**
+   - Use a clear, descriptive title
+   - Fill out the PR template completely
+   - Link related issues (e.g., "Fixes #123")
+   - Add screenshots/videos for UI changes
+
+3. **PR Description Template**
+   ```markdown
+   ## Description
+   Brief description of what this PR does.
+
+   ## Type of Change
+   - [ ] Bug fix (non-breaking change fixing an issue)
+   - [ ] New feature (non-breaking change adding functionality)
+   - [ ] Breaking change (fix or feature causing existing functionality to break)
+   - [ ] Documentation update
+
+   ## Changes Made
+   - Change 1
+   - Change 2
+   - Change 3
+
+   ## Testing
+   - [ ] Unit tests added/updated
+   - [ ] Integration tests added/updated
+   - [ ] Manual testing performed
+
+   ## Screenshots (if applicable)
+
+   ## Related Issues
+   Fixes #(issue number)
+   ```
+
+### Review Process
+
+1. **Automated Checks**: CI/CD will run tests and linting
+2. **Code Review**: Maintainers will review your code
+3. **Feedback**: Address any requested changes
+4. **Approval**: Once approved, your PR will be merged
+
+### After Merge
+
+- Delete your feature branch
+- Update your local main branch
+- Celebrate! 🎉
+
+---
+
+## 📋 Issue Guidelines
+
+### Creating Issues
+
+Use the appropriate issue template:
+
+#### Bug Report Template
+
+```markdown
+**Describe the bug**
+A clear description of what the bug is.
+
+**To Reproduce**
+Steps to reproduce the behavior:
+1. Run command '...'
+2. With configuration '...'
+3. See error
+
+**Expected behavior**
+What you expected to happen.
+
+**Actual behavior**
+What actually happened.
+
+**Environment:**
+- OS: [e.g., Ubuntu 22.04]
+- Python version: [e.g., 3.10.8]
+- PyTorch version: [e.g., 2.0.1]
+- CUDA version: [e.g., 11.8]
+- GPU: [e.g., RTX 3090]
+
+**Error messages**
+```
+Paste error messages here
+```
+
+**Additional context**
+Any other relevant information.
+```
+
+#### Feature Request Template
+
+```markdown
+**Is your feature request related to a problem?**
+A clear description of the problem.
+
+**Describe the solution you'd like**
+What you want to happen.
+
+**Describe alternatives you've considered**
+Other approaches you've thought about.
+
+**Additional context**
+Any other relevant information, mockups, or examples.
+```
+
+### Issue Labels
+
+- `bug`: Something isn't working
+- `enhancement`: New feature or request
+- `documentation`: Documentation improvements
+- `good first issue`: Good for newcomers
+- `help wanted`: Extra attention needed
+- `question`: Further information requested
+- `wontfix`: This will not be worked on
+
+---
+
+## 🌟 Community
+
+### Getting Help
+
+- **GitHub Discussions**: Ask questions and share ideas
+- **GitHub Issues**: Report bugs and request features
+- **Documentation**: Check the [README](README.md) and code comments
+
+### Recognition
+
+Contributors will be:
+- Listed in the project's contributors page
+- Mentioned in release notes for significant contributions
+- Invited to join the core team for sustained contributions
+
+### Stay Updated
+
+- Watch the repository for updates
+- Star the project to show support
+- Follow [MeRL-EDU](https://github.com/merledu) for related projects
+
+---
+
+## 📚 Additional Resources
+
+- [README.md](README.md) - Project overview and setup
+- [Python PEP 8 Style Guide](https://pep8.org/)
+- [Conventional Commits](https://www.conventionalcommits.org/)
+- [GitHub Flow](https://guides.github.com/introduction/flow/)
+- [Writing Good Commit Messages](https://chris.beams.io/posts/git-commit/)
+
+---
+
+## 🙏 Thank You!
+
+Your contributions make AI4Org better for everyone. Whether you're fixing a typo or implementing a major feature, every contribution matters. We appreciate your time and effort!
+
+**Happy Contributing! 🚀**
+
+---
+
+<div align="center">
+
+**Questions?** Open a [GitHub Discussion](https://github.com/merledu/ai4org/discussions)
+
+**Found a bug?** Create an [Issue](https://github.com/merledu/ai4org/issues)
+
+</div>
diff --git a/Dockerfile b/Dockerfile
new file mode 100644
index 0000000..fc7ec56
--- /dev/null
+++ b/Dockerfile
@@ -0,0 +1,20 @@
+# Use an official Python runtime as a parent image
+FROM python:3.10-slim
+
+# Set the working directory in the container
+WORKDIR /app
+
+# Copy the requirements file into the container at /app
+COPY requirements.txt .
+
+# Install any needed packages specified in requirements.txt
+RUN pip install --no-cache-dir -r requirements.txt
+
+# Copy the rest of the application code
+COPY . .
+
+# Set environment variables
+ENV PYTHONUNBUFFERED=1
+
+# Command to run the application (adjust as needed, e.g., running the main script)
+CMD ["python", "-m", "hallucination_reduction.main"]
diff --git a/LICENSE b/LICENSE
new file mode 100644
index 0000000..f288702
--- /dev/null
+++ b/LICENSE
@@ -0,0 +1,674 @@
+                    GNU GENERAL PUBLIC LICENSE
+                       Version 3, 29 June 2007
+
+ Copyright (C) 2007 Free Software Foundation, Inc. <https://fsf.org/>
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+                            Preamble
+
+  The GNU General Public License is a free, copyleft license for
+software and other kinds of works.
+
+  The licenses for most software and other practical works are designed
+to take away your freedom to share and change the works.  By contrast,
+the GNU General Public License is intended to guarantee your freedom to
+share and change all versions of a program--to make sure it remains free
+software for all its users.  We, the Free Software Foundation, use the
+GNU General Public License for most of our software; it applies also to
+any other work released this way by its authors.  You can apply it to
+your programs, too.
+
+  When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+them if you wish), that you receive source code or can get it if you
+want it, that you can change the software or use pieces of it in new
+free programs, and that you know you can do these things.
+
+  To protect your rights, we need to prevent others from denying you
+these rights or asking you to surrender the rights.  Therefore, you have
+certain responsibilities if you distribute copies of the software, or if
+you modify it: responsibilities to respect the freedom of others.
+
+  For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must pass on to the recipients the same
+freedoms that you received.  You must make sure that they, too, receive
+or can get the source code.  And you must show them these terms so they
+know their rights.
+
+  Developers that use the GNU GPL protect your rights with two steps:
+(1) assert copyright on the software, and (2) offer you this License
+giving you legal permission to copy, distribute and/or modify it.
+
+  For the developers' and authors' protection, the GPL clearly explains
+that there is no warranty for this free software.  For both users' and
+authors' sake, the GPL requires that modified versions be marked as
+changed, so that their problems will not be attributed erroneously to
+authors of previous versions.
+
+  Some devices are designed to deny users access to install or run
+modified versions of the software inside them, although the manufacturer
+can do so.  This is fundamentally incompatible with the aim of
+protecting users' freedom to change the software.  The systematic
+pattern of such abuse occurs in the area of products for individuals to
+use, which is precisely where it is most unacceptable.  Therefore, we
+have designed this version of the GPL to prohibit the practice for those
+products.  If such problems arise substantially in other domains, we
+stand ready to extend this provision to those domains in future versions
+of the GPL, as needed to protect the freedom of users.
+
+  Finally, every program is threatened constantly by software patents.
+States should not allow patents to restrict development and use of
+software on general-purpose computers, but in those that do, we wish to
+avoid the special danger that patents applied to a free program could
+make it effectively proprietary.  To prevent this, the GPL assures that
+patents cannot be used to render the program non-free.
+
+  The precise terms and conditions for copying, distribution and
+modification follow.
+
+                       TERMS AND CONDITIONS
+
+  0. Definitions.
+
+  "This License" refers to version 3 of the GNU General Public License.
+
+  "Copyright" also means copyright-like laws that apply to other kinds of
+works, such as semiconductor masks.
+
+  "The Program" refers to any copyrightable work licensed under this
+License.  Each licensee is addressed as "you".  "Licensees" and
+"recipients" may be individuals or organizations.
+
+  To "modify" a work means to copy from or adapt all or part of the work
+in a fashion requiring copyright permission, other than the making of an
+exact copy.  The resulting work is called a "modified version" of the
+earlier work or a work "based on" the earlier work.
+
+  A "covered work" means either the unmodified Program or a work based
+on the Program.
+
+  To "propagate" a work means to do anything with it that, without
+permission, would make you directly or secondarily liable for
+infringement under applicable copyright law, except executing it on a
+computer or modifying a private copy.  Propagation includes copying,
+distribution (with or without modification), making available to the
+public, and in some countries other activities as well.
+
+  To "convey" a work means any kind of propagation that enables other
+parties to make or receive copies.  Mere interaction with a user through
+a computer network, with no transfer of a copy, is not conveying.
+
+  An interactive user interface displays "Appropriate Legal Notices"
+to the extent that it includes a convenient and prominently visible
+feature that (1) displays an appropriate copyright notice, and (2)
+tells the user that there is no warranty for the work (except to the
+extent that warranties are provided), that licensees may convey the
+work under this License, and how to view a copy of this License.  If
+the interface presents a list of user commands or options, such as a
+menu, a prominent item in the list meets this criterion.
+
+  1. Source Code.
+
+  The "source code" for a work means the preferred form of the work
+for making modifications to it.  "Object code" means any non-source
+form of a work.
+
+  A "Standard Interface" means an interface that either is an official
+standard defined by a recognized standards body, or, in the case of
+interfaces specified for a particular programming language, one that
+is widely used among developers working in that language.
+
+  The "System Libraries" of an executable work include anything, other
+than the work as a whole, that (a) is included in the normal form of
+packaging a Major Component, but which is not part of that Major
+Component, and (b) serves only to enable use of the work with that
+Major Component, or to implement a Standard Interface for which an
+implementation is available to the public in source code form.  A
+"Major Component", in this context, means a major essential component
+(kernel, window system, and so on) of the specific operating system
+(if any) on which the executable work runs, or a compiler used to
+produce the work, or an object code interpreter used to run it.
+
+  The "Corresponding Source" for a work in object code form means all
+the source code needed to generate, install, and (for an executable
+work) run the object code and to modify the work, including scripts to
+control those activities.  However, it does not include the work's
+System Libraries, or general-purpose tools or generally available free
+programs which are used unmodified in performing those activities but
+which are not part of the work.  For example, Corresponding Source
+includes interface definition files associated with source files for
+the work, and the source code for shared libraries and dynamically
+linked subprograms that the work is specifically designed to require,
+such as by intimate data communication or control flow between those
+subprograms and other parts of the work.
+
+  The Corresponding Source need not include anything that users
+can regenerate automatically from other parts of the Corresponding
+Source.
+
+  The Corresponding Source for a work in source code form is that
+same work.
+
+  2. Basic Permissions.
+
+  All rights granted under this License are granted for the term of
+copyright on the Program, and are irrevocable provided the stated
+conditions are met.  This License explicitly affirms your unlimited
+permission to run the unmodified Program.  The output from running a
+covered work is covered by this License only if the output, given its
+content, constitutes a covered work.  This License acknowledges your
+rights of fair use or other equivalent, as provided by copyright law.
+
+  You may make, run and propagate covered works that you do not
+convey, without conditions so long as your license otherwise remains
+in force.  You may convey covered works to others for the sole purpose
+of having them make modifications exclusively for you, or provide you
+with facilities for running those works, provided that you comply with
+the terms of this License in conveying all material for which you do
+not control copyright.  Those thus making or running the covered works
+for you must do so exclusively on your behalf, under your direction
+and control, on terms that prohibit them from making any copies of
+your copyrighted material outside their relationship with you.
+
+  Conveying under any other circumstances is permitted solely under
+the conditions stated below.  Sublicensing is not allowed; section 10
+makes it unnecessary.
+
+  3. Protecting Users' Legal Rights From Anti-Circumvention Law.
+
+  No covered work shall be deemed part of an effective technological
+measure under any applicable law fulfilling obligations under article
+11 of the WIPO copyright treaty adopted on 20 December 1996, or
+similar laws prohibiting or restricting circumvention of such
+measures.
+
+  When you convey a covered work, you waive any legal power to forbid
+circumvention of technological measures to the extent such circumvention
+is effected by exercising rights under this License with respect to
+the covered work, and you disclaim any intention to limit operation or
+modification of the work as a means of enforcing, against the work's
+users, your or third parties' legal rights to forbid circumvention of
+technological measures.
+
+  4. Conveying Verbatim Copies.
+
+  You may convey verbatim copies of the Program's source code as you
+receive it, in any medium, provided that you conspicuously and
+appropriately publish on each copy an appropriate copyright notice;
+keep intact all notices stating that this License and any
+non-permissive terms added in accord with section 7 apply to the code;
+keep intact all notices of the absence of any warranty; and give all
+recipients a copy of this License along with the Program.
+
+  You may charge any price or no price for each copy that you convey,
+and you may offer support or warranty protection for a fee.
+
+  5. Conveying Modified Source Versions.
+
+  You may convey a work based on the Program, or the modifications to
+produce it from the Program, in the form of source code under the
+terms of section 4, provided that you also meet all of these conditions:
+
+    a) The work must carry prominent notices stating that you modified
+    it, and giving a relevant date.
+
+    b) The work must carry prominent notices stating that it is
+    released under this License and any conditions added under section
+    7.  This requirement modifies the requirement in section 4 to
+    "keep intact all notices".
+
+    c) You must license the entire work, as a whole, under this
+    License to anyone who comes into possession of a copy.  This
+    License will therefore apply, along with any applicable section 7
+    additional terms, to the whole of the work, and all its parts,
+    regardless of how they are packaged.  This License gives no
+    permission to license the work in any other way, but it does not
+    invalidate such permission if you have separately received it.
+
+    d) If the work has interactive user interfaces, each must display
+    Appropriate Legal Notices; however, if the Program has interactive
+    interfaces that do not display Appropriate Legal Notices, your
+    work need not make them do so.
+
+  A compilation of a covered work with other separate and independent
+works, which are not by their nature extensions of the covered work,
+and which are not combined with it such as to form a larger program,
+in or on a volume of a storage or distribution medium, is called an
+"aggregate" if the compilation and its resulting copyright are not
+used to limit the access or legal rights of the compilation's users
+beyond what the individual works permit.  Inclusion of a covered work
+in an aggregate does not cause this License to apply to the other
+parts of the aggregate.
+
+  6. Conveying Non-Source Forms.
+
+  You may convey a covered work in object code form under the terms
+of sections 4 and 5, provided that you also convey the
+machine-readable Corresponding Source under the terms of this License,
+in one of these ways:
+
+    a) Convey the object code in, or embodied in, a physical product
+    (including a physical distribution medium), accompanied by the
+    Corresponding Source fixed on a durable physical medium
+    customarily used for software interchange.
+
+    b) Convey the object code in, or embodied in, a physical product
+    (including a physical distribution medium), accompanied by a
+    written offer, valid for at least three years and valid for as
+    long as you offer spare parts or customer support for that product
+    model, to give anyone who possesses the object code either (1) a
+    copy of the Corresponding Source for all the software in the
+    product that is covered by this License, on a durable physical
+    medium customarily used for software interchange, for a price no
+    more than your reasonable cost of physically performing this
+    conveying of source, or (2) access to copy the
+    Corresponding Source from a network server at no charge.
+
+    c) Convey individual copies of the object code with a copy of the
+    written offer to provide the Corresponding Source.  This
+    alternative is allowed only occasionally and noncommercially, and
+    only if you received the object code with such an offer, in accord
+    with subsection 6b.
+
+    d) Convey the object code by offering access from a designated
+    place (gratis or for a charge), and offer equivalent access to the
+    Corresponding Source in the same way through the same place at no
+    further charge.  You need not require recipients to copy the
+    Corresponding Source along with the object code.  If the place to
+    copy the object code is a network server, the Corresponding Source
+    may be on a different server (operated by you or a third party)
+    that supports equivalent copying facilities, provided you maintain
+    clear directions next to the object code saying where to find the
+    Corresponding Source.  Regardless of what server hosts the
+    Corresponding Source, you remain obligated to ensure that it is
+    available for as long as needed to satisfy these requirements.
+
+    e) Convey the object code using peer-to-peer transmission, provided
+    you inform other peers where the object code and Corresponding
+    Source of the work are being offered to the general public at no
+    charge under subsection 6d.
+
+  A separable portion of the object code, whose source code is excluded
+from the Corresponding Source as a System Library, need not be
+included in conveying the object code work.
+
+  A "User Product" is either (1) a "consumer product", which means any
+tangible personal property which is normally used for personal, family,
+or household purposes, or (2) anything designed or sold for incorporation
+into a dwelling.  In determining whether a product is a consumer product,
+doubtful cases shall be resolved in favor of coverage.  For a particular
+product received by a particular user, "normally used" refers to a
+typical or common use of that class of product, regardless of the status
+of the particular user or of the way in which the particular user
+actually uses, or expects or is expected to use, the product.  A product
+is a consumer product regardless of whether the product has substantial
+commercial, industrial or non-consumer uses, unless such uses represent
+the only significant mode of use of the product.
+
+  "Installation Information" for a User Product means any methods,
+procedures, authorization keys, or other information required to install
+and execute modified versions of a covered work in that User Product from
+a modified version of its Corresponding Source.  The information must
+suffice to ensure that the continued functioning of the modified object
+code is in no case prevented or interfered with solely because
+modification has been made.
+
+  If you convey an object code work under this section in, or with, or
+specifically for use in, a User Product, and the conveying occurs as
+part of a transaction in which the right of possession and use of the
+User Product is transferred to the recipient in perpetuity or for a
+fixed term (regardless of how the transaction is characterized), the
+Corresponding Source conveyed under this section must be accompanied
+by the Installation Information.  But this requirement does not apply
+if neither you nor any third party retains the ability to install
+modified object code on the User Product (for example, the work has
+been installed in ROM).
+
+  The requirement to provide Installation Information does not include a
+requirement to continue to provide support service, warranty, or updates
+for a work that has been modified or installed by the recipient, or for
+the User Product in which it has been modified or installed.  Access to a
+network may be denied when the modification itself materially and
+adversely affects the operation of the network or violates the rules and
+protocols for communication across the network.
+
+  Corresponding Source conveyed, and Installation Information provided,
+in accord with this section must be in a format that is publicly
+documented (and with an implementation available to the public in
+source code form), and must require no special password or key for
+unpacking, reading or copying.
+
+  7. Additional Terms.
+
+  "Additional permissions" are terms that supplement the terms of this
+License by making exceptions from one or more of its conditions.
+Additional permissions that are applicable to the entire Program shall
+be treated as though they were included in this License, to the extent
+that they are valid under applicable law.  If additional permissions
+apply only to part of the Program, that part may be used separately
+under those permissions, but the entire Program remains governed by
+this License without regard to the additional permissions.
+
+  When you convey a copy of a covered work, you may at your option
+remove any additional permissions from that copy, or from any part of
+it.  (Additional permissions may be written to require their own
+removal in certain cases when you modify the work.)  You may place
+additional permissions on material, added by you to a covered work,
+for which you have or can give appropriate copyright permission.
+
+  Notwithstanding any other provision of this License, for material you
+add to a covered work, you may (if authorized by the copyright holders of
+that material) supplement the terms of this License with terms:
+
+    a) Disclaiming warranty or limiting liability differently from the
+    terms of sections 15 and 16 of this License; or
+
+    b) Requiring preservation of specified reasonable legal notices or
+    author attributions in that material or in the Appropriate Legal
+    Notices displayed by works containing it; or
+
+    c) Prohibiting misrepresentation of the origin of that material, or
+    requiring that modified versions of such material be marked in
+    reasonable ways as different from the original version; or
+
+    d) Limiting the use for publicity purposes of names of licensors or
+    authors of the material; or
+
+    e) Declining to grant rights under trademark law for use of some
+    trade names, trademarks, or service marks; or
+
+    f) Requiring indemnification of licensors and authors of that
+    material by anyone who conveys the material (or modified versions of
+    it) with contractual assumptions of liability to the recipient, for
+    any liability that these contractual assumptions directly impose on
+    those licensors and authors.
+
+  All other non-permissive additional terms are considered "further
+restrictions" within the meaning of section 10.  If the Program as you
+received it, or any part of it, contains a notice stating that it is
+governed by this License along with a term that is a further
+restriction, you may remove that term.  If a license document contains
+a further restriction but permits relicensing or conveying under this
+License, you may add to a covered work material governed by the terms
+of that license document, provided that the further restriction does
+not survive such relicensing or conveying.
+
+  If you add terms to a covered work in accord with this section, you
+must place, in the relevant source files, a statement of the
+additional terms that apply to those files, or a notice indicating
+where to find the applicable terms.
+
+  Additional terms, permissive or non-permissive, may be stated in the
+form of a separately written license, or stated as exceptions;
+the above requirements apply either way.
+
+  8. Termination.
+
+  You may not propagate or modify a covered work except as expressly
+provided under this License.  Any attempt otherwise to propagate or
+modify it is void, and will automatically terminate your rights under
+this License (including any patent licenses granted under the third
+paragraph of section 11).
+
+  However, if you cease all violation of this License, then your
+license from a particular copyright holder is reinstated (a)
+provisionally, unless and until the copyright holder explicitly and
+finally terminates your license, and (b) permanently, if the copyright
+holder fails to notify you of the violation by some reasonable means
+prior to 60 days after the cessation.
+
+  Moreover, your license from a particular copyright holder is
+reinstated permanently if the copyright holder notifies you of the
+violation by some reasonable means, this is the first time you have
+received notice of violation of this License (for any work) from that
+copyright holder, and you cure the violation prior to 30 days after
+your receipt of the notice.
+
+  Termination of your rights under this section does not terminate the
+licenses of parties who have received copies or rights from you under
+this License.  If your rights have been terminated and not permanently
+reinstated, you do not qualify to receive new licenses for the same
+material under section 10.
+
+  9. Acceptance Not Required for Having Copies.
+
+  You are not required to accept this License in order to receive or
+run a copy of the Program.  Ancillary propagation of a covered work
+occurring solely as a consequence of using peer-to-peer transmission
+to receive a copy likewise does not require acceptance.  However,
+nothing other than this License grants you permission to propagate or
+modify any covered work.  These actions infringe copyright if you do
+not accept this License.  Therefore, by modifying or propagating a
+covered work, you indicate your acceptance of this License to do so.
+
+  10. Automatic Licensing of Downstream Recipients.
+
+  Each time you convey a covered work, the recipient automatically
+receives a license from the original licensors, to run, modify and
+propagate that work, subject to this License.  You are not responsible
+for enforcing compliance by third parties with this License.
+
+  An "entity transaction" is a transaction transferring control of an
+organization, or substantially all assets of one, or subdividing an
+organization, or merging organizations.  If propagation of a covered
+work results from an entity transaction, each party to that
+transaction who receives a copy of the work also receives whatever
+licenses to the work the party's predecessor in interest had or could
+give under the previous paragraph, plus a right to possession of the
+Corresponding Source of the work from the predecessor in interest, if
+the predecessor has it or can get it with reasonable efforts.
+
+  You may not impose any further restrictions on the exercise of the
+rights granted or affirmed under this License.  For example, you may
+not impose a license fee, royalty, or other charge for exercise of
+rights granted under this License, and you may not initiate litigation
+(including a cross-claim or counterclaim in a lawsuit) alleging that
+any patent claim is infringed by making, using, selling, offering for
+sale, or importing the Program or any portion of it.
+
+  11. Patents.
+
+  A "contributor" is a copyright holder who authorizes use under this
+License of the Program or a work on which the Program is based.  The
+work thus licensed is called the contributor's "contributor version".
+
+  A contributor's "essential patent claims" are all patent claims
+owned or controlled by the contributor, whether already acquired or
+hereafter acquired, that would be infringed by some manner, permitted
+by this License, of making, using, or selling its contributor version,
+but do not include claims that would be infringed only as a
+consequence of further modification of the contributor version.  For
+purposes of this definition, "control" includes the right to grant
+patent sublicenses in a manner consistent with the requirements of
+this License.
+
+  Each contributor grants you a non-exclusive, worldwide, royalty-free
+patent license under the contributor's essential patent claims, to
+make, use, sell, offer for sale, import and otherwise run, modify and
+propagate the contents of its contributor version.
+
+  In the following three paragraphs, a "patent license" is any express
+agreement or commitment, however denominated, not to enforce a patent
+(such as an express permission to practice a patent or covenant not to
+sue for patent infringement).  To "grant" such a patent license to a
+party means to make such an agreement or commitment not to enforce a
+patent against the party.
+
+  If you convey a covered work, knowingly relying on a patent license,
+and the Corresponding Source of the work is not available for anyone
+to copy, free of charge and under the terms of this License, through a
+publicly available network server or other readily accessible means,
+then you must either (1) cause the Corresponding Source to be so
+available, or (2) arrange to deprive yourself of the benefit of the
+patent license for this particular work, or (3) arrange, in a manner
+consistent with the requirements of this License, to extend the patent
+license to downstream recipients.  "Knowingly relying" means you have
+actual knowledge that, but for the patent license, your conveying the
+covered work in a country, or your recipient's use of the covered work
+in a country, would infringe one or more identifiable patents in that
+country that you have reason to believe are valid.
+
+  If, pursuant to or in connection with a single transaction or
+arrangement, you convey, or propagate by procuring conveyance of, a
+covered work, and grant a patent license to some of the parties
+receiving the covered work authorizing them to use, propagate, modify
+or convey a specific copy of the covered work, then the patent license
+you grant is automatically extended to all recipients of the covered
+work and works based on it.
+
+  A patent license is "discriminatory" if it does not include within
+the scope of its coverage, prohibits the exercise of, or is
+conditioned on the non-exercise of one or more of the rights that are
+specifically granted under this License.  You may not convey a covered
+work if you are a party to an arrangement with a third party that is
+in the business of distributing software, under which you make payment
+to the third party based on the extent of your activity of conveying
+the work, and under which the third party grants, to any of the
+parties who would receive the covered work from you, a discriminatory
+patent license (a) in connection with copies of the covered work
+conveyed by you (or copies made from those copies), or (b) primarily
+for and in connection with specific products or compilations that
+contain the covered work, unless you entered into that arrangement,
+or that patent license was granted, prior to 28 March 2007.
+
+  Nothing in this License shall be construed as excluding or limiting
+any implied license or other defenses to infringement that may
+otherwise be available to you under applicable patent law.
+
+  12. No Surrender of Others' Freedom.
+
+  If conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License.  If you cannot convey a
+covered work so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you may
+not convey it at all.  For example, if you agree to terms that obligate you
+to collect a royalty for further conveying from those to whom you convey
+the Program, the only way you could satisfy both those terms and this
+License would be to refrain entirely from conveying the Program.
+
+  13. Use with the GNU Affero General Public License.
+
+  Notwithstanding any other provision of this License, you have
+permission to link or combine any covered work with a work licensed
+under version 3 of the GNU Affero General Public License into a single
+combined work, and to convey the resulting work.  The terms of this
+License will continue to apply to the part which is the covered work,
+but the special requirements of the GNU Affero General Public License,
+section 13, concerning interaction through a network will apply to the
+combination as such.
+
+  14. Revised Versions of this License.
+
+  The Free Software Foundation may publish revised and/or new versions of
+the GNU General Public License from time to time.  Such new versions will
+be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+
+  Each version is given a distinguishing version number.  If the
+Program specifies that a certain numbered version of the GNU General
+Public License "or any later version" applies to it, you have the
+option of following the terms and conditions either of that numbered
+version or of any later version published by the Free Software
+Foundation.  If the Program does not specify a version number of the
+GNU General Public License, you may choose any version ever published
+by the Free Software Foundation.
+
+  If the Program specifies that a proxy can decide which future
+versions of the GNU General Public License can be used, that proxy's
+public statement of acceptance of a version permanently authorizes you
+to choose that version for the Program.
+
+  Later license versions may give you additional or different
+permissions.  However, no additional obligations are imposed on any
+author or copyright holder as a result of your choosing to follow a
+later version.
+
+  15. Disclaimer of Warranty.
+
+  THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
+APPLICABLE LAW.  EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
+HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
+OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
+THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
+IS WITH YOU.  SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
+ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
+
+  16. Limitation of Liability.
+
+  IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
+THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
+GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
+USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
+DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
+PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
+EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGES.
+
+  17. Interpretation of Sections 15 and 16.
+
+  If the disclaimer of warranty and limitation of liability provided
+above cannot be given local legal effect according to their terms,
+reviewing courts shall apply local law that most closely approximates
+an absolute waiver of all civil liability in connection with the
+Program, unless a warranty or assumption of liability accompanies a
+copy of the Program in return for a fee.
+
+                     END OF TERMS AND CONDITIONS
+
+            How to Apply These Terms to Your New Programs
+
+  If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these terms.
+
+  To do so, attach the following notices to the program.  It is safest
+to attach them to the start of each source file to most effectively
+state the exclusion of warranty; and each file should have at least
+the "copyright" line and a pointer to where the full notice is found.
+
+    <one line to give the program's name and a brief idea of what it does.>
+    Copyright (C) <year>  <name of author>
+
+    This program is free software: you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation, either version 3 of the License, or
+    (at your option) any later version.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+
+    You should have received a copy of the GNU General Public License
+    along with this program.  If not, see <https://www.gnu.org/licenses/>.
+
+Also add information on how to contact you by electronic and paper mail.
+
+  If the program does terminal interaction, make it output a short
+notice like this when it starts in an interactive mode:
+
+    <program>  Copyright (C) <year>  <name of author>
+    This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
+    This is free software, and you are welcome to redistribute it
+    under certain conditions; type `show c' for details.
+
+The hypothetical commands `show w' and `show c' should show the appropriate
+parts of the General Public License.  Of course, your program's commands
+might be different; for a GUI interface, you would use an "about box".
+
+  You should also get your employer (if you work as a programmer) or school,
+if any, to sign a "copyright disclaimer" for the program, if necessary.
+For more information on this, and how to apply and follow the GNU GPL, see
+<https://www.gnu.org/licenses/>.
+
+  The GNU General Public License does not permit incorporating your program
+into proprietary programs.  If your program is a subroutine library, you
+may consider it more useful to permit linking proprietary applications with
+the library.  If this is what you want to do, use the GNU Lesser General
+Public License instead of this License.  But first, please read
+<https://www.gnu.org/licenses/why-not-lgpl.html>.
diff --git a/README.md b/README.md
index afcc2ee..e4d478b 100644
--- a/README.md
+++ b/README.md
@@ -1,18 +1,480 @@
-# Hallucination Reduction (RAG + Discriminators + RL)
+<div align="center">
 
-This repository implements a retrieval-augmented generation pipeline with discriminators and REINFORCE to reduce hallucinations. It includes:
+![AI4Org Logo](frontend/assets/images/logo.jpeg)
 
-- Retriever (TF-IDF)
-- Generator (HuggingFace causal LM, e.g. gpt2)
-- Three discriminators (fact, style, safety) using sequence classification models
-- Supervised fine-tuning (SFT) + REINFORCE loop
-- Overlap-based fact-check reward augmentation
-- Modular structure for real datasets
+# AI4Org: Hallucination Reduction & Data Pipeline
 
-## Quick start
+**An advanced system for reducing hallucinations in Large Language Models using RAG, Discriminator-Guided Reinforcement Learning, and robust data generation pipelines.**
+
+[![Python 3.10+](https://img.shields.io/badge/python-3.10+-blue.svg)](https://www.python.org/downloads/)
+[![PyTorch](https://img.shields.io/badge/PyTorch-%23EE4C2C.svg?style=flat&logo=PyTorch&logoColor=white)](https://pytorch.org/)
+[![Transformers](https://img.shields.io/badge/🤗-Transformers-yellow)](https://huggingface.co/transformers/)
+[![License](https://img.shields.io/badge/license-Open%20Source-green.svg)](LICENSE)
+
+[Features](#-features) • [Architecture](#-architecture) • [Installation](#-installation) • [Quick Start](#-quick-start) • [Documentation](#-documentation) • [Contributing](#-contributing)
+
+</div>
+
+---
+
+## 📋 Overview
+
+**AI4Org** is a comprehensive machine learning system designed to tackle one of the most critical challenges in modern AI: **hallucinations in Large Language Models (LLMs)**. The project combines cutting-edge techniques including:
+
+- **Retrieval-Augmented Generation (RAG)** with semantic search
+- **Multi-Discriminator Architecture** for factuality, style, and safety validation
+- **REINFORCE-based Reinforcement Learning** for model fine-tuning
+- **Automated Q&A Data Generation Pipeline** using Qwen 7B
+- **Desktop Application** with interactive chat interface
+
+This system is particularly designed for organizational policy documents, banking regulations, and other domains where factual accuracy is paramount.
+
+---
+
+## ✨ Features
+
+### 🧠 Hallucination Reduction Pipeline
+- **RAG Integration**: Retrieves relevant context using TF-IDF and sentence embeddings
+- **Triple Discriminator System**:
+  - **Factuality Discriminator**: Validates factual accuracy against source documents
+  - **Style Discriminator**: Ensures professional and appropriate language
+  - **Safety Discriminator**: Filters unsafe or inappropriate content
+- **Reinforcement Learning**: REINFORCE algorithm with discriminator-guided rewards
+- **Supervised Fine-Tuning (SFT)**: Initial training on Q&A pairs before RL
+- **Multi-GPU Support**: Automatic DataParallel for distributed training
+- **Gradient Checkpointing**: Memory-efficient training for large models
+
+### 📊 Data Generation Pipeline
+- **Automated Q&A Generation**: Uses Qwen 7B (4-bit quantized) for generating question-answer pairs
+- **Document Processing**: Supports PDF and TXT files with advanced cleaning
+- **Smart Chunking**: Configurable chunking with overlap for context preservation
+- **Evidence Extraction**: Sentence-level evidence linking using semantic similarity
+- **Deduplication**: Exact and semantic deduplication using FAISS
+- **Validation**: Strict quality checks for section numbers, policy names, and acronyms
+
+### 🖥️ Desktop Frontend
+- **Cross-Platform**: Built with `pywebview` for Windows, macOS, and Linux
+- **Interactive Chat**: Real-time RAG-enhanced question answering
+- **User Management**: Login system with history tracking
+- **Admin Dashboard**: User statistics and login analytics
+- **File Upload**: Upload documents for training directly from the UI
+- **Modern UI**: Responsive design with HTML/CSS/JavaScript
+
+### 🧪 Testing Infrastructure
+- **Unit Tests**: Comprehensive coverage for core components
+- **Integration Tests**: End-to-end pipeline validation
+- **E2E Tests**: Full system testing
+- **Automated Testing**: pytest-based test suite
+
+---
+
+## 🏗️ Architecture
+
+```mermaid
+graph TB
+    subgraph "Data Pipeline"
+        A[Raw Documents] --> B[Text Extraction]
+        B --> C[Cleaning & Chunking]
+        C --> D[Q&A Generation<br/>Qwen 7B]
+        D --> E[Evidence Extraction]
+        E --> F[Deduplication]
+        F --> G[Validated Q&A Pairs]
+    end
+
+    subgraph "Training Pipeline"
+        G --> H[Corpus Building]
+        H --> I[Discriminator Training]
+        I --> J[Supervised Fine-Tuning]
+        J --> K[RL Loop<br/>REINFORCE]
+        K --> L[Fine-tuned Generator]
+    end
+
+    subgraph "Inference"
+        M[User Query] --> N[RAG Retrieval]
+        N --> O[Context + Query]
+        L --> P[Generator]
+        O --> P
+        P --> Q[Response]
+    end
+
+    subgraph "Frontend"
+        R[Desktop App] --> M
+        Q --> R
+    end
+
+    style A fill:#e1f5ff
+    style G fill:#e1f5ff
+    style L fill:#c8e6c9
+    style Q fill:#fff9c4
+    style R fill:#f8bbd0
+```
+
+### Component Overview
+
+| Component | Technology | Purpose |
+|-----------|-----------|---------|
+| **Generator** | TinyLlama-1.1B-Chat | Causal language model for answer generation |
+| **Discriminators** | DistilBERT | Binary classifiers for quality validation |
+| **Retriever** | Sentence-Transformers | Semantic search for relevant context |
+| **Data Pipeline** | Qwen 7B (4-bit) | Automated Q&A pair generation |
+| **Frontend** | pywebview + HTML/CSS/JS | Cross-platform desktop application |
+| **RL Training** | REINFORCE | Policy gradient optimization |
+
+---
+
+## 📦 Installation
+
+### Prerequisites
+
+- **Python**: 3.10 or higher
+- **CUDA**: 11.8+ (recommended for GPU training)
+- **RAM**: 16GB minimum, 32GB recommended
+- **GPU**: NVIDIA GPU with 8GB+ VRAM (optional but recommended)
+
+### Setup Instructions
+
+1. **Clone the repository**
+   ```bash
+   git clone https://github.com/merledu/ai4org.git
+   cd ai4org
+   ```
+
+2. **Create a virtual environment**
+   ```bash
+   python3 -m venv .venv
+   source .venv/bin/activate  # On Windows: .venv\Scripts\activate
+   ```
+
+3. **Install dependencies**
+   ```bash
+   pip install -r requirements.txt
+   ```
+
+4. **Verify installation**
+   Run the included validation script to check your environment:
+   ```bash
+   python scripts/validate_setup.py
+   ```
+   This script will check your Python version, installed packages, data files, and environment variables.
+
+##  Note (Windows / CPU users):
+This project requires `sentence-transformers` and `accelerate`.
+If inference fails, ensure they are installed:
+
+pip install sentence-transformers accelerate
+
+
+---
+
+## 🚀 Quick Start
+
+### 1. Training the Hallucination Reduction Model
+
+Train the complete pipeline (discriminators → SFT → RL):
 
-1. Create virtualenv:
 ```bash
-python3 -m venv .venv
-source .venv/bin/activate
+python -m hallucination_reduction.main
+```
+
+**What happens during training:**
+1. Loads corpus and Q&A pairs from `data/processed/`
+2. Trains three discriminators (factuality, style, safety)
+3. Performs supervised fine-tuning on Q&A pairs
+4. Runs reinforcement learning with discriminator feedback
+5. Saves models to `saved_models_improved/`
+
+**Training Configuration** (edit `hallucination_reduction/config.py`):
+```python
+SFT_EPOCHS = 4        # Supervised fine-tuning epochs
+SFT_BATCH = 1         # Batch size for SFT
+DISC_EPOCHS = 4       # Discriminator training epochs
+RL_EPOCHS = 4         # Reinforcement learning epochs
+MC_ROLLOUTS = 6       # Monte Carlo rollouts per sample
+```
+
+### 2. Running Inference (Command Line)
+
+Chat with the trained model via terminal:
+
+```bash
+python -m hallucination_reduction.inference
+```
+
+**Example interaction:**
+```
+🤖 RAG-Enhanced Chat Mode Started — type 'exit' to quit.
+
+👤 You: What is the data retention policy?
+
+🔍 Retrieved 3 relevant context chunks.
+   [1] Data retention policies specify that customer records...
+   [2] Personal information is stored for a maximum of...
+   [3] Upon user request, all data will be deleted within...
+
+🤖 Generator: Based on the organization's data retention policy,
+customer records are maintained for the duration required by
+regulatory compliance, typically 7 years for financial records...
+```
+
+### 3. Launching the Desktop Application
+
+Start the interactive GUI:
+
+```bash
+cd frontend
 pip install -r requirements.txt
+python main.py
+```
+
+**Features:**
+- 🔐 User login and registration
+- 💬 Interactive chat with RAG-enhanced responses
+- 📤 Document upload for training
+- 👨‍💼 Admin dashboard (PIN: 9999)
+- 📊 User statistics and login history
+
+### 4. Generating Q&A Data
+
+Create training data from policy documents:
+
+```bash
+cd data_generation_pipeline/data-pipeline
+
+# Place your PDF/TXT files in data/input/
+python -m cli run \
+    --input data/input/your_policy.pdf \
+    --output data/output/qa_pairs.json
+```
+
+**Pipeline stages:**
+1. Text extraction from PDF/TXT
+2. Document cleaning and normalization
+3. Smart chunking with overlap
+4. Q&A generation using Qwen 7B
+5. Evidence sentence extraction
+6. Semantic deduplication
+7. Quality validation
+
+---
+
+## 📚 Documentation
+
+We have detailed documentation for each component of the system:
+
+*   **[System Architecture](docs/architecture.md)**: High-level design, component interaction, and data flow diagrams.
+*   **[Hallucination Reduction](docs/hallucination_reduction.md)**: Deep dive into the generator, discriminators, and RL training pipeline.
+*   **[Data Generation Pipeline](docs/data_generation_pipeline.md)**: How to generate training data from your own policy documents.
+*   **[Frontend Application](docs/frontend.md)**: User guide and setup instructions for the desktop app.
+*   **[API Reference](docs/api_reference.md)**: Technical reference for key classes and functions.
+
+### Project Structure
+
+```
+ai4org/
+├── 📂 docs/                         # 📚 Project documentation
+├── 📂 hallucination_reduction/      # Core ML pipeline
+├── 📂 data_generation_pipeline/     # Q&A generation system
+├── 📂 frontend/                     # Desktop application
+├── 📂 data/                         # Data storage
+├── 📂 tests/                        # Test suite
+└── ...
+```
+
+---
+
+## 🧪 Testing
+
+### Running All Tests
+
+```bash
+# Run complete test suite
+pytest tests/
+
+# Run with coverage report
+pytest --cov=hallucination_reduction --cov-report=html tests/
+
+# Run specific test categories
+pytest tests/unit/              # Unit tests only
+pytest tests/integration/       # Integration tests only
+pytest tests/e2e/              # End-to-end tests only
+```
+
+### Test Coverage
+
+The project includes comprehensive tests for:
+- ✅ Data loading and preprocessing
+- ✅ Discriminator training and evaluation
+- ✅ Generator fine-tuning
+- ✅ RAG retrieval accuracy
+- ✅ RL training loop
+- ✅ Inference pipeline
+- ✅ Q&A generation pipeline
+- ✅ Frontend API endpoints
+
+---
+
+## 🔧 Configuration
+
+### Environment Variables
+
+```bash
+# Model selection
+export GEN_MODEL="TinyLlama/TinyLlama-1.1B-Chat-v1.0"
+export DISC_MODEL="distilbert-base-uncased"
+
+# GPU configuration
+export CUDA_VISIBLE_DEVICES="0,1"  # Use specific GPUs
+export PYTORCH_CUDA_ALLOC_CONF="expandable_segments:true"
+
+# Disable tokenizer warnings
+export TOKENIZERS_PARALLELISM="false"
+```
+
+### Training Hyperparameters
+
+Edit `hallucination_reduction/config.py`:
+
+```python
+# Supervised Fine-Tuning
+SFT_EPOCHS = 4
+SFT_BATCH = 1
+SFT_LR = 3e-5
+
+# Discriminator Training
+DISC_EPOCHS = 4
+DISC_BATCH = 8
+DISC_LR = 2e-5
+
+# Reinforcement Learning
+RL_EPOCHS = 4
+MC_ROLLOUTS = 6
+GEN_LR = 1e-5
+MAX_GEN_TOKENS = 64
+
+# Reward Weights
+FACT_WEIGHT = 0.8
+STYLE_WEIGHT = 0.15
+SAFETY_WEIGHT = 0.05
+```
+
+### Data Pipeline Configuration
+
+Edit `data_generation_pipeline/data-pipeline/config/pipeline_config.yaml`:
+
+```yaml
+chunking:
+  chunk_size: 512
+  overlap: 128
+
+generation:
+  max_qa_per_chunk: 5
+  temperature: 0.7
+
+deduplication:
+  similarity_threshold: 0.85
+```
+
+---
+
+## 📊 Model Performance
+
+### Hallucination Reduction Metrics
+
+| Metric | Baseline | After SFT | After RL | Improvement |
+|--------|----------|-----------|----------|-------------|
+| Hallucination Rate | 45.2% | 28.7% | 12.3% | **-32.9%** |
+| Factuality Score | 0.62 | 0.78 | 0.91 | **+0.29** |
+| Style Score | 0.71 | 0.84 | 0.89 | **+0.18** |
+| Safety Score | 0.88 | 0.93 | 0.96 | **+0.08** |
+
+### Training Time (Single RTX 3090)
+
+- Discriminator Training: ~15 minutes
+- Supervised Fine-Tuning: ~30 minutes
+- Reinforcement Learning: ~45 minutes
+- **Total**: ~1.5 hours
+
+---
+
+## 🤝 Contributing
+
+We welcome contributions from the community! Please see [CONTRIBUTING.md](CONTRIBUTING.md) for detailed guidelines.
+
+### Quick Contribution Guide
+
+1. **Fork the repository**
+2. **Create a feature branch**
+   ```bash
+   git checkout -b feature/amazing-feature
+   ```
+3. **Make your changes**
+4. **Run tests**
+   ```bash
+   pytest tests/
+   ```
+5. **Commit with clear messages**
+   ```bash
+   git commit -m "Add amazing feature"
+   ```
+6. **Push to your fork**
+   ```bash
+   git push origin feature/amazing-feature
+   ```
+7. **Open a Pull Request**
+
+### Code Style
+
+- Follow **PEP 8** guidelines
+- Use meaningful variable and function names
+- Add docstrings to all functions and classes
+- Include type hints where appropriate
+- Write tests for new features
+
+---
+
+## 📝 License
+
+This project is open-source and available under the MIT License. See [LICENSE](LICENSE) for details.
+
+---
+
+## 🙏 Acknowledgments
+
+- **Hugging Face** for Transformers library and model hosting
+- **PyTorch** team for the deep learning framework
+- **Sentence-Transformers** for semantic search capabilities
+- **TinyLlama** project for the efficient language model
+- **Qwen** team for the Q&A generation model
+
+---
+
+## 📧 Contact & Support
+
+- **Issues**: [GitHub Issues](https://github.com/merledu/ai4org/issues)
+- **Discussions**: [GitHub Discussions](https://github.com/merledu/ai4org/discussions)
+- **Organization**: [MeRL-EDU](https://github.com/merledu)
+
+---
+
+## 🗺️ Roadmap
+
+- [ ] Support for larger models (Llama 2, Mistral)
+- [ ] Multi-language support
+- [ ] Web-based deployment option
+- [ ] Real-time streaming inference
+- [ ] Advanced evaluation metrics
+- [ ] Model distillation for edge deployment
+- [ ] Integration with vector databases (Pinecone, Weaviate)
+- [ ] API server with FastAPI
+- [ ] Docker containerization
+- [ ] Kubernetes deployment templates
+
+---
+
+<div align="center">
+
+**Built with ❤️ by the MeRL-EDU Team**
+
+⭐ Star us on GitHub — it motivates us a lot!
+
+</div>
diff --git a/data/processed/corpus.txt b/data/processed/corpus.txt
index 801a874..fe64a88 100644
--- a/data/processed/corpus.txt
+++ b/data/processed/corpus.txt
@@ -1,39 +1,5240 @@
-Our cancellation policy: Customers may cancel within 24 hours for a full refund. After that, refund requests are handled on a case-by-case basis.
-
-Data retention rules: We keep system logs for 90 days and anonymize them afterward to protect user privacy.
-
-Access control: Only managers can approve employee role or permission changes.
-
-Security policy: All devices must have full disk encryption enabled to safeguard sensitive company data.
-
-Tone guideline: Use professional, concise, and empathetic language when replying to customers.
-
-Support availability: Customer support operates 24/7 through chat and email to ensure constant assistance.
-
-Remote access policy: Temporary employees may access systems only via secure VPN connections with restricted rights.
-
-Phishing alert policy: Report suspicious emails using the 'Report Phishing' button to notify IT security immediately.
-
-Password standards: Internal passwords must be at least 12 characters long and include uppercase, lowercase, numbers, and special symbols.
-
-Training policy: All employees must complete compliance and cybersecurity training annually.
-
-Email usage policy: Employees must use official company email accounts for all work-related communications.
-
-Customer data retention: Personal data is stored securely for 5 years or until a deletion request is submitted.
-
-Software installation rule: Only IT-approved applications may be installed on company-managed devices.
-
-Backup process: Full backups occur daily, and incremental backups run hourly to ensure data recovery readiness.
-
-Password reset policy: Users can reset passwords via the self-service portal if multi-factor authentication is enabled.
-
-Customer complaint handling: All complaints are logged, reviewed, and resolved within 48 hours by the QA team.
-
-Compliance framework: The company follows GDPR, CCPA, and other relevant data protection laws.
-
-BYOD policy: Employees may use personal devices for work if enrolled in Mobile Device Management (MDM).
-
-Financial data policy: Only authorized finance and audit personnel have access to transaction records.
-
-Document sharing policy: Internal documents must be shared only through secure, company-approved systems such as SharePoint or encrypted email.
+Bank Name: Amanah Bank
+Document Title: Customer-Facing Policy Framework
+Version: 1.0
+Generated On: 2025-10-22
+Generated By: LLM Policy Assistant
+Total Categories: 20
+Format: Markdown-to-PDF Ready
+Amanah Bank Customer Policy Framework v1.0
+A. Core Customer Operations Policies
+Category 1: Account Management Policies
+1.1 Account Opening and Maintenance Policy
+1. Purpose
+This policy establishes comprehensive guidelines for opening, operating, and
+maintaining customer accounts at Amanah Bank. It ensures that all account-
+related activities adhere to regulatory requirements while delivering seamless
+banking experiences. The policy aims to protect customer interests while
+maintaining operational efficiency and compliance with applicable laws.
+2. Scope
+This policy applies to all types of deposit accounts including savings accounts,
+current accounts, fixed deposit accounts, and special purpose accounts offered
+by Amanah Bank. It covers individual accounts, joint accounts, minor accounts,
+corporate accounts, and accounts for non-profit organizations. The policy
+governs account opening procedures, maintenance requirements, dormancy
+management, and reactivation processes across all branches and digital channels.
+3. Definitions
+Customer: Any individual or entity holding or applying for an account with
+Amanah Bank. Account: A financial relationship established between the Customer
+and the Bank for deposit, withdrawal, and transaction purposes. Dormant Account:
+An account with no customer-initiated transactions for a continuous period of
+twelve months. Primary Account Holder: The main person responsible for account
+operations and compliance. Authorized Signatory: Person(s) designated by the
+account holder to conduct transactions on their behalf.
+4. Policy Statement
+Amanah Bank commits to providing transparent, accessible, and secure account
+services to all eligible customers. Account opening requires valid
+identification, proof of address, and completion of KYC documentation as per
+regulatory mandates. The Bank maintains the right to accept or decline account
+applications based on risk assessment, regulatory compliance, and internal
+policies. All accounts must maintain minimum balance requirements as specified
+in the fee schedule. Accounts inactive for twelve months will be classified as
+dormant and subject to reactivation procedures. The Bank reserves the right to
+freeze or close accounts involved in suspicious activities, policy violations,
+or upon regulatory direction.
+5. Customer Responsibilities
+Customers must provide accurate, complete, and current information during
+account opening and promptly update any changes to personal details, contact
+information, or authorized signatories. Customers are responsible for
+maintaining minimum balance requirements and understanding applicable fees and
+charges. Account holders must safeguard their account credentials, cheque books,
+debit cards, and immediately report any unauthorized transactions or suspected
+fraud. Customers must ensure sufficient funds before issuing cheques or
+authorizing payments. Joint account holders must clearly communicate authority
+levels and transaction permissions. Customers are required to review account
+statements regularly and report discrepancies within thirty days.
+6. Bank Responsibilities
+Amanah Bank shall process account opening applications within three business
+days of receiving complete documentation. The Bank will provide clear
+communication about account features, fees, interest rates, and terms and
+conditions at the time of account opening. Monthly statements will be provided
+through the customer's preferred channel (physical or electronic) within five
+business days of month-end. The Bank shall maintain strict confidentiality of
+customer information and implement robust security measures to protect account
+data. Amanah Bank will promptly investigate and resolve customer complaints
+related to account operations. The Bank shall notify customers at least thirty
+days in advance of any changes to fees, interest rates, or account terms.
+Dormant accounts will be reactivated within two business days upon customer
+request and identity verification.
+7. Exceptions / Disclosures
+Minimum balance requirements may be waived for students, senior citizens,
+persons with disabilities, and financially disadvantaged segments as per the
+Bank's financial inclusion initiatives. Account opening for non-residents,
+foreign nationals, and politically exposed persons (PEPs) requires enhanced due
+diligence and additional documentation. The Bank may levy charges for excessive
+transactions, premature account closures, or non-maintenance of minimum balance
+as per the published fee schedule. Joint accounts operate on "either or
+survivor" or "former or survivor" basis as specified by account holders. In
+cases of legal disputes, court orders, or regulatory investigations, the Bank
+may restrict account operations without prior notice. Interest rates on savings
+and deposit accounts are subject to change based on market conditions and
+monetary policy.
+8. Compliance and Review
+This policy complies with the State Bank of Pakistan regulations, Anti-Money
+Laundering Act, Consumer Protection guidelines, and applicable banking laws. The
+policy will be reviewed annually or whenever significant regulatory changes
+occur. Account opening procedures are audited quarterly to ensure adherence to
+KYC/AML norms. Customer complaints regarding account management are tracked,
+analyzed, and incorporated into policy improvements. All staff involved in
+account operations receive mandatory training on this policy twice annually. The
+Bank maintains comprehensive audit trails of all account opening, modification,
+and closure activities for regulatory inspection.
+1.2 Joint Account Operations Policy
+1. Purpose
+This policy defines the operational framework for joint accounts, establishing
+clear guidelines for account ownership, transaction authority, and dispute
+resolution. It aims to protect the interests of all joint account holders while
+ensuring smooth account operations. The policy provides transparency regarding
+rights, responsibilities, and operational modes of joint accounts.
+2. Scope
+This policy applies to all joint accounts held by two or more individuals at
+Amanah Bank, including savings accounts, current accounts, and fixed deposits.
+It covers joint accounts operated under different modes such as "either or
+survivor," "former or survivor," "jointly," or "anyone or survivor." The policy
+governs transaction authorization, signature requirements, dispute resolution,
+and succession procedures. It excludes corporate accounts with multiple
+authorized signatories, which are governed by corporate banking policies.
+3. Definitions
+Joint Account: An account held by two or more individuals with shared ownership.
+Either or Survivor: Operating mode allowing any account holder to transact
+independently, with surviving holder(s) inheriting the account upon death.
+Former or Survivor: Mode where the first-named holder has primary authority,
+with survivor inheritance rights. Jointly: Mode requiring all account holders'
+signatures for any transaction. Primary Holder: First-named account holder with
+primary communication and documentation responsibilities. Secondary Holder(s):
+Additional account holder(s) with rights as per the operating mode.
+4. Policy Statement
+Amanah Bank offers joint accounts to facilitate shared financial management
+between family members, business partners, or other relationships. At account
+opening, holders must specify the operating mode, which cannot be changed
+without written consent from all holders. For "either or survivor" accounts, any
+holder can conduct transactions independently without other holders' consent.
+"Jointly" operated accounts require signatures from all holders for withdrawals,
+transfers, or account modifications. The Bank is not liable for disputes between
+joint holders and will honor instructions as per the specified operating mode.
+Upon death of a joint holder, survivor(s) automatically inherit the account
+balance unless contrary legal instructions exist. All joint holders are jointly
+and severally liable for overdrafts, loan obligations, and account-related
+liabilities.
+5. Customer Responsibilities
+Joint account holders must clearly specify and document the operating mode at
+account opening and ensure all holders understand their rights and obligations.
+Each holder is responsible for maintaining confidentiality of their credentials
+and transaction activities. Holders must promptly communicate disputes, changes
+in relationship, or requests for mode changes in writing to the Bank. In "either
+or survivor" accounts, holders must maintain mutual trust as any holder can
+independently withdraw the entire balance. Holders are responsible for
+monitoring account activity and reporting unauthorized transactions within the
+stipulated timeframe. In case of death, surviving holders must notify the Bank
+immediately and provide necessary documentation for account transmission. All
+holders must comply with tax reporting obligations as applicable to their share
+of account income.
+6. Bank Responsibilities
+Amanah Bank shall clearly explain operating modes, implications, and risks
+before joint account opening. The Bank will maintain accurate records of all
+joint holders' details, signatures, and the specified operating mode.
+Transaction processing will strictly follow the operating mode instructions, and
+the Bank will not accept transactions that violate the specified mode. In cases
+of conflicting instructions from joint holders, the Bank shall freeze the
+account until all holders provide unanimous written instructions or legal
+resolution is obtained. Upon notification of a holder's death, the Bank will
+provide smooth transmission of account to survivor(s) subject to verification of
+legal documents. The Bank shall issue separate tax certificates to each joint
+holder for their proportionate share of interest income. All correspondence will
+be sent to the primary holder's address unless specific instructions exist for
+other holders.
+7. Exceptions / Disclosures
+Joint accounts cannot be opened for minors as primary holders; however, minors
+can be secondary holders with guardian consent. The "either or survivor" mode
+carries inherent risk of one holder withdrawing all funds without consent of
+others. The Bank is not responsible for resolving personal disputes between
+joint holders and will honor account operations as per the registered mode. In
+cases where legal heirs of a deceased joint holder dispute account transmission,
+the Bank may require legal indemnification or court orders before allowing
+operations. Operating mode changes require physical presence of all joint
+holders at the branch with valid identification. For NRI (Non-Resident Indian)
+joint accounts, at least one holder must be resident as per foreign exchange
+regulations.
+8. Compliance and Review
+This policy aligns with State Bank of Pakistan guidelines on joint accounts,
+succession laws, and consumer protection regulations. Joint account operations
+are reviewed during internal audits to ensure compliance with specified
+operating modes. The policy is reviewed biennially or upon significant
+regulatory changes. Customer disputes regarding joint accounts are analyzed to
+identify policy improvement areas. Staff training on joint account procedures is
+conducted annually with emphasis on dispute scenarios. The Bank maintains
+detailed records of operating mode specifications, holder communications, and
+dispute resolutions for regulatory compliance.
+1.3 Minor Account Management Policy
+1. Purpose
+This policy establishes guidelines for opening and managing accounts for minors
+(individuals below 18 years), promoting early financial literacy while ensuring
+proper guardianship and protection. It aims to balance the educational benefits
+of banking for minors with necessary safeguards and regulatory compliance. The
+policy protects minors' interests while enabling age-appropriate financial
+independence.
+2. Scope
+This policy applies to all savings and fixed deposit accounts opened for minors
+below 18 years of age at Amanah Bank. It covers accounts opened by parents,
+legal guardians, or court-appointed guardians on behalf of minors. The policy
+governs transaction limits, guardian responsibilities, account conversion
+procedures upon attaining majority, and operational restrictions. It applies to
+individual minor accounts and excludes joint accounts where minors are secondary
+holders, which are governed by joint account policies.
+3. Definitions
+Minor: Individual below 18 years of age as per applicable law. Guardian: Parent,
+legal guardian, or court-appointed guardian authorized to operate the minor's
+account. Natural Guardian: Biological or adoptive parent managing the minor's
+financial affairs. Legal Guardian: Court-appointed individual authorized to
+manage minor's property and finances. Conversion: Process of converting a minor
+account to a regular adult account upon the minor attaining 18 years. Gift
+Deposits: Contributions made to minor accounts by relatives or well-wishers on
+special occasions.
+4. Policy Statement
+Amanah Bank encourages parents and guardians to open accounts for minors to
+instill savings habits and financial literacy from an early age. Minor accounts
+can only be opened by natural guardians (parents) or legal guardians with
+appropriate documentation. All transactions on minor accounts must be conducted
+by the registered guardian until the minor attains 10 years of age. Minors aged
+10-18 years may be allowed limited transaction capabilities such as deposits and
+ATM withdrawals up to specified limits with guardian consent. The guardian is
+fully responsible for account operations, compliance, and any liabilities until
+the minor attains majority. Upon reaching 18 years, minor accounts are
+automatically converted to regular savings accounts subject to completion of
+fresh KYC documentation. No loans, overdrafts, or credit facilities can be
+extended against minor accounts. The Bank prioritizes the minor's welfare in all
+account-related decisions and disputes.
+5. Customer Responsibilities
+Guardians must provide complete and accurate documentation including the minor's
+birth certificate, guardian's identification, proof of guardianship, and address
+proof at account opening. Guardians are responsible for all transactions,
+maintaining minimum balance, and ensuring the account is operated in the minor's
+best interest. Any funds deposited must be legitimate and guardians must provide
+source of funds information for large deposits. Guardians must update the Bank
+regarding any changes in guardianship, contact information, or the minor's
+status. Upon the minor attaining 18 years, guardians must ensure timely
+conversion by facilitating completion of fresh KYC documents. Guardians must not
+use minor account funds for personal purposes and must maintain transparent
+records of deposits and withdrawals. The minor, upon attaining 10 years, must
+safeguard ATM cards, PIN, and report any unauthorized transactions immediately.
+6. Bank Responsibilities
+Amanah Bank shall verify guardianship credentials thoroughly before account
+opening, ensuring the guardian has legal authority to act on the minor's behalf.
+The Bank will provide age-appropriate financial literacy materials and conduct
+periodic awareness programs for minors and guardians. Special passbooks or
+account statements designed for minors will be provided to make banking engaging
+and educational. The Bank shall monitor minor accounts for unusual activities
+and report suspicious transactions as per AML regulations. Interest rates
+offered on minor accounts will be competitive and clearly communicated at
+account opening. The Bank will proactively contact guardians three months before
+the minor attains 18 years to initiate the conversion process. Upon conversion,
+the Bank shall transfer all account-related authorities to the account holder
+and remove guardian access. The Bank shall maintain strict confidentiality and
+prevent unauthorized access to minor account information.
+7. Exceptions / Disclosures
+Transaction limits for minors aged 10-18 are set at PKR 5,000 per day for ATM
+withdrawals and PKR 10,000 per month for total withdrawals. These limits may be
+revised periodically. No cheque book, internet banking, or mobile banking
+facilities are provided for minor accounts. Minors cannot be added as nominees
+or authorized signatories on other accounts. In cases of guardian disputes,
+death, or incapacity, the Bank requires legal documentation (court orders or
+succession certificates) before allowing account access. Gift deposits exceeding
+PKR 100,000 in a financial year require declaration of source and relationship
+to the minor. The Bank reserves the right to freeze minor accounts if fraudulent
+or improper use is suspected until legal clarification is obtained.
+8. Compliance and Review
+This policy complies with State Bank of Pakistan regulations, Guardians and
+Wards Act, Child Protection laws, and KYC/AML norms specific to minor accounts.
+The policy is reviewed annually with focus on enhancing financial literacy
+initiatives for minors. Guardian verification procedures are audited quarterly
+to ensure proper documentation and authority confirmation. Staff handling minor
+accounts receive specialized training on child protection, guardian rights, and
+age-appropriate customer service. Customer feedback from guardians is collected
+and analyzed to improve minor account features and educational programs. The
+Bank maintains detailed records of guardianship documents, conversion processes,
+and any disputes for regulatory inspection.
+1.4 Account Dormancy and Reactivation Policy
+1. Purpose
+This policy defines procedures for classifying, managing, and reactivating
+dormant accounts to protect customer funds while maintaining regulatory
+compliance. It aims to encourage regular account usage, prevent fraud, and
+ensure dormant funds are eventually reunited with rightful owners. The policy
+balances customer convenience with security requirements for inactive accounts.
+2. Scope
+This policy applies to all savings accounts, current accounts, and other deposit
+accounts that become inactive due to lack of customer-initiated transactions. An
+account is classified as dormant after twelve consecutive months without
+customer-initiated debits or credits, excluding bank-initiated transactions like
+interest credits, fee debits, or dividend credits. The policy covers dormancy
+identification, notification procedures, operational restrictions, reactivation
+processes, and escheatment (transfer to government) for long-term dormant
+accounts. It excludes fixed deposits and term deposits which are governed by
+separate maturity-based policies.
+3. Definitions
+Dormant Account: Account with no customer-initiated transaction for twelve
+consecutive months. Customer-Initiated Transaction: Deposits, withdrawals,
+transfers, or other instructions initiated by the account holder. Inactive
+Account: Account approaching dormancy (9-11 months without transactions).
+Reactivation: Process of restoring full operational status to a dormant account.
+Escheatment: Transfer of unclaimed dormant account funds to government
+authorities after the statutory period. Bank-Initiated Transaction: Interest
+credits, service charges, or regulatory debits not constituting customer
+activity.
+4. Policy Statement
+Amanah Bank proactively monitors account activity and classifies accounts as
+dormant after twelve months of customer inactivity to prevent unauthorized
+transactions and protect customer interests. Customers will receive advance
+notification when accounts approach dormancy status at nine months of
+inactivity. Dormant accounts are restricted from certain operations including
+cheque issuance, ATM withdrawals, internet banking, and mobile banking to
+prevent fraud. Existing cheques, standing instructions, and auto-debit
+facilities are suspended upon dormancy classification. Reactivation requires
+customer verification through in-person visit with valid identification or
+through secure digital verification processes. The Bank maintains dormant
+account funds securely and continues to credit interest as applicable. Accounts
+dormant for ten years with balances below PKR 1,000 may be escheated to
+government authorities as per regulatory requirements. The Bank makes reasonable
+efforts to contact customers before escheatment.
+5. Customer Responsibilities
+Customers must maintain regular account activity through deposits, withdrawals,
+or other transactions to prevent dormancy classification. Upon receiving
+dormancy alert notifications, customers should either conduct transactions or
+visit the branch to confirm account status. Customers are responsible for
+maintaining updated contact information to receive dormancy alerts and
+reactivation instructions. For reactivation, customers must visit the branch
+with valid original identification documents and provide reasons for inactivity
+if requested. Customers should review account statements to identify and report
+any unauthorized transactions that may have occurred before dormancy
+classification. Upon reactivation, customers must update KYC documents if they
+have expired during the dormancy period. Customers should consolidate multiple
+dormant accounts to simplify account management and reduce maintenance costs.
+6. Bank Responsibilities
+Amanah Bank shall monitor all accounts monthly to identify those approaching
+dormancy and send notification letters or emails to customers at nine months of
+inactivity. Upon classifying an account as dormant, the Bank will restrict high-
+risk transaction channels while maintaining the account's security and
+continuing to credit applicable interest. The Bank shall maintain separate
+records and monitoring systems for dormant accounts with enhanced security
+measures. Reactivation requests will be processed within two business days upon
+satisfactory verification of customer identity and account ownership. The Bank
+will provide multiple reactivation channels including branch visits, video KYC,
+and authorized representative processes. Prior to escheatment, the Bank shall
+make three attempts to contact the customer through registered mail, email, and
+phone over a six-month period. Escheated funds can be reclaimed by customers
+even after transfer to government by providing appropriate documentation. The
+Bank shall maintain comprehensive records of all dormancy classifications,
+reactivations, and escheatment actions for audit purposes.
+7. Exceptions / Disclosures
+Accounts with loan obligations, active standing instructions, or auto-debit
+mandates may not be fully restricted during dormancy but will have enhanced
+monitoring. Senior citizen accounts and disability pension accounts receive
+extended dormancy periods (18 months) before classification. Accounts held by
+NRIs, seafarers, or individuals on long-term overseas assignments may request
+dormancy exemption with appropriate documentation. No additional charges are
+levied for dormancy classification or reactivation; however, regular account
+maintenance fees continue unless waived by specific schemes. Dormant accounts
+with active fixed deposits or recurring deposits linked to them will not be
+escheated until all linked deposits mature. In cases where the account holder is
+deceased and legal heirs have not claimed the funds, escheatment timelines are
+extended pending legal resolution.
+8. Compliance and Review
+This policy adheres to State Bank of Pakistan guidelines on dormant accounts,
+Consumer Protection regulations, and Escheatment Acts. Dormant account
+identification and classification processes are automated and audited quarterly
+for accuracy. The policy is reviewed annually with focus on improving customer
+communication and reactivation procedures. Customer complaints regarding
+incorrect dormancy classification or reactivation difficulties are tracked and
+analyzed for process improvements. Staff receive annual training on dormancy
+management, reactivation procedures, and customer sensitivity regarding inactive
+accounts. The Bank submits periodic reports to regulatory authorities on dormant
+account statistics, escheatment actions, and reactivation rates. Technological
+enhancements are continuously evaluated to improve dormancy detection and
+customer alert mechanisms.
+Category 2: Customer Onboarding and Verification (KYC/AML) Policies
+2.1 Know Your Customer (KYC) Policy
+1. Purpose
+This policy establishes comprehensive procedures for customer identification,
+verification, and due diligence to prevent identity fraud, money laundering,
+terrorist financing, and other financial crimes. It ensures Amanah Bank
+maintains accurate customer information while complying with regulatory
+mandates. The policy aims to balance robust security measures with customer
+convenience and privacy protection.
+2. Scope
+This policy applies to all customers opening new accounts, existing customers
+updating information, and beneficial owners of legal entity customers at Amanah
+Bank. It covers individual customers, corporate entities, partnerships, trusts,
+non-profit organizations, and other legal structures. The policy governs initial
+KYC at onboarding, periodic KYC updates, enhanced due diligence for high-risk
+customers, and simplified due diligence for low-risk segments. It applies across
+all channels including branches, digital onboarding platforms, and third-party
+agent networks.
+3. Definitions
+KYC (Know Your Customer): Process of verifying customer identity and assessing
+risk profiles. Customer Due Diligence (CDD): Standard verification procedures
+for regular customers. Enhanced Due Diligence (EDD): Rigorous verification for
+high-risk customers including PEPs and high-value clients. Simplified Due
+Diligence (SDD): Streamlined verification for low-risk customers such as
+government employees. Politically Exposed Person (PEP): Individual holding
+prominent public functions with potential corruption risks. Beneficial Owner:
+Ultimate individual(s) owning or controlling a legal entity customer. Officially
+Valid Document (OVD): Government-issued identity document acceptable for KYC
+verification.
+4. Policy Statement
+Amanah Bank will not open accounts or establish banking relationships without
+satisfactory completion of KYC procedures as per regulatory requirements. All
+customers must provide Officially Valid Documents for identity and address
+verification at account opening. Acceptable OVDs include National Identity Card
+(CNIC/NICOP), Passport, Driving License, and other government-issued photo
+identification. For address verification, utility bills, rent agreements, or
+employer certificates not older than three months are required. Customer
+information must be verified through independent reliable sources, and face-to-
+face verification is mandatory for high-risk customers. Enhanced due diligence
+is mandatory for PEPs, non-resident customers, high net worth individuals, and
+customers from high-risk jurisdictions. KYC information must be updated at least
+once every two years for individual customers and annually for corporate
+customers. The Bank conducts ongoing due diligence through transaction
+monitoring and periodic information updates. Customer information is
+confidential and used solely for compliance, risk management, and regulatory
+reporting purposes.
+5. Customer Responsibilities
+Customers must provide genuine, complete, and accurate information during
+account opening and KYC verification processes. Original documents must be
+presented for verification; photocopies are retained by the Bank after
+verification against originals. Customers are required to inform the Bank within
+fifteen days of any changes to name, address, contact information, occupation,
+or income sources. For corporate customers, any changes in ownership structure,
+directorship, authorized signatories, or beneficial ownership must be reported
+within thirty days. Customers must cooperate with periodic KYC update requests
+and submit updated documents before expiry of existing documents. Submission of
+false information or forged documents constitutes fraud and may result in
+account closure, legal action, and reporting to authorities. Customers
+designated as PEPs must disclose their status and provide additional
+documentation regarding source of wealth and transaction patterns.
+6. Bank Responsibilities
+Amanah Bank shall verify customer identity through robust processes including
+document verification, biometric authentication, and database checks where
+available. The Bank will maintain a risk-based approach, categorizing customers
+into low, medium, and high-risk profiles based on occupation, transaction
+patterns, geographic location, and other factors. Physical verification of
+address may be conducted for high-risk customers or large deposit relationships.
+The Bank shall maintain centralized KYC records accessible across all branches
+and departments for consistent customer service. Customer information is
+securely stored with restricted access and protected against unauthorized
+disclosure or data breaches. The Bank will send KYC update reminders to
+customers before document expiry and provide convenient update channels
+including digital document upload. Accounts with pending KYC updates beyond
+grace periods will have partial restrictions on high-value transactions until
+compliance is achieved. The Bank shall conduct periodic staff training on KYC
+procedures, red flag identification, and customer sensitization.
+7. Exceptions / Disclosures
+Simplified due diligence may be applied for low-risk customers such as
+government employees, senior citizens with pension accounts, or accounts with
+low balances and transaction volumes, subject to regulatory approval. Walk-in
+customers for remittances or forex transactions must complete KYC as per
+transaction value thresholds even without account opening. Non-resident
+customers require additional documentation including visa, work permit, overseas
+address proof, and source of funds declaration. For customers unable to provide
+standard address proof, the Bank may accept alternative documents such as
+attestation from local government officials or employer certificates with proper
+verification. The Bank reserves the right to request additional information or
+documents beyond standard KYC requirements based on risk assessment. Digital KYC
+through video verification and e-document submission is permitted for standard
+accounts subject to regulatory guidelines. Accounts opened through digital
+channels may have initial transaction limits until physical KYC completion.
+8. Compliance and Review
+This policy complies with State Bank of Pakistan KYC/AML regulations, Financial
+Action Task Force (FATF) recommendations, and international best practices. The
+KYC framework is reviewed annually and updated immediately upon regulatory
+changes. Internal audits of KYC processes are conducted quarterly with sample
+verification of customer documentation and risk categorization accuracy.
+Technology solutions for KYC management, document verification, and risk scoring
+are continuously upgraded to enhance efficiency and accuracy. Customer
+complaints regarding KYC procedures are analyzed to identify and eliminate
+unnecessary friction while maintaining compliance. The Bank maintains audit
+trails of all KYC verifications, updates, and risk assessments for regulatory
+inspection. Periodic reports on KYC compliance statistics, pending updates, and
+high-risk customer management are submitted to regulatory authorities and senior
+management.
+2.2 Anti-Money Laundering (AML) and Counter-Terrorist Financing (CFT) Policy
+1. Purpose
+This policy establishes Amanah Bank's framework for detecting, preventing, and
+reporting money laundering and terrorist financing activities to protect the
+financial system's integrity. It ensures compliance with national and
+international AML/CFT regulations while safeguarding the Bank from being used as
+a conduit for illicit funds. The policy aims to create a culture of vigilance
+and accountability across all levels of the organization.
+2. Scope
+This policy applies to all products, services, transactions, and customer
+relationships across Amanah Bank's operations. It covers domestic and
+international transactions, cash and non-cash transactions, one-time customers,
+account holders, and beneficial owners of legal entities. The policy governs
+transaction monitoring, suspicious activity detection, reporting obligations,
+customer risk assessment, sanctions screening, and employee training. It applies
+to all employees, officers, directors, and third-party agents acting on behalf
+of the Bank.
+3. Definitions
+Money Laundering: Process of concealing illicit funds' origin through complex
+transactions to make them appear legitimate. Terrorist Financing: Providing,
+collecting, or using funds with intention to support terrorist activities.
+Suspicious Transaction: Transaction inconsistent with customer profile, having
+no economic rationale, or involving potential illegal activities. Suspicious
+Transaction Report (STR): Regulatory report filed for transactions suspected to
+involve money laundering or terrorist financing. Designated Lists: Lists of
+individuals and entities subject to sanctions by UN, FATF, or national
+authorities. Tipping Off: Informing a customer that they are subject to
+investigation or that an STR has been filed.
+4. Policy Statement
+Amanah Bank maintains a zero-tolerance approach toward money laundering and
+terrorist financing and will not knowingly facilitate such activities. The Bank
+implements risk-based AML/CFT controls proportionate to identified money
+laundering and terrorist financing risks. All employees are responsible for
+identifying and reporting suspicious transactions regardless of amount, and the
+Bank protects whistle-blowers from retaliation. Customer and transaction
+screening against designated lists is mandatory before account opening and on an
+ongoing basis. Cash transactions exceeding regulatory thresholds are reported to
+the Financial Monitoring Unit as per statutory requirements. The Bank conducts
+enhanced due diligence for high-risk customers, products, and geographies prone
+to money laundering risks. Suspicious Transaction Reports are filed within the
+prescribed timeline to regulatory authorities, and tipping off customers is
+strictly prohibited. The Bank cooperates fully with law enforcement and
+regulatory authorities in AML/CFT investigations. Employees violating AML/CFT
+policies face disciplinary action including termination, and the Bank may report
+employee misconduct to authorities.
+5. Customer Responsibilities
+Customers must provide truthful information about transaction purposes, fund
+sources, and beneficial ownership when requested by the Bank. Customers should
+conduct transactions consistent with their stated business or occupation and
+inform the Bank of significant changes. Customers must not use Amanah Bank
+accounts to receive, transfer, or facilitate funds related to illegal
+activities. Structuring transactions to avoid reporting thresholds (smurfing) is
+prohibited and will result in account closure and regulatory reporting.
+Customers must cooperate with the Bank's due diligence inquiries and provide
+supporting documentation for large or unusual transactions. Refusal to provide
+information or documentation for legitimate AML/CFT compliance may result in
+transaction decline or account closure. Customers should be aware that the Bank
+has legal obligations to report suspicious transactions without informing the
+customer.
+6. Bank Responsibilities
+Amanah Bank shall implement automated transaction monitoring systems to detect
+unusual patterns, rapid fund movements, and transactions inconsistent with
+customer profiles. The Bank will screen all customers and transactions against
+designated lists including UN sanctions lists, FATF lists, and domestic
+watchlists in real-time. A dedicated AML/CFT compliance unit shall investigate
+alerts, conduct deeper analysis, and file Suspicious Transaction Reports when
+required. The Bank will maintain detailed transaction records, customer
+communications, and investigation files for at least seven years as per
+regulatory requirements. All currency transactions exceeding PKR 1,000,000 in a
+day are reported to authorities through Currency Transaction Reports (CTR). The
+Bank shall conduct annual AML/CFT risk assessments to identify emerging threats,
+vulnerabilities, and update controls accordingly. Mandatory AML/CFT training is
+provided to all employees at onboarding and annually thereafter, with
+specialized training for high-risk departments. The Bank shall decline
+transactions or relationships that cannot be adequately risk-assessed or that
+pose unacceptable money laundering risks.
+7. Exceptions / Disclosures
+The Bank cannot disclose to customers that an STR has been filed or that they
+are under investigation due to legal restrictions on tipping off. Customers may
+experience transaction delays or additional documentation requests as part of
+AML/CFT due diligence, which are mandatory compliance requirements. High-risk
+customer categories including PEPs, non-residents, and high-value transactors
+are subject to enhanced monitoring and periodic reviews, which may result in
+occasional transaction delays. The Bank may freeze accounts or decline
+transactions based on sanctions screening matches pending verification, which
+may cause temporary inconvenience. Correspondent banks and payment service
+providers may request additional information about Amanah Bank customers'
+transactions for their own AML compliance. The Bank is legally obligated to
+cooperate with law enforcement agencies and may provide customer information
+pursuant to court orders or statutory requests without customer consent.
+8. Compliance and Review
+This policy complies with the Anti-Money Laundering Act, Anti-Terrorism Act,
+State Bank of Pakistan AML/CFT regulations, and Financial Action Task Force
+(FATF) recommendations. The AML/CFT framework is subject to annual internal
+audits and periodic reviews by external consultants to assess effectiveness.
+Technology systems for transaction monitoring, sanctions screening, and STR
+management are upgraded regularly to adapt to evolving threats. The policy is
+reviewed annually or immediately upon regulatory changes, emerging threats, or
+deficiencies identified through audits. AML/CFT compliance statistics including
+STRs filed, CTRs submitted, accounts closed, and training completion rates are
+reported monthly to senior management. The Bank maintains membership in industry
+forums to share typologies, trends, and best practices in combating financial
+crime. Independent effectiveness reviews of the AML/CFT program are conducted
+every three years by qualified external experts.
+2.3 Customer Risk Assessment and Profiling Policy
+1. Purpose
+This policy establishes a systematic approach for assessing and categorizing
+customers based on money laundering, terrorist financing, and fraud risks. It
+enables Amanah Bank to apply proportionate due diligence measures and monitoring
+intensity based on risk profiles. The policy aims to optimize compliance
+resources while enhancing detection of genuinely high-risk relationships and
+transactions.
+2. Scope
+This policy applies to all customers including individuals, businesses, non-
+profit organizations, and other entities maintaining relationships with Amanah
+Bank. It covers initial risk assessment at onboarding, ongoing risk scoring
+through transaction behavior analysis, periodic risk review, and dynamic risk
+re-categorization. The policy governs risk factors, scoring methodologies, risk
+categories (low, medium, high), and corresponding control measures. It applies
+across all products including deposits, loans, payments, remittances, and
+investment services.
+3. Definitions
+Customer Risk Assessment: Evaluation process to determine money laundering,
+terrorist financing, and fraud risks associated with a customer. Risk Score:
+Numerical value indicating customer's overall risk level based on multiple risk
+factors. Risk Category: Classification of customers into low, medium, or high-
+risk segments for differential treatment. Risk Factors: Variables influencing
+customer risk including occupation, income, transaction patterns, geography,
+product usage, and channel preferences. Dynamic Risk Profiling: Continuous risk
+assessment that adjusts customer risk scores based on behavior changes. Risk
+Appetite: Maximum level of risk the Bank is willing to accept for customer
+relationships.
+4. Policy Statement
+Amanah Bank adopts a risk-based approach to customer due diligence, applying
+enhanced scrutiny to higher-risk relationships while enabling smoother
+experiences for low-risk customers. All customers are assigned risk scores at
+onboarding based on occupation, income sources, geographic location, product
+preferences, anticipated transaction patterns, and other relevant factors. Risk
+assessments are conducted using a standardized scoring model approved by the
+Bank's Compliance and Risk Management Committees. Customers are categorized as
+low risk (score 0-30), medium risk (score 31-60), or high risk (score 61-100)
+with corresponding due diligence and monitoring measures. High-risk customers
+include PEPs, non-residents, cash-intensive businesses, money services
+businesses, non-profit organizations, and customers from high-risk
+jurisdictions. Customer risk profiles are dynamically updated based on
+transaction behavior, account activity changes, adverse media reports, and
+periodic reviews. The Bank may decline relationships that exceed its risk
+appetite or where risks cannot be adequately mitigated. Risk assessments are
+confidential and used solely for compliance and risk management purposes.
+5. Customer Responsibilities
+Customers must provide accurate information about occupation, income sources,
+business nature, and anticipated transaction patterns to enable proper risk
+assessment. Customers should inform the Bank of significant life changes such as
+new employment, business expansion, inheritance, or international relocations
+that may affect risk profiles. High-risk category customers must cooperate with
+enhanced due diligence requirements including source of wealth documentation and
+periodic account reviews. Customers should maintain transaction patterns
+consistent with their declared profiles; significant deviations may trigger
+additional verification requirements. Customers are responsible for
+understanding that risk categorization may result in differential account
+features, transaction limits, or approval requirements. Providing false or
+misleading information to obtain lower risk classification constitutes fraud and
+may result in account closure and regulatory reporting.
+6. Bank Responsibilities
+Amanah Bank shall apply consistent risk assessment methodologies across all
+channels ensuring fair and non-discriminatory evaluation of
+customersRetrySMContinue6. Bank Responsibilities (continued)
+Amanah Bank shall apply consistent risk assessment methodologies across all
+channels ensuring fair and non-discriminatory evaluation of customers. The Bank
+will clearly communicate to customers when enhanced due diligence is required
+due to high-risk classification without disclosing specific risk scores. Risk
+assessment models are calibrated annually using historical data, regulatory
+guidance, and industry best practices to ensure accuracy and effectiveness.
+Automated transaction monitoring systems are configured with risk-based
+thresholds, applying stricter surveillance to high-risk customers while
+minimizing false alerts for low-risk segments. The Bank shall conduct periodic
+reviews of customer risk profiles at least annually for high-risk customers and
+biennially for medium-risk customers. Low-risk customers undergo risk reviews
+every three years or upon significant account behavior changes. The Bank
+maintains detailed documentation of risk assessment rationale, supporting
+evidence, and approval authorities for audit and regulatory inspection. Customer
+service staff are trained to handle high-risk customer inquiries sensitively
+without revealing risk scores or creating discrimination.
+7. Exceptions / Disclosures
+Risk scores and specific risk categorizations are confidential Bank information
+and are not disclosed to customers to prevent gaming of risk assessment systems.
+However, customers have the right to understand why additional documentation or
+enhanced due diligence is requested. Certain customer segments may be assigned
+minimum risk categories regardless of individual profiles; for example, all PEPs
+are categorized as high-risk irrespective of other favorable factors. Geographic
+risk factors are based on FATF high-risk jurisdictions, UN sanctions lists, and
+national risk assessments, which may result in customers from certain countries
+receiving higher risk scores. The Bank may apply temporary risk elevation to
+customers involved in negative media reports, legal disputes, or regulatory
+investigations pending clarification. Risk-based transaction limits and approval
+requirements may cause operational differences between customers, which is a
+regulatory compliance requirement rather than service discrimination. Customers
+can request internal review of their risk classification if they believe errors
+exist in the assessment, subject to provision of supporting documentation.
+8. Compliance and Review
+This policy aligns with State Bank of Pakistan risk-based supervision
+guidelines, FATF risk assessment methodologies, and Basel Committee
+recommendations on customer due diligence. The risk assessment model is
+independently validated annually by internal audit and reviewed by external
+auditors during statutory audits. The policy is updated annually or upon
+significant changes in regulatory expectations, threat landscape, or Bank's risk
+appetite. Customer risk distribution statistics (percentage in each risk
+category) are reported quarterly to the Board Risk Committee and senior
+management. Machine learning and artificial intelligence technologies are
+evaluated periodically to enhance risk prediction accuracy and reduce false
+positives. Customer complaints regarding risk-based treatment are analyzed to
+ensure risk measures are proportionate and non-discriminatory. The Bank
+participates in industry forums to benchmark risk assessment practices and share
+intelligence on emerging risk typologies.
+Category 3: Payment and Transaction Handling Policies
+3.1 Domestic Payment and Transfer Policy
+1. Purpose
+This policy establishes comprehensive guidelines for processing domestic fund
+transfers, bill payments, and other payment transactions executed by Amanah Bank
+customers. It ensures secure, timely, and accurate payment processing while
+protecting customers from fraud and operational errors. The policy aims to
+provide convenient payment options while maintaining robust controls and
+regulatory compliance.
+2. Scope
+This policy applies to all domestic payment transactions including inter-bank
+fund transfers (IBFT), intra-bank transfers, Real-Time Gross Settlement (RTGS)
+transactions, automated clearing house (ACH) transactions, bill payments,
+standing instructions, and scheduled payments. It covers payments initiated
+through branches, ATMs, internet banking, mobile banking, telephone banking, and
+point-of-sale terminals. The policy governs transaction authorization,
+processing timelines, fees, transaction limits, error resolution, and fraud
+prevention measures. It excludes international remittances and foreign exchange
+transactions which are covered under separate policies.
+3. Definitions
+Domestic Payment: Fund transfer within Pakistan between Amanah Bank accounts or
+to accounts at other banks. Inter-Bank Fund Transfer (IBFT): Electronic transfer
+from Amanah Bank account to an account at another bank through the national
+payment network. Intra-Bank Transfer: Transfer between two Amanah Bank accounts
+processed instantly. Real-Time Gross Settlement (RTGS): High-value same-day
+transfer system for amounts typically exceeding PKR 100,000. Standing
+Instruction: Pre-authorized recurring payment instruction for regular bills or
+transfers. Cut-off Time: Deadline for same-day processing of payment
+transactions. Value Date: Date when transferred funds become available in the
+beneficiary account.
+4. Policy Statement
+Amanah Bank commits to processing domestic payments accurately, securely, and
+within regulatory timelines to facilitate seamless fund movement for customers.
+Intra-bank transfers between Amanah Bank accounts are processed instantly 24/7
+with immediate availability of funds to beneficiaries. Inter-bank transfers
+(IBFT) submitted before 5:00 PM are processed the same business day with funds
+typically available to beneficiaries within 30 minutes during banking hours.
+RTGS transfers submitted before 3:00 PM are processed the same day with
+immediate settlement; transactions after cut-off time are processed the next
+business day. Customers must ensure sufficient funds in their accounts before
+initiating payments; insufficient balance transactions are declined or may incur
+overdraft charges if applicable. Transaction limits apply based on channel
+security levels with higher limits for branch transactions and lower limits for
+digital channels, which can be customized per customer request. The Bank
+verifies beneficiary account details including account number and title before
+processing to minimize payment errors, though ultimate responsibility for
+correct beneficiary information rests with the customer. All payment
+instructions are irrevocable once processed; however, the Bank will make
+reasonable efforts to recall erroneously sent payments if notified immediately.
+Customers are required to review transaction confirmations and report
+discrepancies within 24 hours for digital transactions and 7 days for branch
+transactions.
+5. Customer Responsibilities
+Customers must verify beneficiary account details including bank name, branch,
+account number, and account title before initiating payments to prevent
+misdirected transfers. Sufficient account balance or available credit limit must
+be maintained before authorizing payments; customers are liable for overdraft
+charges if payments cause negative balances. Customers using digital channels
+must safeguard login credentials, transaction PINs, and OTP codes; sharing
+credentials with others may result in liability for unauthorized transactions.
+Any unauthorized transactions must be reported immediately to the Bank's 24/7
+helpline to enable fraud investigation and potential recovery actions. Customers
+should retain transaction confirmations, reference numbers, and receipts as
+proof of payment for reconciliation and dispute resolution purposes. Standing
+instructions for recurring payments must be updated or cancelled at least three
+business days before the next scheduled payment date. Customers are responsible
+for ensuring that payment purposes comply with legal and regulatory
+requirements; the Bank may decline payments suspected to be for illegal
+purposes. For high-value transactions exceeding PKR 500,000, customers may be
+required to provide supporting documentation or source of funds information as
+per AML/CFT requirements.
+6. Bank Responsibilities
+Amanah Bank shall process payment instructions in the sequence received,
+adhering to established cut-off times and service level agreements for each
+payment channel. The Bank will provide immediate confirmation for successful
+payments including unique transaction reference numbers for tracking and dispute
+resolution. Failed transactions due to technical issues, beneficiary account
+problems, or network downtime are communicated to customers immediately with
+clear explanation and resolution timelines. The Bank maintains 24/7 transaction
+monitoring systems to detect fraud patterns, duplicate payments, and suspicious
+activities, intervening when necessary to protect customers. Customers are
+alerted through SMS, email, or app notifications for all debit transactions
+above PKR 10,000 to enable immediate fraud detection. The Bank shall maintain
+detailed transaction logs including timestamps, IP addresses, device
+information, and authorization records for audit and dispute investigation
+purposes. In cases of payment errors caused by Bank systems or staff, the Bank
+will rectify the error immediately and compensate customers for any financial
+losses including lost interest or penalty charges. The Bank provides multiple
+customer service channels including helpline, email, and branch support to
+address payment-related queries and complaints within specified response
+timelines.
+7. Exceptions / Disclosures
+Transaction limits vary by channel: branch transactions up to PKR 5,000,000 per
+day, internet banking up to PKR 500,000 per day, mobile banking up to PKR
+200,000 per day, subject to customer-specific customization requests. These
+limits are subject to periodic review and may be temporarily reduced during
+security threats. Same-day processing cut-off times are strictly enforced;
+transactions submitted after cut-off are processed the next business day
+regardless of urgency, except for emergency situations with senior management
+approval. The Bank is not liable for delays caused by beneficiary bank systems,
+national payment network issues, or circumstances beyond the Bank's control;
+however, reasonable efforts are made to expedite processing. Payments to new
+beneficiaries may undergo additional verification procedures including cool-off
+periods or phone confirmations to prevent fraud, causing processing delays. The
+Bank reserves the right to decline payment instructions without assigning
+reasons if transactions trigger AML/CFT alerts, sanctions screening hits, or
+fraud detection systems. Charges for payment services are as per the published
+fee schedule and may vary based on transaction value, urgency, and channel used;
+fee waivers may apply for premium account holders or promotional periods.
+8. Compliance and Review
+This policy complies with State Bank of Pakistan payment system regulations,
+electronic fund transfer guidelines, and consumer protection directives
+governing payment services. Payment processing systems undergo annual external
+audits to verify security controls, transaction accuracy, and disaster recovery
+capabilities. The policy is reviewed semi-annually to incorporate technological
+advancements, regulatory changes, and customer experience improvements.
+Transaction success rates, processing times, and customer complaints are
+monitored through daily dashboards with escalation mechanisms for service
+degradation. Customer disputes regarding payment transactions are tracked with
+root cause analysis to identify systemic issues requiring policy or system
+modifications. Staff training on payment products, fraud detection, and customer
+service protocols is conducted quarterly with certification requirements for
+operations personnel. The Bank maintains comprehensive business continuity plans
+ensuring alternative payment processing capabilities during system outages or
+disasters.
+3.2 Cheque Handling and Clearing Policy
+1. Purpose
+This policy establishes guidelines for issuing, depositing, clearing, and
+managing cheques to ensure secure, efficient processing while preventing fraud
+and financial losses. It aims to balance the convenience of cheque transactions
+with necessary security controls and regulatory requirements. The policy
+protects both cheque issuers and beneficiaries while gradually encouraging
+migration to electronic payment alternatives.
+2. Scope
+This policy applies to all cheque books issued by Amanah Bank, cheques deposited
+for collection, cheque clearing processes, and dishonored cheque handling. It
+covers personal cheques, corporate cheques, pay orders, demand drafts, and
+banker's cheques. The policy governs cheque book issuance procedures, deposit
+methods (branch, ATM, mobile), clearing timelines, stop payment instructions,
+and dishonor reasons and consequences. It applies to local cheques within the
+clearing zone and outstation cheques requiring longer clearing periods.
+3. Definitions
+Cheque: Written instruction by account holder directing the Bank to pay
+specified amount to the bearer or named beneficiary. Cheque Clearing: Process of
+presenting cheques to drawee banks for payment and settling inter-bank
+obligations. Dishonored Cheque: Cheque returned unpaid due to insufficient
+funds, signature mismatch, or other irregularities. Stop Payment: Customer
+instruction to the Bank not to honor a specific cheque. Clearing Cycle: Time
+period from cheque deposit to funds availability in beneficiary account.
+Truncated Cheque: Cheque converted to electronic image for clearing rather than
+physical movement. Account Payee Cheque: Cheque marked to be deposited only in
+payee's bank account, not encashable over the counter.
+4. Policy Statement
+Amanah Bank provides cheque facilities to account holders as a traditional
+payment instrument while encouraging adoption of faster electronic payment
+methods. Cheque books are issued only to account holders maintaining
+satisfactory account conduct with no history of cheque dishonor or fraudulent
+activities. Standard cheque books contain 25 leaves with adequate security
+features including watermarks, micro-printing, and UV ink to prevent
+counterfeiting. Local cheques deposited before 2:00 PM on business days are
+cleared within 24 hours with funds available by the next business day; deposits
+after cut-off time are processed the following day. Outstation cheques require
+7-10 business days for clearing depending on the drawee bank location and
+correspondent banking arrangements. Cheques presented over six months from the
+date of issuance are considered stale and will not be honored unless revalidated
+by the drawer. The Bank employs image-based cheque truncation systems where
+available to expedite clearing and reduce operational costs and risks. Post-
+dated cheques presented before the mentioned date are returned; however, the
+Bank advises against issuing post-dated cheques as they create legal and
+operational complications. Customers are liable for all valid cheques drawn on
+their accounts regardless of whether cheques were lost or stolen, unless timely
+stop payment instructions were issued.
+5. Customer Responsibilities
+Customers must safeguard cheque books securely and immediately report loss or
+theft to the Bank to prevent fraudulent usage; the Bank is not liable for
+cheques encashed before stop payment instructions are recorded. Cheques must be
+written clearly in permanent ink with no overwriting or corrections; amount in
+words and figures must match, and signature must correspond to specimen
+signatures on record. Customers issuing cheques are responsible for maintaining
+sufficient balance until cheque clearing; dishonored cheques may result in
+penalties, account restrictions, and legal consequences. When depositing
+cheques, customers must endorse the reverse side with signature and account
+number; endorsements should match account holder name to prevent fraud.
+Customers should verify cheque deposits through account statements and report
+any missing credits within 30 days to enable investigation and recovery. Stop
+payment requests must be submitted in writing with complete cheque details
+including cheque number, date, amount, and payee name at least 24 hours before
+anticipated presentation. Customers receiving dishonored cheques should promptly
+represent them or pursue legal recourse as per negotiable instruments
+regulations; representing beyond reasonable timeframes may weaken legal claims.
+Corporate customers issuing high volumes of cheques should implement dual
+signatory controls and reconcile issued versus presented cheques regularly.
+6. Bank Responsibilities
+Amanah Bank shall issue cheque books within three business days of request,
+ensuring adequate security features and verification of requestor's identity and
+authorization. The Bank will inspect deposited cheques for validity including
+signature verification, date checks, alterations detection, and clearing zone
+determination before accepting for collection. Image-based clearing systems are
+utilized wherever possible to provide faster fund availability and reduce
+physical instrument handling risks. Cheques deposited through ATMs or mobile
+channels undergo additional verification, and provisional credit may be provided
+subject to final clearing confirmation. The Bank shall immediately act on stop
+payment instructions received with complete information, blocking cheque
+presentation and returning if presented subsequently. Dishonored cheques are
+promptly returned to depositing customers with clear reason codes including
+"insufficient funds," "signature mismatch," "account closed," or other specific
+reasons. The Bank maintains comprehensive audit trails of all cheque
+transactions including images, clearing records, and dishonor reasons for
+dispute resolution and regulatory compliance. Customers are alerted through SMS
+or email when cheques are dishonored or when unusually large cheques are
+presented against their accounts. The Bank provides special collection services
+for high-value cheques with expedited clearing and guaranteed fund availability
+for premium customers at applicable charges.
+7. Exceptions / Disclosures
+Cheque clearing timelines are subject to drawee bank processes, clearing house
+schedules, and holidays; the Bank provides estimated timelines but cannot
+guarantee exact clearing dates. Funds from deposited cheques may be available
+immediately or after clearing based on customer relationship, cheque amount, and
+risk assessment; provisional credit policies vary. Cheque dishonor penalties as
+per the published fee schedule apply to drawers; repeated dishonors may result
+in cheque facility suspension, account closure, and reporting to credit bureaus.
+The Bank may place holds on cheques exceeding certain thresholds or from high-
+risk sources until clearing confirmation, which may cause temporary
+inconvenience to depositors. Stop payment services are provided on a best-effort
+basis; if a cheque is presented and cleared before stop payment instructions are
+processed, the Bank is not liable for the payment. Cheques with material
+alterations, cutting, or overwriting are liable to be dishonored even if changes
+appear to be authenticated; customers should issue fresh cheques rather than
+correcting errors. Legal action against dishonored cheques is the payee's
+responsibility; the Bank does not pursue legal cases on behalf of depositors
+though cooperation is provided in legal proceedings.
+8. Compliance and Review
+This policy adheres to State Bank of Pakistan cheque clearing regulations,
+Negotiable Instruments Act, cheque truncation system guidelines, and banker-
+customer relationship principles. Cheque processing systems undergo quarterly
+audits to verify signature verification accuracy, fraud detection effectiveness,
+and clearing timeline compliance. The policy is reviewed annually with focus on
+fraud prevention enhancements, clearing efficiency improvements, and customer
+education on electronic payment alternatives. Cheque dishonor rates, fraud
+incidents, and clearing delays are monitored through management dashboards with
+corrective actions for anomalies. Customer complaints regarding delayed
+clearing, wrongful dishonors, or processing errors are investigated within 5
+business days with compensation for Bank errors. Staff training on cheque
+security features, signature verification techniques, and fraud typologies is
+conducted semi-annually with competency assessments. The Bank collaborates with
+clearing houses and other banks to enhance cheque truncation adoption, fraud
+intelligence sharing, and standardization of clearing practices.
+3.3 Transaction Dispute Resolution Policy
+1. Purpose
+This policy establishes procedures for customers to dispute payment
+transactions, report unauthorized activities, and seek resolution of transaction
+errors or frauds. It ensures fair, transparent, and timely handling of disputes
+while protecting both customer interests and Bank's operational integrity. The
+policy aims to build customer trust through responsive complaint management and
+appropriate liability allocation.
+2. Scope
+This policy applies to all payment transaction disputes including unauthorized
+debits, incorrect transaction amounts, processing errors, duplicate charges,
+failed transactions with debit, merchant disputes, ATM discrepancies, and fraud-
+related claims. It covers transactions across all channels including branches,
+ATMs, internet banking, mobile banking, POS terminals, and e-commerce platforms.
+The policy governs dispute reporting timelines, investigation procedures,
+provisional credit policies, liability determination, and resolution
+communication. It excludes disputes related to loans, credit cards, and
+investment products which are governed by specific product policies.
+3. Definitions
+Transaction Dispute: Customer claim that a transaction was unauthorized,
+erroneous, or fraudulent. Unauthorized Transaction: Transaction not initiated or
+approved by the customer or authorized user. Provisional Credit: Temporary
+credit provided to customer during dispute investigation, subject to reversal if
+dispute is not substantiated. Chargeback: Process of reversing a card
+transaction and returning funds to cardholder, typically for merchant disputes
+or fraud. Fraud: Intentional deception to secure unfair financial gain through
+unauthorized access or false claims. Dispute Window: Time period within which
+customers can report disputes for investigation and potential resolution. Good
+Faith Claim: Dispute reported with honest belief of error or fraud without
+intention to defraud the Bank.
+4. Policy Statement
+Amanah Bank is committed to addressing transaction disputes promptly and fairly,
+protecting customers from unauthorized transactions while preventing fraudulent
+claims. Customers must report disputed transactions within 60 days of the
+transaction date or statement date, whichever is earlier; claims beyond this
+period may not be entertained except in exceptional circumstances. Disputes can
+be reported through multiple channels including 24/7 helpline, email, mobile
+app, internet banking, or by visiting any branch with supporting documentation.
+Upon receiving a dispute, the Bank assigns a unique reference number and
+initiates investigation involving transaction log analysis, system audit,
+merchant verification, or communication with other banks. For unauthorized
+transaction claims reported within 3 days, the Bank provides provisional credit
+within 10 business days while investigation continues, provided the claim meets
+good faith criteria. Final resolution is communicated within 30 days for most
+disputes and 90 days for complex cases involving multiple parties or
+international networks. If investigation confirms error or fraud caused by Bank
+systems, merchants, or third parties, the customer is fully compensated
+including any consequential charges like overdraft fees. If investigation
+reveals customer negligence such as sharing credentials, delayed reporting, or
+failure to maintain security, liability may be partially or fully assigned to
+the customer. The Bank may prosecute customers making false or fraudulent
+dispute claims, and such customers may face account closure and legal action.
+5. Customer Responsibilities
+Customers must monitor account transactions regularly through statements,
+internet banking, or mobile app and report discrepancies immediately upon
+discovery. Disputed transactions should be reported as soon as possible within
+the 60-day window; delayed reporting weakens investigation effectiveness and may
+result in liability assignment to customer. When reporting disputes, customers
+must provide complete information including transaction date, amount, merchant
+name, reason for dispute, and any supporting evidence such as cancellation
+confirmations or communications. Customers must preserve evidence related to
+disputes including receipts, messages, emails, and refrain from physical
+tampering with cards or documents. During investigation, customers should
+cooperate by responding to Bank queries, providing additional documentation,
+signing affidavits if required, and attending in-person meetings if necessary.
+Customers must not simultaneously dispute transactions with merchants and the
+Bank without informing both parties; double recovery attempts constitute fraud.
+If provisional credit is provided, customers should use funds responsibly
+understanding that reversal may occur if dispute is not substantiated. Customers
+filing disputes in bad faith or making repeated false claims may face account
+restrictions, closure, and legal consequences.
+6. Bank Responsibilities
+Amanah Bank shall acknowledge dispute reports immediately upon receipt and
+provide unique reference numbers for tracking and follow-up purposes. The Bank
+will investigate disputes objectively by reviewing transaction logs,
+authentication records, IP addresses, device fingerprints, merchant responses,
+and other relevant evidence. Customers are updated on investigation progress at
+least every 10 days through SMS, email, or phone calls regarding case status.
+Provisional credit is provided for qualifying unauthorized transaction claims
+within 10 business days to minimize financial hardship during investigation. If
+Bank systems, staff errors, or technical failures caused the disputed
+transaction, the Bank immediately reverses the transaction and compensates for
+consequential damages. The Bank maintains confidentiality of dispute information
+and shares details only with parties directly involved in investigation such as
+payment networks or correspondent banks. Final investigation outcomes with
+detailed explanations are communicated in writing, including rationale for
+liability determination and customer's rights to escalate if dissatisfied. The
+Bank documents all disputes, investigations, and resolutions comprehensively for
+audit purposes, regulatory compliance, and pattern analysis to prevent future
+occurrences. Dispute trends are analyzed monthly to identify systemic issues,
+fraud patterns, or process gaps requiring corrective actions.
+7. Exceptions / Disclosures
+The 60-day dispute reporting window is strictly enforced except in cases of
+serious illness, extended overseas travel, or other genuine circumstances
+preventing timely reporting, which require documentary proof. Provisional credit
+policies apply primarily to unauthorized transaction claims; other dispute types
+such as merchant disputes or service quality issues may not receive provisional
+credit. The Bank's maximum liability for unauthorized transactions is limited to
+the account balance or transaction amount, whichever is lower, and does not
+extend to indirect losses or consequential damages except where Bank negligence
+is established. Disputes related to transactions authenticated with correct PIN,
+password, or biometric verification face higher proof requirements as
+authentication implies customer involvement. Customers sharing credentials,
+writing down PINs, or failing to update security information may bear full
+liability for resulting unauthorized transactions. Merchant disputes require
+customers to first attempt resolution with merchants directly; the Bank
+initiates chargebacks only if merchant resolution fails within reasonable
+timeframes. International transaction disputes may take longer to resolve due to
+multiple parties involved and different jurisdictions, potentially extending
+beyond standard 30-day timelines.
+8. Compliance and Review
+This policy complies with State Bank of Pakistan consumer protection guidelines,
+electronic banking regulations, payment system directives, and card network
+rules on dispute resolution. Dispute handling processes undergo semi-annual
+audits to verify compliance with timelines, provisional credit policies, and
+fair investigation practices. The policy is reviewed annually incorporating
+regulatory updates, industry best practices, and learnings from dispute case
+studies. Dispute resolution metrics including volumes, investigation timelines,
+reversal rates, and customer satisfaction scores are reported monthly to senior
+management. Customer complaints regarding dispute handling are escalated to the
+Banking Mohtasib or regulatory authorities if not resolved satisfactorily within
+Bank's internal grievance mechanism. Staff training on dispute investigation
+techniques, fraud detection, evidence evaluation, and customer empathy is
+conducted quarterly with scenario-based assessments. The Bank participates in
+industry forums to share fraud intelligence, dispute trends, and collaborate on
+reducing systemic vulnerabilities enabling unauthorized transactions.
+Category 4: Card Issuance and Usage Policies
+4.1 Debit Card Issuance and Management Policy
+1. Purpose
+This policy establishes comprehensive guidelines for issuing, managing, and
+securing debit cards to enable convenient access to account funds while
+protecting customers from fraud and unauthorized usage. It ensures customers
+understand card features, fees, usage limits, and security responsibilities. The
+policy aims to provide seamless payment experiences while maintaining robust
+fraud prevention measures.
+2. Scope
+This policy applies to all debit cards issued by Amanah Bank linked to savings
+or current accounts including domestic debit cards, international debit cards,
+contactless cards, and virtual cards. It covers card issuance procedures,
+activation requirements, PIN management, transaction limits, usage restrictions,
+liability for unauthorized transactions, card blocking and replacement, and card
+cancellation processes. The policy governs card usage at ATMs, POS terminals, e-
+commerce platforms, and contactless payment scenarios across all geographies
+where cards are enabled.
+3. Definitions
+Debit Card: Payment card linked to customer's bank account enabling ATM
+withdrawals, POS purchases, and online transactions debited directly from the
+account. Personal Identification Number (PIN): Secret numeric code known only to
+cardholder for authenticating ATM and certain POS transactions. Card
+Verification Value (CVV): Three-digit security code printed on card reverse used
+for online and telephone transactions. Contactless Payment: Transaction
+completed by tapping card near NFC-enabled terminal without PIN for small
+amounts. Card Blocking: Temporary or permanent suspension of card to prevent
+unauthorized usage. Chip and PIN: Security technology using embedded microchip
+and PIN authentication for enhanced transaction security. Virtual Card: Card
+number generated for online usage without physical card issuance.
+4. Policy Statement
+Amanah Bank issues debit cards to account holders in good standing to provide
+convenient 24/7 access to their funds for cash withdrawals and payments.
+Standard debit cards are issued free of charge for primary account holders;
+additional or replacement cards may incur fees as per the published schedule.
+Debit cards are valid for three years from issuance and are automatically
+renewed one month before expiry with new cards dispatched to registered
+addresses. Cards must be activated within 30 days of receipt through ATM, phone
+banking, or internet banking using the provided activation code; unactivated
+cards are automatically cancelled. The default PIN is system-generated and
+delivered separately from the card through secure courier; customers must change
+PIN at first use for security. Transaction limits apply based on card type and
+customer profile with standard daily limits of PKR 50,000 for ATM withdrawals
+and PKR 200,000 for POS/online transactions, customizable upon request.
+Customers are liable for all transactions authenticated with correct PIN until
+the card is reported lost or stolen; post-reporting liability is limited to zero
+for unauthorized transactions. The Bank employs real-time fraud detection
+systems monitoring unusual transaction patterns, geographic anomalies, and high-
+risk merchant categories, temporarily blocking cards when suspicious activity is
+detected. Contactless transactions below PKR 5,000 do not require PIN;
+cumulative contactless limits may trigger PIN requirements to maintain security.
+5. Customer Responsibilities
+Customers must sign the signature panel on the card reverse immediately upon
+receipt and activate cards through prescribed secure channels before usage. PINs
+must be memorized and never written down, shared with others including family
+members or bank staff, or stored electronically on phones or computers.
+Customers should regularly monitor card transactions through SMS alerts, mobile
+app notifications, and account statements, reporting unauthorized transactions
+immediately. Lost, stolen, or compromised cards must be reported through 24/7
+helpline immediately; any delay in reporting may result in customer liability
+for unauthorized transactions during the delay period. Customers are responsible
+for ensuring sufficient account balance before card transactions; insufficient
+balance transactions are declined and may incur charges if the transaction
+causes temporary overdraft. Cards should be used only at secure, reputable
+merchants and ATMs; customers should inspect ATMs for skimming devices and
+shield PIN entry from view. For online transactions, customers must verify
+website authenticity, use secure networks, and never save CVV codes on e-
+commerce platforms. Cards remain Bank property and must be surrendered upon
+account closure, card blocking, or Bank's request; cutting cards in half before
+disposal prevents fraudulent usage.
+6. Bank Responsibilities
+Amanah Bank shall issue debit cards within 10 business days of account opening
+or card request, delivering cards and PINs through secure separate couriers to
+registered addresses. The Bank will clearly communicate card features, fees,
+transaction limits, and security best practices through welcome kits, website,
+and mobile app. Real-time SMS and email alerts are sent for all card
+transactions above PKR 1,000 enabling immediate fraud detection and reporting.
+The Bank maintains 24/7 helpline for card blocking, complaint registration, and
+emergency support particularly when customers are traveling. Fraud detection
+systems monitor transactions continuously, temporarily blocking cards when
+unusual patterns emerge and contacting customers for verification before
+unblocking. Upon receiving lost or stolen card reports, the Bank immediately
+blocks the card within 5 minutes preventing further unauthorized transactions.
+Replacement cards are issued within 5 business days at applicable charges, with
+emergency replacement options available for traveling customers. The Bank
+investigates disputed card transactions thoroughly, providing provisional credit
+where appropriate and reversing transactions proven to be fraudulent or
+unauthorized. Card-related complaints are resolved within 15 business days with
+regular status updates to customers.
+7. Exceptions / Disclosures
+Transaction limits are enforced per 24-hour rolling period; exceeding limits
+results in transaction decline regardless of account balance. Limits can be
+increased temporarily for travel or specific needs through phone banking or
+branch requests. International usage is disabled by default for security;
+customers must activate international transactions through mobile app or phone
+banking before overseas travel. Merchant category blocks apply to certain high-
+risk categories like gambling, adult content, or cryptocurrency exchanges; such
+transactions are declined even within transaction limits. Contactless
+transaction limits are regulatory-mandated and cannot be customized; cumulative
+contactless transactions trigger PIN requirements per security protocols. The
+Bank is not liable for transaction declines caused by technical issues with
+merchant terminals, payment network downtime, or international transaction
+restrictions. Cards may be blocked without notice if fraud is suspected,
+excessive failed PIN attempts occur, or when accounts have legal attachments or
+regulatory restrictions. Annual maintenance charges apply for premium
+international debit cards as per fee schedule with charges debited quarterly to
+linked accounts.
+8. Compliance and Review
+This policy complies with State Bank of Pakistan regulations on payment cards,
+international card network (Visa/Mastercard) rules, and consumer protection
+directives for electronic banking. Card issuance and transaction processing
+systems undergo annual PCI-DSS (Payment Card Industry Data Security Standard)
+audits ensuring highest security standards. The policy is reviewed annually
+incorporating technological advancements, emerging fraud patterns, and customer
+feedback on card services. Card fraud rates, dispute volumes, and block-
+replacement cycles are monitored through daily dashboards with immediate
+escalation for unusual spikes. Customer complaints regarding card disputes,
+unauthorized transactions, or service quality are analyzed monthly to identify
+process improvements. Staff training on card products, fraud prevention, and
+customer service protocols is conducted quarterly with certification
+requirements for customer-facing employees. The Bank collaborates with payment
+networks, law enforcement, and other banks to combat card fraud through
+intelligence sharing and coordinated fraud prevention initiatives.
+4.2 ATM Usage and Safety Policy
+1. Purpose
+This policy provides comprehensive guidelines for safe and effective use of
+Automated Teller Machines (ATMs) by Amanah Bank customers to prevent fraud,
+ensure personal safety, and optimize ATM services. It establishes customer
+responsibilities, Bank obligations, and security protocols governing ATM
+transactions. The policy aims to maximize ATM convenience while minimizing
+security risks and operational issues.
+2. Scope
+This policy applies to all ATM transactions including cash withdrawals, balance
+inquiries, mini statements, PIN changes, and fund transfers conducted at Amanah
+Bank's own ATMs and other banks' ATMs through shared networks. It covers ATM
+card usage, transaction limits, fees, dispute resolution, safety precautions,
+and liability for unauthorized withdrawals. The policy governs on-site ATMs
+located at bank branches, off-site ATMs in public locations, and white-label
+ATMs operated by third parties. It applies 24/7 across all ATM operational
+hours.
+3. Definitions
+ATM (Automated Teller Machine): Electronic banking machine enabling customers to
+perform financial transactions without teller assistance. On-Us ATM: ATM owned
+and operated by Amanah Bank where customer transactions typically incur no fees.
+Off-Us ATM: ATM owned by another bank accessed through shared payment networks
+with applicable interchange fees. Skimming: Fraudulent practice of capturing
+card data through devices installed on ATMs to create duplicate cards. Shoulder
+Surfing: Theft technique where criminals observe customers entering PINs at
+ATMs. Card Trapping: Fraud method where devices retain cards in ATMs to enable
+theft. Failed Transaction: ATM transaction that doesn't complete successfully
+but may debit customer account pending reversal.
+4. Policy Statement
+Amanah Bank operates an extensive ATM network enabling 24/7 cash withdrawals,
+balance inquiries, and basic banking services for customer convenience.
+Transactions at Amanah Bank ATMs (on-us) are free of charge; transactions at
+other banks' ATMs (off-us) may incur interchange fees as per the published
+schedule with first two transactions monthly free. Daily ATM withdrawal limits
+are set at PKR 50,000 for standard cards and PKR 100,000 for premium cards to
+balance convenience with security. ATM transaction failures where accounts are
+debited but cash is not dispensed are auto-reversed within 7 business days after
+investigation; customers should report failures immediately for expedited
+resolution. The Bank implements comprehensive ATM security measures including
+CCTV surveillance, periodic security audits, anti-skimming devices, and customer
+education programs. Customers are advised to use Amanah Bank's own ATMs
+preferably for enhanced security and free transactions, especially in unfamiliar
+locations. ATMs displaying signs of tampering, unusual attachments, or
+suspicious behavior of nearby persons should be avoided, and such incidents
+reported to Bank security. For personal safety, customers should avoid using
+ATMs in isolated locations during late hours, keep cash discreetly after
+withdrawal, and remain vigilant of surroundings. The Bank is liable for
+unauthorized ATM withdrawals caused by technical failures or security breaches
+proven to be beyond customer control, but not for losses due to customer
+negligence.
+5. Customer Responsibilities
+Customers must memorize ATM PINs and never write them on cards, store them in
+wallets, or share with anyone including family members or individuals claiming
+to be bank staff. Before inserting cards, customers should inspect ATMs for
+unusual devices, card slot attachments, fake keypads, or camera installations
+that may indicate skimming attempts. PIN entry should be shielded using the
+other hand or body to prevent shoulder surfing or hidden cameras from capturing
+PIN information. Cash should be counted immediately after withdrawal while still
+at the ATM and reported immediately if the dispensed amount is incorrect.
+Customers should not accept help from strangers at ATMs, particularly if cards
+are retained or transactions fail; assistance should be sought from Bank's
+helpline only. Transaction receipts should be properly stored or destroyed;
+leaving receipts at ATM locations exposes account information to potential
+fraudsters. If ATM retains the card, customers must immediately call the
+helpline to block the card before leaving the location; retrieving retained
+cards may take 2-3 business days through branch channels. Customers must report
+lost or stolen ATM cards within one hour of discovery to minimize potential
+liability for unauthorized withdrawals.
+6. Bank Responsibilities
+Amanah Bank shall maintain ATMs in optimal working condition with regular cash
+replenishment, currency note quality checks, and technical maintenance
+schedules. ATM locations are chosen with security considerations including
+adequate lighting, CCTV coverage, proximity to populated areas, and physical
+securityRetrySMContinue6. Bank Responsibilities (continued)
+ATM locations are chosen with security considerations including adequate
+lighting, CCTV coverage, proximity to populated areas, and physical security
+measures like security guards where feasible. The Bank shall install anti-
+skimming devices, tamper-evident seals, and secure card readers on all ATMs with
+quarterly inspections by security teams to detect any tampering attempts. CCTV
+footage from ATMs is retained for 90 days to support dispute investigations,
+fraud detection, and law enforcement requirements. ATM failure incidents where
+cash is not dispensed but accounts are debited are investigated within 24 hours
+with reversal processing initiated immediately upon confirmation. Customers are
+alerted through SMS and email for all ATM withdrawals above PKR 10,000 enabling
+immediate fraud detection and card blocking if unauthorized. The Bank provides
+24/7 helpline support for ATM-related issues including card retention, failed
+transactions, disputes, and emergency card blocking with dedicated ATM support
+specialists. Periodic customer awareness campaigns are conducted through SMS,
+email, app notifications, and branch posters educating about ATM safety,
+skimming prevention, and secure banking practices. The Bank maintains strategic
+partnerships with law enforcement agencies to combat ATM fraud through
+surveillance data sharing, fraud intelligence, and joint investigations.
+7. Exceptions / Disclosures
+ATM withdrawal limits are enforced strictly; attempting multiple withdrawals to
+exceed daily limits results in transaction decline and potential temporary card
+blocking for security. First two transactions at other banks' ATMs are free per
+month; subsequent off-us transactions incur fees of PKR 15-25 per transaction as
+per inter-bank agreements. ATM services may be temporarily unavailable during
+scheduled maintenance windows typically conducted between 1:00 AM - 4:00 AM,
+communicated through advance notices. Cash withdrawal denominations are subject
+to ATM availability; the Bank strives to provide multiple denominations but
+cannot guarantee specific note denominations. The Bank is not liable for ATM
+withdrawal disputes if PIN entry is authenticated correctly and transaction logs
+show normal processing without technical anomalies. Customers withdrawing
+maximum daily limits at unfamiliar locations or during unusual hours may trigger
+fraud alerts resulting in temporary card blocking requiring verification before
+unblocking. ATMs located in remote or high-risk areas may have reduced cash
+withdrawal limits or restricted operational hours for security reasons. Failed
+transactions at third-party ATMs require coordination with host banks; reversal
+timelines may extend to 15 days for off-us transaction failures.
+8. Compliance and Review
+This policy adheres to State Bank of Pakistan ATM operation guidelines, Payment
+Systems and Electronic Fund Transfers Act, and security standards prescribed for
+electronic banking channels. ATM security infrastructure including anti-skimming
+devices, CCTV systems, and physical security measures undergoes quarterly audits
+by internal security teams and annual external security assessments. The policy
+is reviewed semi-annually incorporating emerging fraud techniques, technological
+security enhancements, and customer feedback on ATM experiences. ATM
+availability metrics, transaction success rates, dispute volumes, and fraud
+incidents are monitored daily through centralized dashboards with immediate
+escalation for anomalies. Customer complaints regarding ATM failures,
+unauthorized withdrawals, or safety concerns are investigated within 5 business
+days with resolution communication and compensation where applicable. Staff
+training on ATM dispute resolution, fraud investigation techniques, and customer
+communication protocols is conducted quarterly. The Bank invests continuously in
+next-generation ATM technologies including biometric authentication, cardless
+transactions, and advanced anti-fraud systems to enhance security and
+convenience.
+Category 5: Interest Rate and Deposit Policies
+5.1 Savings Account Interest Policy
+1. Purpose
+This policy establishes transparent guidelines for calculating, crediting, and
+disclosing interest on savings accounts to ensure fair compensation for customer
+deposits while maintaining competitive rates. It aims to provide clear
+understanding of interest computation methods, rate determination factors, and
+tax implications. The policy ensures regulatory compliance while optimizing
+returns for savers across different account types and balance tiers.
+2. Scope
+This policy applies to all savings account variants offered by Amanah Bank
+including regular savings accounts, premium savings accounts, senior citizen
+accounts, women's savings accounts, and children's savings accounts. It covers
+interest rate determination, calculation methodologies, crediting frequencies,
+minimum balance requirements for interest earning, and tax deduction procedures.
+The policy governs rate revisions, customer notification procedures, and
+disclosure requirements. It excludes fixed deposits and term deposits which have
+separate interest policies based on maturity periods and investment amounts.
+3. Definitions
+Interest Rate: Annual percentage rate paid by the Bank on savings account
+balances. Annual Percentage Yield (APY): Effective annual rate including
+compounding effect. Minimum Balance: Threshold balance required to earn interest
+on savings accounts. Average Daily Balance: Sum of daily closing balances
+divided by days in the period, used for interest calculation. Tiered Interest:
+Different interest rates applied to different balance slabs within the same
+account. Withholding Tax: Tax deducted at source by the Bank on interest income
+before crediting to accounts. Profit Rate: Return on Islamic savings accounts
+calculated through profit-sharing rather than fixed interest.
+4. Policy Statement
+Amanah Bank offers competitive interest rates on savings accounts determined
+based on State Bank policy rates, market conditions, funding costs, and
+competitive positioning, reviewed monthly by the Asset-Liability Committee.
+Interest is calculated on the daily closing balance using the Average Daily
+Balance method, ensuring customers earn proportionate returns regardless of
+balance fluctuations during the month. Standard savings accounts earn interest
+at rates ranging from 5% to 8% per annum based on balance tiers: PKR 0-50,000
+earns 5% p.a., PKR 50,001-500,000 earns 6.5% p.a., and balances exceeding PKR
+500,000 earn 8% p.a. Interest is compounded monthly and credited to accounts on
+the last business day of each month, appearing in statements as "Interest
+Credit" with clear rate and calculation details. Minimum balance of PKR 1,000
+must be maintained throughout the month to qualify for interest; accounts
+falling below this threshold earn zero interest for that month. Senior citizens
+(above 60 years) receive preferential rates with an additional 0.5% premium over
+standard rates recognizing their savings needs. Women's savings accounts and
+children's accounts receive promotional rates typically 0.25%-0.5% higher than
+standard accounts as part of financial inclusion initiatives. Interest income is
+subject to withholding tax at applicable rates (currently 15% for filers and 30%
+for non-filers) deducted at source before crediting, with annual tax
+certificates provided for tax filing purposes. Rate changes are communicated
+through multiple channels including website updates, mobile app notifications,
+branch displays, and direct communication for rate reductions affecting existing
+customers.
+5. Customer Responsibilities
+Customers must maintain minimum balance of PKR 1,000 throughout the month to
+earn interest; falling below this amount even briefly disqualifies the entire
+month from interest earning. Customers should provide accurate National Tax
+Number (NTN) or CNIC for proper tax status determination; failure to provide tax
+information results in higher withholding tax deduction. Tax certificates issued
+annually by the Bank must be included in personal tax returns; customers are
+responsible for declaring interest income and reconciling with tax authorities.
+Customers should monitor interest credits monthly through statements or digital
+channels and report discrepancies within 30 days to enable investigation and
+correction. Maintaining updated contact information ensures timely receipt of
+interest rate change notifications, allowing customers to make informed
+decisions about fund allocation. Customers dissatisfied with rate changes have
+the right to close accounts and move funds to alternative investments without
+penalties, maintaining financial autonomy. Senior citizens claiming preferential
+rates must provide valid age proof through CNIC or birth certificate; false age
+claims constitute fraud punishable under law.
+6. Bank Responsibilities
+Amanah Bank shall calculate interest accurately using the Average Daily Balance
+method with automated systems ensuring error-free computation and timely monthly
+crediting. The Bank will maintain transparent disclosure of current interest
+rates through website, mobile app, branch displays, and customer service
+channels with updates within 24 hours of rate revisions. Rate determination
+follows documented methodology approved by senior management with considerations
+including central bank policy rates, competitive landscape, and institutional
+funding requirements. Customers are notified at least 15 days in advance of
+interest rate reductions through SMS, email, or written communication, allowing
+time for alternate arrangements if desired. Interest rate increases are
+implemented immediately with retrospective application where feasible,
+maximizing customer benefits without delay. The Bank shall deduct withholding
+tax accurately based on customer's filer/non-filer status with proper tax code
+application and quarterly reporting to Federal Board of Revenue. Annual tax
+certificates detailing gross interest earned, tax deducted, and net interest
+credited are provided by January 31st each year for preceding calendar year. The
+Bank maintains detailed interest calculation worksheets, rate change approvals,
+and customer notifications as audit evidence for regulatory compliance and
+dispute resolution. Customer complaints regarding interest calculation errors or
+rate application issues are investigated within 10 business days with immediate
+correction and compensation including lost interest.
+7. Exceptions / Disclosures
+Interest rates are variable and subject to change based on economic conditions,
+central bank policy changes, and competitive pressures; the Bank does not
+guarantee rate stability. Promotional interest rates for new accounts or
+specific campaigns have defined validity periods mentioned in promotional
+materials; reverting to standard rates occurs automatically post-promotion.
+Islamic savings accounts follow profit-sharing mechanisms instead of fixed
+interest rates; profit rates fluctuate based on Bank's investment returns and
+are declared monthly. Accounts with dormant status do not earn interest during
+the dormancy period even if balances exceed minimum thresholds; interest resumes
+upon reactivation. Staff accounts, related party accounts, and accounts with
+special arrangements may have different interest rate structures governed by
+internal policies or contractual agreements. Interest earned on balances below
+PKR 10,000 may not be credited monthly but accumulated and credited quarterly to
+optimize operational costs. Tax status changes during the year affect
+withholding rates prospectively; customers must update tax status promptly to
+avoid excess deductions.
+8. Compliance and Review
+This policy complies with State Bank of Pakistan regulations on interest rates,
+banking company ordinance provisions on deposit pricing, and tax laws governing
+withholding tax deductions. Interest calculation systems undergo annual external
+audits verifying accuracy, tax deduction correctness, and compliance with
+approved rate structures. The policy is reviewed quarterly or immediately upon
+State Bank policy rate changes, ensuring alignment with monetary policy
+objectives and competitive positioning. Interest rate competitiveness analysis
+is conducted monthly comparing rates against peer banks, with recommendations to
+senior management for rate adjustments. Customer complaints regarding interest
+calculations, tax deductions, or rate communications are tracked with root cause
+analysis to identify systemic issues. Staff training on interest calculation
+methodologies, tax regulations, and customer communication regarding rate
+changes is conducted semi-annually. The Bank maintains comprehensive
+documentation of rate revisions, justifications, approval authorities, and
+customer communication records for regulatory inspection and audit purposes.
+5.2 Fixed Deposit Account Policy
+1. Purpose
+This policy establishes guidelines for fixed deposit accounts offering customers
+higher interest returns in exchange for committed deposit periods, balancing
+liquidity constraints with attractive yields. It ensures transparent disclosure
+of terms, premature withdrawal consequences, and renewal options. The policy
+aims to mobilize customer savings while providing predictable funding sources
+for Bank's lending operations.
+2. Scope
+This policy applies to all fixed deposit products including standard term
+deposits, special tenure deposits, senior citizen deposits, monthly income
+deposits, and jumbo deposits offered by Amanah Bank. It covers tenure options
+ranging from 1 month to 5 years, minimum deposit requirements, interest rate
+structures, maturity procedures, premature withdrawal rules, and automatic
+renewal options. The policy governs nomination facilities, loan against deposit
+provisions, and tax treatment of fixed deposit interest. It applies to
+individual and joint fixed deposits excluding corporate deposits governed by
+treasury policies.
+3. Definitions
+Fixed Deposit (FD): Time-bound deposit with predetermined interest rate and
+maturity date. Tenure: Committed deposit period ranging from 1 month to 5 years.
+Maturity Date: Date when fixed deposit completes its tenure and becomes payable
+with interest. Premature Withdrawal: Closing fixed deposit before maturity date
+with interest penalty. Auto-Renewal: Automatic reinvestment of matured deposit
+for same tenure at prevailing rates. Compounding Frequency: Periodic interval
+(monthly/quarterly/annually) for interest capitalization. Cumulative Deposit: FD
+where interest is compounded and paid at maturity. Non-Cumulative Deposit: FD
+where interest is paid periodically (monthly/quarterly) rather than at maturity.
+4. Policy Statement
+Amanah Bank offers fixed deposits with tenures from 1 month to 5 years providing
+guaranteed returns ranging from 7% p.a. for 1-3 month deposits to 10% p.a. for
+5-year deposits, with rates higher than savings accounts reflecting liquidity
+premium. Minimum deposit amount is PKR 10,000 with no maximum limit; however,
+jumbo deposits exceeding PKR 10 million may receive negotiated premium rates
+subject to treasury approval. Interest rates are fixed at booking and remain
+constant throughout the tenure regardless of subsequent market rate changes,
+providing return certainty to depositors. Customers choose between cumulative
+deposits where interest compounds and pays at maturity, or non-cumulative
+deposits providing periodic interest payouts monthly or quarterly as per
+preference. Senior citizens above 60 years receive preferential rates with
+additional 0.5% premium across all tenures recognizing retirement income needs.
+Premature withdrawal is permitted with penalty of 1-2% reduction from contracted
+rate depending on actual holding period, discouraging early withdrawals while
+retaining customer flexibility. Upon maturity, deposits auto-renew for the same
+tenure at prevailing rates unless customers provide contrary instructions at
+least 7 days before maturity; maturity alerts are sent 15 days in advance.
+Customers can avail loans or overdrafts against fixed deposits up to 90% of
+deposit value at preferential interest rates typically 2-3% above deposit rate,
+providing liquidity without breaking deposits. Fixed deposit receipts are issued
+as proof containing deposit amount, tenure, interest rate, maturity date, and
+maturity value, serving as negotiable instruments transferable by endorsement.
+Nomination facility is mandatory for fixed deposits enabling smooth transmission
+to nominees upon depositor's death without legal complications.
+5. Customer Responsibilities
+Customers must carefully evaluate liquidity needs before booking fixed deposits
+as premature withdrawals attract penalties reducing effective returns
+significantly. Deposit tenure selection should align with financial goals, cash
+flow requirements, and interest rate expectations for optimal returns. Customers
+must preserve fixed deposit receipts securely as they are valuable documents
+required for maturity claims, premature withdrawals, or loan against deposit
+applications. Maturity instructions including renewal preferences or fund
+transfer details should be communicated at least 7 days before maturity date to
+ensure smooth processing. Customers opting for auto-renewal should monitor rate
+changes and evaluate if renewed rates meet return expectations; renewals can be
+reversed within 7 days of maturity date if dissatisfied. For joint fixed
+deposits, operating instructions (either or survivor/former or survivor/jointly)
+must be clearly specified at booking to avoid disputes during maturity or
+premature withdrawal. Customers must update nomination details upon life events
+such as marriage, childbirth, or nominee's death to ensure intended
+beneficiaries receive deposits. Tax documentation including National Tax Number
+should be provided for accurate withholding tax deduction; updates to tax status
+must be communicated promptly. Customers should verify maturity credits to
+accounts within 5 business days of maturity date and report any delays or
+discrepancies immediately.
+6. Bank Responsibilities
+Amanah Bank shall issue fixed deposit receipts immediately upon booking
+containing all material terms including deposit amount, tenure, interest rate,
+compounding frequency, maturity date, and maturity value prominently displayed.
+The Bank will calculate maturity values accurately using specified interest
+rates and compounding methods, with systems ensuring error-free computation.
+Maturity alerts are sent 15 days before maturity through SMS, email, and phone
+calls informing customers of impending maturity and renewal terms. Upon
+maturity, if no contrary instructions exist, deposits auto-renew at prevailing
+rates for same tenure with renewal confirmation sent to customers within 24
+hours. Customers providing maturity instructions receive funds through their
+chosen method (account credit, cheque, transfer) within 24 hours of maturity
+date. Premature withdrawal requests are processed within 3 business days with
+clear communication of penalty charges and net amount payable before processing
+for customer confirmation. The Bank maintains detailed records of fixed deposit
+bookings, rate cards applicable at booking dates, maturity registers, and
+premature withdrawal approvals for audit and dispute resolution. Interest earned
+is subject to withholding tax deducted at source with accurate tax certificates
+provided annually detailing gross interest, tax deducted, and net interest.
+Customer complaints regarding interest calculation errors, maturity processing
+delays, or rate disputes are investigated within 7 business days with immediate
+rectification where Bank errors are established.
+7. Exceptions / Disclosures
+Fixed deposit rates are subject to change for new bookings but existing deposits
+retain contracted rates throughout tenure, insulating depositors from rate
+reductions but forgoing benefits of rate increases. Jumbo deposits exceeding PKR
+10 million receive special rates negotiated with treasury desk based on amount,
+tenure, and relationship value; rate negotiations require senior management
+approval. Staff deposits, related party deposits, and special relationship
+deposits may have different rate structures, premature withdrawal terms, or
+privileges governed by internal policies. Premature withdrawal within the first
+month of booking attracts higher penalties (3-4% reduction) to discourage
+immediate withdrawals post-booking. Fixed deposits can serve as collateral for
+loans with 90% loan-to-value; however, deposits remain frozen until loan
+repayment, restricting premature withdrawal or partial withdrawals. Auto-renewal
+occurs at prevailing rates which may be lower than original booking rates during
+falling rate environments, potentially disappointing customers expecting
+original rates. Tax rates on fixed deposit interest apply as per tax laws with
+higher rates for non-filers; customers are responsible for understanding tax
+implications before investing. In cases of depositor death, transmission to
+nominees requires legal documentation (death certificate, nominee
+identification) processed within 15 business days of complete documentation
+submission.
+8. Compliance and Review
+This policy complies with State Bank of Pakistan deposit mobilization
+guidelines, banking company ordinance provisions on fixed deposits, and
+regulatory directives on nomination facilities. Fixed deposit systems undergo
+annual audits verifying interest calculation accuracy, premature withdrawal
+penalty applications, and maturity processing timelines. The policy is reviewed
+semi-annually incorporating regulatory changes, competitive positioning
+requirements, and customer feedback on deposit products. Fixed deposit portfolio
+analytics including tenure distribution, premature withdrawal rates, and auto-
+renewal percentages are monitored monthly to inform product and pricing
+strategies. Customer complaints regarding fixed deposit terms, maturity
+processing, or premature withdrawal penalties are analyzed quarterly to identify
+policy refinements needed. Staff training on fixed deposit products, interest
+calculation, premature withdrawal processing, and customer advisory is conducted
+quarterly ensuring consistent service delivery. The Bank maintains comprehensive
+documentation of rate cards, jumbo deposit negotiations, premature withdrawal
+approvals, and exception cases for regulatory compliance and internal audits.
+Category 6: Lending and Credit Policies
+6.1 Personal Loan Policy
+1. Purpose
+This policy establishes comprehensive guidelines for evaluating, approving,
+disbursing, and managing personal loans to enable customers to meet legitimate
+financial needs while ensuring responsible lending and credit risk management.
+It balances customer access to credit with prudent underwriting standards
+protecting both borrower and Bank interests. The policy promotes financial
+inclusion while maintaining asset quality and regulatory compliance.
+2. Scope
+This policy applies to all unsecured personal loans offered by Amanah Bank for
+purposes including medical emergencies, education, marriage, home renovation,
+debt consolidation, and other personal needs. It covers loan eligibility
+criteria, documentation requirements, credit assessment procedures, loan amounts
+and tenures, interest rates and charges, disbursement methods, repayment terms,
+and default consequences. The policy governs salaried and self-employed
+borrowers, co-borrower arrangements, and guarantor requirements. It excludes
+secured loans (mortgage, auto), business loans, and credit cards which have
+separate policies.
+3. Definitions
+Personal Loan: Unsecured credit facility for personal needs repaid through fixed
+monthly installments. Principal Amount: Loan amount disbursed to borrower
+excluding interest and charges. Equated Monthly Installment (EMI): Fixed monthly
+repayment amount including principal and interest components. Tenure: Loan
+repayment period ranging from 12 to 60 months. Annual Percentage Rate (APR):
+Total borrowing cost including interest rate and charges expressed annually.
+Debt-to-Income Ratio (DTI): Percentage of borrower's monthly income committed to
+debt obligations. Credit Score: Numerical representation of borrower's
+creditworthiness based on credit history. Default: Failure to make scheduled EMI
+payment resulting in loan delinquency.
+4. Policy Statement
+Amanah Bank offers personal loans ranging from PKR 50,000 to PKR 2,000,000 with
+tenures from 1 to 5 years to help customers meet diverse financial needs
+responsibly. Eligibility requires minimum age 21 years, maximum age 60 years at
+loan maturity, minimum monthly income PKR 30,000 for salaried and PKR 50,000 for
+self-employed, and minimum 6 months employment/business continuity. Loan amounts
+are determined based on income multiples (maximum 10x monthly income) and debt-
+to-income ratio (total monthly obligations should not exceed 50% of monthly
+income including proposed loan). Interest rates range from 15% to 22% per annum
+based on credit profile, income stability, employment sector, and relationship
+with Bank, reviewed monthly aligned with policy rate changes. Processing fees of
+1-2% of loan amount (minimum PKR 1,000) and documentation charges apply as per
+fee schedule, collected upfront from loan disbursement reducing net proceeds.
+Credit assessment includes verification of employment, income documentation,
+credit bureau checks (minimum credit score 650), banking transaction analysis,
+and reference checks to establish repayment capacity. Loan disbursement occurs
+within 7 business days of approval through direct credit to borrower's Amanah
+Bank account; accounts must be maintained throughout loan tenure for EMI
+deductions. EMI auto-debit from salary accounts is mandatory for salaried
+borrowers; insufficient balance EMI returns attract penalties and adverse credit
+bureau reporting. Part-prepayment (minimum PKR 10,000) and foreclosure are
+permitted after 6 months with charges of 3-5% on prepaid amount compensating
+Bank for interest loss. Defaults trigger recovery proceedings including legal
+action, asset attachment, guarantor liability invocation, and negative credit
+bureau reporting affecting future creditworthiness.
+5. Customer Responsibilities
+Customers must provide accurate, complete, and verifiable information regarding
+employment, income, existing obligations, and personal details during loan
+application; false information constitutes fraud with criminal consequences.
+Supporting documents including salary slips/bank statements (last 6 months),
+employment letter, CNIC, utility bills, and existing loan statements must be
+genuine originals; submission of forged documents leads to application rejection
+and legal action. Customers should borrow amounts commensurate with genuine
+needs and repayment capacity; over-borrowing creates financial stress and
+default risks damaging creditworthiness. Loan proceeds must be used for stated
+purposes; misuse for speculative investments, gambling, or illegal activities
+violates loan terms and may trigger recall. Sufficient balance must be
+maintained in auto-debit accounts on EMI due dates (typically salary credit
+date); managing cash flows to ensure EMI payment is customer's responsibility.
+Customers must promptly inform the Bank of employment changes, income
+reductions, or financial difficulties enabling proactive restructuring rather
+than defaults. Part-prepayment and foreclosure opportunities should be utilized
+when surplus funds are available to reduce interest costs and complete
+obligations early. Customers should preserve loan agreements, repayment
+schedules, and payment receipts as proof of obligations and track loan closure
+certificates upon full repayment.
+6. Bank Responsibilities
+Amanah Bank shall assess loan applications objectively within 5 business days
+using standardized credit scoring models, income verification procedures, and
+credit bureau checks ensuring consistent treatment. The Bank will clearly
+disclose all loan terms including principal amount, interest rate, processing
+fees, EMI amount, total interest payable, total repayment amount, and APR in
+loan agreements and marketing materials. Loan agreements in simple language
+highlighting key terms, prepayment provisions, default consequences, and
+customer rights are provided with adequate time for review before signing.
+Disbursement occurs only after customer acknowledgment of terms, completion of
+documentation, and quality control verification of eligibility and
+creditworthiness. The Bank shall send monthly loan statements detailing EMI
+deducted, principal/interest bifurcation, outstanding balance, and next EMI due
+date through SMS, email, or physical statements. Customers facing temporary
+financial difficulties are offered restructuring options including EMI reduction
+through tenure extension, moratorium periods, or interest rate adjustments
+subject to eligibility. The Bank maintains transparent recovery processes
+beginning with reminders for missed EMIs, progressing to default notices, and
+legal action only as last resort after exhausting resolution attempts. Upon loan
+closure, completion certificates are issued within 7 business days and positive
+closure reported to credit bureaus enhancing customer credit profiles for future
+borrowing.
+7. Exceptions / Disclosures
+Personal loans are unsecured facilities carrying higher interest rates than
+secured loans reflecting credit risk; customers should compare options before
+choosing personal loans over secured alternatives. Interest rates are floating
+linked to Bank's base rate plus customer-specific spread; policy rate changes by
+State Bank may cause EMI adjustments with prior notification. Processing fees
+and documentation charges are non-refundable even if customers prepay or
+foreclose loans; these cover upfront assessment and origination costs incurred
+by Bank. Loan amounts for self-employed borrowers may be lower than salaried
+borrowers at similar income levels due to income stability considerations and
+verification challenges. Customers with existing Amanah Bank loans may face
+cumulative exposure limits restricting additional borrowings regardless of
+individual loan eligibility. Co-borrowers or guarantors improve loan eligibility
+and amounts but undertake joint and several liability; all parties are equally
+responsible for full loan repayment. Partial payments or payments less than EMI
+amounts are not accepted; customers must pay full EMI to avoid default
+classification and penalties. Loan insurance products may be offered to cover
+EMI payments during unemployment, disability, or death; these are optional with
+separate premiums not included in quoted interest rates.
+8. Compliance and Review
+This policy complies with State Bank of Pakistan prudential regulations on
+consumer financing, responsible lending guidelines, and Consumer Protection
+departments directives on disclosure and fair practices. Loan origination
+processes undergo quarterly audits verifying KYC compliance, income verification
+adequacy, credit assessment consistency, and documentation completeness. The
+policy is reviewed annually incorporating regulatory changes, credit performance
+analytics, and best practices in consumer lending. Loan portfolio quality
+metrics including delinquency rates, default rates, and loss rates are monitored
+monthly with early warning systems triggering underwriting criteria tightening
+during deterioration. Customer complaints regarding loan rejections, interest
+calculations, recovery practices, or service quality are analyzed monthly to
+identify process improvements. Staff training on credit assessment, customer
+interaction, responsible lending principles, and regulatory compliance is
+conducted quarterly with competency certifications. The Bank maintains
+comprehensive credit files including applications, assessments, approvals,
+disbursement records, and repayment histories for regulatory inspection and
+audit purposes.
+6.2 Loan Recovery and Restructuring Policy
+1. Purpose
+This policy establishes fair, transparent, and legally compliant procedures for
+recovering overdue loans while providing support mechanisms for customers facing
+genuine financial difficulties. It balances Bank's obligation to protect
+depositor funds with empathy toward borrowers in distress. The policy aims to
+maximize recovery while maintaining customer dignity and exploring
+rehabilitation before resorting to legal action.
+2. Scope
+This policy applies to all retail loans including personal loans, auto loans,
+mortgage loans, and credit cards that become overdue or non-performing at Amanah
+Bank. It covers early-stage collection procedures, restructuring options for
+viable borrowers, write-off procedures for irrecoverable loans, legal recovery
+processes, and asset liquidation. The policy governs communication protocols
+with defaulting borrowers, third-party collection agency engagement, and
+reporting to credit bureaus. It applies from first missed payment through final
+resolution including legal proceedings and asset attachment.
+3. Definitions
+Overdue Loan: Loan with missed EMI payment beyond due date. Non-Performing Loan
+(NPL): Loan overdue for 90 days or more classified as impaired asset.
+Restructuring: Modification of loan terms including tenure extension, interest
+rate reduction, or moratorium to assist distressed borrowers. Write-Off:
+Accounting removal of uncollectible loan from balance sheet while continuing
+recovery efforts. Recovery: Process of collecting overdue amounts through
+voluntary repayment, asset liquidation, or legal proceedings. Guarantor: Third
+party who undertakes legal obligation to repay loan if primary borrower
+defaults. Collateral: Asset pledged as security for secured loans, subject to
+attachment and sale during default.
+4. Policy Statement
+Amanah Bank initiates recovery processes immediately upon EMI default, beginning
+with courteous reminders escalating progressively based on delinquency duration
+while maintaining respect and dignity toward customers. First missed EMI
+triggers automated SMS and email reminders within 24 hours followed by phone
+calls within 3 days to understand reasons and encourage immediate payment. Loans
+overdue 30-60 days enter enhanced collection with dedicated relationship
+managers engaging borrowers to understand difficulties and explore voluntary
+resolution including part-payments or restructuring. Borrowers facing temporary
+financial setbacks due to job loss, medical emergencies, business disruptions,
+or natural calamities are offered restructuring options including tenure
+extension (reducing EMI), moratorium periods (deferring payments), or interest
+rate concessions subject to eligibility assessment. Restructuring requires
+written application with supporting documents proving financial distress,
+proposed repayment plan demonstrating recovery capacity, and may involve
+additional security or guarantors. Loans overdue 90 days are classified as Non-
+Performing Assets (NPA) with mandatory provisioning, credit bureau reporting as
+default, and initiation of legal recovery proceedings unless restructuring is
+approved. Legal notices are issued after 90 days default demanding full
+outstanding amount with interest, penal charges, and recovery costs; non-
+response within 30 days leads to civil suit filing for money recovery. For
+secured loans, the Bank may invoke arbitration clauses, initiate foreclosure
+proceedings, attach and auction pledged assets recovering dues from sale
+proceeds with surplus returned to borrowers. Guarantors are pursued parallely to
+primary borrowers with equal legal liability; guarantor harassment or undue
+pressure is prohibited with professional communication standards maintained.
+Third-party collection agencies may be engaged for overdue portfolios with
+strict oversight ensuring compliance with ethical practices, customer privacy
+protection, and prohibition of harassment tactics. Written-off loans remain
+legally enforceable; the Bank continues recovery efforts indefinitely until full
+recovery or legal time-barring, whichever earlier.
+5. Customer Responsibilities
+Customers must prioritize loan EMI payments treating them as non-negotiable
+obligations even during financial difficulties; proactive communication with
+Bank before defaults enables better resolution options. Upon anticipating
+payment difficulties, customers should immediately contact the Bank explaining
+circumstances, providing financial information, and proposing feasible repayment
+plans rather than avoiding communication. Customers must respond promptly to
+Bank's collection calls, emails, and notices; avoiding contact creates
+assumptions of willful default triggering aggressive recovery actions.
+Supporting documentation for restructuring requests including income proof,
+medical certificates, layoff letters, or business disruption evidence must be
+genuine and submitted promptly. Customers must honor restructuring terms
+committed including revised payment schedules, additional security deposits, or
+guarantor arrangements; second defaults after restructuring lead to immediate
+legal action. For secured loans, customers should maintain collateral assets in
+good condition and refrain from encumbering or disposing them; collateral damage
+or alienation constitutes breach enabling immediate recovery. Customers should
+keep the Bank informed of address changes, contact number updates, and
+employment status ensuring communication channels remain open throughout loan
+tenure. Upon receiving legal notices, customers should seek immediate resolution
+through settlement negotiations or legal representation; ignoring notices leads
+to ex-parte decrees and asset attachment without hearing opportunities.
+6. Bank Responsibilities
+Amanah Bank shall maintain professional, respectful communication during
+recovery processes avoiding harassment, abusive language, threats, public
+humiliation, or contact at unreasonable hours (before 7 AM or after 9 PM). The
+Bank will genuinely evaluate restructuring requests from customers facing
+verified financial hardships using standardized criteria, processing
+applications within 15 business days with clear approval or rejection
+communication. Restructuring terms are designed to balance customer
+affordability with Bank's recovery objective; terms are clearly documented with
+customer acknowledgment before implementation. The Bank shall maintain
+confidentiality of customer financial difficulties and default status, sharing
+information only with credit bureaus, legal authorities, or regulators as
+legally mandated. Third-party collection agencies engaged by the Bank are
+contractually bound to ethical practices; customer complaints regarding agency
+behavior are investigated with agency termination for violations. The Bank
+provides clear communication at each recovery stage including amount overdue,
+penal charges, recovery costs, legal consequences, and resolution options
+enabling informed customer decision-making. For secured loans, asset valuation
+is conducted by independent appraisers before foreclosure ensuring fair pricing;
+auction processes are transparent with adequate public notice. Surplus proceeds
+from asset sales after recovering Bank dues, legal costs, and auction expenses
+are promptly returned to borrowers within 30 days of sale completion. The Bank
+maintains comprehensive records of all recovery communications, restructuring
+decisions, legal proceedings, and asset sales for regulatory compliance and
+customer dispute resolution.
+7. Exceptions / Disclosures
+Restructuring is a relief mechanism, not an entitlement; the Bank reserves
+discretion to approve or reject restructuring based on credit assessment, past
+conduct, and recovery prospects even with valid hardship. Restructured loans
+attract higher interest rates (typically 2-3% premium) reflecting elevated
+credit risk and extended recovery timelines; total interest payable increases
+despite EMI reduction. Loans restructured once may not qualify for subsequent
+restructuring; repeated defaults after restructuring lead directly to legal
+action without further concessions. Penal interest charges ranging from 2-5% per
+month apply on overdue amounts from default date until recovery, significantly
+increasing repayment obligations discouraging delays. Legal costs including
+court fees, lawyer charges, and asset liquidation expenses are recovered from
+borrowers in addition to principal and interest increasing total liability.
+Credit bureau reporting of defaults remains for 7 years impacting future
+creditworthiness; loan closure doesn't erase past default history from credit
+reports. Recovery actions including asset attachment may cause significant
+personal disruption, reputational damage, and emotional stress; borrowers should
+prioritize avoiding defaults through proactive financial management. The Bank's
+exercise of legal rights doesn't prevent borrowers from challenging actions
+through consumer courts, banking mohtasib, or other legal forums as per
+applicable laws.
+8. Compliance and Review
+This policy complies with State Bank of Pakistan prudential regulations on loan
+classification and provisioning, debt recovery guidelines, and consumer
+protection directives prohibiting unfair recovery practices. Recovery processes
+undergo annual internal audits and external reviews verifying compliance with
+regulatory guidelines, ethical standards, and respect for customer dignity. The
+policy is reviewed annually incorporating regulatory updates, judicial
+precedents on recovery practices, and stakeholder feedback including consumer
+advocacy groups. Recovery efficiency metrics including collection rates,
+resolution timelines, legal recovery success rates, and restructuring
+performance are monitored monthly with strategy adjustments for
+underperformance. Customer complaints regarding recovery practices, harassment
+allegations, or restructuring rejections are investigated within 10 business
+days with corrective actions and staff counseling where violations occur. Staff
+and third-party agencies receive mandatory training on ethical recovery
+practices, communication skills, legal boundaries, and empathy toward distressed
+customers conducted quarterly. The Bank maintains comprehensive documentation of
+recovery actions including call logs, notices, restructuring evaluations, and
+legal proceedings for regulatory inspection and defending potential customer
+challenges.
+Category 7: Termination and Account Closure Policies
+7.1 Voluntary Account Closure Policy
+1. Purpose
+This policy establishes transparent procedures for customers to voluntarily
+close their accounts, ensuring smooth exit processes while settling all
+obligations and protecting customer interests. It aims to provide hassle-free
+account closure experiences while maintaining proper documentation and
+regulatory compliance. The policy respects customer choice while capturing
+feedback for service improvement.
+2. Scope
+This policy applies to all voluntary account closures initiated by customers
+including savings accounts, current accounts, fixed deposits, loan accounts, and
+credit card terminations at Amanah Bank. It covers closure request procedures,
+documentation requirementsRetrySMContinue2. Scope (continued)
+It covers closure request procedures, documentation requirements, settlement of
+balances, return of unused cheque books and cards, timeline for closure
+completion, and final statement issuance. The policy governs individual
+accounts, joint accounts, minor accounts, and corporate accounts across all
+channels including branch visits, digital closure requests, and telephone
+banking closures. It excludes involuntary closures initiated by the Bank which
+are governed by separate termination policies.
+3. Definitions
+Voluntary Closure: Account closure initiated by customer based on personal
+decision. Closure Request: Formal application submitted by customer requesting
+account termination. Settlement: Process of clearing all pending transactions,
+charges, and obligations before closure. Cooling Period: Waiting period between
+closure request and actual closure allowing pending transactions to settle.
+Final Statement: Last account statement issued showing final balance, closure
+date, and all transactions until closure. Credit Balance: Positive account
+balance payable to customer upon closure. Debit Balance: Negative account
+balance or outstanding obligations payable by customer before closure.
+4. Policy Statement
+Amanah Bank respects customer autonomy to close accounts at any time without
+requiring justification, ensuring exit processes are convenient, transparent,
+and completed within reasonable timeframes. Customers can initiate closure
+requests through branches by submitting written applications, or through
+internet/mobile banking for accounts without pending obligations or linked
+services. Account closure requires settlement of all obligations including
+outstanding cheques, pending bill payments, loan EMIs, credit card dues, and any
+fees or charges applicable. Credit balances are disbursed to customers through
+cheque, transfer to another bank account, or cash (for amounts below PKR 50,000)
+as per customer preference. For accounts with credit balances exceeding PKR
+10,000, identity verification through original CNIC and additional
+authentication questions ensure funds reach rightful owners preventing fraud.
+Cooling period of 7-10 business days applies between closure request and actual
+closure allowing pending transactions, standing instructions, and automated
+payments to clear preventing incomplete transactions. Fixed deposits closed
+before maturity require premature withdrawal processing with applicable
+penalties before account closure; alternatively, customers may wait until
+maturity for closure. Joint accounts require consent and signatures from all
+account holders as per operating instructions; single holder cannot unilaterally
+close joint accounts unless "either or survivor" mode permits. Minor accounts
+upon minor attaining majority age require closure of minor account and opening
+of regular adult account; guardian authorization terminates automatically upon
+minor turning 18 years. Unused cheque books, ATM cards, debit cards, and any
+other Bank property must be surrendered at closure cut into halves to prevent
+post-closure fraudulent usage. Closure confirmation with account closure
+certificate is issued immediately upon completion serving as proof for tax
+purposes, employer records, or future banking relationships. The Bank retains
+closed account records for 10 years as per regulatory requirements supporting
+potential tax audits, legal disputes, or customer queries regarding historical
+transactions.
+5. Customer Responsibilities
+Customers must submit formal closure requests in writing at branches or through
+authenticated digital channels with clear instructions regarding balance
+disposal. All outstanding obligations including loan EMIs, credit card dues,
+overdraft balances, and pending cheque payments must be cleared before closure;
+customers should verify no pending transactions exist. Customers should
+discontinue standing instructions, auto-debit mandates, direct deposits, and
+other automated transactions linked to accounts at least 15 days before closure
+requests to prevent transaction failures. Unused cheque books must be returned
+with all unused leaves intact; missing cheque leaves require stop payment
+instructions on those cheques before closure processing. ATM cards and debit
+cards must be physically surrendered cut in half across magnetic strip and chip
+ensuring they cannot be misused post-closure. For joint accounts, all holders
+must provide written consent with signatures; any holder objecting to closure
+can prevent closure requiring resolution among holders first. Customers should
+provide alternate account details for balance transfer or choose other
+disbursement methods clearly; ambiguous instructions delay closure processing.
+Fixed deposit premature withdrawal decisions should be made carefully
+considering penalty charges; customers may opt to transfer FDs to other banks
+instead of premature closure. Tax clearance certificates or no-objection
+certificates may be required for certain account types particularly NRI accounts
+or corporate accounts before closure approval.
+6. Bank Responsibilities
+Amanah Bank shall process closure requests within 10 business days from receipt
+of complete documentation and settlement of all obligations ensuring timely
+completion. The Bank will verify customer identity thoroughly during closure
+requests through original CNIC, signature verification, and additional
+authentication to prevent unauthorized closures. Complete account review is
+conducted identifying all pending transactions, standing instructions, linked
+services, automated payments, and active cheques before closure confirmation.
+Customers are informed of any pending obligations, active services, or
+complications preventing immediate closure with clear guidance on resolution
+steps. Credit balances are disbursed securely through customer's chosen method
+within 3 business days of closure approval after all clearances confirm. Final
+account statement covering all transactions until closure date including closure
+charges (if applicable) is provided immediately upon closure completion. Account
+closure confirmation certificates are issued stating account number, closure
+date, final balance settlement, and confirmation that no further obligations
+exist. The Bank sends closure confirmations to registered email and mobile
+numbers preventing fraudulent closures and enabling customers to challenge
+unauthorized closure attempts. Closure feedback surveys are conducted
+understanding reasons for closure, service deficiencies, and areas for
+improvement without pressuring customers to retain accounts. Closed account
+records are securely archived for 10 years with controlled access ensuring data
+privacy while maintaining regulatory compliance and supporting potential future
+queries.
+7. Exceptions / Disclosures
+Accounts with active loans, credit cards, or overdraft facilities cannot be
+closed until all credit facilities are fully settled; loan foreclosure with
+applicable charges must precede account closure. Fixed deposits with balances
+exceeding PKR 5,00,000 require additional verification including in-person
+branch visits regardless of digital closure request capability. Accounts under
+legal attachment, regulatory investigation, or dispute proceedings cannot be
+closed until legal clearances are obtained from courts or authorities. Dormant
+accounts require reactivation before closure with identity re-verification
+ensuring rightful owner initiates closure rather than fraudulent parties. The
+cooling period may extend beyond 10 days if pending cheques, international
+transactions, or complex standing instructions require extended clearing
+periods. Closure charges may apply for accounts closed within 6 months of
+opening (typically PKR 500) recovering account setup costs; waiver applies for
+senior citizens and financial hardship cases. Joint account closures with
+disputes among holders cannot proceed until legal resolution or unanimous
+agreement is achieved; the Bank doesn't adjudicate holder disputes. Customers
+closing accounts due to dissatisfaction are encouraged to escalate concerns to
+customer service management; however, closure requests are honored regardless of
+resolution outcomes respecting customer autonomy.
+8. Compliance and Review
+This policy complies with State Bank of Pakistan regulations on account closure,
+banker-customer relationship termination principles, and consumer protection
+guidelines ensuring fair exit processes. Account closure processes undergo
+annual audits verifying identity verification adequacy, settlement completeness,
+and timeline compliance. The policy is reviewed annually incorporating customer
+feedback on closure experiences, regulatory updates, and operational efficiency
+improvements. Closure metrics including turnaround times, customer satisfaction
+scores, and reasons for closure are analyzed monthly providing insights for
+retention strategies and service improvements. Customer complaints regarding
+closure delays, balance settlement disputes, or procedural difficulties are
+investigated within 5 business days with expedited resolution. Staff training on
+closure procedures, customer communication during exits, feedback collection,
+and retention conversation techniques is conducted semi-annually. The Bank
+maintains comprehensive closure records including applications, settlement
+confirmations, balance disposal records, and closure certificates for regulatory
+inspection and audit trails.
+7.2 Involuntary Account Termination Policy
+1. Purpose
+This policy establishes justifiable grounds and procedures for Bank-initiated
+account closures protecting institutional interests while ensuring fair
+treatment and due process for customers. It balances Bank's risk management
+obligations with customer rights to banking services. The policy aims to
+terminate problematic relationships while minimizing disputes and regulatory
+concerns.
+2. Scope
+This policy applies to all forced account closures initiated by Amanah Bank due
+to regulatory violations, fraudulent activities, persistent misuse, AML/CFT
+concerns, legal requirements, or unacceptable customer conduct. It covers
+decision-making authority, notification requirements, appeal procedures,
+settlement processes, and timelines for involuntary closures. The policy governs
+closures across all account types including deposit accounts, loan accounts,
+credit facilities, and complete customer relationship termination. It applies
+universally to individual, joint, corporate, and institutional customers.
+3. Definitions
+Involuntary Closure: Account termination initiated by Bank due to policy
+violations or risk concerns. Material Breach: Serious violation of account terms
+justifying immediate closure. Notice Period: Advance warning provided to
+customers before closure implementation allowing resolution opportunities. Right
+to Hearing: Customer's opportunity to present explanations before final closure
+decision. Blacklisting: Internal flagging preventing future account opening or
+banking relationship. Regulatory Closure: Account termination mandated by
+regulators or law enforcement. Risk-Based Closure: Termination due to
+unacceptable money laundering, fraud, or credit risk exposure.
+4. Policy Statement
+Amanah Bank reserves the right to terminate customer accounts and relationships
+when continuation poses unacceptable risks to the Bank, violates regulations, or
+breaches customer obligations despite being committed to long-term customer
+relationships. Grounds for involuntary closure include submission of false KYC
+information or forged documents, involvement in fraudulent transactions or money
+laundering activities, persistent cheque dishonor indicating financial
+mismanagement, account usage for illegal purposes, threatening or abusive
+behavior toward staff, failure to update KYC documents despite repeated
+requests, accounts designated by regulatory or law enforcement authorities, and
+material breach of account terms and conditions. Closure decisions are made by
+designated senior management committees after thorough investigation, evidence
+review, and consideration of customer responses ensuring objectivity and
+consistency. Customers are provided written notice at least 30 days before
+closure (except for fraud or legal cases requiring immediate action) explaining
+closure reasons and providing appeal opportunities. During notice period,
+account operations continue normally allowing customers to make alternate
+arrangements, settle obligations, and transfer funds to other banks minimizing
+disruption. Customers may appeal closure decisions within 15 days of notice by
+submitting written explanations, supporting documents, and requesting
+reconsideration by higher management or Bank's grievance committee. Upon closure
+confirmation, all credit facilities are recalled immediately, outstanding
+obligations become due, credit balances are disbursed after settling dues, and
+account closure certificates are issued. Customers whose accounts are closed for
+fraud, money laundering, or regulatory violations are blacklisted from future
+account opening at Amanah Bank and reported to credit bureaus and banking
+industry databases as appropriate. The Bank maintains confidentiality regarding
+closure reasons except when disclosure is legally required to regulators, law
+enforcement, or in response to court orders.
+5. Customer Responsibilities
+Customers receiving closure notices must immediately review reasons, assess
+validity, and respond within the appeal period if grounds exist for
+reconsideration. Outstanding obligations including loans, overdrafts, credit
+card dues, and any fees must be settled immediately upon closure notice; failure
+to settle leads to legal recovery actions. Customers should make alternate
+banking arrangements during notice period including opening accounts elsewhere,
+redirecting salary deposits, updating standing instructions, and informing
+beneficiaries of account changes. If closure reasons involve documentary
+deficiencies such as expired KYC documents, customers should promptly submit
+updated documents to prevent closure. Customers disputing closure decisions
+should provide substantive evidence contradicting Bank's findings rather than
+emotional appeals; factual documentation strengthens appeal cases. Issued
+cheques outstanding at closure may be dishonored causing payee inconvenience and
+legal complications; customers must inform payees and arrange alternate
+payments. Customers whose accounts are closed for cause should understand that
+negative information may be reported to credit bureaus affecting future
+creditworthiness and banking relationships. Legal recourse through Banking
+Mohtasib or consumer courts is available if customers believe closures are
+unjustified; however, pursuing legal action doesn't prevent closure
+implementation during proceedings.
+6. Bank Responsibilities
+Amanah Bank shall investigate thoroughly before closure decisions collecting
+evidence, reviewing transaction histories, obtaining staff inputs, and
+documenting findings comprehensively. Closure notices are sent through
+registered mail, email, and courier to all registered addresses ensuring
+customers receive notifications and have opportunities to respond. The notice
+clearly states specific closure reasons with sufficient detail enabling
+customers to understand violations and prepare responses if appealing. During
+notice period, the Bank remains open to customer explanations, documentary
+evidence, or remediation proposals that may reverse closure decisions. Appeals
+are reviewed by independent senior management not involved in initial closure
+decisions ensuring objective reconsideration without bias. Customers are
+informed of appeal outcomes within 15 business days with detailed explanations
+of final decisions and any conditions for decision reversal. Upon closure,
+complete account settlement is conducted calculating final obligations,
+adjusting for pending transactions, and determining net payable or receivable
+amounts. Credit balances are disbursed within 7 business days through customer's
+designated method after deducting any dues ensuring customers receive rightful
+funds. Closure confirmation certificates are issued documenting closure date,
+final settlement, and confirmation of no further obligations providing closure
+proof for customer records. The Bank maintains comprehensive closure files
+including investigation reports, notices, customer responses, appeal reviews,
+and final decisions for audit, regulatory inspection, and potential legal
+challenges.
+7. Exceptions / Disclosures
+Immediate closures without notice periods apply for fraud, money laundering,
+terrorist financing, or when regulators mandate urgent action protecting
+financial system integrity. Closure decisions are final after appeal processes;
+however, customers may seek external recourse through Banking Mohtasib or
+consumer forums as independent remedies. Accounts with active loans or credit
+facilities face accelerated repayment demands; entire outstanding balances
+become immediately due upon closure notification. Joint accounts face closure
+based on primary holder's violations; co-holders may open separate individual
+accounts if not implicated in violations. Blacklisting for closure cause
+prevents account opening across all Amanah Bank branches for a minimum period of
+3 years; longer periods apply for serious violations like fraud. The Bank is not
+obligated to disclose specific evidence or internal investigation details if
+disclosure compromises security, other investigations, or regulatory
+confidentiality. Customers may experience difficulties opening accounts
+elsewhere due to closure reasons visible in banking industry databases; this
+consequence is inherent to relationship termination for cause. Legal costs
+incurred by the Bank in closure-related disputes including staff time, legal
+fees, and recovery expenses may be charged to customers if legally permissible.
+8. Compliance and Review
+This policy complies with State Bank of Pakistan guidelines on account closure,
+AML/CFT reporting obligations, consumer protection regulations ensuring due
+process, and banking company ordinance provisions. Involuntary closure decisions
+undergo quarterly internal audits verifying procedural compliance, notice
+adequacy, appeal consideration, and documentation completeness. The policy is
+reviewed annually ensuring consistency with regulatory expectations, legal
+precedents from Banking Mohtasib decisions, and fairness standards. Closure
+statistics including grounds distribution, appeal success rates, and Mohtasib
+complaints are monitored quarterly identifying any patterns suggesting
+procedural improvements needed. Customer complaints regarding involuntary
+closures escalated to Mohtasib or regulatory authorities are analyzed for
+adverse decisions indicating policy or process deficiencies. Staff training on
+involuntary closure procedures, evidence documentation, customer communication,
+and appeal evaluation is conducted annually emphasizing fairness and due
+process. The Bank maintains indefinite records of involuntary closures including
+complete investigation files supporting decisions if challenged legally years
+after closure.
+B. Regulatory and Compliance Policies
+Category 8: Consumer Protection and Rights Policies
+8.1 Customer Rights and Fair Treatment Policy
+1. Purpose
+This policy establishes Amanah Bank's commitment to treating all customers
+fairly, transparently, and respectfully while protecting their fundamental
+rights as banking service consumers. It ensures equitable treatment regardless
+of socio-economic status, background, or transaction size. The policy aims to
+build trust through ethical conduct, transparency, and accountability in all
+customer interactions.
+2. Scope
+This policy applies to all customer interactions across all products, services,
+channels, and touchpoints at Amanah Bank including account management, lending,
+payments, customer service, complaint handling, and product sales. It covers
+rights to information, privacy, fair treatment, complaint redressal, grievance
+escalation, and protection from unfair practices. The policy governs employee
+conduct, marketing practices, product design, fee structures, and service
+delivery ensuring customer-centricity. It applies to all customers including
+individuals, small businesses, corporate clients, and prospective customers.
+3. Definitions
+Customer Rights: Fundamental entitlements of banking customers to fair
+treatment, transparency, privacy, and recourse. Fair Treatment: Equitable
+service delivery without discrimination based on account balance, relationship
+value, or personal characteristics. Transparency: Clear, accurate, and timely
+disclosure of terms, conditions, fees, and rights. Vulnerable Customer:
+Individuals requiring special consideration including seniors, disabled persons,
+financially unsophisticated, or distressed borrowers. Complaint: Customer
+expression of dissatisfaction regarding products, services, or staff conduct
+requiring resolution. Grievance: Unresolved complaint requiring escalation to
+higher management or external authorities.
+4. Policy Statement
+Amanah Bank commits to treating all customers with respect, dignity, and
+fairness regardless of account balance, transaction size, or relationship
+duration ensuring inclusive banking experiences. Customers have the right to
+clear, accurate information about products including features, fees, terms,
+conditions, and risks in simple language avoiding complex jargon or fine print
+deception. All terms and conditions are disclosed upfront before account opening
+or product purchase; hidden charges, surprise fees, or undisclosed terms are
+strictly prohibited. Customers have the right to choose products suitable for
+their needs without coercion, mis-selling, or incentive-driven product pushing
+by staff; suitability assessments precede product recommendations. Fair pricing
+applies universally; customers with similar profiles receive comparable pricing
+without arbitrary discrimination, though risk-based differentiation is permitted
+with clear rationale. Customers have the right to privacy and confidentiality;
+personal information is protected and shared only with consent or legal
+obligation without unauthorized disclosure or commercial exploitation. Complaint
+mechanisms are accessible through multiple channels including branches,
+helpline, email, and online platforms with acknowledgment within 24 hours and
+resolution commitments within specified timelines. Customers dissatisfied with
+complaint resolution have the right to escalate to senior management, internal
+ombudsman, Banking Mohtasib, or consumer courts without fear of retaliation or
+service deterioration. Vulnerable customers including seniors, disabled persons,
+non-literate customers, and financially distressed borrowers receive special
+consideration with patient service, simplified processes, and protection from
+exploitation. Customers have the right to exit banking relationships voluntarily
+without unreasonable restrictions, penalties, or obstacles honoring their
+autonomy to switch banks based on service satisfaction.
+5. Customer Responsibilities
+Customers must provide accurate, complete information during account opening,
+loan applications, and service requests enabling appropriate product
+recommendations and risk assessment. Customers should read and understand terms
+and conditions before signing agreements; seeking clarifications on unclear
+terms is encouraged rather than signing without comprehension. Banking products
+should be used for intended legitimate purposes; misuse for illegal activities,
+fraud, or policy violations enables Bank intervention including relationship
+termination. Customers should maintain confidentiality of banking credentials
+including passwords, PINs, OTPs, and account information preventing unauthorized
+access by third parties. Complaints should be raised through proper channels
+with factual information and supporting evidence rather than vague accusations
+or emotional outbursts facilitating objective investigation. Customers should
+respond to Bank communications regarding KYC updates, policy changes, or account
+irregularities within reasonable timeframes enabling compliance and issue
+resolution. Respectful, courteous interaction with Bank staff is expected;
+abusive behavior, threats, or violence toward employees is unacceptable and may
+result in relationship termination. Customers should honor financial commitments
+including loan repayments, maintaining minimum balances, and adhering to account
+terms; persistent violations affect relationship continuity and
+creditworthiness.
+6. Bank Responsibilities
+Amanah Bank shall design products and services with customer interests as
+primary consideration avoiding features intended to confuse, trap, or exploit
+customers for short-term profits. All marketing materials, product brochures,
+and advertisements are truthful, not misleading, and highlight risks alongside
+benefits ensuring informed customer decisions. Staff are trained to prioritize
+customer suitability over sales targets; mis-selling to achieve targets is
+prohibited with disciplinary consequences for violations. Fees and charges are
+displayed prominently on websites, branches, and mobile apps with advance notice
+before any changes enabling customers to make informed choices. Customer data is
+protected through robust cybersecurity measures, access controls, and staff
+training on privacy regulations preventing breaches and unauthorized
+disclosures. Complaints are handled professionally and objectively without
+dismissiveness or defensiveness; every complaint is investigated fairly with
+outcomes communicated transparently. The Bank maintains an internal ombudsman
+function for escalated grievances providing independent review and fair
+adjudication of customer-Bank disputes. Vulnerable customers receive dedicated
+support including priority service lanes, audio-visual aids for disabled
+customers, and financial counseling for distressed borrowers demonstrating
+social responsibility. Staff conduct is monitored through mystery shopping,
+customer feedback, and service audits; employees violating fair treatment
+principles face counseling, training, or disciplinary action. Customer feedback
+through surveys, focus groups, and complaint analysis informs continuous
+improvements in products, processes, and service delivery creating a customer-
+centric culture.
+7. Exceptions / Disclosures
+Fair treatment doesn't preclude risk-based differentiation in pricing, terms, or
+service levels based on objective credit risk, relationship value, or regulatory
+risk categorization with transparent rationale. Customers engaged in fraudulent
+activities, money laundering, or serious policy violations forfeit certain
+rights including continued relationship and may face legal action beyond normal
+customer treatment principles. The Bank's obligation to protect confidentiality
+yields to legal requirements including court orders, regulatory demands, tax
+authority requests, and AML/CFT reporting obligations. Complaint resolution
+timelines are best-effort commitments; complex cases involving multiple parties,
+external investigations, or legal issues may extend beyond standard timelines.
+Customer expectations of specific outcomes from complaints may not materialize;
+complaints are resolved based on evidence, policies, and fairness rather than
+customer demands. Vulnerable customer protections require self-identification or
+obvious indicators; the Bank cannot identify all vulnerable situations requiring
+customers to communicate special needs proactively. Banking Mohtasib or consumer
+court decisions may occasionally override Bank's internal decisions; the Bank
+complies with legal directives while reserving rights to appeal when
+appropriate. Customer rights to information, privacy, and fair treatment coexist
+with Bank's rights to protect interests, manage risks, and terminate
+relationships when continuation is untenable.
+8. Compliance and Review
+This policy aligns with State Bank of Pakistan Consumer Protection Department
+regulations, fair treatment principles in financial services, and international
+best practices in customer rights. Customer treatment practices undergo annual
+audits by compliance teams evaluating adherence to fair treatment commitments
+across all customer touchpoints. The policy is reviewed annually incorporating
+customer feedback, regulatory updates, Mohtasib decisions, and emerging consumer
+protection standards. Complaint data including volumes, categories, root causes,
+and resolution timelines are analyzed monthly identifying systemic issues
+requiring process or policy corrections. Mystery shopping exercises are
+conducted quarterly assessing staff adherence to fair treatment principles,
+transparency in information provision, and product suitability assessments.
+Customer satisfaction surveys are conducted semi-annually measuring perceptions
+of fairness, transparency, and service quality with results informing
+improvement initiatives. Staff training on customer rights, fair treatment,
+ethical conduct, and complaint handling is mandatory annually with competency
+assessments and refreshers for customer-facing employees. The Bank publishes
+annual consumer protection reports transparently disclosing complaint
+statistics, resolution rates, and improvement initiatives demonstrating
+accountability to customers and regulators.
+8.2 Complaint and Grievance Redressal Policy
+1. Purpose
+This policy establishes comprehensive, accessible, and time-bound procedures for
+customers to raise complaints and seek redressal ensuring responsive handling
+and fair resolution. It aims to convert customer dissatisfaction into
+opportunities for service improvement while demonstrating accountability. The
+policy provides clear escalation paths including external forums when internal
+resolution fails.
+2. Scope
+This policy applies to all customer complaints regarding products, services,
+transactions, fees, staff conduct, digital banking, loan processing, account
+management, or any aspect of banking relationship with Amanah Bank. It covers
+complaint registration channels, acknowledgment procedures, investigation
+processes, resolution timelines, escalation mechanisms, and closure protocols.
+The policy governs complaints from individual customers, joint account holders,
+corporate clients, and third parties authorized by customers. It extends to
+complaints raised directly with the Bank and those received through Banking
+Mohtasib, regulatory authorities, or social media platforms.
+3. Definitions
+Complaint: Customer expression of dissatisfaction with Amanah Bank's products,
+services, or staff requiring investigation and response. Grievance: Complaint
+unresolved at initial level requiring escalation to higher management for review
+and decision. Resolution: Bank's response addressing the complaint with
+explanation, corrective action, or compensation as appropriate. Turnaround Time
+(TAT): Maximum duration within which complaints at each level must be resolved.
+Escalation: Process of elevating unresolved complaints to higher authorities for
+reconsideration and final decision. Ombudsman: Independent internal authority
+reviewing escalated grievances providing impartial adjudication. Banking
+Mohtasib: External regulatory authority providing free dispute resolution
+between customers and banks.
+4. Policy Statement
+Amanah Bank welcomes customer complaints as valuable feedback for service
+improvement and commits to prompt, fair resolution through transparent
+processes. Customers can register complaints through multiple convenient
+channels including toll-free helpline (24/7), email addresses dedicated for
+complaints, complaint forms at all branches, internet banking complaint portals,
+mobile app complaint features, written letters to branch managers or head
+office, and social media platforms monitored by customer service teams. Every
+complaint receives unique reference numbers upon registration enabling tracking
+and follow-up throughout the resolution process. Complaints are acknowledged
+within 24 hours through SMS, email, or phone confirming receipt and providing
+reference number and expected resolution timeline. First-level complaints are
+resolved within 5 business days for simple matters and 15 business days for
+complex issues requiring detailed investigation. Customers receive regular
+status updates at least every 5 days during complaint investigation preventing
+perception of neglect or indifference. Resolution communications explain
+findings, decisions, actions taken, and rationale in clear language enabling
+customer understanding of outcomes. If customers are dissatisfied with first-
+level resolution, they can escalate to branch managers, regional managers, head
+office complaint cell, or internal ombudsman with each level providing fresh
+review. Final internal escalation to internal ombudsman must conclude within 30
+days of initial complaint registration providing definitive Bank position.
+Customers unsatisfied with internal resolution can approach Banking Mohtasib
+(free dispute resolution) or consumer courts (legal recourse) with the Bank
+fully cooperating in external proceedings. Compensation is provided when Bank
+errors cause customer losses including interest on delayed payments, penalty
+reversals, and reasonable consequential damages within defined limits. No
+retaliation, service deterioration, or relationship strain occurs due to
+complaint filing; customers are encouraged to raise concerns without fear of
+negative consequences.
+5. Customer Responsibilities
+Customers should provide complete, accurate information when registering
+complaints including account details, transaction references, dates, amounts,
+and specific grievances enabling efficient investigation. Supporting documents
+such as transaction receipts, email correspondence, SMS records, or photographs
+strengthen complaint credibility and facilitate resolution. Complaints should be
+raised within reasonable timeframes from the incident occurrence; delayed
+complaints make investigation difficult and may affect resolution possibilities.
+Customers must preserve complaint reference numbers and respond to Bank queries
+during investigation providing additional information or clarifications when
+requested. Exaggerated claims, false information, or frivolous complaints waste
+resources and undermine genuine grievances; customers should raise legitimate
+concerns honestly. While expressing dissatisfaction, customers should maintain
+civility and respect; abusive language, threats, or harassment of staff hinder
+constructive resolution. Customers should allow reasonable investigation time
+before escalating; premature escalations without allowing first-level resolution
+disrupt efficient complaint handling. Upon satisfactory resolution, customers
+should confirm closure enabling the Bank to officially close complaints and
+focus resources on pending issues.
+6. Bank Responsibilities
+Amanah Bank shall maintain easily accessible complaint channels with prominent
+display of contact information on websites, mobile apps, branches, and ATMs.
+Complaint registration systems capture complete information, assign unique
+references, and route complaints to appropriate departments based on nature and
+complexity. Acknowledgments are sent immediately (within 24 hours) through
+customer's preferred channel confirming receipt, providing reference number,
+designating responsible officer, and communicating expected resolution timeline.
+Investigations are conducted objectively reviewing transaction logs, staff
+inputs, system records, and customer evidence to establish facts before
+conclusions. Customers are updated regularly during investigation at minimum 5-
+day intervals through SMS, email, or phone calls preventing anxiety and
+demonstrating active handling. Resolution communications are clear,
+comprehensive, and empathetic explaining findings, decisions, and actions taken;
+when complaints are rejected, rationale is explained respectfully with evidence.
+Where Bank errors are established, corrective actions are implemented
+immediately including transaction reversals, fee refunds, interest compensation,
+and systemic fixes preventing recurrence. Escalated complaints receive senior
+management attention with fresh perspectives ensuring previous level conclusions
+are challenged if evidence supports customer claims. Root cause analysis is
+conducted on complaint patterns identifying systemic issues, process gaps, or
+training needs requiring organizational interventions beyond individual
+resolutions. Complaint data including volumes, categories, resolution rates, and
+customer satisfaction scores are published in annual reports demonstrating
+transparency and accountability.
+7. Exceptions / Disclosures
+Resolution timelines are best-effort commitments; highly complex complaints
+involving legal interpretations, external parties, or detailed investigations
+may exceed standard timelines with explanations provided. Complaints beyond
+Bank's control including inter-bank transaction delays, payment network issues,
+or third-party merchant problems have limited resolution options with best-
+effort facilitation. Compensation for Bank errors is limited to direct financial
+losses and reasonable consequential damages; indirect losses, emotional
+distress, or reputational damages typically aren't compensated unless legally
+mandated. Complaints raising allegations against specific employees are
+investigated confidentially; complainants may not receive details of internal
+disciplinary actions taken due to employee privacy considerations. Vexatious
+complaints filed repeatedly despite satisfactory resolutions, or complaints with
+malicious intent to harass staff, may be declined with limited investigation.
+Social media complaints receive public acknowledgment directing customers to
+private channels for detailed resolution; sensitive information isn't discussed
+publicly protecting privacy. Banking Mohtasib can adjudicate complaints up to
+PKR 1 million; higher value disputes require consumer court or civil litigation
+for resolution. Mohtasib decisions are binding on the Bank; compliance occurs
+within mandated timelines even if the Bank disagrees with decisions, though
+appeal rights exist in specific circumstances.
+8. Compliance and Review
+This policy complies with State Bank of Pakistan complaint management
+guidelines, Consumer Protection Department directives, Banking Mohtasib
+jurisdiction and procedures, and service quality standards. Complaint handling
+processes undergo quarterly audits assessing acknowledgment timeliness,
+investigation quality, resolution adequacy, and compliance with turnaround time
+commitments. The policy is reviewed annually incorporating regulatory updates,
+Mohtasib decisions, best practices, and customer feedback on complaint
+experiences. Complaint analytics including trending issues, resolution rates,
+escalation patterns, and customer satisfaction scores are presented monthly to
+senior management driving accountability and improvement. Mystery shopping
+evaluations assess complaint handling quality across channels testing staff
+responsiveness, empathy, and resolution effectiveness with findings feeding into
+training programs. Staff training on complaint handling, active listening,
+empathy, investigation techniques, and resolution communication is mandatory
+annually for all customer-facing employees. The Bank benchmarks complaint
+metrics against peer banks and international standards continuously raising
+service quality expectations and complaint handling excellence. Technology
+investments in complaint management systems, AI-driven categorization, and
+customer feedback tools are prioritized enhancing efficiency and customer
+experience.
+Category 9: Transparency and Ethical Conduct Policies
+9.1 Fee and Charge Transparency Policy
+1. Purpose
+This policy establishes comprehensive transparency in all fees, charges, and
+costs associated with banking products ensuring customers make informed
+financial decisions. It prevents hidden charges, surprise fees, and exploitative
+pricing practices. The policy aims to build trust through clear, upfront
+disclosure of all costs enabling customers to compare options and manage banking
+expenses effectively.
+2. Scope
+This policy applies to all fees and charges levied by Amanah Bank including
+account maintenance fees, transaction charges, ATM fees, loan processing fees,
+prepayment charges, penalty fees, service charges, and any other costs customers
+may incur. It covers disclosure requirements in marketing materials, product
+brochures, account opening documents, fee schedules, mobile apps, internet
+banking, and customer communications. The policy governs fee structure design,
+pricing methodologies, change notification procedures, and waiver eligibility.
+It applies to all products including deposits, loans, payments, cards, and
+digital banking services.
+3. Definitions
+Fee: Charge levied by the Bank for providing specific services or facilities.
+Service Charge: Periodic fee for account maintenance or facility availability
+regardless of usage. Transaction Charge: Fee levied per transaction such as ATM
+withdrawals, fund transfers, or cheque issuance. Penalty Fee: Charge imposed for
+policy violations such as minimum balance non-maintenance, cheque dishonor, or
+late loan payments. Processing Fee: One-time charge for processing applications
+such as loan origination or account opening. Hidden Charge: Fee not disclosed
+upfront or buried in fine print constituting unfair practice. Fee Schedule:
+Comprehensive document listing all applicable fees with amounts and conditions
+clearly specified.
+4. Policy Statement
+Amanah Bank commits to complete transparency in all fees and charges with
+upfront disclosure before customers commit to products or services eliminating
+surprises or hidden costs. A comprehensive fee schedule listing all charges
+across all products is published prominently on the Bank's website, mobile app,
+displayed at all branches, and provided in account opening kits ensuring easy
+accessibility. Fee schedules are written in simple language avoiding jargon,
+with clear descriptions of what each fee covers, when it applies, calculation
+methods, and any conditions or waivers available. At account opening or loan
+processing, customers receive personalized fee disclosures highlighting fees
+applicable to their specific products, anticipated transaction patterns, and
+estimated annual banking costs. Marketing materials and product advertisements
+disclose material fees prominently; attractive headline rates or features are
+not promoted without accompanying cost disclosures preventing misleading
+advertising. New fees or fee increases are communicated at least 30 days in
+advance through multiple channels including SMS, email, branch notices, website
+updates, and account statements allowing customers to adjust usage or close
+accounts if dissatisfied. Customers opting out within the notice period for fee
+increases are not charged increased fees and can close accounts without closure
+penalties respecting their right to reject new terms. Fee waivers are available
+for specific customer segments including senior citizens, persons with
+disabilities, students, low-balance accounts, and salary account holders as part
+of financial inclusion commitments clearly disclosed in fee schedules. Penalty
+fees are reasonable and proportionate to the violation or cost incurred by the
+Bank; excessive or punitive fees designed purely for revenue generation are
+prohibited. Digital channels including internet banking and mobile apps display
+applicable fees before transaction confirmation enabling customers to cancel if
+unwilling to pay charges.
+5. Customer Responsibilities
+Customers must review fee schedules before opening accounts or availing services
+understanding cost implications and assessing affordability and value
+proposition. During account opening, customers should ask staff to explain
+applicable fees, typical charges based on anticipated usage, and any fee waivers
+they may qualify for ensuring clear comprehension. Fee disclosures provided in
+account opening kits or loan agreements should be read carefully; signing
+constitutes acknowledgment of fees making subsequent disputes difficult.
+Customers should monitor account statements regularly identifying fee debits,
+verifying accuracy, and raising disputes promptly if unexplained or incorrect
+charges appear. Maintaining minimum balances, avoiding excessive transactions,
+or meeting fee waiver criteria are customer responsibilities to minimize banking
+costs through prudent account management. Customers dissatisfied with fee
+changes communicated in advance should exercise opt-out rights including account
+closure rather than continuing relationship and subsequently complaining. When
+comparing banking products across institutions, customers should consider total
+cost including all fees rather than focusing solely on interest rates or
+headline features for informed decisions. Customers seeking fee waivers should
+provide supporting documentation proving eligibility such as student IDs, senior
+citizen status, or disability certificates enabling Bank verification.
+6. Bank Responsibilities
+Amanah Bank shall maintain comprehensive, up-to-date fee schedules covering all
+products and services with regular reviews ensuring accuracy and completeness.
+Fee schedules are accessible through multiple channels with consistent
+information across website, mobile app, branches, and customer service ensuring
+customers receive uniform information regardless of inquiry method. Product
+design incorporates cost considerations with fees set to recover reasonable
+costs and provide fair profit margins without exploiting customers particularly
+vulnerable segments. Before implementing new fees or increasing existing fees,
+impact assessments are conducted evaluating customer segments affected,
+potential hardships, alternatives available, and justification ensuring
+fairness. Fee change notifications are clear, prominent, and timely (minimum 30
+days advance) through multiple channels with opt-out instructions and customer
+service contactsRetrySMContinue6. Bank Responsibilities (continued)
+Fee change notifications are clear, prominent, and timely (minimum 30 days
+advance) through multiple channels with opt-out instructions and customer
+service contacts for queries ensuring customers can make informed decisions.
+Staff across all branches and customer service channels are trained on fee
+structures, waiver eligibility, and transparent communication enabling
+consistent, accurate fee information provision to customers. Fee disputes raised
+by customers are investigated promptly reviewing transaction details, fee
+applicability, and any errors with reversals and compensation for incorrect
+charges within 5 business days. The Bank conducts periodic benchmarking of fees
+against peer banks and international standards ensuring competitiveness,
+reasonableness, and alignment with market practices. Fee revenue and cost
+recovery metrics are monitored ensuring fees serve legitimate business purposes
+rather than exploitative profit maximization at customer expense. Annual
+disclosures in reports and websites provide transparency on fee income as
+percentage of total revenue demonstrating balance between fee revenue and
+customer-friendly pricing. Customer feedback on fee structures through surveys,
+complaints, and branch interactions is analyzed systematically identifying
+unpopular fees or areas requiring simplification.
+7. Exceptions / Disclosures
+Third-party charges such as payment network fees, correspondent bank charges, or
+regulatory levies are passed through to customers with clear disclosure that
+these are external costs not controlled by Amanah Bank. Cross-border
+transactions attract additional fees including foreign exchange margins, SWIFT
+charges, and intermediary bank costs which vary based on transaction specifics
+making exact pre-disclosure challenging; estimated ranges are provided. Penalty
+fees for violations such as cheque dishonor or minimum balance non-maintenance
+are punitive by design deterring negative behaviors; however, reasonableness
+standards and regulatory caps are adhered to. Fee waivers for specific segments
+may require annual re-verification of eligibility; customers maintaining waiver
+eligibility must provide updated documentation periodically or lose waivers.
+Negotiated fees for high-value corporate clients, jumbo deposits, or special
+arrangements may differ from published schedules reflecting relationship pricing
+and volume considerations with proper documentation. Promotional zero-fee
+periods or special offers have defined validity clearly communicated in
+promotional materials; reverting to standard fees occurs automatically post-
+promotion without individual notifications. Regulatory changes mandating fee
+increases or new charges are implemented with minimal advance notice citing
+regulatory compliance requirements beyond Bank control. Fee structures may
+change based on cost inflation, regulatory requirements, or business
+sustainability needs; the Bank retains pricing autonomy with transparency
+commitments but not rate freezes.
+8. Compliance and Review
+This policy complies with State Bank of Pakistan transparency requirements,
+Consumer Protection Department fee disclosure guidelines, and international
+principles of fair pricing in financial services. Fee schedules and disclosure
+practices undergo semi-annual compliance audits verifying accuracy,
+accessibility, and adherence to advance notification requirements for changes.
+The policy is reviewed annually incorporating regulatory updates, customer
+feedback on fee transparency, and best practices in fee communication. Fee-
+related complaints including allegations of hidden charges, incorrect debits, or
+inadequate disclosure are tracked and analyzed monthly identifying systemic
+disclosure gaps. Mystery shopping exercises assess fee disclosure quality at
+branches and through customer service channels testing staff knowledge,
+transparency, and provision of complete information. Customer surveys on fee
+transparency and satisfaction with fee levels are conducted annually with
+results informing fee structure reviews and communication improvements. Staff
+training on fee structures, transparent communication, handling fee objections,
+and waiver processing is conducted quarterly ensuring consistent customer
+experience. Technology investments in dynamic fee disclosure tools, transaction-
+time fee alerts, and personalized fee calculators are prioritized enhancing
+customer understanding and control over banking costs.
+9.2 Conflict of Interest Management Policy
+1. Purpose
+This policy establishes frameworks for identifying, disclosing, and managing
+conflicts of interest to ensure customer interests take precedence over
+institutional or employee interests. It protects customers from biased advice,
+unfair treatment, or exploitation arising from conflicting interests. The policy
+aims to maintain integrity, trust, and ethical conduct in all customer
+interactions and business decisions.
+2. Scope
+This policy applies to all situations where Amanah Bank's interests, employee
+interests, or third-party interests may conflict with customer interests
+including product recommendations, loan decisions, investment advice, and
+service delivery. It covers conflicts arising from incentive structures, related
+party transactions, employee personal investments, vendor relationships, and
+cross-selling activities. The policy governs disclosure requirements, mitigation
+measures, decision-making protocols, and oversight mechanisms. It applies to all
+employees, directors, agents, and third parties acting on behalf of the Bank in
+customer interactions.
+3. Definitions
+Conflict of Interest: Situation where personal, institutional, or third-party
+interests may compromise objective decision-making in customer's best interest.
+Material Conflict: Significant conflict substantially affecting recommendations,
+decisions, or treatment of customers. Related Party: Individual or entity having
+special relationship with the Bank or its employees creating potential
+conflicts. Chinese Wall: Information barrier between departments preventing
+conflicts from sharing of confidential information. Disclosure: Transparent
+communication to customers about conflicts enabling informed decisions. Recusal:
+Voluntary withdrawal from decision-making when conflicts compromise objectivity.
+Independent Review: Evaluation by parties without conflicts ensuring fairness.
+4. Policy Statement
+Amanah Bank prioritizes customer interests above institutional profit
+maximization or employee incentives when conflicts arise, maintaining fiduciary
+responsibility and ethical conduct. Employees are required to identify and
+disclose conflicts of interest immediately upon awareness to supervisors and
+compliance officers enabling appropriate management before customer harm.
+Product recommendations to customers are based on suitability assessments
+considering customer needs, risk profiles, and financial situations rather than
+employee incentive structures or Bank revenue goals. Sales incentives and
+performance targets are structured to reward customer satisfaction, appropriate
+product matching, and long-term relationship value rather than short-term
+transaction volumes or high-margin product pushing. Employees advising customers
+on investments, insurance, or financial products disclose compensation
+arrangements including commissions, fees, or incentives received for specific
+product sales enabling customer evaluation of advice objectivity. Related party
+lending, transactions with directors or employees, or dealings with entities
+having ownership links to Bank personnel undergo enhanced scrutiny, independent
+approval, and disclosure preventing favoritism or conflicts. Chinese Walls
+separate departments handling proprietary trading, investment banking, or
+confidential client information from retail banking operations preventing
+information misuse. Employees trading in securities of companies where the Bank
+has material non-public information or where employee involvement in Bank
+decisions creates conflicts must pre-clear transactions and face trading
+restrictions. Gifts, entertainment, or favors from vendors, borrowers, or
+customers beyond minimal value (typically below PKR 5,000) are prohibited
+preventing improper influence on decisions or service delivery. Situations where
+conflicts cannot be eliminated are transparently disclosed to customers before
+transactions, and customers may seek independent advice or choose alternatives
+without pressure.
+5. Customer Responsibilities
+Customers should inquire about employee compensation structures when receiving
+financial advice understanding whether advisors receive commissions influencing
+recommendations enabling evaluation of advice objectivity. When offered
+products, customers should assess suitability against their needs rather than
+relying solely on sales presentations; seeking independent advice or comparing
+alternatives ensures informed decisions. Customers should disclose their
+complete financial situation, risk tolerance, and goals to enable appropriate
+recommendations; incomplete information leads to unsuitable products regardless
+of conflict management. If suspecting biased recommendations due to conflicts,
+customers should escalate concerns to branch managers or compliance officers for
+independent review of advice and alternatives. Customers should read conflict
+disclosures provided in product documents understanding implications and
+assessing whether disclosed conflicts affect their comfort with proceeding.
+Related parties of Bank including employees or directors seeking banking
+services should disclose relationships enabling appropriate conflict management
+and enhanced scrutiny. Customers approached by Bank employees for personal
+investments, business ventures, or unofficial transactions should report such
+approaches as serious conflicts warranting investigation. Accepting
+inappropriate gifts, favors, or special treatments from Bank staff may create
+obligations or expectations; customers should decline such offers maintaining
+arm's length relationships.
+6. Bank Responsibilities
+Amanah Bank shall establish clear policies defining acceptable and prohibited
+conflicts with specific examples, thresholds, and disclosure requirements
+communicated to all employees. Incentive structures for sales staff,
+relationship managers, and advisors are reviewed annually ensuring alignment
+with customer interest priorities over pure revenue generation. Conflicts
+identified in customer interactions trigger mandatory disclosure in writing
+before product finalization or advice implementation enabling customers to make
+informed decisions. Independent review mechanisms including compliance
+committees, ethics officers, or senior management oversight evaluate high-
+conflict situations ensuring customer interests are protected. Related party
+transaction registers are maintained recording all dealings with directors,
+employees, or connected entities with enhanced approval requirements and
+periodic Board review. Chinese Wall protocols include physical separation,
+information access controls, and confidentiality training preventing improper
+information flows between conflicted departments. Employee trading policies
+require pre-clearance of personal investments in securities, mandatory holding
+periods, and restrictions during sensitive periods preventing insider trading or
+conflicts. Gifts and entertainment received by employees are declared in
+registers with values exceeding thresholds requiring senior management approval
+or declining; aggregate tracking prevents circumvention through multiple small
+gifts. Vendor relationships are managed through competitive processes, arm's
+length terms, and rotation policies preventing dependency or favoritism
+compromising objective decision-making. Customer complaints alleging biased
+advice, conflict-driven recommendations, or unfair treatment due to conflicts
+are investigated by independent parties with remediation for confirmed
+violations.
+7. Exceptions / Disclosures
+Certain inherent conflicts exist in banking including the Bank's profit motive
+potentially conflicting with lowest-cost solutions for customers; these
+fundamental conflicts are acknowledged with reliance on regulatory oversight and
+competitive markets for discipline. Cross-selling opportunities where existing
+customers are approached for additional products involve conflicts between
+relationship expansion and avoiding over-commitment; transparent needs
+assessment and voluntary customer consent mitigate these conflicts. Group
+structures where Amanah Bank has affiliates in insurance, investments, or other
+financial services create referral conflicts managed through disclosure,
+customer choice, and prohibition of coercive bundling. Employment of relatives
+in different Bank departments may create conflicts in credit decisions or
+service delivery; comprehensive related party policies including recusal
+requirements manage these situations. Small community branches where staff have
+personal relationships with customers face inherent conflicts managed through
+dual authorization, supervisor oversight, and conflict disclosure rather than
+relationship prohibition. Performance pressures during quarter-ends or year-ends
+may incentivize aggressive sales potentially conflicting with customer
+suitability; monitoring systems detect unusual patterns triggering reviews. The
+Bank's role as both lender and deposit-taker creates conflicts in fund
+allocation decisions between maximizing lending returns and deposit interest
+payments; Asset Liability Committee oversight and regulatory requirements
+provide governance. Complete conflict elimination is impractical in banking; the
+policy therefore emphasizes identification, disclosure, mitigation, and
+oversight rather than absolute conflict prohibition.
+8. Compliance and Review
+This policy complies with State Bank of Pakistan governance guidelines, conflict
+of interest management requirements, and ethical standards for financial
+institutions. Conflict of interest registers, related party transactions, and
+employee trading activities undergo quarterly internal audits verifying
+compliance with disclosure and approval requirements. The policy is reviewed
+annually incorporating regulatory updates, emerging conflict scenarios from
+business evolution, and lessons from conflict-related complaints or violations.
+Conflicts of interest statistics including identified conflicts, disclosed
+instances, independent reviews conducted, and remediation actions are reported
+quarterly to Board Risk and Audit Committees. Employee training on conflict
+identification, disclosure obligations, ethical decision-making, and specific
+policy provisions is mandatory annually with scenario-based assessments.
+Whistleblower mechanisms enable anonymous reporting of undisclosed conflicts,
+biased advice, or policy violations without fear of retaliation encouraging
+ethical culture. The Bank benchmarks conflict management practices against peer
+institutions and international standards continuously enhancing frameworks as
+best practices evolve. Independent ethics reviews by external consultants every
+three years assess conflict management effectiveness, organizational culture,
+and framework adequacy providing improvement recommendations.
+Category 10: Data Privacy and Security Policies
+10.1 Customer Data Protection and Privacy Policy
+1. Purpose
+This policy establishes comprehensive safeguards for customer personal and
+financial information protecting privacy, preventing unauthorized access, and
+ensuring compliant data handling. It aims to build customer trust through
+responsible data stewardship while enabling legitimate business uses. The policy
+balances data utility for service delivery with stringent privacy protections
+and customer control over information.
+2. Scope
+This policy applies to all customer data collected, processed, stored,
+transmitted, or shared by Amanah Bank including personal identification,
+financial information, transaction data, communication records, and behavioral
+analytics. It covers data across all formats including electronic databases,
+paper records, audio recordings, video surveillance, and mobile app data. The
+policy governs data collection practices, consent requirements, usage
+limitations, security measures, sharing protocols, retention periods, and
+customer access rights. It applies to all employees, contractors, vendors, and
+third parties handling customer data on the Bank's behalf across all locations
+and channels.
+3. Definitions
+Personal Data: Information identifying or relating to an individual customer
+including name, CNIC, contact details, financial status, and transaction
+history. Sensitive Data: Highly confidential information requiring enhanced
+protection including passwords, PINs, biometrics, account balances, and credit
+information. Data Processing: Collection, storage, analysis, transmission, or
+any handling of customer data. Data Subject: Customer whose personal information
+is being processed by the Bank. Consent: Informed, voluntary agreement by
+customer for specific data processing activities. Data Breach: Unauthorized
+access, disclosure, loss, or compromise of customer data. Anonymization:
+Removing personally identifiable elements making data unable to identify
+individuals. Right to Erasure: Customer's right to request deletion of personal
+data under specified circumstances.
+4. Policy Statement
+Amanah Bank collects only data necessary for account opening, service delivery,
+regulatory compliance, and fraud prevention avoiding excessive or irrelevant
+information gathering. At data collection, customers are informed of purposes,
+legal basis, retention periods, sharing arrangements, and rights regarding their
+information through clear privacy notices. Explicit customer consent is obtained
+for data processing beyond core banking services including marketing
+communications, product recommendations, and data analytics with easy opt-out
+mechanisms. Customer data is used exclusively for stated purposes; repurposing
+data for new uses requires fresh consent or legitimate interest assessment with
+customer notification. Robust technical and organizational security measures
+protect customer data including encryption, access controls, network security,
+secure data centers, and regular security audits preventing unauthorized access
+or breaches. Access to customer data is restricted on need-to-know basis with
+role-based permissions, activity logging, and periodic access reviews ensuring
+only authorized personnel access specific data for legitimate purposes. Customer
+data is shared with third parties only when necessary for service delivery
+(payment processors, credit bureaus) or legally mandated (regulators, law
+enforcement) with contractual protections ensuring third-party compliance.
+Customers have rights to access their personal data, request corrections of
+inaccuracies, obtain data portability in structured formats, object to certain
+processing, and request erasure where legally permissible. Data retention
+periods align with regulatory requirements typically 10 years for financial
+records; data is securely deleted or anonymized after retention periods expire
+preventing indefinite storage. Data breaches are investigated immediately upon
+detection with incident response protocols including containment, impact
+assessment, notification to affected customers and regulators, and remediation
+measures.
+5. Customer Responsibilities
+Customers must provide accurate personal information during account opening and
+promptly update changes enabling the Bank to maintain current records for
+service delivery and communication. Login credentials, passwords, PINs, and OTPs
+are customer secrets to be safeguarded; sharing with others including family
+members compromises data security and may result in customer liability for
+unauthorized transactions. Customers should use secure devices and networks for
+digital banking avoiding public WiFi or shared devices for financial
+transactions preventing data interception or malware risks. Privacy settings in
+mobile apps and internet banking should be reviewed and configured according to
+customer preferences controlling data sharing, marketing communications, and
+behavioral tracking. Customers should report suspected data breaches including
+phishing emails, unauthorized account access, or suspicious communications
+immediately enabling the Bank to investigate and mitigate impact. Phishing
+awareness is customer responsibility; customers should verify communication
+authenticity before clicking links, downloading attachments, or providing
+information preventing social engineering attacks. Consent for marketing
+communications can be withdrawn anytime through opt-out links, customer service
+requests, or privacy preference centers; customers should actively manage
+communication preferences. Data access requests, correction requests, or erasure
+requests should be submitted formally through designated channels with proper
+identification enabling the Bank to process requests accurately and securely.
+6. Bank Responsibilities
+Amanah Bank shall implement layered security architecture including firewalls,
+intrusion detection systems, encryption, secure authentication, and continuous
+monitoring protecting customer data from cyber threats. Data encryption applies
+to data at rest (stored data) and data in transit (network transmissions) using
+industry-standard encryption protocols preventing unauthorized access even if
+data is intercepted. Access controls include unique user IDs, strong password
+policies, multi-factor authentication for privileged access, and automatic
+timeout preventing unauthorized access from unattended terminals. Employee
+training on data privacy, security best practices, phishing recognition, and
+handling of sensitive information is mandatory quarterly creating a security-
+conscious workforce. Vendor contracts include stringent data protection clauses
+requiring equivalent security standards, limiting data usage to specified
+purposes, and enabling audit rights ensuring third-party compliance. Privacy
+impact assessments are conducted for new products, systems, or data processing
+activities identifying privacy risks and implementing controls before launch.
+Data breach response plans include detection mechanisms, escalation protocols,
+forensic investigation capabilities, notification templates, and recovery
+procedures enabling rapid, effective response. Customer data access requests are
+fulfilled within 15 business days providing data in portable formats; correction
+requests are processed within 10 days with verification of requester identity.
+Annual privacy audits by internal and external auditors assess compliance with
+privacy policies, regulatory requirements, and international standards like ISO
+27001 identifying improvement areas. Transparency reports published annually
+disclose data request statistics from regulators and law enforcement, breach
+incidents, and privacy program enhancements demonstrating accountability.
+7. Exceptions / Disclosures
+Regulatory requirements mandate data sharing with State Bank of Pakistan,
+Federal Board of Revenue, Financial Monitoring Unit, and other authorities
+without individual customer consent as legal obligations. Credit bureaus receive
+customer credit information enabling credit risk assessment across the banking
+industry; customers cannot opt-out of credit bureau reporting as it serves
+system-wide risk management. Court orders, investigation demands, or legal
+process may require customer data disclosure; the Bank complies with lawful
+demands while challenging overly broad or improper requests protecting customer
+interests. Fraud investigation and prevention may involve data sharing with
+other banks, law enforcement, or industry databases identifying fraudsters and
+protecting the financial system. Data retention for legal compliance purposes
+prevents immediate deletion upon customer request; minimum retention periods
+must complete before erasure requests are honored. Anonymized, aggregated data
+used for analytics, research, or reporting doesn't identify individuals and
+isn't subject to individual access or erasure rights as it's no longer personal
+data. Cross-border data transfers for international payments, correspondent
+banking, or group services may occur with appropriate safeguards including
+contractual protections and adequacy assessments. Complete data deletion may not
+be technically feasible for backup archives or distributed systems; data is
+marked for non-restoration and eventual deletion during backup rotation cycles.
+8. Compliance and Review
+This policy complies with State Bank of Pakistan data protection guidelines,
+Electronic Transactions Ordinance, Telegraph Act provisions on communication
+privacy, and international standards like GDPR principles. Information security
+management systems certified to ISO 27001 standards undergo annual surveillance
+audits and triennial recertification audits verifying ongoing compliance. The
+policy is reviewed annually incorporating regulatory changes, technological
+advancements in security, emerging threats, and evolving privacy expectations.
+Data breach incidents, privacy complaints, and security incidents are analyzed
+monthly for patterns identifying systemic vulnerabilities requiring enhanced
+controls or policy updates. Penetration testing and vulnerability assessments
+conducted quarterly by independent security firms identify technical weaknesses
+before malicious actors exploit them. Employee compliance with data protection
+policies is monitored through access log reviews, privacy training completion
+tracking, and disciplinary actions for violations creating accountability.
+Customer surveys on privacy perceptions, trust levels, and concerns inform
+privacy program enhancements and communication strategies building confidence in
+Bank's data stewardship. The Bank maintains cyber insurance coverage protecting
+against financial impacts of data breaches while prioritizing prevention as
+primary strategy.
+10.2 Cybersecurity and Digital Banking Security Policy
+1. Purpose
+This policy establishes comprehensive cybersecurity measures protecting digital
+banking channels, customer transactions, and information systems from cyber
+threats including hacking, malware, phishing, and fraud. It ensures resilient,
+secure technology infrastructure enabling safe digital banking experiences. The
+policy aims to prevent cyber incidents while maintaining rapid detection and
+response capabilities when threats materialize.
+2. Scope
+This policy applies to all digital banking channels including internet banking,
+mobile banking apps, SMS banking, USSD banking, and API-based integrations used
+by Amanah Bank customers. It covers security architecture, authentication
+mechanisms, transaction security, malware protection, network security,
+application security, and infrastructure resilience. The policy governs customer
+security obligations, Bank security responsibilities, incident response
+procedures, and recovery mechanisms. It applies to all technology assets
+including servers, networks, applications, databases, endpoints, and cloud
+services.
+3. Definitions
+Cybersecurity: Protection of information systems, networks, and data from
+digital attacks, unauthorized access, and damage. Multi-Factor Authentication
+(MFA): Security requiring two or more verification factors (password + OTP,
+biometric + PIN) for access. Phishing: Fraudulent communication impersonating
+legitimate entities to steal credentials or financial information. Malware:
+Malicious software including viruses, trojans, ransomware, or spyware designed
+to damage systems or steal data. Encryption: Converting data into coded form
+requiring decryption keys for access protecting confidentiality. Firewall:
+Network security system controlling incoming and outgoing traffic based on
+security rules. Penetration Testing: Simulated cyber attack assessing security
+vulnerabilities before real attackers exploit them. Security Incident: Event
+compromising confidentiality, integrity, or availability of information systems
+or data.
+4. Policy Statement
+Amanah Bank implements defense-in-depth security architecture with multiple
+layers of protection including network security, application security, data
+security, and endpoint protection preventing single point of failure. Multi-
+factor authentication is mandatory for digital banking access requiring
+something customer knows (password), something customer has (OTP to mobile), and
+optionally something customer is (biometric) enhancing security beyond passwords
+alone. Transaction authorization for high-value or high-risk transactions
+requires additional verification including OTP, biometric authentication, or
+secure tokens preventing unauthorized transactions even with compromised
+credentials. Session management includes automatic timeout after 5 minutes of
+inactivity, single concurrent session restrictions, and session termination upon
+logout preventing unauthorized access from unattended devices. Customer login
+credentials are never stored in plain text; passwords are hashed using strong
+algorithms with salts, PINs are encrypted, and biometric templates are stored in
+secure enclaves preventing credential theft usefulness. Transaction monitoring
+systems analyze patterns in real-time detecting anomalies including unusual
+login locations, rapid fund transfers, or atypical transaction sequences
+triggering alerts and temporary holds for verification. Secure communication
+protocols including TLS 1.2+ encryption protect data transmitted between
+customer devices and Bank servers preventing eavesdropping or man-in-the-middle
+attacks on networks. Application security includes secure coding practices,
+regular vulnerability assessments, penetration testing, and security patches
+protecting against injection attacks, cross-site scripting, and other web
+vulnerabilities. Network security employs firewalls, intrusion
+detection/prevention systems, DDoS mitigation, and network segmentation
+protecting against external attacks and containing breaches if perimeters are
+compromised. Malware protection includes antivirus software on Bank systems,
+email filtering, web filtering, and endpoint detection and response solutions
+preventing malware infiltration and spread. Mobile app security includes code
+obfuscation, root/jailbreak detection, certificate pinning, and secure storage
+preventing reverse engineering, tampering, or data extraction from compromised
+devices. Security incident response protocols include detection mechanisms,
+incident classification, escalation procedures, containment strategies,
+eradication steps, recovery processes, and post-incident reviews ensuring rapid
+effective response minimizing damage.
+5. Customer Responsibilities
+Customers must create strong, unique passwords for digital banking combining
+uppercase, lowercase, numbers, and special characters avoiding dictionary words,
+personal information, or reused passwords from other sites. Passwords and PINs
+must never be written down, saved in browsers, shared with others, or disclosed
+in response to calls/emails claiming to be from the Bank; staff never ask for
+complete passwords. Customers should access digital banking only from trusted
+devices that they own and control avoiding public computers, shared devices, or
+borrowed phones where malware or keyloggers may capture credentials. Secure
+internet connections should be used for banking; public WiFi networks are risky
+due to potential eavesdropping; VPNs provide additional protection when using
+untrusted networks. Mobile banking apps should be downloaded only from official
+app stores (Google Play, Apple App Store); apps from unofficial sources may
+contain malware or fake versions designed to steal credentials. Device security
+including screen locks, biometric authentication, and updated operating systems
+with latest security patches protects against unauthorized access if devices are
+lost or stolen. Customers should verify website authenticity before entering
+credentials checking for "https://" and padlock symbols, correct Bank domain,
+and valid security certificates avoiding phishing sites. Suspicious
+communications including emails, SMS, or calls requesting account information,
+passwords, or urgent actions should be verified by contacting the Bank directly
+through official channels before responding. Security alerts from the Bank
+regarding unusual login attempts, device registrations, or transactions should
+be reviewed immediately reporting unauthorized activities enables rapid response
+and limiting damage.
+6. Bank Responsibilities
+Amanah Bank shall implement and maintain internationally recognized security
+frameworks including ISO 27001, NIST Cybersecurity Framework, and OWASP
+standards ensuring comprehensive security coverage. Security architecture
+reviews conducted annually by independent experts assess design effectiveness,
+identify vulnerabilities, and recommend enhancements keeping defenses current
+against evolving threats. Penetration testing by ethical hackers performed
+quarterly simulates real-world attacks identifying exploitable weaknesses before
+malicious actors discover them enabling proactive remediation. Vulnerability
+management includes continuous scanning, risk-based prioritization, and patching
+of security vulnerabilities in systems and applications within defined
+timeframes based on severity. Security Operations Center (SOC) monitors systems
+24/7 analyzing logs, detecting anomalies, and responding to security events
+providing real-time threat detection and incident response. Incident response
+team with defined roles, communication protocols, and forensic capabilities
+responds immediately to security incidents containing breaches, preserving
+evidence, and minimizing customer impact. Customer security awareness campaigns
+through SMS, emails, app notifications, and website content educate about
+phishing, safe banking practices, and emerging threats empowering customers to
+protect themselves. Secure software development lifecycle includes security
+requirements definition, secure coding standards, code reviews, security
+testing, and vulnerability remediation before production release preventing
+introduction of vulnerabilities. Third-party security assessments verify that
+vendors, service providers, and partners handling Bank data or services maintain
+equivalent security standards through audits and contractual obligations.
+Security metrics including incident frequency, vulnerability remediation times,
+penetration test findings, and security training completion rates are tracked
+monthly driving continuous improvement and accountability.
+7. Exceptions / Disclosures
+Perfect security is unattainable; despite best efforts, determined sophisticated
+attackers may occasionally breach defenses; the Bank focuses on minimizing
+likelihood, rapid detection, and effective response. Customer liability for
+unauthorized transactions depends on circumstances including timely reporting,
+credential compromise cause, and negligence assessment as per applicable
+regulations and Bank policies. Security measures including transaction limits,
+device restrictions, or enhanced authentication may cause occasional
+inconvenience; these are necessary trade-offs between security and convenience.
+System downtime for security maintenance including patching, upgrades, or
+incident response may temporarily disrupt services; advance notifications
+minimize inconvenience where feasible. Behavioral analytics and transaction
+monitoring may occasionally generate false positives causing legitimate
+transactions to be blocked requiring customer verification before release. The
+Bank cannot guarantee security of customer devices, networks, or third-party
+services used to access digital banking; customer-side security is outside
+Bank's control requiring customer responsibility. Evolving threats require
+continuous security investment and process evolution; measures adequate today
+may require enhancement tomorrow necessitating regular policy and control
+updates. Regulatory reporting of security incidents to State Bank, law
+enforcement, or other authorities may occur without specific customer consent
+when legally mandated or when incidents affect multiple customers.
+8. Compliance and Review
+This policy complies with State Bank of Pakistan cyber security guidelines,
+Electronic Transactions Ordinance, Payment Systems Operators and Payment Service
+Providers Regulations, and international security standards. Information
+security management system certified to ISO 27001 undergoes annual surveillance
+audits by accredited certification bodies verifying ongoing compliance and
+control effectiveness. The policy is reviewed semi-annually or immediately upon
+major security incidents, regulatory updates, or significant threat landscape
+changes ensuring relevance and adequacy. Security posture assessments by
+independent cybersecurity firms conducted annually provide objective evaluation
+of controls, identification of gaps, and benchmarking against industry best
+practices. Cyber resilience exercises including disaster recovery drills,
+incident response simulations, and business continuity tests conducted quarterly
+validate response capabilities and identify improvement needs. Security training
+for IT staff, developers, and operations teams is conducted quarterly with
+specialized topics including secure coding, threat intelligence, and incident
+response maintaining technical competencies. Board and senior management receive
+quarterly cybersecurity briefings covering threat landscape, incident
+statistics, security investments, and strategic risks ensuring governance
+oversight. The Bank participates in industry information sharing forums,
+computer emergency response teams (CERT), and cybersecurity alliances
+collaborating on threat intelligence and collective defense.
+Category 11: Record Retention and Data Handling Policies
+11.1 Document Retention and Archival Policy
+1. Purpose
+This policy establishes systematic procedures for retaining, storing,
+retrieving, and destroying customer records ensuring regulatory compliance,
+operational efficiency, and evidence preservation. It balances retention needs
+for legal protection with customer privacy through timely disposal. The policy
+aims to maintain accessible records supporting business operations and
+regulatory requirements while managing storage costs and data protection risks.
+2. Scope
+This policy applies to all customer-related documents including account opening
+forms, KYC documents, transaction records, loan files, correspondence,
+agreements, statements, and audit trails maintained by Amanah Bank. It covers
+physical records stored in branches and central archives, electronic records in
+databases and document management systems, audio recordings of calls, video
+surveillance footage, and email communications. The policy governs retention
+periods, storage requirements, access controls, retrieval procedures, and secure
+destruction methods. It applies across all departments and locations handling
+customer records throughout the document lifecycle from creation to destruction.
+3. Definitions
+Record: Document or data capturing information about customer relationships,
+transactions, decisions, or communications requiring preservation. Retention
+Period: Minimum duration for which records must be preserved before eligible for
+destruction. Active Records: Documents frequently accessed for current
+operations stored in readily accessible locations. Archived Records: Historical
+documents rarely accessed stored in lower-cost storage with retrieval processes.
+Secure Destruction: Irreversible elimination of records preventing
+reconstruction or unauthorized access after retention periods. Legal Hold:
+Suspension of normal destruction schedules when records are relevant to
+litigation or investigations. Document Management System (DMS): Electronic
+repository organizing, storing, and managing documents with access controls and
+audit trails.
+4. Policy Statement
+Amanah Bank retains customer records for minimum periods prescribed by State
+Bank regulations, tax laws, and legal statutes typically 10 years from account
+closure or relationship termination ensuring compliance and evidence
+preservation. Account opening documents including KYC forms, identification
+copies, address proofs, and specimen signatures are retained for 10 years post-
+account closure supporting verification if disputes arise. Transaction records
+including deposit slips, withdrawal vouchers, transfer instructions, cheque
+images, and electronic payment logs are retained for 10 years enabling
+reconstruction of account history for audits or investigations. Loan
+documentation including applications, credit assessments, approval memos,
+agreements, collateral documents, and repayment records are retained for 10
+years after loan closure or write-off supporting recovery actions and compliance
+reviews. Audio recordings of customer service calls and video surveillance
+footage are retained for 90 days unless involved in disputes or investigations
+requiring extended preservation as evidence. Email communications and electronic
+correspondence containing material customer interactions or decisions are
+captured in document management systems and retained per relevant category
+retention periods. Physical documents are stored in fireproof, secure archive
+facilities with environmental controls, restricted access, and inventory
+management preventing loss, damage, or unauthorized access. Electronic records
+are maintained in secure databases with regular backups, disaster recovery
+capabilities, encryption, and access controls ensuring availability and
+confidentiality throughout retention periods. Records beyond retention periods
+are destroyed securely through shredding for physical documents and degaussing
+or cryptographic erasure for electronic media preventing data recovery. Legal
+hold processes suspend normal destruction when records are relevant to ongoing
+litigation, regulatory investigations, or internal inquiries preserving evidence
+until legal matters conclude.
+5. Customer Responsibilities
+Customers should retain personal copies of account statements, transaction
+receipts, loan agreements, and correspondence as the Bank's retention is for
+compliance purposes, not indefinite customer service. Document retrieval
+requests should specify exact timeframes, account numbers, and document types
+enabling efficient search and retrieval from archives reducing costs and delays.
+Customers requesting historical documents beyond 10 years of relationship
+termination may face inability to retrieve records if destruction schedules have
+completed; timely requests during retention periods are advisable. Certified
+copies or document authentication services may incur fees as per the Bank's
+published schedule; customers should budget accordingly for legal or regulatory
+requirements needing authenticated records. During legal proceedings, customers
+should inform the Bank if specific records are relevant enabling legal hold
+placement preventing inadvertent destruction before matters resolve. Customers
+should understand that certain records like call recordings have short retention
+periods (90 days); disputes should be raised promptly while recordings exist for
+investigation. Data subject access requests for historical records should
+acknowledge retrieval complexities and potential delays for archived documents
+stored off-site requiring logistics coordination.
+6. Bank Responsibilities
+Amanah Bank shall maintain comprehensive retention schedules specifying
+retention periods for each record category with legal and regulatory
+justifications documented and approved by compliance and legal departments.
+Records are classified during creation or receipt by record type enabling
+automatic retention period assignment, storage location determination, and
+destruction scheduling when systems permit. Active records supporting current
+operations are maintained in branches, departments, or easily accessible
+electronic systems with indexing enabling rapid retrieval during business hours.
+Archived records are transferred to central archive facilities or electronic
+archive systems annually consolidating inactive records, freeing operational
+space, and optimizing storage costs. Physical archive facilities maintain
+environmental controls (temperature, humidity), fire protection, pest control,
+and security measures protecting records from deterioration, damage, or theft.
+Electronic records management includes backup systems, disaster recovery sites,
+format migration for technology evolution, and audit trails of access ensuring
+long-term preservation and integrity. Retrieval processes respond to customer
+requests, audit requirements, or legal demands within defined service levels
+typically 5 business days for archives, with expedited options for urgent needs.
+Destruction procedures include documented approvals, witnessed destruction for
+physical records, certificate of destruction issuance, and audit trails ensuring
+destruction occurs only for eligible records. Legal hold systems enable
+immediate suspension of destruction schedules across all locations and formats
+when litigation or investigations commence preventing evidence spoliation.
+Periodic audits of retention compliance verify records are maintained for
+required periods, destruction occurs timely after expiry, and no premature or
+delayed destruction violations occur.
+7. Exceptions / Disclosures
+Longer retention periods apply when specific circumstances exist including
+ongoing litigation, regulatory investigations, disputed transactions, or
+customer bankruptcy proceedings requiring records as potential evidence. Shorter
+retention periods for call recordings and surveillance footage balance storage
+costs and privacy considerations with operational needs; customers should raise
+issues promptly while such records exist. Tax-related documents may require
+retention beyond standard periods if tax disputes, audits, or assessments extend
+beyond typical closure timelines; legal advice guides retention extensions.
+Customer consent cannot reduce statutory retention periods; even if customers
+request deletion, minimum legal retention must complete before destruction
+complying with regulatory obligations. Digital records in backup systems may
+persist beyond active deletion due to backup rotation cycles; logical deletion
+occurs immediately with physical erasure following backup schedules. Records
+held by vendors, service providers, or third parties on the Bank's behalf are
+subject to contractual retention and destruction obligations aligned with this
+policy. Cross-border data flows for multinational customers or international
+transactions may face conflicting retention requirements from multiple
+jurisdictions; longer retention prevails balancing compliance across
+jurisdictions. Historical records predating current retention schedules are
+evaluated case-by-case balancing historical preservation with storage costs and
+privacy considerations.
+8. Compliance and Review
+This policy complies with State Bank of Pakistan record retention directives,
+banking company ordinance requirements, tax documentation mandates, and legal
+evidence preservation standards. Retention schedule accuracy is reviewed
+annually incorporating regulatory changes, new product records, and operational
+lessons ensuring comprehensive coverage of all record categories. Compliance
+audits conducted semi-annually verify records are maintained for required
+periods through sampling of active and archived records across categories and
+locations. Destruction audit trails are reviewed quarterly confirming only
+eligible records are destroyed with proper approvals, documentation, and
+certificates of destruction maintained. The policy is updated promptly when
+regulatory changes mandate retention period revisions ensuring immediate
+compliance with new requirements. Technology investments in document management
+systems, electronic archival, and automated retention workflows are prioritized
+reducing manual effort and improving compliance accuracy. Staff training on
+record retention, classification, handling, and destruction protocols is
+conducted annually for employees involved in record management ensuring
+consistent application. The Bank consults with legal advisors regarding
+retention practices, legal hold management, and destruction procedures ensuring
+defensible practices withstanding legal scrutiny.
+Category 12: Cross-RetrySMContinueCategory 12: Cross-Border and Foreign Exchange
+Policies
+12.1 Foreign Exchange and International Transaction Policy
+1. Purpose
+This policy establishes comprehensive guidelines for foreign exchange
+transactions, international remittances, and cross-border payments ensuring
+regulatory compliance, competitive pricing, and customer convenience. It aims to
+facilitate legitimate foreign exchange needs while preventing money laundering,
+terrorist financing, and unauthorized capital flight. The policy balances
+customer access to forex services with prudent risk management and regulatory
+adherence.
+2. Scope
+This policy applies to all foreign exchange services offered by Amanah Bank
+including currency exchange, outward remittances, inward remittances, foreign
+currency accounts, travel forex, import/export financing, and foreign currency
+demand drafts. It covers foreign exchange rate determination, documentation
+requirements, transaction limits, purpose codes, reporting obligations, and
+compliance procedures. The policy governs transactions for individuals,
+businesses, exporters, importers, and non-resident Pakistanis across all
+branches authorized for foreign exchange operations. It excludes derivative
+transactions and treasury operations which are governed by separate wholesale
+banking policies.
+3. Definitions
+Foreign Exchange (Forex): Conversion between Pakistani Rupees and foreign
+currencies or between different foreign currencies. Exchange Rate: Price at
+which one currency exchanges for another determined by market forces and Bank
+margins. Outward Remittance: Transfer of funds from Pakistan to foreign
+countries for permissible purposes. Inward Remittance: Receipt of funds into
+Pakistan from foreign sources. Authorized Dealer: Bank licensed by State Bank of
+Pakistan to conduct foreign exchange transactions. Foreign Currency Account:
+Bank account denominated in foreign currencies enabling holding and transactions
+in forex. SWIFT: Secure messaging network for international payment instructions
+between banks. Nostro Account: Foreign currency account held by Amanah Bank with
+correspondent banks abroad facilitating international transactions.
+4. Policy Statement
+Amanah Bank as an Authorized Dealer facilitates legitimate foreign exchange
+transactions in compliance with Foreign Exchange Regulation Act, State Bank
+directives, and international sanctions ensuring customer convenience within
+regulatory frameworks. Foreign exchange rates for customer transactions include
+inter-bank market rates plus reasonable spreads covering costs, risks, and
+margins published daily on the Bank's website, mobile app, and displayed at
+branches. Outward remittances up to USD 25,000 annually per individual for
+permissible purposes including education fees, medical treatment, family
+maintenance, investments, and travel are processed based on declarations without
+prior State Bank approval. Remittances exceeding annual limits or for restricted
+purposes require State Bank approval obtained through the Bank with supporting
+documentation justifying the remittance purpose and amount. Inward remittances
+have no limits and are freely credited to customer accounts or paid in cash
+after verifying beneficiary identity, source legitimacy through correspondent
+bank certifications, and compliance with sanctions screening. Foreign Currency
+Accounts allow individuals and businesses to maintain balances in major
+currencies (USD, EUR, GBP) earning minimal interest with flexibility for
+international transactions without immediate conversion to PKR. Travel forex up
+to USD 10,000 per trip is provided in cash or travel cards based on ticket
+verification, passport, and visa documentation facilitating legitimate travel
+needs. Export proceeds must be repatriated within 180 days of shipment; delayed
+realization requires State Bank reporting and extension applications ensuring
+export earnings return to Pakistan. Import payments are processed against
+shipping documents, customs declarations, and commercial invoices verifying
+transaction legitimacy and preventing over-invoicing capital flight. Enhanced
+due diligence applies to foreign exchange transactions involving high-risk
+countries, politically exposed persons, large amounts, or unusual patterns
+detecting potential money laundering or sanctions violations.
+5. Customer Responsibilities
+Customers must provide accurate information regarding remittance purposes using
+correct purpose codes enabling proper regulatory reporting and compliance with
+foreign exchange regulations. Supporting documents including invoices, admission
+letters, medical reports, property documents, or relationship proof must be
+genuine and submitted for outward remittances facilitating verification and
+approval. Travel forex requests should be made at least 2 business days before
+travel allowing adequate time for currency procurement, documentation
+verification, and compliance processes. Foreign Currency Accounts should be used
+for legitimate international transactions; misuse for speculation, unauthorized
+trading, or circumventing regulations violates terms and may result in account
+closure. Export proceeds must be repatriated promptly within regulatory
+timelines; exporters facing delays should proactively seek extensions rather
+than defaulting on repatriation obligations. Import documentation must
+accurately reflect transaction values, quantities, and purposes; false
+declarations to obtain excess forex constitute fraud punishable under law.
+Customers should compare exchange rates across banks and money changers
+understanding that rates vary based on currencies, amounts, and transaction
+types enabling informed decisions. Inward remittance recipients must provide
+complete identification, source information, and intended use facilitating AML
+compliance and sanctions screening before funds release.
+6. Bank Responsibilities
+Amanah Bank shall display current foreign exchange rates prominently on digital
+channels and at branches with transparent disclosure of spreads, fees, and
+charges enabling customer price comparison. Forex transactions are processed
+efficiently within 1-2 business days for standard cases and 5-7 business days
+for transactions requiring State Bank approvals providing timely service. The
+Bank verifies supporting documents thoroughly including invoices, contracts, and
+certificates authenticating transaction legitimacy and compliance with purpose-
+specific documentation requirements. Outward remittances are transmitted through
+SWIFT network to correspondent banks with complete beneficiary information,
+purpose codes, and regulatory references ensuring successful crediting abroad.
+Inward remittances are screened against sanctions lists, verified for source
+legitimacy, and credited to beneficiary accounts or disbursed in cash within 24
+hours of receipt barring compliance holds. Foreign Currency Account operations
+include monthly statements, internet banking access, and international payment
+capabilities providing convenient forex management for customers. The Bank
+maintains adequate foreign currency liquidity through nostro accounts with major
+correspondent banks globally ensuring ability to fulfill customer forex
+requirements promptly. Customer education on foreign exchange regulations,
+documentation requirements, and permissible purposes is provided through
+relationship managers, website content, and informational brochures. Suspicious
+forex transactions including structuring, unusual patterns, or inconsistent
+documentation are reported to Financial Monitoring Unit as Suspicious
+Transaction Reports per AML obligations. Regulatory reporting including daily
+forex position reports, transaction-level reporting to State Bank, and
+compliance with concentration limits ensures institutional compliance and
+license maintenance.
+7. Exceptions / Disclosures
+Foreign exchange rates fluctuate continuously based on market dynamics; rates
+quoted are indicative and final rates apply at transaction execution potentially
+causing slight variations. Large forex transactions exceeding USD 100,000
+equivalent may require advance booking allowing the Bank to manage liquidity and
+obtain competitive rates through treasury operations. Certain currencies from
+high-risk jurisdictions or less-traded currencies may face limited availability,
+wider spreads, or longer processing times due to correspondent banking
+constraints. Forex transactions to sanctioned countries, entities, or
+individuals are strictly prohibited; the Bank cannot process such transactions
+regardless of customer intent or stated purposes. Outward remittances for
+certain purposes including real estate purchases abroad, stock trading in
+foreign markets, or business investments may require State Bank approvals beyond
+Bank's authority. Exchange rate movements during transaction processing may
+cause final amounts to differ from initial estimates; customers bear currency
+fluctuation risks during processing periods. Forex services may be temporarily
+unavailable during correspondent bank holidays, SWIFT network maintenance, or
+when regulatory directives mandate temporary restrictions. Nostro account
+charges, correspondent bank fees, and intermediary bank deductions are beyond
+the Bank's control and may reduce amounts received by overseas beneficiaries.
+8. Compliance and Review
+This policy complies with Foreign Exchange Regulation Act, State Bank of
+Pakistan foreign exchange operations regulations, FATF recommendations on cross-
+border payments, and international sanctions regimes. Forex operations undergo
+monthly compliance reviews verifying documentation adequacy, purpose code
+accuracy, regulatory reporting completeness, and adherence to transaction
+limits. The policy is reviewed quarterly incorporating regulatory changes,
+correspondent banking updates, sanctions list additions, and operational
+efficiency improvements. Forex transaction statistics including volume trends,
+currency compositions, purpose distributions, and rejected transactions are
+analyzed monthly informing liquidity management and compliance risk assessment.
+Customer complaints regarding exchange rates, processing delays, or
+documentation requirements are investigated within 5 business days with
+explanations and resolution where Bank errors exist. Staff training on foreign
+exchange regulations, documentation requirements, sanctions screening, and AML
+red flags is conducted quarterly ensuring consistent compliance and customer
+service. The Bank maintains updated sanctions lists, high-risk jurisdiction
+lists, and regulatory guidelines ensuring real-time compliance screening of all
+forex transactions. Correspondent banking relationships are reviewed annually
+assessing service quality, competitive pricing, compliance standards, and
+strategic alignment ensuring optimal partnerships for customer service.
+12.2 Non-Resident and Overseas Pakistani Banking Policy
+1. Purpose
+This policy establishes specialized banking services for Non-Resident Pakistanis
+(NRPs) and Overseas Pakistanis facilitating remittances, investments, and
+banking relationships while complying with foreign exchange regulations. It aims
+to attract remittances supporting Pakistan's foreign exchange reserves while
+providing convenient financial services to the diaspora. The policy balances
+regulatory requirements with customer-friendly procedures recognizing unique
+needs of overseas Pakistanis.
+2. Scope
+This policy applies to all banking services for Pakistani citizens residing
+abroad including Non-Resident Rupee Accounts, Foreign Currency Accounts, Roshan
+Digital Accounts, remittance services, property financing, investment
+facilitation, and repatriation rights. It covers account opening procedures for
+non-residents, documentation requirements, transaction permissions, tax
+treatment, and regulatory compliance. The policy governs services across
+branches, digital channels, and overseas representative offices. It applies to
+Pakistani passport holders residing abroad, Pakistani origin foreign nationals,
+and returning overseas Pakistanis establishing banking relationships remotely or
+through branch visits during home visits.
+3. Definitions
+Non-Resident Pakistani (NRP): Pakistani citizen residing abroad for employment,
+business, or permanent settlement. Overseas Pakistani: Pakistani national living
+outside Pakistan including temporary workers, students, and permanent
+expatriates. Non-Resident Rupee Account (NRA): PKR-denominated account for non-
+residents with special repatriation privileges. Foreign Currency Account (FCA):
+Dollar/Euro/Pound account for non-residents maintaining foreign exchange. Roshan
+Digital Account: State Bank initiative enabling overseas Pakistanis to open
+accounts digitally without physical presence. Repatriation: Transfer of funds
+from Pakistan to overseas destinations without restrictions. Remittance:
+Transfer of money by overseas Pakistanis to Pakistan supporting families or
+investments.
+4. Policy Statement
+Amanah Bank offers specialized banking solutions for Non-Resident Pakistanis
+recognizing their valuable contributions to Pakistan's economy through
+remittances and investments deserving preferential treatment and convenience.
+Roshan Digital Account enables complete digital account opening from abroad
+without physical presence using video KYC, passport verification, and overseas
+address documentation providing banking access from anywhere globally. Non-
+Resident Rupee Accounts allow PKR deposits and transactions with unrestricted
+repatriation rights meaning funds can be transferred back overseas anytime
+without State Bank approval unlike resident accounts. Foreign Currency Accounts
+maintain balances in USD, EUR, or GBP without forced conversion to PKR enabling
+expatriates to save foreign earnings and conduct international transactions
+conveniently. Inward remittances from overseas Pakistanis receive preferential
+treatment with zero charges, competitive exchange rates, instant credit, and
+promotional incentives encouraging continued remittance flows through banking
+channels. Investment facilitation includes access to Treasury Bills, Pakistan
+Investment Bonds, mutual funds, and stock market investments from abroad with
+simplified procedures and repatriation guarantees. Property financing enables
+overseas Pakistanis to purchase or construct property in Pakistan with special
+schemes offering favorable terms, flexible documentation, and rent-based
+repayment options. Returning overseas Pakistanis receive assistance in account
+conversion, settlement services, and tax guidance facilitating smooth transition
+from non-resident to resident status. Special relationship managers dedicated to
+non-resident banking provide personalized service, handle documentation
+complexities, and ensure seamless banking experiences for diaspora customers.
+5. Customer Responsibilities
+Non-resident customers must provide valid Pakistani passport, overseas residence
+proof (visa/work permit/utility bill), and tax residency documentation for
+account opening and ongoing compliance. Customers should maintain their non-
+resident status genuinely; returning to Pakistan permanently requires
+notification within 60 days and account conversion to resident status per
+regulations. Inward remittances should be genuine personal transfers or
+legitimate business proceeds; using NRP accounts for third-party remittances or
+trade financing without proper authorization violates regulations. Property
+financing borrowers must ensure rental income, overseas salary, or legitimate
+sources service EMIs; default affects creditworthiness and relationship with the
+Bank. Investment decisions should be based on personal financial assessment,
+risk tolerance, and professional advice; the Bank provides facilitation but not
+investment recommendations warranting returns. Tax obligations in residence
+countries regarding Pakistani source income, investments, or property are
+customer responsibilities; the Bank provides withholding services for Pakistan
+taxes only. Communication channels including email addresses, phone numbers, and
+overseas addresses must be kept current enabling the Bank to reach customers for
+important notifications or compliance requirements. Upon returning to Pakistan,
+customers must notify the Bank promptly facilitating account status conversion
+and ensuring continued regulatory compliance under resident banking rules.
+6. Bank Responsibilities
+Amanah Bank shall provide simplified account opening through digital channels
+with video KYC, electronic document submission, and remote identity verification
+eliminating physical visit requirements for overseas customers. The Bank
+verifies overseas address and residence status through documents like utility
+bills, residence permits, or employer letters ensuring genuine non-resident
+status per regulatory definitions. Foreign exchange conversion for remittances
+offers competitive rates with transparent spreads incentivizing remittances
+through formal banking channels rather than informal hundi/hawala networks.
+Funds in Non-Resident accounts are freely repatriable; the Bank processes
+outward remittances without State Bank approval requirements or purpose
+restrictions up to available balances. Investment facilitation includes
+assistance with documentation, online trading platform access, portfolio
+management services, and guidance on repatriation procedures for investment
+proceeds. Property financing processes include overseas income verification,
+flexible documentation acceptance, construction monitoring for development
+loans, and customer-friendly policies recognizing distance challenges. Dedicated
+relationship managers maintain regular communication through emails, video
+calls, and home country visits where feasible building strong relationships and
+addressing concerns proactively. The Bank collaborates with overseas
+correspondents, exchange companies, and remittance platforms offering multiple
+convenient channels for sending money to Pakistan with instant credit. Tax
+guidance including withholding tax implications, treaty benefits, and compliance
+requirements is provided assisting customers in understanding and meeting
+Pakistan tax obligations. Annual newsletters, webinars, and digital content keep
+overseas customers informed about product updates, regulatory changes, and
+investment opportunities in Pakistan maintaining engagement.
+7. Exceptions / Disclosures
+Non-resident status requires genuine overseas residence; temporary visits to
+Pakistan don't affect status, but permanent return requires account conversion
+within 60 days under regulations. Repatriation rights for NRP accounts apply to
+funds originating from overseas remittances, foreign currency conversions, or
+permissible investments; local PKR income may face restrictions. Investment
+returns including capital gains, dividends, or profit on debt instruments are
+subject to applicable withholding taxes; treaty benefits require tax residency
+certificates from foreign tax authorities. Property financing eligibility
+requires stable overseas income, satisfactory credit history, and appropriate
+debt-to-income ratios; financing isn't guaranteed merely based on non-resident
+status. Foreign exchange regulations may change based on State Bank policy
+shifts, balance of payments situations, or economic conditions potentially
+affecting account features or transaction freedoms. Correspondent bank
+relationships enable international remittances; disruptions in correspondent
+banking due to sanctions, de-risking, or compliance issues may affect service
+availability temporarily. Roshan Digital Accounts have operational limits
+initially including transaction caps and phased feature rollouts; full-service
+parity with conventional accounts develops progressively as systems mature. Tax
+residency in foreign countries may create tax reporting obligations for those
+jurisdictions; some countries require disclosure of foreign accounts and assets
+with customer responsibility for compliance.
+8. Compliance and Review
+This policy complies with Foreign Exchange Regulation Act provisions on non-
+resident accounts, State Bank of Pakistan regulations on Roshan Digital
+Accounts, and international best practices in diaspora banking. Non-resident
+account operations undergo quarterly compliance audits verifying genuine non-
+resident status, proper documentation, repatriation right adherence, and
+regulatory reporting accuracy. The policy is reviewed semi-annually
+incorporating State Bank policy changes, Roshan Digital Account guideline
+updates, and customer feedback on overseas banking experiences. Remittance
+volumes, account growth statistics, investment flows, and property financing
+uptake are monitored monthly assessing policy effectiveness and informing
+product development. Customer complaints regarding account opening difficulties,
+repatriation delays, or service quality are investigated within 7 business days
+with resolution and system improvements where needed. Staff training on non-
+resident banking regulations, Roshan Digital Account procedures, and diaspora
+customer service nuances is conducted quarterly ensuring knowledgeable,
+empathetic service delivery. The Bank participates in State Bank initiatives,
+overseas Pakistani conventions, and diaspora engagement programs strengthening
+relationships and promoting formal banking channel usage. Technology investments
+in digital onboarding, video KYC, remote service delivery, and mobile banking
+enhancements are prioritized improving overseas customer experiences
+continuously.
+Category 13: Consent and Authorization Policies
+13.1 Customer Consent and Authorization Management Policy
+1. Purpose
+This policy establishes comprehensive frameworks for obtaining, recording,
+managing, and honoring customer consents and authorizations ensuring
+transparent, voluntary agreements for data processing, marketing communications,
+and transaction executions. It protects customer autonomy while enabling
+legitimate Bank operations through proper consent mechanisms. The policy aims to
+build trust through respect for customer choices and preferences across all
+interactions.
+2. Scope
+This policy applies to all situations requiring customer consent including
+account opening terms, data processing beyond core banking, marketing
+communications, third-party data sharing, standing instructions, auto-debit
+mandates, and authorized signatory designations. It covers consent capture
+methods, documentation requirements, revocation procedures, consent renewal, and
+record-keeping obligations. The policy governs consents across all channels
+including written forms, electronic acceptances, verbal recordings, and
+biometric authentications. It applies to all customer types including
+individuals, joint account holders, minor accounts, and corporate customers with
+appropriate authority verification.
+3. Definitions
+Consent: Informed, voluntary agreement by customer for specific purposes or
+actions. Informed Consent: Agreement based on clear understanding of
+implications, purposes, and rights regarding what is being consented to.
+Explicit Consent: Clear affirmative action (signature, checkbox, verbal yes)
+indicating agreement as opposed to implied or assumed consent. Opt-In: Consent
+mechanism requiring customer to actively choose to participate in optional
+services like marketing communications. Opt-Out: Mechanism enabling customers to
+withdraw from services or communications they previously consented to. Standing
+Instruction: Pre-authorized recurring transaction instruction executed
+automatically per specified schedule. Authorization: Specific permission to
+execute transactions or access accounts on customer's behalf.
+4. Policy Statement
+Amanah Bank obtains explicit customer consent for all material matters affecting
+customer rights, data usage, or obligations ensuring decisions are informed,
+voluntary, and properly documented. Account opening requires consent to general
+terms and conditions with clear explanations of customer obligations, Bank
+rights, fees, interest rates, and dispute resolution mechanisms provided before
+signature. Data processing consents distinguish between mandatory processing for
+core banking services and optional processing for marketing, analytics, or
+third-party sharing with separate opt-in mechanisms for optional uses. Marketing
+communication consent is obtained separately for different channels (SMS, email,
+phone calls) with clear opt-out instructions in every communication honoring
+customer preferences promptly. Standing instructions and auto-debit mandates
+require written authorization specifying beneficiary details, amounts (fixed or
+variable within limits), frequency, and duration with revocation rights clearly
+disclosed. Third-party data sharing beyond regulatory requirements or core
+service delivery requires explicit consent naming the third parties, purposes,
+and data categories being shared. Authorized signatories for accounts require
+proper documentation including identity verification, authority limits, and
+revocation procedures ensuring only legitimately authorized persons access
+accounts. Consent forms use clear, simple language avoiding legal jargon or fine
+print strategies; material terms are highlighted ensuring customers understand
+what they're agreeing to. Digital consents through checkboxes, electronic
+signatures, or click-through agreements are legally valid and enforceable
+equivalent to physical signatures when proper authentication and record-keeping
+exist. Consent revocation rights are respected promptly typically within 3
+business days of notification; customers can withdraw consents for optional
+services anytime without relationship termination threats.
+5. Customer Responsibilities
+Customers must read consent documents carefully before signing or clicking
+acceptance understanding rights, obligations, and implications of agreements
+being entered. Questions or unclear terms should be clarified with Bank staff
+before providing consent; signing without understanding creates risks of
+unintended obligations or consequences. Authorized signatory designations should
+be considered carefully selecting trustworthy individuals with appropriate
+authority levels and monitoring their activities regularly. Standing
+instructions and auto-debits require sufficient balance maintenance on due
+dates; customers are responsible for fund availability preventing bounced
+payments and associated charges. Consent revocations should be communicated
+formally through proper channels (written requests, authenticated digital
+submissions) rather than informal mentions for effective processing. Changes in
+circumstances affecting consents including revocation of authorized signatory
+authority, cancellation of standing instructions, or marketing preference
+updates should be notified promptly. Customers should retain copies of consent
+documents, authorization letters, and revocation requests as proof of agreements
+and instructions for future reference or dispute resolution. Consents given
+should be genuine and voluntary; providing consent under pressure,
+misunderstanding, or for accessing services being denied creates complications
+and potential disputes.
+6. Bank Responsibilities
+Amanah Bank shall design consent mechanisms ensuring information is clear,
+prominent, and understandable to average customers avoiding technical jargon or
+complex legal language. Material terms affecting customer rights or obligations
+are highlighted using bold text, larger fonts, or summary boxes drawing
+attention before detailed terms and conditions. Consent forms separate mandatory
+consents required for service delivery from optional consents for value-added
+services enabling customers to decline optional consents without service denial.
+Digital consent interfaces include scroll-to-bottom requirements, key terms
+acceptance, and confirmation screens ensuring customers cannot accidentally
+accept without reviewing content. The Bank maintains comprehensive consent
+records including signed forms, electronic acceptance logs with timestamps and
+IP addresses, and audio recordings of verbal consents for audit and dispute
+resolution. Consent revocations are processed promptly typically within 3
+business days with confirmations sent to customers and system updates preventing
+further processing contrary to revoked consents. Periodic consent reviews prompt
+customers to reconfirm or update preferences especially for marketing
+communications ensuring consents remain current and reflect customer wishes.
+Staff training on consent procedures, explanation requirements, and proper
+documentation ensures consistent consent capture across all branches and
+channels. The Bank does not employ dark patterns, misleading interfaces, or
+coercive practices to obtain consents; all consent mechanisms prioritize
+customer understanding and voluntary agreement. Customers exercising revocation
+rights do not face retaliation, service deterioration, or relationship strain;
+the Bank respects customer autonomy in managing consents and preferences.
+7. Exceptions / Disclosures
+Certain processing activities are permitted without explicit consent based on
+legal obligations (AML reporting, tax compliance), contractual necessity
+(payment processing), or legitimate interests (fraud prevention) under data
+protection principles. Consent for account opening terms and conditions is
+required for establishing banking relationships; declining fundamental terms
+prevents account opening as agreements form contractual basis. Revocation of
+consents central to service delivery (account terms, transaction authorizations)
+effectively terminates the service or relationship requiring account closure or
+service discontinuation. Marketing consent revocations are honored for future
+communications; communications already sent or in-process at revocation time
+cannot be recalled but subsequent communications cease. Standing instruction
+cancellations require advance notice (typically 3 business days) allowing time
+for system updates; payments initiated before cancellation process may execute.
+Authorized signatory revocations don't affect transactions already executed by
+those persons before revocation; only future transactions are prevented
+requiring careful timing of revocations. Consents cannot override statutory
+rights or legal protections; provisions attempting to waive customer rights to
+complaint, legal recourse, or regulatory protection are void regardless of
+consent. Minor consents require guardian authorization with specific limitations
+on scope protecting minor interests; certain high-risk authorizations may be
+declined regardless of guardian consent.
+8. Compliance and Review
+This policy complies with Electronic Transactions Ordinance provisions on
+electronic consents, State Bank consumer protection guidelines on transparent
+agreements, and international standards on consent management. Consent capture
+processes undergo annual audits verifying forms are clear and complete, staff
+provide adequate explanations, and documentation is properly maintained. The
+policy is reviewed annually incorporating regulatory changes, customer feedback
+on consent processes, and best practices in consent user experience design.
+Consent management systems track consent status, revocation requests, and
+processing timelines with dashboards monitoring compliance with revocation
+processing commitments. Customer complaints regarding consent processes, unclear
+terms, or revocation difficulties are investigated within 5 business days with
+process improvements for systemic issues. Staff training on consent principles,
+explanation techniques, documentation requirements, and revocation handling is
+conducted semi-annually ensuring competency. The Bank benchmarks consent
+practices against peer institutions and international standards continuously
+improving consent user experience and legal robustness. Technology investments
+in consent management platforms, digital signature solutions, and preference
+centers are prioritized enabling efficient, customer-friendly consent
+administration.
+C. Customer Experience and Service Policies
+Category 14: Service and Fee Disclosure Policies
+14.1 Service Level Agreement and Performance Standards Policy
+1. Purpose
+This policy establishes quantitative service level commitments for key banking
+services creating accountability and transparency regarding service delivery
+expectations. It enables customers to assess Bank performance objectively while
+driving internal excellence through measurable targets. The policy aims to build
+confidence through consistent service delivery meeting or exceeding published
+standards.
+2. Scope
+This policy applies to service level agreements for critical customer
+touchpoints including account opening, loan processing, payment transactions,
+complaint resolution, card issuance, cheque clearing, and customer service
+responsiveness. It covers service availability commitments, processing
+timelines, error rates, and compensation mechanisms for breaches. The policy
+governs performance measurement, reporting, and continuous improvement
+processes. It applies across all branches, digital channels, and service centers
+with segment-specific variations for retail and corporate customers.
+3. Definitions
+Service Level Agreement (SLA): Quantified commitment regarding service
+performance dimensions like speed, accuracy, or availability. Turnaround Time
+(TAT): Maximum time duration for completing specific services or transactions
+from initiation to conclusion. Uptime: Percentage of time digital services
+remain available and functional excluding planned maintenance. Service Breach:
+Failure to meet published service level commitments requiring investigation and
+potential compensation. Compensation: Financial or service remedy provided to
+customers when service levels are not met due to Bank failures. Performance
+Dashboard: Real-time monitoring system tracking actual performance against SLA
+targets enabling proactive management.
+4. Policy Statement
+Amanah Bank publishes quantified service level commitments for key services on
+its website, mobile app, and branch displays creating transparent performance
+expectations customers can rely upon. Account opening for standard savings or
+current accounts completes within 3 business days of complete documentation
+submission with instant account number provisioning for digital account
+openings. Personal loan applications receive credit decisions within 5 business
+days of complete documentation with disbursement within 2 business days post-
+approval ensuring timely access to credit. Domestic fund transfers submitted
+before cut-off times (IBFT by 5 PM, RTGS by 3 PM) complete same business day
+with beneficiary credit typically within 30 minutes during banking hours.
+Customer service calls are answered within 60 seconds on average with maximum
+wait time not exceeding 3 minutes for 95% of calls maintaining responsive
+support. Complaint acknowledgments occur within 24 hours of registration with
+resolution within 5 business days for simple matters and 15 business days for
+complex issues providing time-bound redressal. ATM and debit card issuance
+completes within 10 business days of application with replacement cards issued
+within 5 business days balancing security procedures with customer convenience.
+Internet banking and mobile banking platforms maintain 99.5% uptime excluding
+planned maintenance windows announced 48 hours in advance ensuring reliable
+digital access. Cheque clearing for local cheques completes within 24 hours (1
+business day) with funds available by next business day providing predictable
+fund availability. Service level breaches caused by Bank systems, processes, or
+staff errors result in compensation including fee waivers, interest adjustments,
+or goodwill credits proportionate to inconvenience. Performance against service
+levels is published quarterly on the Bank's website demonstrating accountability
+and transparency in service delivery enabling customer assessment of performance
+trends.
+5. Customer Responsibilities
+Customers must provide complete, accurate documentation at service initiation
+enabling the Bank to meet processing timelines; incomplete submissions restart
+turnaround time clocks. Service level commitments apply to standard cases;
+complex situations involving exceptions, investigations, or third-party
+dependencies may require extended timelines beyond SLAs. Customers should
+initiate time-sensitive services with adequate lead time considering SLA
+commitments; last-minute requests may not meet personal deadlines even if within
+SLAs. Planned maintenance windows for digital services communicated in advance
+are excluded from uptime calculations; customers should plan around announced
+maintenance for critical transactions. Service level complaints should specify
+which SLA was breached, provide evidence (timestamps, reference numbers), and
+allow investigation before demanding compensation. Customers bear responsibility
+for transaction accuracy (beneficiary details, amounts, purposes); the Bank's
+SLA covers processing speed not error correction from customer mistakes.
+Multiple service requests submitted simultaneously compete for resources;
+customers should prioritize critical services when submitting several requests
+concurrently. Service level commitments apply to transactions meeting regulatory
+and policy requirements; suspicious transactions or compliance holds may extend
+timelines beyond SLAs for legitimate risk management.
+6. Bank Responsibilities
+Amanah Bank shall design service processes with adequate capacity, technology
+automation, and staff resources ensuring consistent achievement of published
+service level commitments. Real-time performance dashboards monitor SLA
+compliance across services and locations with alerts when targets are at risk
+enabling proactive intervention before breaches. Root cause analysis is
+conducted for service level breaches identifying systemic issues, process
+bottlenecks, technology limitations, or training gaps requiring corrective
+action. Customers experiencing service level breaches receive proactive
+communication explaining delays, revised timelines, and compensation eligibility
+demonstrating accountability and customer care. Compensation for SLA breaches is
+provided automatically where possible or upon customer request after breach
+verification typically including fee waivers, interest credits, or service fee
+refunds. Service level targets are reviewed quarterly based on performance data,
+industry benchmarks, and customer expectations with targets tightened as
+capabilities improve driving continuous excellence. Technology investments
+prioritize service delivery improvements including process automation, system
+upgrades, and digital channel enhancements enabling faster, more reliable
+service. Staff performance evaluations incorporate SLA achievement metrics
+creating accountability at individual and team levels for service delivery
+excellence. Customer feedback on service delivery through surveys, complaints,
+and social media is analyzed identifying perception gaps between actual
+performance and customer experience. The Bank communicates service improvements,
+SLA enhancements, and performance achievements proactively building confidence
+and differentiating service quality in the competitive marketplace.
+7. Exceptions / Disclosures
+Force majeure events including natural disasters, civil unrest, pandemics, or
+large-scale technology failures exempt the Bank from SLA commitments during
+impact periods. Regulatory investigations, law enforcement holds, or court
+orders may require transaction delays or account freezes beyond SLA control
+prioritizing legal compliance over service speed. Third-party dependencies
+including correspondent banks, payment networks, clearing houses, or vendor
+systems sometimes cause delays beyond the Bank's direct control. Complex
+transactions requiring manual processing, senior management approvals, or
+detailed investigations naturally take longer than standard transactions
+reflected in published SLAs. Seasonal volumes during peak periods (month-end,
+holidays, salary days) may strain capacity causing temporary service slowdowns
+despite best efforts to maintain standards. Incomplete documentation, customer
+non-responsiveness to queries, or pending clarifications pause SLA clocks;
+timelines resume only after customer provides required inputs. Service level
+commitments represent targets and typical performance; individual transactions
+may occasionally exceed timelines without compensation unless patterns indicate
+systemic failures. Digital service uptime calculations exclude planned
+maintenance, customer internet connectivity issues, and problems originating
+from customer devices or software.
+8. Compliance and Review
+This policy aligns with State Bank of Pakistan service quality guidelines,
+customer service standards, and international best practices in banking service
+level management. Service level performance undergoes monthly monitoring with
+detailed reports to senior management highlighting trends, breaches, root
+causes, and improvement initiatives. The policy is reviewed semi-annually
+incorporating performance insights, competitive benchmarking, regulatory
+expectations, and customer feedback on service experiences. Mystery shopping
+exercises assess actual service delivery against published SLAs testing whether
+branch and call center experiences align with commitments. Customer surveys
+specifically assess awareness of service level commitments and satisfaction with
+actual delivery identifying gaps between promise and perception. Staff training
+on service excellence, time management, prioritization, and customer
+communication ensures consistent understanding and commitment to SLA
+achievement. Technology performance including system response times,
+availability, and transaction processing speeds is monitored continuously with
+infrastructure upgrades prioritized for bottleneck elimination. The Bank
+celebrates SLA achievements publicly and internally recognizing teams and
+individuals delivering exceptional service excellence creating a performance-
+driven culture.
+14.2 Product Suitability and Responsible Selling Policy
+1. Purpose
+This policy establishes principles and procedures for recommending suitable
+banking products aligned with customer needs, risk profiles, and financial
+capabilities preventing mis-selling and exploitation. It ensures customer
+interests guide product recommendations rather than sales targets or revenue
+considerations. The policy aims to build long-term relationships through
+appropriate product matching enhancing customer satisfaction and financial
+wellness.
+2. Scope
+This policy applies to all product sales interactions including account opening,
+loan origination, credit card issuance, investment product sales, insurance
+distribution, and cross-selling activities at Amanah Bank. It covers needs
+assessment procedures, suitability evaluation criteria, product comparison
+disclosure, risk explanation requirements, and post-sale reviews. The policy
+governs staff conduct, incentive structure alignment, supervision mechanisms,
+and consequence management for mis-selling. It applies to all distribution
+channels including branches, call centers, digital platforms, and third-party
+agents selling Bank products.
+3. Definitions
+Suitability: Appropriateness of a product for a customer based on needs, risk
+tolerance, financial capacity, and understanding. Needs Assessment: Process of
+understanding customer financial situation, goals, risk appetite, and
+preferences before product recommendations. Mis-Selling: Recommending or selling
+unsuitable products through misrepresentation, omission of material facts, or
+pressure tactics prioritizing sales over suitability. Product Disclosure:
+Comprehensive explanation of product features, costs, risks, alternatives, and
+consequences enabling informed decisions. Cooling-Off Period: Time after product
+purchase allowing cancellation without penalties enabling reflection on purchase
+decisions. Vulnerable Customer: Individual requiring special consideration due
+to age, financial literacy, distress, or circumstances affecting decision-making
+capacity.
+4. Policy Statement
+Amanah Bank prioritizes product suitability over sales volume ensuring customer
+needs and capabilities guide recommendations creating value for customers and
+sustainable relationships for the Bank. Comprehensive needs assessment precedes
+product recommendations involving discussions about financial goals, income
+stability, existing obligations, risk tolerance, and product understanding
+determining suitable options. Product recommendations present multiple options
+when available explaining differences, trade-offs, costs, and risks enabling
+customers to choose products matching their priorities rather than pushing
+single options. Complex or high-risk products including market-linked
+investments, long-term commitments, or variable-rate loans receive enhanced
+suitability assessment with documented rationale and supervisory oversight.
+Product disclosures use clear, simple language highlighting key features, costs,
+risks, and exit options; marketing promises are substantiated, and risks are
+prominently disclosed not buried in fine print. Vulnerable customers including
+seniors, low-income segments, distressed borrowers, or financially
+unsophisticated individuals receive special consideration with patient
+explanations, family involvement encouragement, and conservative product
+recommendations. Cooling-off periods allow customers to cancel products within
+specified periods (typically 7-14 days) without penalties for products involving
+long-term commitments or significant financial implications. Sales incentives
+reward suitability compliance, customer satisfaction scores, and relationship
+longevity rather than purely volume-based metrics preventing mis-selling
+pressures from compensation structures. Supervisory reviews include transaction
+monitoring, customer callback programs, and complaint analysis detecting
+potential mis-selling requiring investigation, remediation, and staff
+consequences. Customers receive post-sale communications confirming product
+features, costs, rights, and contact points for queries ensuring understanding
+persists beyond the sales moment and enabling early issue detection.
+5. Customer Responsibilities
+Customers must provide accurate, complete information about financial situation,
+goals, risk tolerance, and existing obligations enabling appropriate suitability
+assessment and product recommendations. Customers should actively participate in
+needs assessment discussions asking questions, expressing concerns, and honestly
+communicating preferences rather than passive acceptance of recommendations.
+Product disclosures, terms and conditions, and risk explanations should be read
+carefully before purchase; signing without understanding creates risks of
+unsuitable products and financial difficulties. Customers should compare product
+options considering not just benefits but also costs, risks, commitments, and
+exit penalties making holistic assessments rather than focusing narrowly on
+attractive features. If feeling pressured, rushed, orRetrySMContinue5. Customer
+Responsibilities (continued)
+If feeling pressured, rushed, or uncertain about product recommendations,
+customers should request time to consider, seek second opinions, or consult
+family members before committing to purchases. Cooling-off period rights should
+be exercised promptly if post-purchase reflection reveals unsuitability,
+misunderstanding, or changed circumstances enabling product cancellation without
+penalties. Changes in financial circumstances affecting ability to maintain
+products (income loss, increased obligations, health issues) should be
+communicated to the Bank enabling proactive adjustments or alternatives.
+Customers should monitor product performance, review statements, and assess
+whether products continue meeting needs over time requesting reviews or switches
+when circumstances change. Mis-selling suspicions including misrepresentation,
+omitted risk disclosure, or pressure tactics should be reported through
+complaint channels enabling investigation and remediation.
+6. Bank Responsibilities
+Amanah Bank shall implement structured needs assessment frameworks requiring
+staff to document customer financial situation, goals, risk appetite, and
+product understanding before recommendations. Suitability evaluation matrices
+map customer profiles to appropriate products with clear criteria for matching
+ensuring consistent, objective product recommendations across staff and
+locations. Product comparison tools enable staff to present multiple suitable
+options with side-by-side feature, cost, and risk comparisons empowering
+customers to make informed choices. Risk disclosure scripts and materials ensure
+consistent communication of product risks, worst-case scenarios, and exit costs
+preventing selective disclosure or risk minimization. Supervisory oversight
+includes pre-approval requirements for high-risk products, random transaction
+reviews, and customer callback programs verifying suitability compliance and
+customer satisfaction. The Bank conducts post-sale reviews contacting customers
+after product purchase to confirm understanding, satisfaction, and absence of
+mis-selling providing early detection and remediation opportunities. Complaint
+analysis identifies patterns suggesting mis-selling by specific staff, branches,
+or product types triggering investigations, corrective actions, and potential
+staff consequences. Staff training on needs assessment techniques, product
+knowledge, ethical selling, and regulatory requirements is conducted quarterly
+ensuring competency and compliance. Incentive structures balance volume targets
+with quality metrics including suitability compliance rates, customer
+satisfaction scores, complaint rates, and retention rates preventing pure
+volume-driven selling. The Bank maintains comprehensive sales records including
+needs assessment documentation, product recommendations, customer
+acknowledgments, and suitability rationale enabling audit trails and dispute
+resolution.
+7. Exceptions / Disclosures
+Suitability assessment depth varies by product complexity; simple products like
+basic savings accounts require less extensive assessment than complex
+investments or long-term credit commitments. Customer insistence on specific
+products deemed marginally unsuitable may be accommodated with enhanced
+disclosure, documented acknowledgment of unsuitability reasons, and management
+approval. Products with regulatory suitability requirements (investments,
+insurance) face stricter assessment standards and mandatory documentation
+compared to standard banking products. Suitability is point-in-time evaluation;
+changed circumstances post-purchase may render previously suitable products
+unsuitable requiring customer-initiated review and adjustment requests. Digital
+channel sales may have simplified suitability assessments with automated
+screening questions and algorithm-based recommendations subject to human review
+for complex products. Walk-in customers requesting specific products without
+full relationship context receive limited suitability assessment based on
+available information and customer declarations. Regulatory changes, product
+discontinuations, or bank policies may necessitate product migrations or changes
+affecting existing customers handled with advance notice and alternative
+options. Suitability guarantees cannot be provided as financial outcomes depend
+on market conditions, customer circumstances, and macroeconomic factors beyond
+Bank control despite appropriate product selection.
+8. Compliance and Review
+This policy complies with State Bank of Pakistan responsible lending guidelines,
+Consumer Protection Department directives on fair dealing, and international
+principles of suitable product distribution. Suitability compliance undergoes
+quarterly audits through transaction sampling, documentation review, customer
+interviews, and supervisory control verification assessing adherence. The policy
+is reviewed annually incorporating regulatory updates, complaint trend analysis,
+mis-selling incidents, and evolving best practices in responsible product
+distribution. Mystery shopping exercises assess actual sales practices testing
+whether staff conduct proper needs assessment, provide balanced disclosure, and
+avoid pressure tactics. Customer satisfaction surveys specifically assess
+suitability perceptions asking whether products meet expectations and needs
+identifying gaps between intent and perception. Staff performance evaluations
+incorporate suitability compliance metrics with consequences ranging from
+coaching to termination for repeated mis-selling incidents. The Bank benchmarks
+suitability practices against peer institutions and international standards
+adopting industry-leading practices in needs-based selling. Compensation
+structure reviews ensure incentives genuinely reward suitable selling without
+creating perverse incentives for short-term volume over long-term customer
+satisfaction.
+Category 15: Customer Service and Complaint Resolution Policies
+15.1 Multi-Channel Customer Service Delivery Policy
+1. Purpose
+This policy establishes comprehensive customer service delivery across multiple
+touchpoints ensuring consistent, accessible, and responsive support through
+channels matching customer preferences. It aims to provide seamless experiences
+whether customers interact via branches, phone, digital platforms, or social
+media. The policy prioritizes customer convenience while maintaining service
+quality and security across all channels.
+2. Scope
+This policy applies to all customer service channels operated by Amanah Bank
+including branch banking, 24/7 call center, internet banking support, mobile app
+assistance, email support, social media engagement, video banking, and chatbot
+services. It covers service availability, response time standards, staff
+competency requirements, channel integration, and escalation procedures. The
+policy governs routine inquiries, transaction requests, complaint handling, and
+technical support across all customer segments. It applies to both direct Bank
+staff and outsourced service providers operating customer-facing channels.
+3. Definitions
+Multi-Channel Service: Availability of customer support through diverse channels
+enabling customer choice of preferred interaction method. Omnichannel
+Experience: Seamless, integrated service where customer interactions across
+channels are connected with shared context and history. First Call Resolution
+(FCR): Percentage of customer inquiries resolved during initial contact without
+transfers or callbacks. Channel Shift: Strategy of encouraging customers toward
+efficient self-service digital channels for routine transactions. Service
+Escalation: Transfer of complex issues to specialized teams or senior management
+for resolution. Average Handling Time (AHT): Mean duration to resolve customer
+inquiries including interaction time and after-call work. Customer Effort Score
+(CES): Metric measuring ease of getting issues resolved from customer
+perspective.
+4. Policy Statement
+Amanah Bank provides comprehensive customer service across multiple channels
+recognizing diverse customer preferences, digital literacy levels, and
+transaction types requiring appropriate interaction methods. Branch banking
+offers full-service support for complex transactions, elderly customers, and
+situations requiring document verification with extended hours at select
+locations serving working customers. 24/7 call center handles inquiries,
+transaction requests, complaint registration, and emergency services like card
+blocking providing round-the-clock telephone access with multilingual support in
+Urdu and English. Internet banking and mobile app support includes in-app chat,
+email tickets, and phone callbacks for technical issues, navigation assistance,
+and digital transaction support. Social media monitoring on platforms including
+Facebook, Twitter, and Instagram provides public query responses and private
+message handling with 2-hour response time commitments during business hours.
+Email support addresses detailed inquiries, documentation requests, and non-
+urgent matters with 24-hour response commitments ensuring written communication
+preferences are accommodated. Video banking enables remote face-to-face
+interactions for account opening, KYC updates, and advisory services combining
+branch-like personal touch with digital convenience. Chatbot services powered by
+artificial intelligence handle routine inquiries like balance checks,
+transaction status, FAQs, and navigation guidance with human handoff for complex
+issues. Channel integration ensures customer context including previous
+interactions, account information, and issue history is accessible across
+channels preventing customers from repeating information. Service escalation
+protocols route complex issues to specialized teams, subject matter experts, or
+senior management with defined escalation criteria and turnaround time
+commitments. First call resolution targets of 70% for call center and 60% for
+branch inquiries drive efficiency while recognizing some issues require
+investigation or follow-up beyond initial interaction. Customer feedback through
+post-interaction surveys, service ratings, and regular satisfaction studies
+informs continuous improvement across all service channels.
+5. Customer Responsibilities
+Customers should choose appropriate channels for their needs using self-service
+digital channels for routine transactions and human-assisted channels for
+complex issues optimizing efficiency. Security protocols including identity
+verification questions, OTP confirmations, or account authentication must be
+cooperated with patiently as these protect customer accounts from unauthorized
+access. Clear communication of issues, questions, or requests with relevant
+details like account numbers, transaction references, and specific concerns
+enables faster, more accurate resolution. Customers should note reference
+numbers from interactions for follow-up purposes enabling continuity across
+multiple touchpoints or when escalating unresolved issues. Respectful, courteous
+interaction with service staff regardless of channel maintains professional
+environment; abusive behavior hampers resolution and may result in service
+withdrawal. Customers should provide feedback through post-service surveys
+honestly rating experiences and suggesting improvements helping the Bank enhance
+service quality. Multiple simultaneous interactions on same issue across
+different channels should be avoided as this creates confusion, duplicate
+efforts, and inefficient resource utilization. Digital channel usage requires
+basic device and connectivity responsibility; the Bank supports platform issues
+but cannot resolve customer internet or device problems.
+6. Bank Responsibilities
+Amanah Bank shall maintain adequate staffing across all channels ensuring
+reasonable wait times with call center answer times within 60 seconds and branch
+queues managed through token systems and staff optimization. Staff training on
+product knowledge, systems operation, soft skills, and problem-solving ensures
+competent service delivery with quarterly refresher programs and competency
+certifications. Channel capacity planning uses historical volumes, seasonal
+patterns, and growth projections to ensure sufficient resources preventing
+service degradation during peak periods. Technology infrastructure supporting
+customer service including telephony systems, CRM platforms, knowledge bases,
+and communication tools receives continuous investment ensuring reliability and
+functionality. Customer context including account details, interaction history,
+and previous complaints is accessible to service staff across channels enabling
+informed, personalized service without repetitive information requests. Quality
+monitoring includes call recordings, branch mystery shopping, chat transcript
+reviews, and email quality audits assessing staff performance against service
+standards with coaching interventions. Service recovery empowers frontline staff
+to resolve complaints, waive fees, or provide goodwill gestures within defined
+limits enabling immediate resolution without bureaucratic escalations. The Bank
+publishes channel-specific service standards including response times,
+resolution timelines, and availability hours creating transparency and
+accountability for service delivery. Accessibility features including hearing-
+impaired support, language options, and elderly-friendly interfaces ensure
+inclusive service delivery accommodating diverse customer needs. Performance
+dashboards track channel metrics including volumes, wait times, resolution
+rates, and customer satisfaction enabling proactive management and continuous
+improvement.
+7. Exceptions / Disclosures
+Channel availability may vary with branch hours typically 9 AM to 5 PM weekdays,
+call center 24/7, and digital channels always available except during
+maintenance windows communicated in advance. Service scope differs by channel
+with branches offering full services, call centers handling most requests, and
+digital channels focused on self-service transactions with some limitations.
+Complex transactions requiring physical document verification, senior management
+approval, or regulatory compliance may only be feasible through branch channels
+despite customer preference for remote channels. Response time commitments apply
+during normal operations; system outages, natural disasters, or extraordinary
+circumstances may cause temporary service degradation beyond Bank control.
+Multilingual support availability varies by channel with broader language
+options at branches in diverse communities compared to standardized Urdu/English
+in call centers. Social media responses balance public engagement with privacy
+protection; detailed account discussions occur through private channels rather
+than public posts. Video banking availability may be limited based on customer
+device capabilities, internet bandwidth, and appointment scheduling requiring
+advance booking for guaranteed access. Outsourced service providers operate some
+channels under Bank supervision; service quality may occasionally differ from
+direct Bank operations though oversight ensures standards compliance.
+8. Compliance and Review
+This policy aligns with State Bank of Pakistan service quality guidelines,
+consumer protection standards, and international best practices in multi-channel
+banking service delivery. Service quality across channels undergoes monthly
+monitoring through KPIs including response times, resolution rates, customer
+satisfaction, and quality scores with performance reporting to management. The
+policy is reviewed annually incorporating technological advancements, channel
+usage trends, customer preferences evolution, and competitive practices in
+service delivery. Customer complaints regarding service quality, channel
+accessibility, or staff conduct are analyzed for patterns identifying systematic
+issues requiring training, process changes, or technology enhancements. Mystery
+shopping and customer journey mapping assess actual service experiences across
+channels testing whether standards translate into customer perceptions. Staff
+training programs are updated quarterly based on service quality findings, new
+product launches, system changes, and evolving customer expectations. The Bank
+invests in channel innovation including AI-powered assistance, predictive
+service, and proactive outreach leveraging data analytics to anticipate needs
+and resolve issues before customers contact service. Benchmarking against peer
+banks and global banking leaders identifies service excellence gaps driving
+aspirational targets and innovation adoption.
+15.2 Vulnerable Customer Support Policy
+1. Purpose
+This policy establishes specialized support mechanisms for vulnerable customers
+including elderly persons, disabled individuals, low-income segments, and
+financially distressed borrowers ensuring equitable access and protection. It
+recognizes that uniform treatment may disadvantage customers facing special
+circumstances requiring tailored approaches. The policy aims to promote
+financial inclusion while preventing exploitation of vulnerability through
+enhanced safeguards.
+2. Scope
+This policy applies to identified vulnerable customer segments including senior
+citizens above 60 years, persons with physical or mental disabilities, low-
+literacy customers, low-income account holders, distressed loan borrowers, and
+temporarily vulnerable customers facing crises. It covers special service
+provisions, communication adaptations, product modifications, complaint
+prioritization, and protection measures. The policy governs staff training,
+identification procedures, and support coordination. It applies across all
+branches, customer service channels, and product lines ensuring consistent
+vulnerability-responsive service.
+3. Definitions
+Vulnerable Customer: Individual facing circumstances requiring special
+consideration including age, disability, financial distress, literacy
+limitations, or temporary crises. Elder Customer: Person aged 60 years or above
+potentially facing physical, cognitive, or digital literacy challenges requiring
+patient, accessible service. Disability: Physical, sensory, cognitive, or mental
+condition affecting ability to access standard banking services requiring
+accommodations. Financial Distress: Temporary or permanent difficulty meeting
+financial obligations requiring supportive rather than purely commercial
+responses. Literacy Challenge: Limited reading, writing, or digital skills
+affecting ability to understand banking products, documents, or operate digital
+channels. Reasonable Accommodation: Modifications to standard procedures
+enabling vulnerable customers to access services without discrimination.
+4. Policy Statement
+Amanah Bank commits to inclusive banking recognizing vulnerable customers
+deserve equitable access to financial services with accommodations addressing
+specific challenges they face. Senior citizens receive priority service
+including dedicated queues at branches, priority call routing, extended
+transaction times without pressure, and patient explanations recognizing
+potential physical or cognitive limitations. Customers with disabilities receive
+reasonable accommodations including wheelchair accessibility at branches, audio-
+visual assistance for visually or hearing-impaired customers, large-print
+documents, Braille ATMs where feasible, and home banking services for mobility-
+impaired customers. Low-literacy customers receive verbal explanations of
+documents, simplified language in communications, pictorial guides for digital
+banking, and assisted transactions without judgment or impatience. Financially
+distressed borrowers receive empathetic, constructive engagement exploring
+restructuring options, temporary relief measures, or financial counseling rather
+than purely aggressive recovery approaches. Low-income customers access basic
+banking services with reduced or waived fees, simplified account options, and
+protection from unsuitable expensive products through enhanced suitability
+assessment. Customers facing temporary vulnerabilities due to bereavement,
+medical emergencies, or unemployment receive flexible treatment including
+payment deferrals, documentation deadline extensions, or expedited processing of
+legitimate requests. Staff training on vulnerability recognition, empathetic
+communication, patience, and appropriate accommodations ensures consistent,
+dignified treatment across all customer interactions. Complaint prioritization
+gives vulnerable customer complaints enhanced urgency and senior management
+visibility ensuring their concerns receive prompt, fair resolution. Protection
+measures prevent exploitation of vulnerability including enhanced suitability
+assessments for product sales, fraud monitoring patterns typical of elder abuse,
+and cooling-off periods for significant decisions. Privacy and dignity are
+maintained; vulnerability identification occurs through self-declaration,
+obvious indicators, or family inputs without stigmatization or insensitive
+categorization.
+5. Customer Responsibilities
+Vulnerable customers should self-declare their status or special needs enabling
+the Bank to provide appropriate accommodations and support rather than assuming
+staff will detect all vulnerabilities. Supporting documentation for disability
+accommodations or senior citizen benefits including age certificates or medical
+reports should be provided facilitating verification and service customization.
+Family members or trusted representatives can be designated to assist with
+banking particularly for customers with cognitive limitations or severe
+disabilities ensuring supported rather than independent decision-making where
+appropriate. Customers should communicate specific needs clearly whether
+requiring large-print statements, sign language interpretation, home visits, or
+extended service times enabling staff to respond effectively. Reasonable
+cooperation with security procedures is necessary; vulnerability doesn't exempt
+customers from identity verification or transaction authorization requirements
+protecting account security. Vulnerability status changes including recovery
+from temporary distress or changed capabilities should be communicated enabling
+service adjustments aligned with current circumstances. Customers should utilize
+available support resources including financial counseling, customer service
+assistance, or family consultation for significant financial decisions
+preventing impulsive or unsuitable choices. Vulnerability accommodations are
+genuine service enhancements not opportunities for preferential treatment in
+policy compliance; regulatory requirements and policy adherence apply
+universally.
+6. Bank Responsibilities
+Amanah Bank shall train all customer-facing staff on vulnerability recognition,
+sensitive communication, patience, and accommodation provision ensuring
+dignified service delivery. Branch infrastructure includes wheelchair ramps,
+accessible restrooms, comfortable seating areas, and clear signage supporting
+physical accessibility for disabled and elderly customers. Technology
+accommodations include screen readers for visually impaired, large-font options
+in apps, voice-assisted banking, and simplified interfaces for low-literacy
+users. Home banking services enable mobility-impaired or extremely elderly
+customers to conduct transactions through scheduled staff visits with proper
+security protocols and documentation. Sign language interpretation, multilingual
+support, and communication aids assist customers with hearing, speech, or
+language barriers ensuring effective interaction. Distressed borrower support
+programs include financial counseling, restructuring options, temporary payment
+deferrals, and connection to social services when appropriate providing holistic
+assistance beyond pure collections. Priority handling systems identify
+vulnerable customers in queues, call routing, and complaint management ensuring
+they receive timely attention without excessive waiting. The Bank monitors
+vulnerable customer accounts for unusual activity patterns potentially
+indicating exploitation, fraud, or undue influence by others triggering welfare
+checks. Product design incorporates accessibility considerations including
+simplified terms, affordable pricing, and protection features relevant to
+vulnerable segments. The Bank collaborates with disability organizations, elder
+care services, and financial counseling agencies ensuring awareness of best
+practices and available community resources for customer support. Feedback
+mechanisms specifically capture vulnerable customer experiences identifying
+service gaps, accommodation deficiencies, or staff insensitivity requiring
+corrective action.
+7. Exceptions / Disclosures
+Vulnerability doesn't override security requirements; identity verification,
+transaction authorization, and fraud prevention protocols apply universally
+protecting all customers including vulnerable ones. Some accommodations face
+practical limitations including Braille ATMs availability constrained by cost-
+benefit considerations, requiring pragmatic alternatives like audio guidance or
+assisted service. Home banking services for mobility-impaired customers may have
+geographic limitations, minimum transaction thresholds, or appointment
+scheduling requirements managing operational feasibility. Priority service for
+vulnerable customers doesn't guarantee immediate service during extreme peak
+periods; reasonable priority within operational constraints applies.
+Vulnerability support focuses on accessibility and fair treatment; it cannot
+provide financial concessions violating banking regulations or creating unfair
+advantages over other customers. Self-declaration of vulnerability is generally
+accepted; however, the Bank may request verification for significant
+accommodations preventing abuse of vulnerability provisions. Vulnerability
+identification by staff is based on observable indicators and customer
+communication; the Bank cannot identify all vulnerable situations requiring
+customer cooperation in disclosure. Financial distress support explores
+rehabilitation options but cannot guarantee loan waivers or forgiveness;
+commercial sustainability and fairness to depositors require balanced
+approaches.
+8. Compliance and Review
+This policy aligns with State Bank of Pakistan financial inclusion directives,
+disability rights legislation, elder protection principles, and international
+accessibility standards. Vulnerable customer service provisions undergo annual
+audits assessing accommodation availability, staff competency, and vulnerable
+customer satisfaction. The policy is reviewed annually incorporating disability
+advocacy feedback, elder service best practices, and evolving understanding of
+vulnerability dimensions. Vulnerable customer complaint analysis identifies
+service gaps, insensitive treatment, or accommodation deficiencies requiring
+systemic improvements. Staff training on vulnerability support is mandatory
+annually with scenario-based learning covering diverse vulnerability types and
+appropriate responses. The Bank collaborates with disability organizations
+conducting accessibility audits of branches and digital channels with
+implementation of recommended improvements. Mystery shopping includes vulnerable
+customer scenario testing assessing whether staff provide patient, accommodating
+service aligned with policy commitments. Performance metrics track vulnerable
+customer satisfaction, accommodation provision rates, and complaint resolution
+ensuring accountability for inclusive service delivery.
+Category 16: Digital and Accessibility Policies
+16.1 Digital Banking Services and Innovation Policy
+1. Purpose
+This policy establishes framework for developing, launching, and managing
+digital banking services ensuring innovation serves customer convenience while
+maintaining security, reliability, and regulatory compliance. It aims to
+position Amanah Bank as a digitally progressive institution meeting evolving
+customer expectations. The policy balances rapid innovation with prudent risk
+management and inclusive design.
+2. Scope
+This policy applies to all digital banking initiatives including internet
+banking platforms, mobile banking applications, USSD banking, API-based
+services, chatbots, digital account opening, blockchain experiments, and
+emerging technology adoption. It covers innovation governance, customer testing,
+security requirements, accessibility standards, and performance monitoring. The
+policy governs digital service development, launch approvals, post-launch
+support, and periodic enhancement. It applies to both customer-facing digital
+services and internal digital processes improving customer experiences
+indirectly.
+3. Definitions
+Digital Banking: Delivery of banking services through electronic channels
+including internet, mobile apps, and automated systems without physical branch
+interaction. Innovation: Development or adoption of new technologies, processes,
+or service models enhancing customer value or operational efficiency. User
+Experience (UX): Overall experience customers have using digital services
+including ease, intuitiveness, efficiency, and satisfaction. Application
+Programming Interface (API): Technical interface enabling third-party
+applications to integrate with Bank systems securely. Minimum Viable Product
+(MVP): Initial version of digital service with core features enabling customer
+testing and feedback before full development. Digital Divide: Gap between
+customers with digital access and skills versus those lacking technology or
+literacy to use digital services. Fintech Partnership: Collaboration with
+financial technology companies leveraging their innovations while maintaining
+Bank's customer relationships and regulatory compliance.
+4. Policy Statement
+Amanah Bank embraces digital innovation as strategic priority investing in
+technology enhancing customer convenience, operational efficiency, and
+competitive positioning in evolving banking landscape. Digital service
+development follows customer-centric design thinking involving customer
+research, prototype testing, iterative development, and post-launch optimization
+ensuring solutions address genuine customer needs. Security-by-design principles
+embed cybersecurity, data protection, and fraud prevention in digital services
+from conception rather than retrofitting security after development.
+Accessibility standards ensure digital services accommodate diverse customers
+including elderly users, disabled persons, and those with limited digital
+literacy through inclusive design and alternative channels. Mobile-first
+strategy prioritizes smartphone-based banking recognizing mobile penetration
+exceeds desktop internet usage particularly in emerging customer segments.
+Innovation governance includes cross-functional committees evaluating digital
+initiatives for business value, risk profile, regulatory compliance, and
+alignment with strategic priorities before approval. Pilot testing with customer
+groups validates digital services before full launch gathering feedback,
+identifying bugs, and refining features minimizing post-launch issues.
+Performance monitoring tracks digital service adoption, usage patterns, customer
+satisfaction, and technical performance enabling data-driven optimization and
+issue resolution. Open banking principles through secure APIs enable integration
+with fintech partners, aggregation services, and third-party apps expanding
+service ecosystem while maintaining security. Digital channel shift strategies
+encourage customer migration from branches to self-service channels for routine
+transactions through education, incentives, and superior digital experiences
+optimizing resource allocation. The Bank maintains hybrid model supporting
+customers preferring traditional channels while enhancing digital options
+recognizing transition takes time and universal digital adoption remains
+aspirational.
+5. Customer Responsibilities
+Customers adopting digital banking must invest time learning platform
+functionality through tutorials, demos, and practice transactions building
+confidence and competence. Device security including operating system updates,
+antivirus software, strong passwords, and avoiding rooted/jailbroken devices is
+customer responsibility protecting their digital banking access. Customers
+should report digital service bugs, usability issues, or improvement suggestions
+through feedback channels helping the Bank enhance platform quality. Digital
+self-service usage for routine transactions frees branch staff for complex
+services; customers should embrace appropriate channel usage optimizing
+efficiency. Customers uncomfortable with digital banking should access available
+training including branch demonstrations, video tutorials, or dedicated
+helplines rather than avoiding beneficial services due to intimidation. Digital
+literacy development is encouraged through Bank-provided resources, community
+classes, or family assistance recognizing some customers need support beyond
+intuitive design. Customers should review digital transaction confirmations,
+alerts, and statements regularly detecting errors or fraud promptly enabling
+swift resolution. Digital channel availability doesn't eliminate customer
+responsibility for transaction accuracy; input errors remain customer
+responsibility regardless of channel used.
+6. Bank Responsibilities
+Amanah Bank shall invest substantially in digital infrastructure, platforms, and
+talent ensuring technical capabilities match strategic digital ambitions and
+customer expectations. User experience design involves actual customers through
+focus groups, usability testing, and beta programs ensuring interfaces are
+intuitive, efficient, and aesthetically pleasing. Digital services undergo
+rigorous security testing including penetration testing, vulnerability
+assessments, and compliance audits before launch ensuring customer data and
+transaction security. The Bank provides comprehensive digital banking education
+through in-app tutorials, video guides, branch demonstrations, and dedicated
+helplines easing customer transition to digital channels. Performance monitoring
+includes uptime tracking, transaction success rates, loading speeds, and error
+rates with immediate escalation for service degradation. Customer feedback
+through ratings, reviews, support contacts, and behavioral analytics informs
+continuous enhancement ensuring digital services evolve with needs and
+expectations. The Bank maintains channel redundancy ensuring branch and phone
+banking remain available for customers unable or unwilling to use digital
+services preventing digital exclusion. Innovation pipeline balances emerging
+technology experimentation with stable core platform maintenance ensuring
+reliability doesn't suffer in pursuit of innovation. Fintech partnerships
+undergo due diligence assessing technical competency, security standards,
+financial stability, and regulatory compliance before integration approval. The
+Bank communicates digital service updates, new features, and maintenance
+schedules proactively through multiple channels ensuring customers stay informed
+and can plan usage.
+7. Exceptions / Disclosures
+Digital services cannot replicate every branch service; complex transactions,
+document submissions, or exceptions may still require physical branch visits
+despite digital advancements. Technology glitches, network outages, or
+cyberattacks may occasionally disrupt digital services; the Bank maintains
+business continuity through alternative channels and rapid incident response.
+Digital innovation experiments may have limited initial availability,
+functionality constraints, or pilot participant restrictions before broader
+rollout. Customer internet connectivity, device capabilities, and digital
+literacy affect digital service experiences; the Bank optimizes platforms but
+cannot control customer-side technology limitations. Digital channel shift
+incentives including lower fees or enhanced features for digital transactions
+reflect genuine cost differences and encourage efficient channel usage without
+penalizing non-digital users excessively. Third-party app integrations through
+open banking APIs create some dependence on external service provider
+reliability and security beyond direct Bank control. Emerging technologies
+including blockchain or artificial intelligence are experimental; the Bank makes
+no guarantees regarding timing or ultimate adoption as commercial viability and
+regulatory clarity evolve. Digital preference data collected through usage
+analytics informs personalization but also creates data privacy considerations
+managed through strict consent and protection protocols.
+8. Compliance and Review
+This policy complies with State Bank of Pakistan digital banking regulations,
+cybersecurity guidelines, Electronic Transactions Ordinance, and international
+standards for digital financial services. Digital service launches undergo
+regulatory approval where required ensuring compliance with licensing, security,
+and consumer protection regulations before customer availability. The policy is
+reviewed semi-annually incorporating technological developments, regulatory
+updates, customer feedback, and competitive landscape changes. Digital banking
+metrics including adoption rates, transaction volumes, customer satisfaction,
+and technical performance are monitored through executive dashboards driving
+accountability. Customer complaints regarding digital services are prioritized
+with rapid resolution, root cause analysis, and systemic fixes preventing
+recurrence. Staff training on digital banking support, troubleshooting, customer
+education, and escalation procedures ensures competent assistance across all
+service channels. The Bank participates in banking technology forums, fintech
+ecosystems, and regulatory consultations on digital banking contributing to
+industry standards and regulatory development. Investment in digital innovation
+balances short-term enhancements with long-term transformation ensuring
+sustainable competitive positioning in digital banking landscape.
+Category 17: Marketing and Communication Policies
+17.1 Marketing Communications and Advertising Policy
+1. Purpose
+This policy establishes ethical standards for marketing communications ensuring
+advertisements, promotions, and customer outreach are truthful, transparent, and
+respectful. It prevents misleading marketing practices that exploit customer
+trust or create unrealistic expectations. The policy aims to build brand
+reputation through honest, customer-centric communications compliant with
+regulations and social norms.
+2. Scope
+This policy applies to all marketing activities including print advertisements,
+television commercials, radio spots, digital marketing, social media content,
+SMS campaigns, email marketing, outdoor advertising, and promotional materials
+across all products and services offered by Amanah Bank. It covers content
+development, approval processes, disclosure requirements, consent management,
+and compliance verification. The policy governs internal marketing teams,
+external advertising agencies, brand ambassadors, and third-party marketers
+acting on the Bank's behalf. It applies to both mass marketing campaigns and
+personalized direct marketing communications.
+3. Definitions
+Marketing Communication: Any message from the Bank promoting products, services,
+or brand designed to influence customer perceptions or decisions. Advertisement:
+Paid promotional content in media channels including print, broadcast, digital,
+or outdoor platforms. Direct Marketing: Personalized communications to specific
+customers including SMS, email, telemarketing, or direct mail. Disclosure:
+Transparent communication of material terms, conditions, risks, or limitations
+associated with promoted products. Opt-In Consent: Customer agreement to receive
+marketing communications providing permission for future outreach. Greenwashing:
+Misleading environmental claims creating false impression of sustainability or
+social responsibility. Testimonial: Customer or celebrity endorsement of Bank
+products requiring genuine experiences and appropriate disclosures.
+4. Policy Statement
+Amanah Bank conducts marketing with integrity ensuring all communications are
+truthful, substantiated, and not misleading through omission or exaggeration
+protecting customer trust. Product benefits highlighted in marketing must be
+accurate and achievable; exaggerated claims, impossible promises, or selective
+disclosure of favorable attributes while hiding limitations are prohibited.
+Interest rates, fees, eligibility criteria, and material terms prominently
+featured in advertising are accurate and current; fine print cannot contradict
+or substantially limit headline claims. Comparative advertising against
+competitors must be factual, verifiable, and fair avoiding disparagement,
+misrepresentation, or unfair comparisons cherry-picking favorable dimensions.
+Risk disclosures accompany marketing for products with potential downsides
+including variable rates, market risks, penalties, or long-term commitments
+ensuring balanced information. Marketing targeting vulnerable populations
+including children, elderly persons, or low-income segments receives enhanced
+scrutiny ensuring protection from exploitation and unsuitable product promotion.
+Direct marketing to customers requires prior opt-in consent; unsolicited
+marketing to those who haven't consented or have opted out violates customer
+preferences and regulations. Marketing materials undergo multi-level approval
+including product, legal, compliance, and marketing teams ensuring accuracy,
+regulatory compliance, and alignment with brand values before release. Celebrity
+or customer testimonials must reflect genuine experiences, cannot make atypical
+claims without disclosure, and require written consent from individuals
+featured. Marketing campaigns track customer response, complaints, and
+regulatory feedback enabling rapid correction if unintended misleading
+impressions emerge post-launch.
+5. Customer Responsibilities
+Customers should read marketing materials critically assessing claims against
+their needs and seeking detailed information beyond promotional highlights
+before decisions. Promotional offers have specific terms, conditions,
+eligibility criteria, and time limitations; customers should verify these
+details rather than assuming universal applicability. Consent to marketing
+communications can be withdrawn anytime through opt-out mechanisms provided in
+messages; customers should actively manage communication preferences. Customers
+encountering misleading advertising should report concerns through complaint
+channels enabling investigation and corrective action protecting other
+customers. Marketing creates awareness but shouldn't replace comprehensive due
+diligence; customers should review terms and conditions, compare alternatives,
+and assess suitability before product purchases. Promotional pricing, waived
+fees, or special rates typically have time limitations or eligibility
+conditions; customers should understand when regular pricing resumes or what
+triggers apply. Customers should protect themselves from phishing or fraud
+attempts mimicking Bank marketing by verifying message authenticity through
+official channels before responding.
+6. Bank Responsibilities
+Amanah Bank shall establish marketing approval workflows requiring sign-off from
+product owners verifying claim accuracy, legal teams confirming regulatory
+compliance, and senior management ensuring brand alignment. Marketing content
+undergoes fact-checking verifying all statistics, product features, pricing, and
+claims against current product terms and competitive information. Disclosure
+hierarchies ensure material information appears prominently in marketing not
+relegated to fine print, footnotes, or linked documents requiring proactive
+customer effort to discover. The Bank maintains current marketing material
+repository with version control ensuring outdated materials with incorrect
+information are withdrawn from circulation. Customer complaints regarding
+misleading marketing are investigated within 3 business days with immediate
+corrective action including campaign withdrawal, customer communication, and
+internal accountability. Marketing effectiveness metrics balance response rates
+with quality indicators including suitability of resulting sales, customer
+satisfaction, and complaint rates preventing purely volume-driven evaluation.
+The Bank monitors competitor advertising and industry practices ensuring its
+marketing maintains competitive truth standards without racing to bottom in
+exaggeration. Marketing budgets allocate resources to customer education and
+financial literacy alongside promotional campaigns demonstrating social
+responsibility beyond commercial interests. Agency contracts include clauses
+holding agencies accountable for content accuracy, regulatory compliance, and
+brand standard adherence with consequences for violations. The Bank publishes
+marketing guidelines on its website transparently communicating ethical
+standards and inviting customer feedback on advertising practices.
+7. Exceptions / Disclosures
+Promotional offers targeting new customers or specific segments may appear
+preferential; differential pricing based on objective criteria like relationship
+value or risk profile is permissible with transparent explanation. Limited-time
+offers create urgency; while legitimate, artificial urgency through deceptive
+scarcity tactics or false deadlines is prohibited. Aspirational marketing using
+imagery, emotions, or lifestyle associations is acceptable provided core claims
+about products remain factual and substantiated. Humor, creativity, or
+attention-grabbing techniques in marketing are encouraged provided they don't
+mislead through implication or create false impressions about product
+attributes. Marketing to existing customers through relationship channels may
+reference account-specific information; this personalization uses existing data
+with consent rather than constituting privacy violation. Regional marketing
+variations reflect local languages, cultural nuances, or market conditions;
+consistency in core messages and claims is maintained across regions. Digital
+marketing including search ads, social media, and online display follow
+platform-specific rules and formats; space constraints require adaptation while
+maintaining substantive accuracy. Regulatory pre-approval is sought for
+marketing of new products, complex instruments, or materials making
+medical/legal claims ensuring compliance before customer exposure.
+8. Compliance and Review
+This policy complies with State Bank of Pakistan advertising guidelines,
+Consumer Protection Department directives, Advertisement Standards Council
+codes, and international marketing ethics principles. Marketing materials
+undergo compliance reviews before launch and post-launch monitoring ensures
+actual customer communications align with approved content. The policy is
+reviewed annually incorporating regulatory updates, complaint learnings,
+industry standard evolution, and brand strategy changes. Customer complaints
+regarding marketing are analyzed quarterly identifying patterns suggesting
+systematic misleading elements requiring campaign modification or withdrawal.
+Mystery shopping assesses whether branch staff explanations align with marketing
+promises testing consistency between advertising and actual service delivery.
+Staff training on marketing ethics, claim substantiation, disclosure
+requirements, and handling customer queries about promotions ensures
+organizational alignment with policy. The Bank participates in advertising self-
+regulatory bodies contributing to industry standards development and subjecting
+its marketing to independent ethical review. Marketing campaign post-mortems
+evaluate not just commercial success but also ethical performance, customer
+feedback, and regulatory interactions informing future campaign development.
+Category 18: Customer Education and Awareness Policies
+18.1 Financial Literacy and Customer Education Policy
+1. Purpose
+This policy establishes Amanah Bank's commitment to customer financial literacy
+enhancing understanding of banking products, financial planning, digital safety,
+and rights and responsibilities. It recognizes that educated customers make
+better financial decisions benefiting themselves and creating sustainable
+banking relationships. The policy aims to position the Bank as a trusted
+financial education resource beyond its commercial role.
+2. Scope
+This policy applies to all financial education initiatives including branch
+workshops, digital content, school programs, community outreach, financial
+counseling, product tutorials, and awareness campaigns conducted by Amanah Bank.
+It covers topics including banking basics, budgeting, savings, credit
+management, investment understanding, fraud prevention, digital banking safety,
+and customer rights. The policy governs content development, delivery methods,
+target audience selection, and impact measurement. It applies to education
+provided directly by Bank staff, through partnerships with educational
+institutions, and via digital platforms reaching broad audiences.
+3. Definitions
+Financial Literacy: Knowledge and skills to make informed, effective decisions
+regarding financial resources and banking products. Customer Education:
+Structured learning initiatives helping customers understand banking operations,
+products, rights, and financial management. Financial Inclusion: Efforts
+ensuring all population segments including underserved communities access
+financial services and education. Digital Financial Literacy: Specific knowledge
+for safely and effectively using digital banking channels, apps, and online
+financial services. **Financial CounselRetrySMContinue3. Definitions (continued)
+Financial Counseling: Personalized guidance helping distressed customers manage
+debt, restructure obligations, or navigate financial difficulties. Awareness
+Campaign: Mass communication initiative educating customers about specific risks
+like fraud, rights like complaint mechanisms, or opportunities like new
+services.
+4. Policy Statement
+Amanah Bank commits to financial literacy as corporate social responsibility and
+business strategy recognizing educated customers benefit from better financial
+outcomes and sustainable banking relationships. Banking basics education covers
+account types, transaction methods, interest calculations, fee structures, and
+digital banking usage through branch workshops, video tutorials, and
+informational brochures helping customers navigate services confidently.
+Budgeting and savings guidance teaches income-expense management, emergency fund
+building, goal-based saving, and compound interest benefits encouraging
+financial discipline and long-term wealth building particularly for young
+customers and low-income segments. Credit management education explains loan
+products, interest calculations, credit scores, repayment discipline, and debt
+trap avoidance empowering borrowers to use credit responsibly without over-
+extension. Investment literacy initiatives demystify mutual funds, government
+securities, stock market basics, risk-return relationships, and diversification
+principles enabling informed investment decisions beyond traditional deposits.
+Fraud prevention awareness campaigns educate about phishing, vishing, card
+skimming, identity theft, and social engineering tactics providing practical
+protection tips and reporting mechanisms reducing customer victimization.
+Digital banking tutorials through in-app guides, video demonstrations, and
+hands-on branch sessions teach platform navigation, security practices, and
+troubleshooting building confidence in digital adoption especially among elderly
+and technology-hesitant customers. Rights and responsibilities education informs
+customers about grievance mechanisms, regulatory protections, Banking Mohtasib,
+product suitability rights, and their obligations regarding accurate information
+and timely payments creating informed, empowered consumers. School and college
+partnerships deliver financial literacy modules to students teaching early money
+management, banking relationships, career financial planning, and
+entrepreneurship basics building lifetime financial competency. Community
+outreach targets underserved areas, women's groups, small businesses, and rural
+populations addressing specific financial challenges, access barriers, and
+literacy gaps advancing financial inclusion goals. Financial counseling for
+distressed customers provides empathetic, constructive guidance on debt
+management, restructuring options, budgeting assistance, and sometimes referrals
+to social services going beyond commercial recovery to genuine customer welfare.
+Content quality ensures accuracy, simplicity, cultural sensitivity, and
+practical applicability with periodic expert review maintaining educational
+credibility and usefulness.
+5. Customer Responsibilities
+Customers should actively engage with available financial education resources
+including attending workshops, watching tutorials, reading materials, and asking
+questions to enhance their financial literacy. Learning must translate to
+practice; customers should apply budgeting principles, security practices, and
+informed decision-making taught through education programs in their actual
+financial management. Customers participating in workshops or counseling
+sessions should provide honest financial information enabling personalized,
+relevant guidance rather than generic advice with limited applicability.
+Feedback on education programs regarding content clarity, relevance, delivery
+effectiveness, and suggested topics helps the Bank improve educational offerings
+continually. Customers should share financial literacy knowledge with family
+members, particularly teaching children money management and protecting elderly
+relatives from financial fraud creating multiplier effects. Financial education
+provides knowledge tools but cannot guarantee financial success; customers
+remain responsible for their financial decisions, discipline, and outcomes
+regardless of education received. Customers should verify information from
+multiple sources for major financial decisions; while Bank education is
+valuable, consulting independent financial advisors for complex situations is
+prudent. Participation in education programs doesn't create obligations to
+purchase Bank products; customers should view education as separate from sales
+maintaining healthy skepticism in commercial contexts.
+6. Bank Responsibilities
+Amanah Bank shall develop comprehensive financial literacy curriculum covering
+essential topics with content refreshed annually incorporating new products,
+emerging risks, and regulatory changes. Educational content uses clear, simple
+language avoiding jargon, with multilingual options (Urdu, English, regional
+languages) ensuring accessibility across diverse populations. Delivery methods
+accommodate different learning preferences including in-person workshops for
+interactive learners, video content for visual learners, written guides for
+readers, and one-on-one counseling for personalized needs. Branch staff receive
+training as financial educators capable of explaining products clearly,
+answering questions patiently, and conducting basic financial literacy sessions
+as community ambassadors. The Bank collaborates with schools, colleges, NGOs,
+and community organizations reaching audiences beyond existing customers
+advancing financial literacy as public good not just customer service. Digital
+platforms including website, mobile app, YouTube channel, and social media
+distribute educational content broadly with search optimization and social
+sharing enabling viral reach. Impact measurement through pre-post surveys,
+knowledge tests, behavior change tracking, and long-term customer financial
+health indicators assesses education effectiveness informing program refinement.
+The Bank allocates dedicated budget to financial literacy separate from
+marketing budgets demonstrating genuine commitment beyond using education as
+product promotion vehicle. Financial counselors undergo specialized training in
+debt management, empathetic communication, and social service resources
+providing professional, compassionate support to distressed customers.
+Educational initiatives maintain neutrality providing balanced information about
+banking generally not just Amanah Bank specifically and covering competitor
+products where helpful for informed decisions. Annual financial literacy reports
+document program reach, impact, success stories, and plans demonstrating
+transparency and accountability in education commitments.
+7. Exceptions / Disclosures
+Financial education provides general guidance not personalized financial advice;
+customers with complex situations should consult certified financial planners or
+advisors for tailored recommendations. Education programs are complementary
+services not contractual obligations; program availability, frequency, or topics
+may change based on resources, demand, or strategic priorities. Financial
+literacy content is educational not predictive; economic conditions, market
+performance, or individual circumstances affect outcomes beyond what education
+can control. Bank staff conducting education are trained presenters not
+certified financial advisors; their role is explaining products and concepts not
+providing investment or legal advice. Educational materials may reference Amanah
+Bank products as examples; this isn't sales pressure but practical context
+requiring customer discernment separating education from promotion. Financial
+counseling explores options within Bank's products and policies; customers may
+need to consider alternatives including other banks, debt consolidation
+companies, or bankruptcy counsel for comprehensive solutions. Participation in
+education programs doesn't entitle customers to fee waivers, preferential rates,
+or service exceptions; commercial terms remain separate from educational
+benefits. Educational content reflects current knowledge and regulations;
+rapidly evolving areas like fintech, regulations, or tax laws may have
+information lags before educational materials update.
+8. Compliance and Review
+This policy aligns with State Bank of Pakistan financial inclusion goals,
+Consumer Protection Department literacy initiatives, and international
+principles of customer financial capability building. Educational content
+undergoes periodic expert review by financial planning professionals, consumer
+advocates, and regulatory specialists ensuring accuracy and appropriateness. The
+policy is reviewed annually incorporating educational impact data, customer
+feedback, regulatory priorities, and emerging financial literacy needs.
+Financial literacy program metrics including reach, participation, knowledge
+improvement, and behavior change are reported quarterly to senior management and
+Board committees. Customer satisfaction surveys assess perceived value, content
+quality, delivery effectiveness, and topics of interest informing program
+development and resource allocation. Staff training on financial education
+delivery, adult learning principles, and community engagement ensures quality,
+consistency, and professionalism in education initiatives. The Bank benchmarks
+its financial literacy efforts against peer institutions and international best
+practices aspiring to leadership in banking sector education initiatives.
+Partnerships with educational institutions, consumer organizations, and
+government financial inclusion programs are pursued amplifying impact through
+collaboration and resource sharing.
+Category 19: Financial Inclusion and Accessibility Policies
+19.1 Financial Inclusion and Underserved Segment Banking Policy
+1. Purpose
+This policy establishes Amanah Bank's commitment to financial inclusion ensuring
+banking services reach underserved populations including low-income individuals,
+rural communities, women, youth, and persons with disabilities. It recognizes
+that universal financial access is both social responsibility and business
+opportunity. The policy balances commercial sustainability with inclusive
+banking ensuring profitability doesn't exclude deserving segments.
+2. Scope
+This policy applies to products, services, and delivery channels specifically
+designed or adapted for financial inclusion including basic banking accounts,
+microfinance, agent banking, mobile banking, simplified KYC, and targeted credit
+programs. It covers rural branch expansion, women-focused initiatives, youth
+banking, accessibility features, and pricing concessions for inclusion segments.
+The policy governs product design, eligibility criteria, documentation
+requirements, and performance measurement. It applies across all geographies
+with emphasis on underserved areas lacking banking penetration.
+3. Definitions
+Financial Inclusion: Ensuring all individuals and businesses have access to
+useful, affordable financial products and services delivered responsibly and
+sustainably. Underserved Segment: Population groups with limited access to
+formal banking including rural residents, low-income individuals, women, youth,
+persons with disabilities, and informal sector workers. Basic Banking Account:
+No-frills account with minimal documentation, zero or low fees, and essential
+services enabling entry into formal banking. Agent Banking: Licensed third-party
+agents operating as Bank touchpoints in areas lacking branches extending reach
+cost-effectively. Microfinance: Small loans to low-income borrowers or micro-
+enterprises typically lacking collateral or formal credit history. Simplified
+KYC: Relaxed documentation requirements for low-risk, low-value accounts
+balancing inclusion with compliance. Financial Literacy: Critical companion to
+access ensuring customers understand and effectively use financial services.
+4. Policy Statement
+Amanah Bank embraces financial inclusion as strategic priority and social
+responsibility committing resources, innovation, and leadership to banking the
+unbanked and underbanked. Basic banking accounts with zero minimum balance, no
+monthly fees, free debit cards, and limited free transactions provide affordable
+entry points for low-income customers and first-time bankers previously excluded
+by minimum balance requirements. Rural branch expansion guided by strategic
+planning targets underserved districts ensuring physical banking presence in
+areas lacking financial infrastructure with appropriate staffing, security, and
+service levels. Agent banking through partnerships with retailers, post offices,
+and community enterprises extends banking touchpoints to remote villages and
+urban slums where traditional branches aren't viable economically. Mobile
+banking and USSD services enable basic transactions through simple phones
+without internet requirements recognizing smartphone penetration limitations in
+low-income and rural segments. Women-focused banking includes women-only
+branches or service windows in conservative communities, women entrepreneurs
+loan programs, and female relationship managers addressing cultural barriers to
+women's banking participation. Youth banking introduces school and college
+students to banking through simplified accounts, financial literacy programs,
+and youth-appropriate services building lifetime banking relationships from
+early age. Microfinance and small business loans with flexible collateral
+requirements, group lending models, and simplified applications provide credit
+access to informal sector workers and micro-entrepreneurs excluded from
+traditional lending. Persons with disabilities receive accessibility
+accommodations including wheelchair access, Braille materials, sign language
+interpretation, and home banking services ensuring equitable access. Simplified
+KYC procedures for accounts with low balances and transaction limits reduce
+documentation barriers for populations lacking conventional identity or address
+proofs within regulatory guidelines. Pricing concessions including fee waivers,
+lower interest rates, or preferential terms for inclusion segments balance
+social objectives with commercial sustainability through cross-subsidization
+from profitable segments. Financial literacy initiatives specifically target
+inclusion segments teaching basic banking, digital usage, fraud prevention, and
+financial management building capability alongside access. Impact measurement
+tracks inclusion metrics including accounts opened in rural areas, women account
+holders, low-balance accounts, microfinance disbursed, and agent banking
+transactions demonstrating commitment and accountability.
+5. Customer Responsibilities
+Inclusion segment customers must provide accurate available documentation for
+account opening cooperating with bank's efforts to balance inclusion with
+regulatory compliance. Low-balance accounts, while fee-free, require customers
+to maintain account activity and use services appropriately avoiding dormancy or
+misuse that creates operational costs without benefits. Financial literacy
+resources provided by the Bank should be utilized by inclusion customers
+building capability to manage accounts, avoid fraud, and use services
+effectively maximizing inclusion benefits. Women customers in conservative
+settings should communicate cultural considerations enabling the Bank to provide
+appropriate accommodations like female staff or private service areas. Youth
+account holders and students should use accounts for intended purposes avoiding
+misuse for adult transactions or exploiting simplified requirements.
+Microfinance borrowers must honor repayment commitments even without traditional
+collateral as group lending and character-based lending rely on trust and
+community accountability. Agent banking customers should verify agent
+authorization through displayed certificates and report any suspicious agent
+behavior protecting service integrity. Inclusion benefits including fee waivers
+or preferential rates are designed for eligible segments; customers should not
+exploit inclusion products if they don't genuinely belong to target segments.
+Customers should graduate to regular banking products when their financial
+status improves ensuring inclusion products serve those truly needing them
+rather than becoming permanently concessional alternatives.
+6. Bank Responsibilities
+Amanah Bank shall allocate capital, human resources, and management attention to
+inclusion initiatives ensuring they receive adequate support not just token
+efforts or box-checking exercises. Product design for inclusion balances
+simplicity, affordability, and functionality avoiding over-simplification that
+restricts utility or patronizes users while ensuring accessibility for target
+segments. Staff in rural branches, agent banking operations, and inclusion-
+focused roles receive specialized training on serving diverse customers,
+cultural sensitivity, and patient service for first-time bankers. The Bank
+invests in appropriate technology enabling cost-effective service delivery
+through mobile platforms, agent networks, and biometric authentication reducing
+per-transaction costs making small accounts viable. Risk management adapts to
+inclusion contexts using alternative credit assessment methods like psychometric
+testing, social guarantees, or transaction behavior analysis where traditional
+credit scores are absent. The Bank collaborates with government programs, NGOs,
+self-help groups, and community organizations leveraging existing trust networks
+and social infrastructure accelerating inclusion. Performance incentives for
+branches and staff include inclusion metrics alongside profitability ensuring
+field teams are motivated to pursue inclusion goals not just chase high-value
+customers. Monitoring systems track inclusion account usage, dormancy, fraud
+patterns, and customer satisfaction enabling early intervention when issues
+arise and continuous improvement in service delivery. The Bank publicly reports
+inclusion progress through annual disclosures, regulatory submissions, and
+sustainability reports demonstrating transparency and accountability in social
+commitments. The Bank advocates for supportive policies including simplified
+regulations, financial infrastructure investments, and digital literacy programs
+contributing to national financial inclusion ecosystem beyond its institutional
+efforts.
+7. Exceptions / Disclosures
+Financial inclusion prioritizes access but cannot guarantee credit approval;
+loan decisions remain risk-based with many inclusion customers facing rejections
+due to legitimate creditworthiness concerns. Fee waivers and concessions for
+inclusion accounts apply to target segments; the Bank reserves rights to verify
+eligibility and withdraw concessions if accounts are misused or customers are
+ineligible. Rural branch presence depends on security assessments, viable
+population density, and operational feasibility; the Bank strives for broad
+coverage but cannot serve every remote village with physical branches. Agent
+banking depends on agent performance, security, and regulatory compliance;
+poorly performing or non-compliant agents may be terminated affecting local
+service availability temporarily until replacement. Simplified KYC applies
+within regulatory limits typically accounts below specified thresholds; higher-
+value relationships require standard KYC regardless of customer segment.
+Inclusion products may have feature limitations like transaction caps,
+restricted payment types, or limited channel access balancing affordability with
+risk management. Technology-based inclusion services require customer access to
+mobile phones and basic digital literacy; the Bank provides training but cannot
+overcome complete technology absence in some populations. Cross-subsidization
+supporting inclusion pricing depends on profitable segment performance; severe
+financial stress could necessitate inclusion program modifications ensuring
+institutional sustainability.
+8. Compliance and Review
+This policy aligns with State Bank of Pakistan financial inclusion strategy,
+national financial inclusion framework, priority sector lending targets, and
+international inclusive finance principles. Inclusion program performance
+undergoes quarterly reviews assessing reach, usage, viability, and social impact
+with regular reporting to Board committees and regulatory authorities. The
+policy is reviewed annually incorporating regulatory changes, technology
+evolution, competitive practices, and learnings from inclusion initiatives.
+Inclusion metrics including accounts opened, loan disbursements, rural
+penetration, women participation, and agent network size are tracked monthly
+driving accountability. Customer satisfaction surveys specifically target
+inclusion customers assessing service quality, discrimination perception,
+accessibility adequacy, and unmet needs informing improvements. Staff training
+on inclusion banking, cultural sensitivity, rural operations, and serving
+diverse populations is mandatory annually reinforcing organizational inclusion
+commitment. The Bank participates in financial inclusion forums, industry
+collaborations, and policy dialogues contributing expertise and learning from
+broader inclusion ecosystem. Impact assessments using third-party evaluators
+periodically measure social outcomes including poverty reduction, women
+empowerment, and financial resilience attributable to Bank's inclusion efforts
+demonstrating genuine impact beyond access statistics.
+Category 20: Insurance and Investment Service Policies
+20.1 Bancassurance and Insurance Distribution Policy
+1. Purpose
+This policy establishes guidelines for distributing insurance products through
+Amanah Bank's branch network as corporate agent ensuring suitable product
+recommendations, transparent pricing, and compliant distribution practices. It
+protects customer interests in insurance purchases while enabling the Bank to
+diversify revenue through insurance commissions. The policy balances commercial
+incentives with suitability obligations recognizing insurance is protection not
+purely investment.
+2. Scope
+This policy applies to all insurance product distribution activities including
+life insurance, health insurance, general insurance, credit life insurance, and
+investment-linked insurance offered through Amanah Bank branches and digital
+channels. It covers product selection, advisor training, needs assessment,
+disclosure requirements, claim support, and commission structures. The policy
+governs relationships with insurance partners, product governance, compliance
+monitoring, and customer complaint handling. It applies to all staff involved in
+insurance distribution whether full-time insurance specialists or branch staff
+with cross-selling responsibilities.
+3. Definitions
+Bancassurance: Distribution of insurance products through bank branches
+leveraging customer relationships and distribution networks. Corporate Agent:
+Bank acting as licensed agent for insurance companies distributing their
+products to customers. Insurance Advisor: Bank staff certified and licensed to
+sell insurance products after completing regulatory training and examinations.
+Needs Assessment: Process of understanding customer's protection needs, risk
+profile, and financial capacity before insurance recommendation. Credit Life
+Insurance: Insurance covering loan repayment upon borrower's death or disability
+protecting families and Bank. Investment-Linked Insurance: Insurance policies
+combining protection with investment components where returns vary with
+underlying fund performance. Policy Illustration: Document showing premium,
+benefits, maturity values, and assumptions helping customers understand
+insurance products. Surrender Value: Amount payable if insurance policy is
+terminated before maturity typically less than premiums paid especially in early
+years.
+4. Policy Statement
+Amanah Bank distributes insurance products as corporate agent partnering with
+reputable insurance companies after due diligence on their financial strength,
+product quality, and claim settlement reputation ensuring customer interests.
+Only insurance advisors holding valid regulatory licenses and certifications
+sell insurance products; untrained staff provide basic information directing
+customers to licensed advisors for actual sales. Comprehensive needs assessment
+precedes insurance recommendations exploring customer's existing coverage,
+dependents, liabilities, financial goals, and risk tolerance ensuring products
+address genuine protection needs. Product disclosure includes policy
+illustrations showing realistic return scenarios, fee structures, premium
+allocation, surrender values, and exclusions enabling informed purchase
+decisions beyond marketing highlights. Insurance is presented as protection tool
+not guaranteed investment; return projections for investment-linked products
+show multiple scenarios including poor market performance managing expectations
+honestly. Credit life insurance for loan customers is optional despite strong
+recommendations; customers can decline understanding they and families bear full
+loan obligation upon death or disability. Commission structures are disclosed to
+customers transparently explaining that Bank earns compensation from insurance
+companies enabling customers to assess potential conflict of interest in
+recommendations. High surrender charges in early policy years are prominently
+disclosed warning customers against premature termination and ensuring
+commitment matches product features like long-term protection. Post-sale service
+includes claim assistance, policy servicing, premium reminders, and periodic
+reviews ensuring customers receive ongoing support beyond initial sale. The Bank
+advocates for customers with insurance companies during claim disputes
+leveraging relationship strength ensuring fair treatment though ultimate claim
+decisions rest with insurers. Customer complaints regarding insurance sales
+receive priority investigation with remediation including policy cancellation,
+premium refund, or compensation where mis-selling is established.
+5. Customer Responsibilities
+Customers must provide accurate health information, financial details, and
+personal circumstances during needs assessment and insurance applications
+enabling appropriate recommendations and preventing claim rejections. Insurance
+purchase decisions should be based on genuine protection needs not purely
+investment returns recognizing insurance's primary purpose is risk mitigation
+not wealth creation. Policy documents including terms, conditions, exclusions,
+and benefits should be read carefully before purchase; customers should seek
+clarifications on unclear aspects rather than signing without understanding.
+Customers should maintain premium payments regularly avoiding policy lapse which
+eliminates protection and results in surrender value losses substantially below
+premiums paid. Insurance needs should be reviewed periodically as life
+circumstances change informing decisions about policy continuations, increases,
+or termination when protection is no longer needed. Customers should compare
+insurance options across multiple providers not just Bank-offered products
+ensuring comprehensive market assessment before purchase. Claim procedures
+including documentation requirements, timelines, and exclusions should be
+understood upfront enabling smooth claims when needed rather than disputes after
+incidents. Customers should resist pressure tactics for insurance purchases
+taking time to evaluate suitability, consulting family or independent advisors,
+and exercising cooling-off rights if hasty decisions prove unsuitable.
+6. Bank Responsibilities
+Amanah Bank shall partner only with insurance companies meeting minimum criteria
+including financial stability ratings, claim settlement ratios, customer service
+quality, and regulatory compliance records. Insurance advisor training includes
+product knowledge, needs assessment techniques, disclosure obligations, ethical
+selling, and regulatory requirements with annual recertification ensuring
+competency. Needs assessment documentation captures customer situation, stated
+needs, recommended products, and rationale creating audit trail for suitability
+reviews and complaint investigations. Product comparison tools enable advisors
+to present multiple suitable options with transparent comparison of features,
+costs, benefits, and terms empowering customer choice. The Bank maintains
+insurance product portfolio balance across protection-oriented and investment-
+linked products avoiding overemphasis on high-commission investment products at
+expense of pure protection. Sales monitoring includes transaction reviews,
+customer callbacks, and pattern analysis detecting potential mis-selling
+requiring intervention before harm to many customers. Claim support services
+assist customers in claim filing, documentation, follow-up with insurance
+companies, and escalation for delayed or disputed claims demonstrating
+commitment beyond sales. Commission structures balance advisor incentives across
+product types preventing distortion toward products benefiting advisors rather
+than customers. The Bank conducts periodic insurance customer satisfaction
+surveys assessing sales experience quality, product suitability, post-sale
+service, and claim experiences informing improvement. Complaints regarding
+insurance mis-selling trigger investigations within 5 business days with
+remediation including policy cancellation, full premium refund, and advisor
+consequences where mis-selling is confirmed.
+7. Exceptions / Disclosures
+Bank earns commissions from insurance sales creating potential conflicts of
+interest between customer interests and Bank revenue managed through suitability
+obligations and supervision. Insurance products have cooling-off periods
+typically 15-30 days allowing cancellation; exercising this right results in
+premium refund minus proportionate risk charges incurred. Policy illustrations
+show projected returns based on assumptions about market performance and
+persistence; actual returns may differ substantially particularly for
+investment-linked products. Surrender values especially in early policy years
+are significantly below premiums paid due to allocation charges, mortality
+costs, and acquisition expenses making premature termination expensive.
+Insurance claim approval ultimately rests with insurance companies not the Bank;
+while the Bank assists and advocates, it cannot guarantee claim acceptance or
+amounts. Medical underwriting for health and life insurance may result in
+exclusions, premium loadings, or application rejections based on health status
+discovered during assessment. Group insurance schemes for account holders or
+borrowers may have master policy terms differing from individual policies
+requiring careful review of actual coverage and benefits. Insurance products
+distributed by the Bank are insurance company products not Bank products; credit
+risk, performance risk, and obligation fulfillment are insurance company
+responsibilities with Bank acting as facilitator.
+8. Compliance and Review
+This policy complies with Insurance Ordinance provisions on corporate agents,
+Securities and Exchange Commission regulations on bancassurance, and State Bank
+guidelines on insurance product distribution. Insurance distribution activities
+undergo quarterly compliance audits verifying advisor licensing, needs
+assessment documentation, disclosure adequacy, and suitability compliance. The
+policy is reviewed annually incorporating regulatory changes, insurance partner
+performance, customer complaints analysis, and best practices in insurance
+distribution. Insurance sales metrics are tracked alongside quality indicators
+including policy persistency, claim ratios, customer complaints, and mis-selling
+incidents preventing purely volume-driven evaluation. Customer complaints
+regarding insurance sales are segregated and analyzed identifying products,
+advisors, or practices requiring attention through training, supervision, or
+product discontinuation. Staff compensation for insurance sales is reviewed
+annually ensuring balance between productivity incentives and customer
+protection obligations without excessive sales pressure creation. The Bank
+maintains insurance partner performance dashboards tracking claim settlement
+ratios, turnaround times, customer complaints, and service quality informing
+partnership continuations or terminations. Mystery shopping periodically tests
+insurance sales practices assessing needs assessment quality, disclosure
+adequacy, and absence of pressure tactics with findings driving training and
+supervision improvements.
+20.2 Investment Product Distribution and Wealth Management Policy
+1. Purpose
+This policy establishes guidelines for distributing investment products
+including mutual funds, Pakistan Investment Bonds, Treasury Bills, and offering
+wealth management advice ensuring suitability, risk disclosure, and compliant
+advisory practices. It protects customers from unsuitable investments while
+enabling the Bank to offer comprehensive financial solutions. The policy
+balances revenue opportunities from investment distribution with fiduciary
+responsibilities toward customers.
+2. Scope
+This policy applies to investment product distribution and wealth management
+services including mutual fund sales, government securities purchase
+facilitation, stock brokerage referrals, portfolio management services, and
+financial planning advisory offered by Amanah Bank. It covers customer risk
+profiling, product suitability assessment, disclosure requirements, conflict
+management, and performance monitoring. The policy governs relationship
+managers, investment advisors, and digital investment platforms. It applies
+across all customer segments with enhanced protocols for high-net-worth and
+institutional clients.
+3. Definitions
+Investment Product: Financial instrument offering returns with associated risks
+including mutual funds, bonds, equities, and structured products. Wealth
+Management: Comprehensive financial advisory service covering investment
+planning, tax planning, estate planning, and portfolio management for affluent
+customers. Risk Profile: Assessment of customer's risk tolerance, investment
+horizon, and financial capacity determining suitable investment types.
+Suitability Assessment: Evaluation whether specific investment products match
+customer's risk profile, goals, and financial situation. Mutual Fund: Pooled
+investment vehicle managed by professionals investing in diversified securities.
+Portfolio Management Service (PMS): Discretionary or non-discretionary
+management of customer investment portfolio by professional managers. Total
+Expense Ratio (TER): Annual fund operating expenses including management fees
+and other costs impacting investor returns. Capital Protection: Investment
+feature ensuring principal amount is returned regardless of market performance,
+typically at maturity.
+4. Policy Statement
+Amanah Bank distributes investment products and provides wealth management
+services prioritizing customer suitability and risk-appropriate recommendations
+over transaction volumes or fee generation. Comprehensive risk profiling
+precedes investment recommendations assessing customer's investment knowledge,
+risk tolerance, investment horizon, financial goals, and liquidity needs
+determining appropriate risk-return profiles. Investment product recommendations
+provide portfolio allocation across asset classes like debt, equity, and money
+market instruments achieving diversification matching customer risk appetite
+rather than concentrating in single products. Clear risk disclosure accompanies
+investment recommendations explaining market risk, credit risk, liquidity risk,
+and specific product risks ensuring customers understand potential losses
+alongside return expectations. Performance projections for investment products
+show multiple scenarios including adverse market conditions avoiding only
+optimistic scenarios that create unrealistic expectations and future
+disappointments. Fees and charges including management fees, entry loads, exit
+loads, performance fees, and total expense ratios are disclosed transparently
+enabling customers to assess cost impact on net returns. Conflict of interest
+management ensures recommendations prioritize customer suitability over product
+distribution commissions or proprietary product promotion with disclosure of
+commission structures. Ongoing portfolio reviews for wealth management clients
+include periodic performance reporting, rebalancing recommendations, and
+adjustments for changed circumstances or goals maintaining long-term
+appropriateness. The Bank facilitates investment transactions but investment
+decisions remain customer responsibility; advisory relationships are non-
+discretionary unless explicit portfolio management mandates are granted.
+Investment product suitability is dynamic requiring periodic reassessment;
+customers receive annual reviews evaluating whether existing investments
+continue matching profiles and recommending adjustments. Vulnerable customers
+including elderly persons, retirees, or financially unsophisticated investors
+receive enhanced protection through conservative recommendations, detailed
+explanations, and cooling-off periods for significant investments.
+5. Customer Responsibilities
+Customers must provide accurate, complete information about financial situation,
+investment experience, risk tolerance, and goals enabling appropriate risk
+profiling and product recommendations. Investment decisions should be based on
+own assessment and understanding not blind reliance on advisor recommendations;
+customers retain ultimate responsibility for investment outcomes. Product
+literature, fund fact sheets, offering documents, and risk disclosures should be
+read carefully before investments understanding what is being purchased beyond
+sales presentations. Customers should diversify investments across products,
+asset classes, and institutions avoiding concentration that magnifies risk
+despite potential short-term underperformance of diversified portfolios.
+Investment performance should be evaluated over appropriate horizons matching
+product characteristics; short-term volatility is inherent in equity investments
+requiring patient long-term perspective. Changed financial circumstances
+including income loss, major expenses, or shortened horizons should be
+communicated enabling portfolio adjustments before forced liquidations at
+unfavorable times. Tax implications of investment returns including capital
+gains, dividend taxation, and wealth reporting are customer responsibility
+requiring tax advisory consultation for comprehensive planning. Unrealistic
+return expectations should be tempered through self-education; consistently high
+returns without commensurate risk are rare with past performance not
+guaranteeing future results. Customers should report pressure tactics,
+unsuitable recommendations, or inadequate disclosure through complaint channels
+enabling investigation and protection of other customers from potential mis-
+selling.
+6. Bank Responsibilities
+Amanah Bank shall maintain competent investment advisory teams with professional
+certifications, continuous training, and expertise in financial markets,
+products, and advisory best practices. Risk profiling uses standardized
+questionnaires and tools ensuring consistent, objective assessment across
+advisors and customers with periodic recalibration validating profile accuracy.
+Investment product due diligence evaluates fund manager track records,
+investment strategies, risk management, fee structures, and regulatory
+compliance before distribution approval. Product shelf maintains diversified
+options across risk levels, asset classes, and investment horizons enabling
+suitable matches for different customer profiles rather than one-size-fits-all
+offerings. Conflict management includes disclosure of distribution commissions,
+separation of advisory and sales roles where feasible, and supervisory oversight
+ensuring recommendations withstand suitability scrutiny. Portfolio performance
+reporting provides transparent updates on investment values, returns, asset
+allocation, and benchmark comparison enabling customers to monitor progress
+toward goals. The Bank maintains investment markets expertise analyzing economic
+trends, market developments, and outlook informing customer communications and
+advisory recommendations. Customer education through seminars, webinars, market
+commentaries, and educational content builds investment literacy enabling
+informed participation in investment decisions. Complaint handling for
+investment disputes includes investigation of suitability, disclosure adequacy,
+and advisor conduct with remediation including investment reversal, fee refunds,
+or compensation where mis-selling occurred. The Bank maintains professional
+liability insurance covering investment advisory activities protecting customers
+in cases where Bank errors cause investment losses beyond normal market risk.
+7. Exceptions / Disclosures
+Investment returns are market-dependent; the Bank cannot guarantee investment
+performance with potential losses including principal loss especially in equity
+and market-linked products. Past performance of investment products is not
+indicative of future results; historical returns in marketing materials
+represent specific periods which may not repeat. Investment advisory is provided
+by Bank staff who may not hold independent financial advisor certifications;
+customers seeking comprehensive financial planning may need specialized external
+advisors. Distribution commissions from fund houses or product providers create
+potential conflicts managed through disclosure and suitability processes but not
+fully eliminated. Investment products distributed are third-party products not
+Bank deposits; credit risk and performance risk are borne by product providers
+not guaranteed by the Bank. Market volatility causes investment value
+fluctuations sometimes significantly; customers should be prepared for temporary
+losses without panic selling in bear markets. Liquidity constraints in some
+investments including closed-end funds or real estate products mean selling
+before maturity may be difficult or involve substantial discounts to fair value.
+Tax laws change affecting investment taxation; customers should monitor tax
+developments and seek updated tax planning advice annually. Wealth management
+services serve affluent customers with minimum relationship values; mass-market
+customers receive product sales support rather than comprehensive wealth
+advisory.
+8. Compliance and Review
+This policy complies with Securities and Exchange Commission regulations on
+investment advisors, mutual fund distribution rules, and State Bank guidelines
+on bank-sponsored investment services. Investment advisory activities undergo
+quarterly compliance reviews verifying risk profiling documentation, product
+suitability, disclosure adequacy, and conflict management. The policy is
+reviewed annually incorporating regulatory changes, investment product
+evolution, market developments, and advisory best practices. Investment advisory
+quality is assessed through customer satisfaction surveys, portfolio performance
+analysis, complaint rates, and regulatory feedback informing training and
+process improvements. Advisor performance evaluation balances assets under
+management growth with quality metrics including suitability compliance,
+customer retention, and satisfaction preventing purely sales-driven behavior.
+Staff compensation for investment distribution is structured balancing revenue
+with risk-adjusted metrics and customer outcomes avoiding short-term transaction
+focus at expense of long-term customer welfare. The Bank benchmarks advisory
+practices against wealth management industry standards adopting best practices
+in client service, portfolio construction, and advisory processes. Investment
+product provider relationships are reviewed annually assessing product
+performance, service quality, commission competitiveness, and strategic fit
+informing product shelf optimization.
+APPENDIX: Acronyms and Abbreviations
+AML: Anti-Money Laundering
+API: Application Programming Interface
+APR: Annual Percentage Rate
+APY: Annual Percentage Yield
+ATM: Automated Teller Machine
+CDD: Customer Due Diligence
+CERT: Computer Emergency Response Team
+CES: Customer Effort Score
+CFT: Counter-Terrorist Financing
+CNIC: Computerized National Identity Card
+CTR: Currency Transaction Report
+CVV: Card Verification Value
+DDoS: Distributed Denial of Service
+DMS: Document Management System
+DTI: Debt-to-Income Ratio
+EDD: Enhanced Due Diligence
+EMI: Equated Monthly Installment
+FATF: Financial Action Task Force
+FCA: Foreign Currency Account
+FCR: First Call Resolution
+FD: Fixed Deposit
+Forex: Foreign Exchange
+GDPR: General Data Protection Regulation
+IBFT: Inter-Bank Fund Transfer
+IP: Internet Protocol
+ISO: International Organization for Standardization
+KYC: Know Your Customer
+MFA: Multi-Factor Authentication
+MVP: Minimum Viable Product
+NICOP: National Identity Card for Overseas Pakistanis
+NPA: Non-Performing Asset
+NPL: Non-Performing Loan
+NRA: Non-Resident Rupee Account
+NRI: Non-Resident Indian
+NRP: Non-Resident Pakistani
+NTN: National Tax Number
+OWASP: Open Web Application Security Project
+OTP: One-Time Password
+OVD: Officially Valid Document
+PCI-DSS: Payment Card Industry Data Security Standard
+PEP: Politically Exposed Person
+PIN: Personal Identification Number
+PKR: Pakistani Rupee
+PMS: Portfolio Management Service
+POS: Point of Sale
+RTGS: Real-Time Gross Settlement
+SDD: Simplified Due Diligence
+SLA: Service Level Agreement
+SMS: Short Message Service
+SOC: Security Operations Center
+STR: Suspicious Transaction Report
+SWIFT: Society for Worldwide Interbank Financial Telecommunication
+TAT: Turnaround Time
+TER: Total Expense Ratio
+TLS: Transport Layer Security
+UX: User Experience
+VPN: Virtual Private Network
+END OF DOCUMENT
+Document Status: Final
+Total Pages: 150+
+Last Updated: 2025-10-22
+Next Review Date: 2026-10-22
+Document Owner: Policy & Compliance Department, Amanah Bank
+Approval Authority: Board of Directors, Amanah Bank
+Distribution: All Amanah Bank Branches, Departments, and Customer-Facing
+Channels
+Accessibility: Public Document Available on Website, Mobile App, and Branch
+Locations
+Customer Helpline: 021-111-AMANAH (021-111-262624)
+Email: [email protected]
+Website: www.amanahbank.com.pk
diff --git a/data/qa/qa.json b/data/qa/qa.json
index 8ce0bbf..43e52e0 100644
--- a/data/qa/qa.json
+++ b/data/qa/qa.json
@@ -1,142 +1,9 @@
 [
-    {
-        "question": "Can a customer get a refund if they cancel after 12 hours?",
-        "answer": "Yes — customers may cancel within 24 hours for a full refund.",
-        "supporting_passages": [
-            "Our cancellation policy: Customers may cancel within 24 hours for a full refund. After that, refund requests are handled on a case-by-case basis."
-        ]
-    },
-    {
-        "question": "How long do we retain logs?",
-        "answer": "We retain logs for 90 days and then anonymize them.",
-        "supporting_passages": [
-            "Data retention rules: We keep system logs for 90 days and anonymize them afterward to protect user privacy."
-        ]
-    },
-    {
-        "question": "Who can approve role changes for employees?",
-        "answer": "Only managers can approve employee role changes.",
-        "supporting_passages": [
-            "Access control: Only managers can approve employee role or permission changes."
-        ]
-    },
-    {
-        "question": "Do we require disk encryption on devices?",
-        "answer": "Yes, all devices must have disk encryption enabled.",
-        "supporting_passages": [
-            "Security policy: All devices must have full disk encryption enabled to safeguard sensitive company data."
-        ]
-    },
-    {
-        "question": "What tone should customer-facing replies use?",
-        "answer": "Use professional, concise, and empathetic language.",
-        "supporting_passages": [
-            "Tone guideline: Use professional, concise, and empathetic language when replying to customers."
-        ]
-    },
-    {
-        "question": "When are customer support hours?",
-        "answer": "Customer support is available 24/7 via chat and email.",
-        "supporting_passages": [
-            "Support availability: Customer support operates 24/7 through chat and email to ensure constant assistance."
-        ]
-    },
-    {
-        "question": "Are temporary employees allowed remote access?",
-        "answer": "Yes, but only through secure VPN with limited access rights.",
-        "supporting_passages": [
-            "Remote access policy: Temporary employees may access systems only via secure VPN connections with restricted rights."
-        ]
-    },
-    {
-        "question": "How should employees report suspicious emails?",
-        "answer": "Employees should report suspicious emails to the IT security team using the 'Report Phishing' button.",
-        "supporting_passages": [
-            "Phishing alert policy: Report suspicious emails using the 'Report Phishing' button to notify IT security immediately."
-        ]
-    },
-    {
-        "question": "What is the password policy for internal accounts?",
-        "answer": "Passwords must be at least 12 characters long and include uppercase, lowercase, numbers, and symbols.",
-        "supporting_passages": [
-            "Password standards: Internal passwords must be at least 12 characters long and include uppercase, lowercase, numbers, and special symbols."
-        ]
-    },
-    {
-        "question": "How often must employees complete compliance training?",
-        "answer": "Compliance training must be completed annually by all employees.",
-        "supporting_passages": [
-            "Training policy: All employees must complete compliance and cybersecurity training annually."
-        ]
-    },
-    {
-        "question": "Can employees use personal email for work-related communication?",
-        "answer": "No, all work-related communication must occur via the company email domain.",
-        "supporting_passages": [
-            "Email usage policy: Employees must use official company email accounts for all work-related communications."
-        ]
-    },
-    {
-        "question": "What is the retention period for customer data?",
-        "answer": "Customer data is retained for 5 years unless deletion is requested earlier.",
-        "supporting_passages": [
-            "Customer data retention: Personal data is stored securely for 5 years or until a deletion request is submitted."
-        ]
-    },
-    {
-        "question": "Are employees allowed to install unapproved software?",
-        "answer": "No, only software approved by the IT department may be installed on company devices.",
-        "supporting_passages": [
-            "Software installation rule: Only IT-approved applications may be installed on company-managed devices."
-        ]
-    },
-    {
-        "question": "How often are system backups performed?",
-        "answer": "Full system backups are performed daily and incremental backups every hour.",
-        "supporting_passages": [
-            "Backup process: Full backups occur daily, and incremental backups run hourly to ensure data recovery readiness."
-        ]
-    },
-    {
-        "question": "Can users reset their passwords without contacting support?",
-        "answer": "Yes, users can reset passwords using the self-service portal if multi-factor authentication is enabled.",
-        "supporting_passages": [
-            "Password reset policy: Users can reset passwords via the self-service portal if multi-factor authentication is enabled."
-        ]
-    },
-    {
-        "question": "How do we handle customer complaints?",
-        "answer": "All customer complaints are logged and reviewed within 48 hours by the quality assurance team.",
-        "supporting_passages": [
-            "Customer complaint handling: All complaints are logged, reviewed, and resolved within 48 hours by the QA team."
-        ]
-    },
-    {
-        "question": "What data protection laws does the company comply with?",
-        "answer": "We comply with GDPR, CCPA, and other relevant regional data protection laws.",
-        "supporting_passages": [
-            "Compliance framework: The company follows GDPR, CCPA, and other relevant data protection laws."
-        ]
-    },
-    {
-        "question": "Are personal mobile devices allowed for work?",
-        "answer": "Yes, under the BYOD policy with mobile device management (MDM) enabled.",
-        "supporting_passages": [
-            "BYOD policy: Employees may use personal devices for work if enrolled in Mobile Device Management (MDM)."
-        ]
-    },
-    {
-        "question": "Who can access financial transaction records?",
-        "answer": "Only authorized finance and audit personnel have access to transaction records.",
-        "supporting_passages": [
-            "Financial data policy: Only authorized finance and audit personnel have access to transaction records."
-        ]
-    },
-    {
-        "question": "How should internal documents be shared?",
-        "answer": "Internal documents must be shared only through secure, company-approved file-sharing systems.",
-        "supporting_passages": [
-            "Document sharing policy: Internal documents must be shared only through secure, company-approved systems such as SharePoint or encrypted email."
-        ]
-    }
-]
+  {
+    "question": "What is the purpose of Section 1.1 Account Opening and Maintenance Policy",
+    "answer": "The purpose of Section 1.1 Account Opening and Maintenance Policy is to establish comprehensive guidelines for opening, operating, and maintaining customer accounts at Amanah Bank, ensuring adherence to regulatory requirements while delivering seamless banking experiences and protecting customer interests while maintaining operational efficiency and compliance with applicable laws",
+    "supporting_passages": [
+      "Purpose This policy establishes comprehensive guidelines for opening, operating, and maintaining customer accounts at Amanah Bank.",
+      "Core Customer Operations Policies Category 1: Account Management Policies 1.1 Account Opening and Maintenance Policy 1."
+    ]
+  }]
diff --git a/data/raw/411811106-Branch-Operations-Manual-v2-0-December-2010.pdf b/data/raw/411811106-Branch-Operations-Manual-v2-0-December-2010.pdf
deleted file mode 100644
index 7ecc109..0000000
Binary files a/data/raw/411811106-Branch-Operations-Manual-v2-0-December-2010.pdf and /dev/null differ
diff --git a/data/raw/Elite_Dynamics_Partners_Policies.pdf b/data/raw/Elite_Dynamics_Partners_Policies.pdf
index 83e3576..69019d6 100644
Binary files a/data/raw/Elite_Dynamics_Partners_Policies.pdf and b/data/raw/Elite_Dynamics_Partners_Policies.pdf differ
diff --git a/data/raw/README.md b/data/raw/README.md
new file mode 100644
index 0000000..50ffc4d
--- /dev/null
+++ b/data/raw/README.md
@@ -0,0 +1,26 @@
+# Reflect Clone Desktop (Python + HTML/CSS)
+
+A minimal Reflect-style hero page with a looping background video, wrapped as a desktop app using **pywebview** (Python).
+
+## Run
+
+1. Install Python 3.10+.
+2. Open terminal in this folder and run:
+   ```bash
+   pip install -r requirements.txt
+   python main.py
+   ```
+
+> Note: Put your looping video as `assets/bg.mp4`. A placeholder path is already referenced in `index.html`.
+
+## Build EXE (Windows)
+
+```bash
+pip install pyinstaller
+pyinstaller -F --add-data "index.html;." --add-data "styles.css;." --add-data "script.js;." --add-data "assets;assets" main.py
+```
+The built exe will be in `dist/main.exe`.
+
+## Customize
+- Edit text, links, and buttons in `index.html`.
+- Tweak colors and glow in `styles.css`.
diff --git a/data/raw/amanah_bank_policy.pdf b/data/raw/amanah_bank_policy.pdf
new file mode 100644
index 0000000..e5c558d
Binary files /dev/null and b/data/raw/amanah_bank_policy.pdf differ
diff --git a/data/raw/conanfile.txt b/data/raw/conanfile.txt
new file mode 100644
index 0000000..86539ae
--- /dev/null
+++ b/data/raw/conanfile.txt
@@ -0,0 +1,29 @@
+[requires]
+onetbb/[>=2021.2.1]
+pugixml/[>=1.10]
+protobuf/3.21.12
+ittapi/[>=3.23.0]
+opencl-icd-loader/[>=2023.04.17]
+rapidjson/[>=1.1.0]
+xbyak/[>=6.62]
+snappy/[>=1.1.7]
+onnx/1.18.0
+pybind11/[>=3.0.1]
+flatbuffers/[>=22.9.24]
+
+[tool_requires]
+cmake/[>=3.20]
+pkgconf/1.9.5
+patchelf/[>=0.12]
+protobuf/3.21.12
+flatbuffers/[>=22.9.24]
+
+[options]
+protobuf/*:lite=True
+protobuf/*:with_zlib=False
+protobuf/*:shared=False
+flatbuffers/*:header_only=True
+
+[generators]
+CMakeDeps
+CMakeToolchain
diff --git a/data/raw/inference_log.txt b/data/raw/inference_log.txt
new file mode 100644
index 0000000..ea0540e
--- /dev/null
+++ b/data/raw/inference_log.txt
@@ -0,0 +1,273 @@
+=== RAG Inference Log ===
+
+🚀 Starting QA + Corpus generation...
+
+📘 Processing: Elite_Dynamics_Partners_Policies
+✏️ Added 4 chunks to corpus file.
+
Generating QAs for Elite_Dynamics_Partners_Policies:   0%|                                            | 0/4 [00:00<?, ?it/s]
Generating QAs for Elite_Dynamics_Partners_Policies: 100%|█████████████████████████████████| 4/4 [00:00<00:00, 99864.38it/s]
+⚠️ OPENAI_API_KEY not set. Skipping QA generation for this run.
+⚠️ OPENAI_API_KEY not set. Skipping QA generation for this run.
+⚠️ OPENAI_API_KEY not set. Skipping QA generation for this run.
+⚠️ OPENAI_API_KEY not set. Skipping QA generation for this run.
+✅ Saved 0 QAs for Elite_Dynamics_Partners_Policies
+
+🎯 Done! All QAs saved to:
+   → data/qa/qa.json
+   And corpus appended to:
+   → data/processed/corpus.txt
+The `load_in_4bit` and `load_in_8bit` arguments are deprecated and will be removed in the future versions. Please, pass a `BitsAndBytesConfig` object in `quantization_config` argument instead.
+Some weights of DistilBertForSequenceClassification were not initialized from the model checkpoint at distilbert-base-uncased and are newly initialized: ['classifier.bias', 'classifier.weight', 'pre_classifier.bias', 'pre_classifier.weight']
+You should probably TRAIN this model on a down-stream task to be able to use it for predictions and inference.
+Some weights of DistilBertForSequenceClassification were not initialized from the model checkpoint at distilbert-base-uncased and are newly initialized: ['classifier.bias', 'classifier.weight', 'pre_classifier.bias', 'pre_classifier.weight']
+You should probably TRAIN this model on a down-stream task to be able to use it for predictions and inference.
+Some weights of DistilBertForSequenceClassification were not initialized from the model checkpoint at distilbert-base-uncased and are newly initialized: ['classifier.bias', 'classifier.weight', 'pre_classifier.bias', 'pre_classifier.weight']
+You should probably TRAIN this model on a down-stream task to be able to use it for predictions and inference.
+Traceback (most recent call last):
+  File "<frozen runpy>", line 198, in _run_module_as_main
+  File "<frozen runpy>", line 88, in _run_code
+  File "/home/shehroz/Desktop/New Folder/ai4org/hallucination_reduction/main.py", line 210, in <module>
+    main()
+    ~~~~^^
+  File "/home/shehroz/Desktop/New Folder/ai4org/hallucination_reduction/main.py", line 126, in main
+    fact_disc = train_discriminator_minibatch(fact_disc, fact_tok, fact_texts, fact_labels,
+                                              device=DEVICE, epochs=DISC_EPOCHS, batch_size=DISC_BATCH, lr=DISC_LR)
+  File "/home/shehroz/Desktop/New Folder/ai4org/hallucination_reduction/discriminator_training_utils.py", line 27, in train_discriminator_minibatch
+    optimizer.step()
+    ~~~~~~~~~~~~~~^^
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/torch/optim/optimizer.py", line 516, in wrapper
+    out = func(*args, **kwargs)
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/torch/optim/optimizer.py", line 81, in _use_grad
+    ret = func(*args, **kwargs)
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/torch/optim/adam.py", line 237, in step
+    has_complex = self._init_group(
+        group,
+    ...<5 lines>...
+        state_steps,
+    )
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/torch/optim/adam.py", line 177, in _init_group
+    state["exp_avg"] = torch.zeros_like(
+                       ~~~~~~~~~~~~~~~~^
+        p, memory_format=torch.preserve_format
+        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+    )
+    ^
+torch.OutOfMemoryError: CUDA out of memory. Tried to allocate 20.00 MiB. GPU 0 has a total capacity of 5.79 GiB of which 21.88 MiB is free. Process 61757 has 2.47 GiB memory in use. Including non-PyTorch memory, this process has 3.28 GiB memory in use. Of the allocated memory 3.06 GiB is allocated by PyTorch, and 118.23 MiB is reserved by PyTorch but unallocated. If reserved but unallocated memory is large try setting PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True to avoid fragmentation.  See documentation for Memory Management  (https://pytorch.org/docs/stable/notes/cuda.html#environment-variables)
+ Single GPU detected. Using cuda:0
+ Using device: cuda
+Loading generator and discriminators...
+Enabled gradient checkpointing on generator.
+Using single GPU or CPU.
+Training fact discriminator...
+🚀 Starting QA + Corpus generation...
+
+📘 Processing: Elite_Dynamics_Partners_Policies
+✏️ Added 4 chunks to corpus file.
+
Generating QAs for Elite_Dynamics_Partners_Policies:   0%|                                            | 0/4 [00:00<?, ?it/s]
Generating QAs for Elite_Dynamics_Partners_Policies: 100%|█████████████████████████████████| 4/4 [00:00<00:00, 93727.46it/s]
+⚠️ OPENAI_API_KEY not set. Skipping QA generation for this run.
+⚠️ OPENAI_API_KEY not set. Skipping QA generation for this run.
+⚠️ OPENAI_API_KEY not set. Skipping QA generation for this run.
+⚠️ OPENAI_API_KEY not set. Skipping QA generation for this run.
+✅ Saved 0 QAs for Elite_Dynamics_Partners_Policies
+
+🎯 Done! All QAs saved to:
+   → data/qa/qa.json
+   And corpus appended to:
+   → data/processed/corpus.txt
+The `load_in_4bit` and `load_in_8bit` arguments are deprecated and will be removed in the future versions. Please, pass a `BitsAndBytesConfig` object in `quantization_config` argument instead.
+Some weights of DistilBertForSequenceClassification were not initialized from the model checkpoint at distilbert-base-uncased and are newly initialized: ['classifier.bias', 'classifier.weight', 'pre_classifier.bias', 'pre_classifier.weight']
+You should probably TRAIN this model on a down-stream task to be able to use it for predictions and inference.
+Some weights of DistilBertForSequenceClassification were not initialized from the model checkpoint at distilbert-base-uncased and are newly initialized: ['classifier.bias', 'classifier.weight', 'pre_classifier.bias', 'pre_classifier.weight']
+You should probably TRAIN this model on a down-stream task to be able to use it for predictions and inference.
+Some weights of DistilBertForSequenceClassification were not initialized from the model checkpoint at distilbert-base-uncased and are newly initialized: ['classifier.bias', 'classifier.weight', 'pre_classifier.bias', 'pre_classifier.weight']
+You should probably TRAIN this model on a down-stream task to be able to use it for predictions and inference.
+Traceback (most recent call last):
+  File "<frozen runpy>", line 198, in _run_module_as_main
+  File "<frozen runpy>", line 88, in _run_code
+  File "/home/shehroz/Desktop/New Folder/ai4org/hallucination_reduction/main.py", line 210, in <module>
+    main()
+    ~~~~^^
+  File "/home/shehroz/Desktop/New Folder/ai4org/hallucination_reduction/main.py", line 145, in main
+    _, old_before, _ = evaluate_old_vs_new_generator(baseline_generator, generator,
+                       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+                                                     gen_tok, retriever, qa_pairs,
+                                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+                                                     fact_disc, fact_tok, device=DEVICE)
+                                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+  File "/home/shehroz/Desktop/New Folder/ai4org/hallucination_reduction/evaluation.py", line 46, in evaluate_old_vs_new_generator
+    old_out = generate_answer(old_gen, tokenizer, prompt, max_new_tokens=MAX_GEN_TOKENS, min_new_tokens=MIN_GEN_TOKENS, device=device, num_return_sequences=1)[0]
+              ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+  File "/home/shehroz/Desktop/New Folder/ai4org/hallucination_reduction/generator.py", line 30, in generate_answer
+    out = generator.generate(
+        **inputs,
+    ...<6 lines>...
+        pad_token_id=tokenizer.eos_token_id
+    )
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/torch/utils/_contextlib.py", line 120, in decorate_context
+    return func(*args, **kwargs)
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/transformers/generation/utils.py", line 2539, in generate
+    result = self._sample(
+        input_ids,
+    ...<5 lines>...
+        **model_kwargs,
+    )
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/transformers/generation/utils.py", line 2867, in _sample
+    outputs = self(**model_inputs, return_dict=True)
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/torch/nn/modules/module.py", line 1773, in _wrapped_call_impl
+    return self._call_impl(*args, **kwargs)
+           ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/torch/nn/modules/module.py", line 1784, in _call_impl
+    return forward_call(*args, **kwargs)
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/transformers/utils/generic.py", line 940, in wrapper
+    output = func(self, *args, **kwargs)
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/transformers/models/llama/modeling_llama.py", line 459, in forward
+    outputs: BaseModelOutputWithPast = self.model(
+                                       ~~~~~~~~~~^
+        input_ids=input_ids,
+        ^^^^^^^^^^^^^^^^^^^^
+    ...<6 lines>...
+        **kwargs,
+        ^^^^^^^^^
+    )
+    ^
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/torch/nn/modules/module.py", line 1773, in _wrapped_call_impl
+    return self._call_impl(*args, **kwargs)
+           ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/torch/nn/modules/module.py", line 1784, in _call_impl
+    return forward_call(*args, **kwargs)
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/transformers/utils/generic.py", line 1064, in wrapper
+    outputs = func(self, *args, **kwargs)
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/transformers/models/llama/modeling_llama.py", line 395, in forward
+    hidden_states = decoder_layer(
+        hidden_states,
+    ...<5 lines>...
+        **kwargs,
+    )
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/transformers/modeling_layers.py", line 94, in __call__
+    return super().__call__(*args, **kwargs)
+           ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/torch/nn/modules/module.py", line 1773, in _wrapped_call_impl
+    return self._call_impl(*args, **kwargs)
+           ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/torch/nn/modules/module.py", line 1784, in _call_impl
+    return forward_call(*args, **kwargs)
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/transformers/utils/deprecation.py", line 172, in wrapped_func
+    return func(*args, **kwargs)
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/transformers/models/llama/modeling_llama.py", line 294, in forward
+    hidden_states, _ = self.self_attn(
+                       ~~~~~~~~~~~~~~^
+        hidden_states=hidden_states,
+        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+    ...<6 lines>...
+        **kwargs,
+        ^^^^^^^^^
+    )
+    ^
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/torch/nn/modules/module.py", line 1773, in _wrapped_call_impl
+    return self._call_impl(*args, **kwargs)
+           ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/torch/nn/modules/module.py", line 1784, in _call_impl
+    return forward_call(*args, **kwargs)
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/transformers/utils/deprecation.py", line 172, in wrapped_func
+    return func(*args, **kwargs)
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/transformers/models/llama/modeling_llama.py", line 252, in forward
+    attn_output, attn_weights = attention_interface(
+                                ~~~~~~~~~~~~~~~~~~~^
+        self,
+        ^^^^^
+    ...<6 lines>...
+        **kwargs,
+        ^^^^^^^^^
+    )
+    ^
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/transformers/integrations/sdpa_attention.py", line 83, in sdpa_attention_forward
+    attn_output = torch.nn.functional.scaled_dot_product_attention(
+        query,
+    ...<6 lines>...
+        **sdpa_kwargs,
+    )
+torch.OutOfMemoryError: CUDA out of memory. Tried to allocate 512.00 MiB. GPU 0 has a total capacity of 5.79 GiB of which 249.88 MiB is free. Including non-PyTorch memory, this process has 4.24 GiB memory in use. Process 65257 has 1.30 GiB memory in use. Of the allocated memory 3.72 GiB is allocated by PyTorch, and 417.37 MiB is reserved by PyTorch but unallocated. If reserved but unallocated memory is large try setting PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True to avoid fragmentation.  See documentation for Memory Management  (https://pytorch.org/docs/stable/notes/cuda.html#environment-variables)
+ Single GPU detected. Using cuda:0
+ Using device: cuda
+Loading generator and discriminators...
+Enabled gradient checkpointing on generator.
+Using single GPU or CPU.
+Training fact discriminator...
+Disc train epoch 1/4, loss=0.5201, val_acc=0.7500
+Disc train epoch 2/4, loss=0.2322, val_acc=1.0000
+Disc train epoch 3/4, loss=0.0366, val_acc=1.0000
+Disc train epoch 4/4, loss=0.0120, val_acc=1.0000
+Training style discriminator...
+Disc train epoch 1/4, loss=0.4904, val_acc=1.0000
+Disc train epoch 2/4, loss=0.1207, val_acc=1.0000
+Disc train epoch 3/4, loss=0.0324, val_acc=1.0000
+Disc train epoch 4/4, loss=0.0150, val_acc=1.0000
+Training safety discriminator...
+Disc train epoch 1/4, loss=0.5335, val_acc=0.7500
+Disc train epoch 2/4, loss=0.2243, val_acc=1.0000
+Disc train epoch 3/4, loss=0.0391, val_acc=1.0000
+Disc train epoch 4/4, loss=0.0122, val_acc=1.0000
+
+Sanity-check discriminator metrics:
+Fact disc: {'acc': 1.0, 'prec': 1.0, 'rec': 1.0, 'f1': 1.0}
+Style disc: {'acc': 1.0, 'prec': 1.0, 'rec': 1.0, 'f1': 1.0}
+Safety disc: {'acc': 1.0, 'prec': 1.0, 'rec': 1.0, 'f1': 1.0}
+
+Evaluation before SFT/RL (baseline):
+🚀 Starting QA + Corpus generation...
+
+📘 Processing: Elite_Dynamics_Partners_Policies
+✏️ Added 4 chunks to corpus file.
+
Generating QAs for Elite_Dynamics_Partners_Policies:   0%|                                            | 0/4 [00:00<?, ?it/s]
Generating QAs for Elite_Dynamics_Partners_Policies: 100%|████████████████████████████████| 4/4 [00:00<00:00, 100462.37it/s]
+⚠️ OPENAI_API_KEY not set. Skipping QA generation for this run.
+⚠️ OPENAI_API_KEY not set. Skipping QA generation for this run.
+⚠️ OPENAI_API_KEY not set. Skipping QA generation for this run.
+⚠️ OPENAI_API_KEY not set. Skipping QA generation for this run.
+✅ Saved 0 QAs for Elite_Dynamics_Partners_Policies
+
+🎯 Done! All QAs saved to:
+   → data/qa/qa.json
+   And corpus appended to:
+   → data/processed/corpus.txt
+The `load_in_4bit` and `load_in_8bit` arguments are deprecated and will be removed in the future versions. Please, pass a `BitsAndBytesConfig` object in `quantization_config` argument instead.
+Some weights of DistilBertForSequenceClassification were not initialized from the model checkpoint at distilbert-base-uncased and are newly initialized: ['classifier.bias', 'classifier.weight', 'pre_classifier.bias', 'pre_classifier.weight']
+You should probably TRAIN this model on a down-stream task to be able to use it for predictions and inference.
+Some weights of DistilBertForSequenceClassification were not initialized from the model checkpoint at distilbert-base-uncased and are newly initialized: ['classifier.bias', 'classifier.weight', 'pre_classifier.bias', 'pre_classifier.weight']
+You should probably TRAIN this model on a down-stream task to be able to use it for predictions and inference.
+Some weights of DistilBertForSequenceClassification were not initialized from the model checkpoint at distilbert-base-uncased and are newly initialized: ['classifier.bias', 'classifier.weight', 'pre_classifier.bias', 'pre_classifier.weight']
+You should probably TRAIN this model on a down-stream task to be able to use it for predictions and inference.
+Traceback (most recent call last):
+  File "<frozen runpy>", line 198, in _run_module_as_main
+  File "<frozen runpy>", line 88, in _run_code
+  File "/home/shehroz/Desktop/New Folder/ai4org/hallucination_reduction/main.py", line 210, in <module>
+    main()
+    ~~~~^^
+  File "/home/shehroz/Desktop/New Folder/ai4org/hallucination_reduction/main.py", line 126, in main
+    fact_disc = train_discriminator_minibatch(fact_disc, fact_tok, fact_texts, fact_labels,
+                                              device=DEVICE, epochs=DISC_EPOCHS, batch_size=DISC_BATCH, lr=DISC_LR)
+  File "/home/shehroz/Desktop/New Folder/ai4org/hallucination_reduction/discriminator_training_utils.py", line 27, in train_discriminator_minibatch
+    optimizer.step()
+    ~~~~~~~~~~~~~~^^
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/torch/optim/optimizer.py", line 516, in wrapper
+    out = func(*args, **kwargs)
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/torch/optim/optimizer.py", line 81, in _use_grad
+    ret = func(*args, **kwargs)
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/torch/optim/adam.py", line 237, in step
+    has_complex = self._init_group(
+        group,
+    ...<5 lines>...
+        state_steps,
+    )
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/torch/optim/adam.py", line 177, in _init_group
+    state["exp_avg"] = torch.zeros_like(
+                       ~~~~~~~~~~~~~~~~^
+        p, memory_format=torch.preserve_format
+        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+    )
+    ^
+torch.OutOfMemoryError: CUDA out of memory. Tried to allocate 20.00 MiB. GPU 0 has a total capacity of 5.79 GiB of which 21.88 MiB is free. Process 75192 has 2.47 GiB memory in use. Including non-PyTorch memory, this process has 3.28 GiB memory in use. Of the allocated memory 3.06 GiB is allocated by PyTorch, and 118.23 MiB is reserved by PyTorch but unallocated. If reserved but unallocated memory is large try setting PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True to avoid fragmentation.  See documentation for Memory Management  (https://pytorch.org/docs/stable/notes/cuda.html#environment-variables)
+ Single GPU detected. Using cuda:0
+ Using device: cuda
+Loading generator and discriminators...
+Enabled gradient checkpointing on generator.
+Using single GPU or CPU.
+Training fact discriminator...
diff --git a/data/raw/png2pdf-1.pdf b/data/raw/png2pdf-1.pdf
new file mode 100644
index 0000000..7af1b39
Binary files /dev/null and b/data/raw/png2pdf-1.pdf differ
diff --git a/data/raw/png2pdf-2.pdf b/data/raw/png2pdf-2.pdf
new file mode 100644
index 0000000..499d411
Binary files /dev/null and b/data/raw/png2pdf-2.pdf differ
diff --git a/data/raw/requirements.txt b/data/raw/requirements.txt
new file mode 100644
index 0000000..3351f75
--- /dev/null
+++ b/data/raw/requirements.txt
@@ -0,0 +1,8 @@
+# Core
+torch>=1.12
+transformers>=4.30
+scikit-learn
+tqdm
+numpy
+pyyaml
+sentencepiece
diff --git a/data/raw/sops.pdf b/data/raw/sops.pdf
new file mode 100644
index 0000000..050bf68
Binary files /dev/null and b/data/raw/sops.pdf differ
diff --git a/data/raw_text/411811106-Branch-Operations-Manual-v2-0-December-2010.txt b/data/raw_text/411811106-Branch-Operations-Manual-v2-0-December-2010.txt
new file mode 100644
index 0000000..9eddcd5
--- /dev/null
+++ b/data/raw_text/411811106-Branch-Operations-Manual-v2-0-December-2010.txt
@@ -0,0 +1 @@
+All rights reserved. This document is the property of MCB Bank Limited and is classified and will only be circulated amongst the relevant departments for internal consumption. No part of this document should be printed, quoted or copied in any form outside the bank BRANCH OPERATIONS MANUAL Version 2.0, December 2010 B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 TABLE OF CONTENTS PREFACE ................................ ................................ ................................ ................................ ...................... 11 SECTION 1 PRODUCTS ................................ ................................ ................................ ................................ . 13 CHAPTER 1 PRODUCT FEATURES & E LIGIBILITY CRITERIA ................................ ................................ ............................ 14 1.1 OVERVIEW ................................ ................................ ................................ ................................ ................................ ... 14 1.2 CURRENT ACCOUNTS ................................ ................................ ................................ ................................ ..................... 15 1.3 SAVING ACCOUNTS ................................ ................................ ................................ ................................ ........................ 20 1.4 TERM DEPOSITS ................................ ................................ ................................ ................................ ............................ 32 1.5 REMOTE CHANNELS ................................ ................................ ................................ ................................ ....................... 35 SECTION 2 ACCOUNT OPENING ................................ ................................ ................................ ................... 40 CHAPTER 1 ACCOUNT OPENING DOCU MENTATION & GENERAL POLICIES ................................ ................................ .. 41 1.1 DOCUMENTATION REQUIREMENT ................................ ................................ ................................ ................................ .... 41 1.2 SYMBOLS ACCOUNT TYPES, CURRENCY , SERVICE TYPES & INTREST TYPES................................ ................................ .............. 48 1.3 ACCOUNT ACTIVATION DEPOSIT ................................ ................................ ................................ ................................ ....... 49 1.4 COMPUTERIZED NATIONAL IDENTIFICATION CARD (CNIC) /ONLINE VERIFICATION / VALIDATION ................................ .................. 49 1.5 CLEARANCE OF ACCOUNT HOLDER ’S NAME FROM UN/ OFAC/ BOE/ EU/ OTHER LISTS ................................ ........................... 51 1.6 EXEMPTION FOR SENIOR CITIZENS TO OPEN AN A/C AGAINST EXPIRED CNIC ................................ ................................ ............ 51 1.7 OPENING OF CONSUMER CUSTOMER ’S COLLECTION ACCOUNT (CCA) ................................ ................................ .................... 51 1.8 RESTRAINT TYPES ................................ ................................ ................................ ................................ .......................... 52 1.9 EXEMPTION OF SERVICE CHARGES ................................ ................................ ................................ ................................ .... 53 1.10 LETTER OF AUTHORITY ................................ ................................ ................................ ................................ ................... 53 CHAPTER 2 CUSTOMER DUE DILIGEN CE / KNOW YOUR CUSTO MER ................................ ................................ ........... 55 2.1 ELEMENTS OF BANKS CDD/ KYC POLICY ................................ ................................ ................................ ........................... 55 2.2 CDD/ KYC POLICY ................................ ................................ ................................ ................................ ........................ 55 2.3 COMPLETION OF ACCOUNT OPENING & KNOW YOUR CUSTOMER FORMS ................................ ................................ ............... 56 2.4 THRESHOLD LIMITS ................................ ................................ ................................ ................................ ........................ 56 2.5 EXCEPTION REPORTS ................................ ................................ ................................ ................................ ...................... 57 CHAPTER 3 ACCOUNT OPENING PROC ESS FLOWS ................................ ................................ ................................ ....... 58 3.1 OVERVIEW ................................ ................................ ................................ ................................ ................................ ... 58 3.2 ACCOUNT OPENING – NORMAL BRANCHES (OTHER THAN E2E) ................................ ................................ ............................. 59 3.3 ACCOUNT OPENING – CENTRALIZED BRANCHES (E2E) ................................ ................................ ................................ ......... 64 3.4 ACCOUNT ACQUISITION BY DIRECT SALES FORCE ................................ ................................ ................................ ................. 69 CHAPTER 4 ACCOUNT OPERATING AN D MAINTENANCE ................................ ................................ ............................. 71 4.1 JOINT ACCOUNT ................................ ................................ ................................ ................................ ............................ 71 4.2 PROPRIETORSHIP ACCOUNT ................................ ................................ ................................ ................................ ............. 71 4.3 PARTNERSHIP ACCOUNT ................................ ................................ ................................ ................................ ................. 71 4.4 TRUST ACCOUNTS ................................ ................................ ................................ ................................ ......................... 74 B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 4.5 COMPANIES REGISTERED UNDER COMPANIES ORDINANCE 1984 ................................ ................................ ............................ 74 4.6 CLUBS/ SOCIETIES / ASSOCIATIONS ................................ ................................ ................................ ................................ ... 74 4.7 LOCAL BODIES ACCOUNT ................................ ................................ ................................ ................................ ................ 75 4.8 LOCAL / DISTRICT ZAKAT / USHR COMMITTEE ACCOUNT ................................ ................................ ................................ ....... 75 4.9 MINOR ACCOUNT ................................ ................................ ................................ ................................ ......................... 76 4.10 STUDENT ACCOUNT ................................ ................................ ................................ ................................ ....................... 76 4.11 ILLITER ATE/ DISABLE / BLIND PERSONS BANK ACCOUNTS ................................ ................................ ................................ ...... 77 4.12 SHARES COLLECTION ACCOUNT ................................ ................................ ................................ ................................ ........ 77 4.13 COLLECTION ACCOUNT ................................ ................................ ................................ ................................ ................... 78 4.14 NON-RESIDENT ACCOUNTS ................................ ................................ ................................ ................................ ............. 78 4.15 NEW FOREIGN CURRENCY ACCOUNTS SCHEME , (F.E. 25) ................................ ................................ ................................ .... 81 4.16 DECEASED ACCOUNT ................................ ................................ ................................ ................................ ..................... 82 4.17 ACCOUNT CLOSURE ................................ ................................ ................................ ................................ ....................... 84 4.18 PROCEDU RE FOR ACCOUNT CLOSURE ................................ ................................ ................................ ................................ 85 4.19 NOTICE UNDER SECTION 140 OF THE INCOME TAX ORDINANCE - 2001 ................................ ................................ .................. 86 4.20 POWER TO CALL FOR INF ORMATION BY THE INCO ME TAX OFFICER (ITO) ................................ ................................ ................... 86 4.21 ATTACHMENT OF CREDIT BALANCE (GARNISHEE ORDER ) ................................ ................................ ................................ ...... 87 4.22 PROCEDURE FOR MARKING FUNDS ON HOLD ................................ ................................ ................................ ..................... 87 4.23 STOP PAYMENT OF CHEQUES ................................ ................................ ................................ ................................ ........... 88 4.24 PROCEDURE TO MARK ACCOUNT ACTIVITY SEIZE ................................ ................................ ................................ ................. 89 4.25 PROCEDURE TO MARK TAX EXEMPTION RESTRAINT ................................ ................................ ................................ .............. 89 4.26 REMOVAL OF RESTRAINT FROM ACCOUN T ................................ ................................ ................................ .......................... 90 4.27 CHANGE IN CUSTOMER ACCOUNT INFORMATION (MASTER DATA) ................................ ................................ ......................... 91 CHAPTER 5 CLASSIFICATION OF AC COUNTS ................................ ................................ ................................ ................ 92 5.1 DORMANT / INOPERATIVE ACCOUNTS & FINANCIAL INSTRUMENTS ................................ ................................ ......................... 92 5.2 UNCLAIMED DEPOSITS & FINANCIAL INSTRUMENTS ................................ ................................ ................................ ............. 92 5.3 MARKING OF RESTRAINT FOR EXEMPTION FROM UNCLAIMED ................................ ................................ ................................ 93 5.4 ACTIVATION & OPERATION IN DORMANT , INOPERATIVE & UNCLAIMED DEPOSIT ACCOUNTS ................................ ...................... 93 5.5 SURRENDER OF UNCLAIMED DEPOSIT TO SBP ................................ ................................ ................................ .................... 95 5.6 REFUND PROCEDURE FOR UNCLAIMED DEPOSITS SURRENDERED TO SBP ................................ ................................ ................. 97 CHAPTER 6 CHEQUE BOOK MANAGEME NT ................................ ................................ ................................ ................. 98 6.1 GENERAL INSTRUCTIONS FOR NEW ACCOUNT HOLDERS ................................ ................................ ................................ ......... 98 6.2 GENERAL INSTRUCTIONS FOR EXISTING ACCOUNT HOLD ERS ................................ ................................ ................................ ... 98 6.3 PROCEDURE FOR ISSUANCE OF CHEQUE BOOKS (NIFT) ................................ ................................ ................................ ......... 99 6.4 COLLECTION OF CHEQUE BOOK BY THE CUSTOMER (NIFT) ................................ ................................ ................................ .. 100 6.5 ISSUANCE OF MANUAL CHEQUE BOOKS ................................ ................................ ................................ ........................... 102 6.6 MANUAL CHEQUE BOOK STOCK ENTRY & MAINTENANCE ................................ ................................ ................................ ... 102 6.7 MICR ENCODED CHEQUE BOOKS BY NIFT - FEATURES ................................ ................................ ................................ ....... 103 6.8 NIFT CHEQUE BOOK STOCK ENTRY & MAINTENANCE ................................ ................................ ................................ ......... 103 6.9 HANDLING OF UNDELIVERED CHEQUE BOOKS ................................ ................................ ................................ ................... 104 CHAPTER 7 TERM DEPOSIT ................................ ................................ ................................ ................................ ........ 105 7.1 TERM DEPOSIT PRODUCTS ................................ ................................ ................................ ................................ ............ 105 7.2 TERM DEPOSIT APPLICATION FORM (SF265 -NEW) ................................ ................................ ................................ ........... 105 7.3 INSTRUCTIONS FOR TERM DEPOSIT ................................ ................................ ................................ ................................ .. 105 7.4 PROCESS – BOOKING OF FDA / MPA (CENTRALIZED PRODUCT ) ................................ ................................ .......................... 106 7.5 PROCESS – MATURITY OF FDA / MPA (CENTRALIZED PRODUCT ) ................................ ................................ ......................... 108 7.6 PROCESS – PREMATURE ENCASHMENT OF FDA / MPA (CENTRALIZED PRODUCT ) ................................ ................................ ... 109 7.7 PROCESS – LIEN MARKING / RELEASING OF FDA / MPA (CENTRALIZED PRODUCT ) ................................ ................................ .. 110 7.8 ANNEXURES & ACCOUNTING FOR FDA/ MPA (CENTRALIZED PRODUCTS ) ................................ ................................ ............. 111 7.9 SMART FOREIGN CURRENCY TERM DEPOSITS – (NON CENTRALIZED PRODUCT ) ................................ ................................ ....... 111 7.10 MANAGEMENT OF TDR/STDR/SND (OPENED PRIOR TO CENTRALIZATION ) ................................ ................................ .......... 113 B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 7.11 MANAGEMENT OF MATURED / OUTSTANDING CAPITAL GROWTH CERTIFICATES ................................ ................................ ...... 117 CHAPTER 8 GUIDELINE ON DED UCTION OF ZAKAT ................................ ................................ ................................ .... 118 8.1 ZAKAT ON PLS SAVINGS & OTHER SIMILAR ACCOUNTS (ASSET CODE: 101) ................................ ................................ ........... 118 8.2 ZAKAT ON TERM DEPOSIT PRODUCTS (ASSET CODE: 103) ................................ ................................ ................................ .. 118 8.3 ZAKAT EXEMPTIONS ................................ ................................ ................................ ................................ ..................... 118 8.4 PROCED URE FOR CALCULATION & DEDUCTION OF ZAKAT ON TERM DEPOSITS ................................ ................................ ........ 119 8.5 PROCEDURE FOR CALCULATION & DEDUCTION OF ZAKAT ON PLS SAVINGS & OTHER SIMILAR ACCOUNTS ................................ .... 120 8.6 DEDUCTION OF ZAKAT ................................ ................................ ................................ ................................ .................. 121 8.7 REPORTING PROCEDURE FOR BRANCHES / CIRCLE OFFICES ................................ ................................ ................................ .. 121 SECTION 3 CASH MANAGEMENT & TE LLER SERVICES ................................ ................................ ................. 122 CHAPTER 1 CASH MANAGEMENT ................................ ................................ ................................ .............................. 123 1.1 DAILY CASH BALANCING ................................ ................................ ................................ ................................ ............... 123 1.2 CASH HANDLING & CASH POSITION STATEMENT ................................ ................................ ................................ ............... 123 1.3 PROCEDURE FOR CASH FOUND EXCESS ................................ ................................ ................................ ............................ 124 1.4 SECURITY ARRANGEMENTS FOR CASH ................................ ................................ ................................ ............................. 125 1.5 CASH IN HAND & CASH IN HAND INSURANCE LIMIT ................................ ................................ ................................ ........... 125 1.6 CASH DEPOSIT BY BRANCHES WITH CASH HOUSE / CASH FEEDING BRANCH ................................ ................................ ........... 126 1.7 CASH DEPOSIT BY UP-COUNTRY BRANCHES WITH CASH HOUSE / CASH FEEDING BRANCH ................................ ........................ 127 1.8 CASH TRANSFER FROM CASH HOUSE TO BRANCHES ................................ ................................ ................................ ........... 127 1.9 TRANSFER OF CASH FROM CASH HOUSE TO SBP ................................ ................................ ................................ ............... 128 1.10 CHARGES FOR CASH COUNTING AND SORTING OF CASH ................................ ................................ ................................ ...... 128 1.11 HIRING CHARGES FOR ARMORED VEHICLES OF SECURITY SERVICE AGENCY ................................ ................................ ............. 128 1.12 CASH HOUSE CHARGES FOR SUPPLY AND COLLECTION OF CASH ................................ ................................ ........................... 128 1.13 CASH TRANSFER FROM CASH FEEDING BRANCH TO BRANCHES ................................ ................................ ............................ 128 1.14 PROCEDURE FOR TRANSFERING FOREIGN CURRENCY TO MAIN BRANCH ................................ ................................ ................. 129 1.15 PROCEDURE FOR RECEIVING FOREIGN CURRENCY FROM MAIN BRANCH ................................ ................................ ................ 131 1.16 LATE RECEIPTS ................................ ................................ ................................ ................................ ............................ 132 1.17 TELLER CASH TRANSFER ................................ ................................ ................................ ................................ ............... 132 1.18 KEYS & KEY REGISTERS ................................ ................................ ................................ ................................ ................. 132 1.19 APPLICATION OF TEST ................................ ................................ ................................ ................................ .................. 132 1.20 RESTORE OFFLINE FINANCIAL TRANSACTIONS ................................ ................................ ................................ ................... 133 1.21 USAGE & SAFE CUSTODY OF CASH RECEIPT /PAID STAMPS ................................ ................................ ................................ .. 134 1.22 IMPOSITION OF SBP PENALTIES ................................ ................................ ................................ ................................ ..... 134 1.23 BASIC GUIDELINES FOR MCB COLLECTION SYSTEM FOR TBD TRANSACTIONS ................................ ................................ .......... 135 1.24 CURRENCY TRANSACTION REPORTING (CTR) ................................ ................................ ................................ .................... 136 CHAPTER 2 CASH DEPOSIT & WITHD RAWAL ................................ ................................ ................................ ............. 137 2.1 PROCEDURE OF CASH DEPOSIT ................................ ................................ ................................ ................................ ...... 137 2.2 PROCEDURE FOR CASH DEPOSIT REVERSAL ................................ ................................ ................................ ....................... 137 2.3 PROCEDURE FOR CASH WITHDRAWAL VIA CHEQUE ................................ ................................ ................................ ............ 138 2.4 PRECAUTIONS AGAINST FAKE/ CHEMICALLY ALTERED / RUBBED / DEFACED CHEQUES ................................ .............................. 139 2.5 PROCEDURE FOR CHEQUE WITHDRAWAL REVERSAL ................................ ................................ ................................ .......... 139 2.6 PAYMENT OF ON-LINE CASH CHEQUES OV ER BRANCH COUNTERS ................................ ................................ ......................... 140 2.7 PROCEDURE FOR PAYMENT OF PKR AGAINST FCY A/C CHEQUE ................................ ................................ ........................... 141 2.8 CALL BACK CONFIRMATION PROCESS (CBC) ................................ ................................ ................................ ..................... 142 2.9 PROCEDURE FOR CREDIT CARD PAYMENTS AGAINST CASH - ONLINE PAYMENT FACILITY ................................ ........................... 143 2.10 PROCEDURE FOR CREDIT CARD PAYMENT T HROUGH CHEQUE – DROP-BOX FACILITY ................................ ................................ . 144 2.11 PROCEDURE FOR CASH ADVANCE TO CREDIT CARD CUSTOMERS ................................ ................................ ........................... 145 B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 CHAPTER 3 INWARD & OUTWARD CLE ARING ................................ ................................ ................................ ........... 147 3.1 OUTWARD CLEARING ................................ ................................ ................................ ................................ ................... 147 3.2 PROCED URE FOR OUTWARD CLEARING – NIFT BRANCHES ................................ ................................ ................................ .. 148 3.3 PROCEDURE FOR OUTWARD SAME-DAY CLEARING – NIFT BRANCHES ................................ ................................ .................. 150 3.4 INWARD CLEARING ................................ ................................ ................................ ................................ ...................... 152 3.5 PROCEDURE FOR INWARD CLEARING – NIFT BRANCHES ................................ ................................ ................................ ..... 152 3.6 RESOLUTION OF DISCREPANCIES ................................ ................................ ................................ ................................ ..... 154 3.7 INWARD CLEARING – CHEQUE DEBIT REVERSAL ................................ ................................ ................................ ................ 155 3.8 CHEQUE RETURN MEMO ................................ ................................ ................................ ................................ .............. 155 CHAPTER 4 INWARD / OUTWARD BIL LS FOR COLLECTION ................................ ................................ ........................ 156 4.1 INWARD & OUTWARD LOCAL BILLS FOR COLLECTIONS ................................ ................................ ................................ ....... 156 4.2 OUTWARD FOREIGN BILLS FOR COLLECTION ................................ ................................ ................................ ..................... 159 4.3 FBC - LOCAL BANK’S FCY CHEQUE DEPOSITED IN MCB FCY ACCOUNT ................................ ................................ ................. 161 4.4 FBC - MCB FCY CHEQUE (OF OTHER BRANCH ) DEPOSITED IN MCB PKR ACCOUNT ................................ ............................... 162 4.5 OUTWARD FBC - LOCAL BANK’S FCY CHEQUE DEPOSITED IN MCB PKR ACCOUNT ................................ ................................ . 162 4.6 INWARD FOREIGN BILLS FOR COLLECTION ................................ ................................ ................................ ........................ 163 CHAPTER 5 INTERNAL FUNDS TRANS FER ................................ ................................ ................................ ................... 164 5.1 OVERVIEW – APPLICATION FOR INTERNAL FUND TRANSFER ................................ ................................ ................................ . 164 5.2 PROCEDURE FOR INTERNAL FUNDS TRANSFER ................................ ................................ ................................ ................... 164 5.3 PROCEDURE FOR CHEQUE DEPOSIT (OWN BANK) ................................ ................................ ................................ .............. 166 5.4 PROCEDURE FOR TRANSACTION REVERSALS ................................ ................................ ................................ ...................... 166 CHAPTER 6 UTILITY BILLS MANAGE MENT ................................ ................................ ................................ ................. 167 6.1 COLLECTION ARRANGEMENT ................................ ................................ ................................ ................................ ......... 167 6.2 TELLER ’S LIMIT FOR COLLECTION OF UTILITY BILLS ................................ ................................ ................................ ............. 168 6.3 PTCL – UTILITY BILLS COLLECTION PROCESS ................................ ................................ ................................ .................... 168 6.4 KESC – UTILITY BILLS COLLECTION PROCESS - SPECIFIC /INDUSTRIAL CONSUMERS ONLY ................................ .......................... 169 6.5 UTILITY BILLS STANDARD COLLECTION PROCESS – KESC/ WAPDA/ SNGPL/ SSGC ................................ .............................. 170 6.6 UTILITY BILLS COLLECTION – VIA MCB BOOTHS ................................ ................................ ................................ ............... 172 6.7 AUTHORITY TO DELETE ARREARS ................................ ................................ ................................ ................................ .... 172 CHAPTER 7 PRIZE BONDS ................................ ................................ ................................ ................................ .......... 174 7.1 SALE AND ENCASHMENT TRANSACTIONS ................................ ................................ ................................ .......................... 174 7.2 MAINTENANCE OF MONTHLY PRIZE BONDS STATEMENT ................................ ................................ ................................ ..... 174 7.3 REQUIREMENT DURING SHUT PERIOD ................................ ................................ ................................ ............................. 175 7.4 MAINTENANCE OF PRIZE BONDS REGISTER ................................ ................................ ................................ ....................... 175 7.5 MAINTENANCE OF PRIZE BONDS SHUT PERIOD REGISTER - SB-107 ................................ ................................ ...................... 175 7.6 PROCEDURE FOR SALE OF PRIZE BONDS (CASH) ................................ ................................ ................................ ................ 176 7.7 PROCEDURE FOR SALE OF PRIZE BONDS (DEBIT TO ACCOUNT ) ................................ ................................ ............................. 177 7.8 PROCEDURE FOR ENCASHMENT OF PRIZE BONDS (CASH) ................................ ................................ ................................ .... 178 7.9 PROCEDURE FOR ENCASHMENT OF PRIZE BONDS (CREDIT TO ACCOUNT ) ................................ ................................ ............... 179 B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 SECTION 4 REMITTANCES ................................ ................................ ................................ ......................... 180 CHAPTER 1 GENERAL INSTRUCTIONS FOR PO / DD ................................ ................................ ................................ ... 181 1.1 OVERIEW - APPLICATION FORM ................................ ................................ ................................ ................................ ..... 181 1.2 SCRUTINY OF DEMAND DRAFT & PAY ORDER ................................ ................................ ................................ ................... 181 1.3 BALANCING OF PO / DD PAYABLE ACCOUNTS ................................ ................................ ................................ .................. 181 1.4 ISSUANCE OF NEW PAYMENT ORDER / DEMAND DRAFT SERIES ................................ ................................ ........................... 181 1.5 BALANCING OF PAYMENT ORDER / DEMAND DRAFT LEAVES ................................ ................................ ............................... 182 1.6 TRANSFER OF DDS & POS TO UNCLAIMED ACCOUNT ................................ ................................ ................................ ........ 182 CHAPTER 2 PO / DD / CDR & LCY -TT PROCESSES ................................ ................................ ................................ ....... 183 2.1 PO ISSUANCE – SELL AGAINST CASH ................................ ................................ ................................ ................................ 183 2.2 PO ISSUANCE – SELL AGAINST ACCOUNT ................................ ................................ ................................ ......................... 184 2.3 PO PURCHASE – TRANSFER INTO ACCOUNT ................................ ................................ ................................ ..................... 185 2.4 LCY DD ISSUANCE – SELL VIA CASH ................................ ................................ ................................ ................................ 186 2.5 LCY DD ISSUANCE – SELL VIA ACCOUNT ................................ ................................ ................................ .......................... 187 2.6 LCY DD PURCHASE – TRANSFER INTO ACCOUNT ................................ ................................ ................................ ............... 188 2.7 FCY DD ISSUANCE – SELL VIA ACCOUNT ................................ ................................ ................................ ......................... 189 2.8 FCY DD PURCHASE – UNDER RUPEE DRAWING ARRANGEMENT ................................ ................................ .......................... 190 2.9 FCY DD PURCHASE – UNDER DOLLAR DRAWING ARRANGEMENT ................................ ................................ ........................ 191 2.10 PO/ DD ISSUANCE – SELL AGAINST HEAD OFFICE ADVISE ................................ ................................ ................................ ... 192 2.11 REVALIDATION OF PAY ORDER / DEMAND DRAFT ................................ ................................ ................................ .............. 193 2.12 CHANGE OF PAYEE’S NAME ................................ ................................ ................................ ................................ ........... 193 2.13 ISSUANCE OF DUPLICATE PAY ORDER / DEMAND DRAFT ................................ ................................ ................................ ..... 193 2.14 CANCELLATION OF DEMAND DRAFT ................................ ................................ ................................ ................................ 194 2.15 CANCELLATION OF PAY ORDER ................................ ................................ ................................ ................................ ...... 196 2.16 PAYMENT OF CANCELLED PAY ORDER / DEMAND DRAFT (ISSUING BRANCH ) ................................ ................................ .......... 196 2.17 ISSUANCE OF CALL DEPOSIT RECEIPT (CDR) ................................ ................................ ................................ ..................... 197 2.18 PAYMENT OF CALL DEPOSIT RECEIPT (CDR) ................................ ................................ ................................ ..................... 198 2.19 LCY TELEGRAPHIC TRANSFER ................................ ................................ ................................ ................................ ......... 199 CHAPTER 3 FOREIGN WIRE TRANSFE R ................................ ................................ ................................ ....................... 205 3.1 FOREIGN WIRE TRANSFER – INWARD ................................ ................................ ................................ .............................. 205 3.2 PROCEDURE FOR FOREIGN WIRE TRANSFER – INWARD ................................ ................................ ................................ ....... 206 3.3 FOREIGN WIRE TRANSFER – OUTWARD ................................ ................................ ................................ ........................... 207 3.4 PROCEDURE FOR FOREIGN WIRE TRANSFER – OUTWARD ................................ ................................ ................................ .... 208 CHAPTER 4 RUPEE TRAVELERS CHEQ UES (RTC) ................................ ................................ ................................ ......... 210 4.1 INTRODUCTION ................................ ................................ ................................ ................................ ........................... 210 4.2 DENOMINATION ................................ ................................ ................................ ................................ ......................... 210 4.3 COMMISSION / TAXES ................................ ................................ ................................ ................................ .................. 211 4.4 RTC STOCK AND REPLENISHMENT ................................ ................................ ................................ ................................ .. 211 4.5 RTC SALE PROCEDURE ................................ ................................ ................................ ................................ ................. 214 4.6 SURRENDER OF UNCLAIMED DEPOSITS /INSTRUMENTS TO SBP ................................ ................................ ............................ 217 4.7 RTC PURCHASE PROCEDURE ................................ ................................ ................................ ................................ ......... 217 4.8 REPORT OF LOST / STOLEN RTC ................................ ................................ ................................ ................................ ..... 223 4.9 REFUND / REPLACEMENT OF LOST / STOLEN RTC ................................ ................................ ................................ .............. 225 4.10 PROCESSING OF REFUND APPLICATION / RE-ISSUE / ACCOUNTING ................................ ................................ ........................ 227 4.11 REFUND PROCEDURE OF RTC S................................ ................................ ................................ ................................ ....... 228 4.12 REPLACEMENT OF TORN / SOILED & DAMAGED RTC S ................................ ................................ ................................ ........ 229 4.13 SAFE CUSTODY OF RTC ................................ ................................ ................................ ................................ ................ 230 4.14 COMPLIANCE / REGULATORY / OPERATIONAL INSTRUCTIONS ................................ ................................ ............................... 230 4.15 FLOAT INCOME DISBURSEMENT TO BRANCHES ................................ ................................ ................................ .................. 231 B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 CHAPTER 5 HOME REMITTANCE ................................ ................................ ................................ ................................ 232 5.1 MCB HOME REMITTANCE ................................ ................................ ................................ ................................ ............ 232 5.2 EXPRESS MONEY ................................ ................................ ................................ ................................ ......................... 235 5.3 MONEY GRAM ................................ ................................ ................................ ................................ ........................... 236 5.4 SPEED CASH NOW ................................ ................................ ................................ ................................ ....................... 237 5.5 PAYMENT THROUGH RAM ................................ ................................ ................................ ................................ ........... 238 SECTION 5 REMOTE CHANNELS ................................ ................................ ................................ ................. 239 CHAPTER 1 AUTO TELLER MACHINE ................................ ................................ ................................ .......................... 240 1.1 FUNDS TRANSFER VIA ATM ................................ ................................ ................................ ................................ .......... 240 1.2 MNET - MCB NETWORK FOR ELECTRONIC TRANSACTIONS ................................ ................................ ................................ . 240 1.3 INTER -SWITCH CONNECTIVITY ................................ ................................ ................................ ................................ ........ 240 1.4 ACQUIRER TRANSACTIONS ................................ ................................ ................................ ................................ ............ 240 1.5 ISSUER TRANSACTIONS ................................ ................................ ................................ ................................ ................. 241 1.6 DISABLED , RETAINED & CAPTURED CARDS ON ATM S ................................ ................................ ................................ ........ 241 1.7 CARD FACILITATION CENTER (CFC) ................................ ................................ ................................ ................................ . 242 1.8 ATM CUSTODIANS RESPONSIBILITIES ................................ ................................ ................................ .............................. 243 1.9 ATM CASH REPLENISHMENT ................................ ................................ ................................ ................................ ......... 244 1.10 CASH VAULT OPENING / CLOSING ON AN OFF-DAY / HOLIDAY ................................ ................................ ............................ 245 1.11 DAILY BALANCING OF ATM CASH ................................ ................................ ................................ ................................ .. 245 1.12 STEPS TO FOLLOW FOR C ASH BALANCING IN CAS E RAMS REPORT IS NOT AVAILA BLE ................................ ................................ . 249 1.13 SBP MANDATED TIMELINES FOR ”AUTOMATIC CREDIT ” OF SUSPENSE ATM CASH ................................ ................................ .. 250 1.14 RECONCILIATION OF ATM CASH WITH CASH-IN-ATM GL ................................ ................................ ................................ .. 251 1.15 STEPS TO FOLLOW FOR GL BALANCING IN CASE RAMS REPORT IS NOT AVAILA BLE ................................ ................................ .... 253 1.16 MCB ATM / SMART CARD PROACTIVE TRANSACTION SETTLEMENT ................................ ................................ ..................... 254 1.17 ATM CLAIM MANUAL SETTLEMENTS ................................ ................................ ................................ .............................. 255 1.18 DISPUTE RESOLUTION UNIT ................................ ................................ ................................ ................................ .......... 256 1.19 ESCALATION MATRIX – ATM CASH & GL BALANCING ................................ ................................ ................................ ....... 256 CHAPTER 2 SMART CARD ................................ ................................ ................................ ................................ .......... 258 2.1 SMART CARD – LIFE CYCLE ................................ ................................ ................................ ................................ ............ 258 2.2 SMART CARD REQUEST ORDER TAKING ................................ ................................ ................................ ......................... 258 2.3 SMART CARD & PIN PRODUCTION & DELIVERY ................................ ................................ ................................ ................. 261 2.4 CUSTODY OF SMART CARD & PIN ................................ ................................ ................................ ................................ ... 261 2.5 HANDOVER OF SMART CARD & PIN ................................ ................................ ................................ ................................ 261 2.6 DAILY BALANCING OF SMART CARDS & PIN MAILERS ................................ ................................ ................................ ....... 261 2.7 HANDLING OF UNDELIVERED SMART CARDS ................................ ................................ ................................ ..................... 261 2.8 SMART CARD ACTIVATION ................................ ................................ ................................ ................................ ............ 262 2.9 SMART CARD BLOCKING (LOST/ STOLEN ) ................................ ................................ ................................ ........................ 262 2.10 SMART CARD DELETION ................................ ................................ ................................ ................................ ............... 262 2.11 SMART CARD PIN CHANGE ................................ ................................ ................................ ................................ ............ 262 2.12 ACTIVATION OF WARM (DISABLED ) SMART CARD ................................ ................................ ................................ ............. 262 2.13 ISSUANCE OF SMART CARDS TO NON-RESIDENT RUPEE ACCOUNT HOLDERS ................................ ................................ ......... 263 2.14 HANDLING OF RETAINED / CAPTURED CARDS ON ATM S ................................ ................................ ................................ ..... 263 2.15 COLLECTION & RECORD KEEPING OF RETAINED /CAPTURED CARDS ................................ ................................ ....................... 263 2.16 DISPOSITION OF RETAINED / CAPTURED CARDS ................................ ................................ ................................ ................. 264 B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 CHAPTER 3 PREPAID VISA CARD ................................ ................................ ................................ ................................ 266 3.1 BRANCH RESPONSIBILITIES ................................ ................................ ................................ ................................ ............ 266 3.2 PREPAID VISA – CARD ISSUANCE PROCESS ................................ ................................ ................................ ....................... 267 3.3 PREPAID VISA – CARD & PIN ISSUANCE PROCESS ................................ ................................ ................................ .............. 268 3.4 PREPAID VISA – LOAD / RE-LOAD PROCESS ................................ ................................ ................................ ...................... 268 3.5 PREPAID VISA – BALANCE ENQUIRY ................................ ................................ ................................ ................................ 270 3.6 PREPAID VISA – STATEMENT REQUEST ................................ ................................ ................................ ............................ 270 3.7 PREPAID VISA – INVENTORY MANAGEMENT ................................ ................................ ................................ ..................... 271 3.8 PREPAID VISA – PROCESS FOR CAPTURED CARDS IN ATM ................................ ................................ ................................ ... 272 CHAPTER 4 VIRTUAL BANKING ................................ ................................ ................................ ................................ .. 273 4.1 VB REGISTRATION PROCESS FOR INDIVIDUAL CUSTOMERS ................................ ................................ ................................ ... 273 4.2 VB REGISTRATION PROCESS FOR CUSTOMERS ABROAD ................................ ................................ ................................ ...... 273 4.3 VB REGISTRATION PROCESS FOR CORPORATE CUSTOMERS ................................ ................................ ................................ .. 273 CHAPTER 5 CALL CENTER ................................ ................................ ................................ ................................ ........... 274 5.1 CALL CENTER REGISTRATION PROCESS FOR NTB CUSTOMERS ................................ ................................ .............................. 274 5.2 CALL CENTER REGISTRATION PROCESS FOR OLD CUSTOMERS (PRIOR 01-JAN-09) ................................ ................................ ... 274 5.3 CONTROL GUIDELINES ................................ ................................ ................................ ................................ .................. 274 CHAPTER 6 MOBILE BANKING ................................ ................................ ................................ ................................ ... 275 6.1 REGISTRATION PROCESS ................................ ................................ ................................ ................................ ............... 275 6.2 MCB MOBILE REGISTRATIONS POS TERMINAL MANAGEMENT ................................ ................................ ........................... 276 SECTION 6 CENTRALIZED & AUTOMA TED OPERATIONS ................................ ................................ ............. 278 CHAPTER 1 CENTRALIZATION & AUT OMATION OF BRANCH BA CK-END PROCESS ................................ ..................... 279 1.1 ROLE & RESPONSIBILITIES OF STAKEHOLDERS ................................ ................................ ................................ .................... 280 1.2 COLLECTION OF FED FROM BRANCHES & ONWARD PAYMENT TO GOVERNMENT ................................ ................................ .... 280 1.3 COLLECTION OF WHT FROM BRANCHES & ITS ONWARD PAYMENT TO THE GOVERNMENT ................................ ........................ 281 1.4 PAYMENT OF WHT TO THE GOVT BY BRANCHES UNDER JURISDICTION OF AZAD JAMMU KASHMIR ................................ ............. 282 1.5 RECOVERY OF SERVICE CHARGES FROM CUSTOMERS ................................ ................................ ................................ .......... 282 1.6 RECOVERY OF APPLICABLE CHARGES FROM CUSTOMERS MAINTAINING BBA ACCOUNT ................................ ............................ 283 1.7 COMPILATION & SETTLEMENT OF HO. POOL MARK-UP BETWEEN BRANCHES & HO ................................ ................................ 283 1.8 BULK SALARY PROCESSING ................................ ................................ ................................ ................................ ............ 283 1.9 SETTLEMENT OF TREASURY (TROPS) ADVICES ................................ ................................ ................................ ................. 284 1.10 ALLOCATION OF COD POSTAGE EXPENSES TO BRANCHES RELATED TO CENTRALIZED CLEARING & ACCOUNT OPENING ................... 284 1.11 ALLOCATION OF NIFT EXPENSES TO BRANCHES FOR PROCESSING OF CLEARING & CHEQUE BOOKS ................................ ............. 285 1.12 ALLOCATION OF CASH–IN–TRANSIT & CASH HOUSE CHARGES TO BRANCHES DIRECTLY DEA LING WITH CASH HOUSE ...................... 285 1.13 CENTRALIZATION OF CASH IN TRANSIT CHARGES AT CASH FEEDING BRANCHES ................................ ................................ ....... 286 1.14 ALLOCATION OF SWIFT PROCESSING CHARGES TO BRANCHES ................................ ................................ ............................. 287 1.15 ALLOCATION OF STATIONERY CHARGES OF MCBEF TO BRANCHES ................................ ................................ ........................ 288 1.16 PROCESSING & ALLOCATION OF HRMG COST (SALARIES ) OF CONTRACTUAL STAFF TO BRANCHES ................................ ............. 288 1.17 PROCESSING OF ACCOUNT SWEEP INSTRUCTIONS FOR UTILITY COMPANIES & TPD CUSTOMERS ................................ ................ 289 1.18 SUBMISSION OF DATA TO CIRCLES FOR UNCLAIMED DEPOSITS / INSTRUMENTS FOR GENERATION OF NOTICE PERIOD LETTERS ......... 289 1.19 ALLOCATION OF SEMI-ANNUAL STATEMENT RENDITION CHARGES TO BRANCHES ................................ ................................ ..... 289 1.20 RENDITION OF SEMI-ANNUAL ACCOUNT STATEMENT ................................ ................................ ................................ ......... 290 B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 SECTION 7 GENERAL BANKING OPER ATIONS / MISCELLANEOUS ................................ ................................ 292 CHAPTER 1 GENERAL LEDGER ................................ ................................ ................................ ................................ .... 293 1.1 OVERVIEW ................................ ................................ ................................ ................................ ................................ . 293 1.2 GENERAL LEDGER CONTROL ACCOUNTS ................................ ................................ ................................ .......................... 293 1.3 CENTRALIZED POSTING IN GENERAL LEDGER ................................ ................................ ................................ ..................... 294 1.4 TRANSACTION PROCESSIN G IN GL MODULE ................................ ................................ ................................ ..................... 296 CHAPTER 2 BRANCH REPORTS ................................ ................................ ................................ ................................ ... 300 2.1 MANDATORY BRANCH REPORTS ................................ ................................ ................................ ................................ .... 300 2.2 MANDATORY REPORTS – BRANCH RESPONSIBILITIES ................................ ................................ ................................ .......... 302 2.3 MISCELLANEOUS BRANCH REPORTS ................................ ................................ ................................ ................................ 303 2.4 MISCELLANEOUS REPORTS – BRANCH RESPONSIBILITIES ................................ ................................ ................................ ..... 305 CHAPTER 3 IT SECURITY GUIDELIN ES ................................ ................................ ................................ ......................... 306 3.1 PASSWORD PROTECTION ................................ ................................ ................................ ................................ .............. 306 3.2 EMAIL USAGE ................................ ................................ ................................ ................................ ............................. 306 3.3 REMOVABLE STORAGE PROTECTION ................................ ................................ ................................ ................................ 307 3.4 VIRUS AND MALICIOUS PROGRAMS PROTECTION ................................ ................................ ................................ .............. 307 3.5 SYSTEM ACCEPTABLE USE ................................ ................................ ................................ ................................ ............. 307 CHAPTER 4 START & END OF DAY ................................ ................................ ................................ .............................. 308 4.1 START OF DAY ................................ ................................ ................................ ................................ ............................ 308 4.2 END OF DAY ................................ ................................ ................................ ................................ ............................... 308 CHAPTER 5 LOCKER MANAGEMENT ................................ ................................ ................................ .......................... 309 5.1 RIGHTS & OBLIGATIONS OF LICENSEE ................................ ................................ ................................ .............................. 309 5.2 ISSUE OF LICENSE ................................ ................................ ................................ ................................ ........................ 309 5.3 TERMINATION OF LICENSE ................................ ................................ ................................ ................................ ............. 310 5.4 RIGHTS OF THE BANK (LICENSOR ) IN CASE OF NON-PAYMENT OF RENT ................................ ................................ .................. 310 5.5 LIABILITIES OF THE BANK (LICENSOR )................................ ................................ ................................ ............................... 311 5.6 USE OF LOCKER ................................ ................................ ................................ ................................ ........................... 311 5.7 RENEWAL / EXPIRY ................................ ................................ ................................ ................................ ...................... 311 5.8 KEY DEPOSIT ................................ ................................ ................................ ................................ .............................. 311 5.9 PAYMENT OF RENT ................................ ................................ ................................ ................................ ...................... 311 5.10 RECOVERY OF RENT IN CASE OF DEFAULT ................................ ................................ ................................ ......................... 311 5.11 BREAK OPENING OF LOCKERS ................................ ................................ ................................ ................................ ........ 312 5.12 GENERAL INSTRUCTIONS FOR THE LICENSEE / LICENSOR ................................ ................................ ................................ ....... 313 5.13 LOCKER INSURANCE POLICY ................................ ................................ ................................ ................................ ........... 313 5.14 CONTROL GUIDELINES ................................ ................................ ................................ ................................ .................. 313 CHAPTER 6 INTER -BRANCH RECONCILIATIO N APPLICATION CORONA ................................ ................................ ....... 314 6.1 OUTSTANDING TRANSACTIONS AT BRANCH END AGING ANALYSIS ................................ ................................ ........................ 314 6.2 OUTSTANDING /UNRESOLVED AMOUNT AT BRANCH END ................................ ................................ ................................ ... 315 6.3 TRANSACTIONS TO BE RESPONDED BY OTHER BRANCHES ................................ ................................ ................................ ..... 315 6.4 TRANSACTIONS AMOUNT (VALUE ) TO BE RESPONDED BY O THER BRANCHES ................................ ................................ ............ 315 6.5 HEAD OFFICE GENERAL LEDGER ACCOUNT MOVEMENT ................................ ................................ ................................ ..... 315 6.6 SUMMARY SCHEDULE ................................ ................................ ................................ ................................ .................. 316 CHAPTER 7 INVESTMENT SERVICES - MUTUAL FUNDS ................................ ................................ .............................. 319 7.1 SALES OF MUTUAL FUNDS ................................ ................................ ................................ ................................ ............ 319 7.2 DISCREPANCIES AND REVERSALS ................................ ................................ ................................ ................................ ..... 321 7.3 AFTER-SALES SERVICES ................................ ................................ ................................ ................................ ................. 322 B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 CHAPTER 8 GOVERNMENT SECURITIE S (DSC/ SSC) ................................ ................................ ................................ .... 324 8.1 ABOUT DEFENCE SAVING CERTIFICATES (DSC) ................................ ................................ ................................ ................. 324 8.2 ISSUANCE OF DSC ................................ ................................ ................................ ................................ ....................... 325 8.3 ENCASHME NT OF DSC ................................ ................................ ................................ ................................ ................. 328 8.4 ABOUT SPECIAL SAVING CERTIFICATES (SSC) ................................ ................................ ................................ .................... 332 8.5 ISSUANCE OF SSC ................................ ................................ ................................ ................................ ........................ 333 8.6 ENCASHMENT OF SSC ................................ ................................ ................................ ................................ .................. 335 8.7 ENCASH MENT OF SSC COUPONS ................................ ................................ ................................ ................................ .... 339 8.8 DSC & SSC STOCK RECEIVING PROCEDURE ................................ ................................ ................................ ..................... 343 8.9 PROCEDURE FOR RE-ISSUANCE OF LOST SECURITIES ................................ ................................ ................................ .......... 343 8.10 PROCEDURE FOR MAIN BRANCHES NOT DEA LING IN HO A/C FOR DSC/SSC CLAIM SETTLEMENT ................................ ................ 344 8.11 GENERAL CONTROLS ................................ ................................ ................................ ................................ .................... 345 8.12 MIS PREPARATION AT BRANCH END ................................ ................................ ................................ ............................... 345 CHAPTER 9 OPERATIONAL RISK AND CONTROLS ................................ ................................ ................................ ....... 346 CHAPTER 10 HIGH PRIORITY DOCUME NTS & RETENTION PERI OD................................ ................................ ............... 350 CHAPTER 11 BRANCH MANDATORY NOT ICES/ WALLBOA RDS/ MATERIAL ................................ ................................ .. 354 CHAPTER 12 SBP GUIDELINES FOR S UB-BRANCHES ................................ ................................ ................................ ..... 355 CHAPTER 13 BRANCH TRANSACTIONAL AUTHORITIES & THRESH OLD LIMITS ................................ ............................. 356 ANNEXURES ................................ ................................ ................................ ................................ ............... 363 PROCESS DEVIATION ................................ ................................ ................................ ................................ .. 387 GLOSSARY ................................ ................................ ................................ ................................ ................. 388 B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 11 PREFACE We are pleased to present updated version of the Branch Operations Manual (version 2.0 – December 2010). The B ranch Operation s Manual was last updated in December 2007 and since then various policies and procedural instructions, having impact on branch banking operations, have been issued. Hence, it was necessary to update the existing version of the Manual and incorporate all substantial changes. Resultantly, the Manua l has undergone significant revision through reorganizing the structure of the previous version, updating all material and increasing the coverage of critical subject matter . The primary audience of this Manual is i ndividuals involved in the management & performance of branch banking operations and related activities , Compliance & Controls Group and Audit & Risk Assets Review Group. The Manual covers regulatory requirements, policies and procedural instructions relevant to branch banking operations. Howev er, the users of the Manual, for better understanding, are recommended to read it in overall context of relevant policies approved by the Board, Application User Manuals and other documents such as the Accounting Manual etc. The actions of this audience must be in line with the policies and procedures stated in the Manual. Any un - authorized deviation can result in disciplinary action being initiated against the concerned individual (s) depending upon the ser iousness of the action . Branches, in particular, a re expected to follow the instructions laid down in this manual for achieving business objectives and maintaining effective control environment. This will improve their operations and also help them achieve complian ce with regulatory requirements and bette r audit rating. The Content of the Manual is classified into various sections based on broader categori es of banking operations and is further split into different chapters. The Section Summaries on the Section header pages spell out the content of the se ction for users’ benefit. Efforts have been made to organize each chapter so that the coverage is more thorough on all aspects, emphasizing the critical regulatory /policy requirements on one hand, whilst aided by detailed process flows on the other hand. P rocess flows are carefully included in a sequential manner and have been simplified without compromising the quality of substance and objectivity. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 12 Besides procedural instructions to perform various operations, in this version, the branches and supervisory staff have also been facilitated with provision of various tools to monitor their financial transactions and non- financial operational activities t o strengthen the control environment. Another emphasis in this version is to supplement the process flows with steps for usage of Symbols application. The Bank has undertaken approach of centralization of business processes with an objective of improved co ntrols and process efficiency. To date, various processes have b een centralized that also a ffect branch operations and processes. These processes have been included in the Manual, specifically, highlighting the functions to be performed by the branches wit h their respective responsibilities. The instructions of the Manual, since its issuance, may be further revised, amended, modified or overridden through subsequent issuance of policies and circulars, hence, the users are instructed to conform to those policies and ci rculars and use them as addenda to the Manual. In this regard, whenever a change of a permanent nature is made to any operational policies and/or procedures, a new circular will be issued by giving reference to the particular Chapter / Section / Subsection of the Manual. To update the Manual was a huge exercise and could not be possible without active participation of resources across the Bank. We would like to thank various groups involved in providing v alued feedback and suggestions includin g Commercial Branch Banking, Islamic Banking, Consumer Banking, Compliance & Controls, Financial Control, Risk Management, Information Technology and Audit & Risk Assets Review. Finally, we would like to appreciate Business Process Management Division who led this critical assignment in collaboration with other Divisions of Operations Group. Dated: December 2 4, 2010 Branch Operations Manual – Version 2.0 P a g e | 13 PRODUCTS SECTION 1 PRODUCTS Section Summary : This section elaborates the features and eligibility criteria of liability products and remote channels be ing offered by an MCB Branch. SECTION 1 B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 14 Chapter 1 PRODUCT FEATURES & E LIGIBILITY CRITERIA 1.1 OVERVIEW Currently MCB Branch is offering following types of accounts / banking services to its customers. Specific features and eligibility criteria of each product is elaborated in the following pages. Current Accounts 1.2 Saving Accounts 1.3 Current Account 1.2.1 Basic Banking Account 1.2.2 Current Life Account 1.2.3 Business Accoun t 1.2.4 New Foreign Currency Current Account 1.2.5 Call Deposit Receipts 1.2.6 (PLS) Savings Account 1.3.1 Smart Savin gs Account 1.3.2 365 Savings Gold Account 1.3.3 Khushali Bachat Account 1.3.4 Savings Xtra Account 1.3.5 Savings Maximizer Account 1.3.6 Salary Club Gold Account 1.3.7 365 Savings Account 1.3.8 Smart Saving Foreign Currency Account 1.3.9 New Foreign Currency Savings Account 1.3.10 Enhanced Savings Account (Discontinued ) 1.3.11 Rupee Maximizer Account (Discontinued) 1.3.12 Term Deposits 1.4 Remote Channels 1.5 Flexi Deposit Account 1.4.1 Mahana Profit Account 1.4.2 Special Foreign Currency Term Deposits 1.4.3 Special Term Deposit Receipt (Discontinued) 1.4.4 Special Notice Deposit (Discontinued) 1.4.5 Call Center 1.5.1 Auto Teller machine 1.5.2 Smart Card 1.5.3 Visa Debit Card 1.5.4 Virtual Banking 1.5.5 Mobile Banking 1.5.6 B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 15 1.2 CURRENT ACCOUNTS 1.2.1 Current Account Benefit A Non -profit bearing account with absolutely no transactional restrictions . Account A ctivation Deposit PKR 1,000 Min Balance Requirement PKR 10,000 Permissible Currency PKR Transaction Limit Unlimited withdrawals and deposits Charges as per the SOBC ATM/Debit Card Yes Virtual Banking, MCB Mobile and Call Center Available Zakat No Zakat is deducted on Current Accounts as per the Zakat & Usher Ordinance, 1980 Taxes as per applicable Government Laws Advance Tax 0.3% on all Cash withdrawals which are >25K in a single day (Under section 231AA of Income Tax Ordinance 2001) Eligibility Individuals, Firms (Sole Proprietor, Partnership), Companies (Public and Private Limited), Trust/ Clubs/ Societies and Associations B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 16 1.2.2 Basic Banking Account Benefit A Non -profit bearing account for small depositors who cannot maintain a minimum balance in their accounts and who wish to carry out the basic banking needs. Account A ctivation Deposit PKR 1000 Min Balance Requirement PKR 0 Permissible Currency PKR Transaction Limit 2 Free over the counter deposits (per month) & 2 Free over the counter withdrawals (per month) Charges as per the SOBC ATM/Debit Card Yes Virtual Banking, MCB Mobile and Call Center Available Zakat No Zakat is deducted on Current Accounts as per the Zakat & Usher Ordinance, 1980 Taxes as per applicable Government Laws Advance Tax 0.3% on all Cash withdrawals which are >25K in a single day (Under section 231AA of Income Tax Ordinance 2001) Eligibility Individuals only Limitations In case where balance in BBA remains “ZERO” for a continuous 06 month period, the account will be close d. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 17 1.2.3 Current Life Account Benefit A Non -profit bearing account with the benefi t of Free Life Insurance Cover . More the balance maintained, higher the cover Account A ctivation Deposit PKR 1000 Min Balance Requirement PKR 25,000 Permissible Currency PKR Transaction Limit Unlimited withdrawals and deposits. Charges as per the SOBC ATM/Debit Card Yes Virtual Banking, MCB Mobile and Call Center Available Zakat No Zakat is deducted on Current Accounts as per the Zakat & Usher Ordinance, 1980 Taxes as per applicable Government Laws Advance Tax 0.3% on all Cash withdrawals which are > 25K in a single day (Under section 231AA of Income Tax Ordinance 2001) Life Insurance Cover Double the amount of last three months average balance Condition: Death of the customer is Natural or Accidental At the time of death the customer's age is between 18 -60 year Given Balance does not fall below PKR 25000 on any day in the last 3 months. The maximum cover will be 1 Million PKR In case of non completion of 3 months, the number of days completed will be considered and the average of days completed will be taken Eligibility Individuals only B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 18 1.2.4 Business Account Benefit A Non -profit bearing account for Businessmen who can maintain high deposits and get waivers on PO s, DDs, Cancelations, recurring cheque books, multiple bank statements and more Account A ctivation Deposit PKR 1000 Min Balance Requirement PKR 50,000 Permissible Currency PKR Transaction Limit Unlimited withdrawals and deposits. Charges as per the SOBC ATM/Debit Card Yes (free Joining) Virtual Banking, MCB Mobile and Call Center Availabl e Zakat: No Zakat is deducted on Current Accounts as per the Zakat & Usher Ordinance, 1980 Taxes as per applicable Government Laws Advance Tax 0.3% on all Cash withdrawals which are > 25K in a single day (Under section 231AA of Income Tax Ordinance 2001) Special Features Free PO, DD, Cancellations, recurring cheque books, multiple bank statements as per the SOBC Eligibility Individuals, Firms (Sole Proprietor, Partnership), Companies (Public and Private Limited), Trust/ Clubs/ Societies and Associations B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 19 1.2.5 New Foreign Currency Current Account Benefit A Non -profit bearing Foreign Currency account with absolutely no transactional restrictions Account A ctivation Deposit USD 500 Min Balance Requirement USD 500 Permissible Currency USD / GBP / EUR/ JPY Transaction Limit Unlimited withdrawals and deposits. Charges as per the SOBC ATM/Debit Card No Virtual Banking, MCB Mobile and Call Center Not Available Zakat: No Zakat is deducted on Current Accounts as per the Zakat & Usher Ordinance, 1980 Taxes as per applicable Government Laws Advance Tax 0.3% on all Cash withdrawals which are >25K in a single day (Under section 231AA of Income Tax Ordinance 2001) Eligibility Individuals, Firms (Sole Proprietor, Partnership), Companies (Private Limited), Trust/ Clubs/ Societies and Associations 1.2.6 Call Deposit Receipt Benefit Security deposit Issued in favor of Government, Semi -Government, Institutions, Corporations, and Semi -Autonomous Bodies etc. It is also issued in favor of Individuals Profit Call Deposit does not earn any income or profit. Permissible Currency PKR Charges as per the SOBC Zakat Not applicable Eligibility Individuals, Firms (Sole Proprietor, Partnership), Companies (Private Limited), Trust/ Clubs/ Societies and Associations B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 20 1.3 SAVING ACCOUNTS 1.3.1 PLS Savings Account Benefit A plain Savings account for everyone with no transactional restrictions Account A ctivation Deposit PKR 1000 Min Balance Requirement PKR 10,000 Profit expected rate of return Profit Calculation Minimum Monthly Balance (calculation based on 365 days a year) Profit Payout Semi - Annually Permissible Currency PKR Transaction Limit Unlimited withdrawals and deposits. Charges as per the SOBC ATM/Debit Card Yes Virtual Banking, MCB Mobile and Call Center Available Zakat Zakat is deducted as per the Zakat & Usher Ordinance, 1980 Withholding Tax Withholding Tax is deducted on Profit as per the Government’s policy. Eligibility Individuals, Firms (Sole Proprietor, Partnership), Companies (Public and Private Limited), Trust/ Clubs/ Societies and Associations B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 21 1.3.2 Smart Savings Account Benefit A Savings Account offering high profit rates to depositors maintaining between 200k - 300k. This is a non checking account (No cheque book) but Smart Card is available Account A ctivation Deposit PKR 1000 Min Balance Requirement PKR 10,000 Profit Profit Upto 7% (as per the expected rate of return) Profit Calculation Minimum Monthly Balance (calculation based on 365 days a year) Profit Payout Quarterly Permissible Currency PKR Transaction Limit only via ATM (no Cheque Book) Charges as per the SOBC ATM/Debit Card Yes Virtual Banking, MCB Mobile and Call Center Available Zakat Zakat is deducted as per the Zakat & Usher Ordinance, 1980 Withholding Tax Withholding Tax is deducted on Profit as per the Government’s policy. Eligibility Individuals only B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 22 1.3.3 365 Savings Gold Account Benefit A Daily Product for high net worth customers with monthly returns and higher profit on higher deposits as well Account A ctivation Deposit PKR 1000 Min Balance Requirement PKR 500,000 Profit Profit Upto 8.25% (as per the expected rate of return) Profit Calculation Daily Ending Balance (calculation based on 365 days a year) Profit Payout Monthly Permissible Currency PKR Transaction Limit Unlimited withdrawals and deposits Charges as per the SOBC ATM/Debit Card Yes Virtual Banking, MCB Mobile and Call Center Available Zakat Zakat is deducted as per the Zakat & Usher Ordinance, 1980 Withholding Tax Withholding Tax is deducted on Profit as per the Government’s policy. Eligibility Individuals, Firms (Sole Proprietor, Partnership), Companies (Public and Private Limited), Trust/ Clubs/ Societies and Associations B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 23 1.3.4 Khushali Bachat A ccount Benefit A Daily Product for small Investors with semiannual returns and no restriction on transactions . Account A ctivation Deposit PKR 1000 Min Balance Requirement PKR 20,000 Profit 5% (as per the expected rate of return) Profit Calculation Daily Ending Balance (calculation based on 365 days a year) Profit Payout Semi - Annually Permissible Currency PKR Transaction Limit Unlimited withdrawals and deposits. Charges as per the SOBC ATM/Debit Card Yes Virtual Banking, MCB Mobile and Call Center Available Zakat Zakat is deducted as per the Zakat & Usher Ordinance, 1980 Withholding Tax Withholding Tax is deducted on Profit as per the Government’s policy. Eligibility Individuals only B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 24 1.3.5 Savings Xtra Account Benefit A product offering high rate of return: higher the deposit, higher the returns with 3 free cash withdrawals over the counter per month. Account A ctivation Deposit PKR 1,000 Min Balance Requirement PKR 100,000 Profit Profit Upto 8.5% (as per the expected rate of return) Profit Calculation Minimum Monthly Balance (calculation based on 365 days a year) Profit Payout Monthly Permissible Currency PKR Transaction Limit 3 over the counter withdrawals per month Charges as per the SOBC ATM/Debit Card Yes. Gold (free Joining) Virtual Banking, MCB Mobile and Call Center Available Zakat Zakat is deducted as per the Zakat & Usher Ordinance, 1980 Withholding Tax Withholding Tax is deducted on Profit as per the Government’s policy. Eligibility Individuals, Firms (Sole Proprietor, Partnership), Companies (Public and Private Limited), Trust/ Clubs/ Societies and Associations B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 25 1.3.6 Savings Maximizer Account Benefit Higher returns, Greater access Account A ctivation Deposit PKR 1,000 Min Balance Requirement PKR 1000,000 Profit Announced profit rate according to the defined slabs I-e less than IM, 1M to 3M, above 3M Profit Calculation Minimum Monthly Balance (calculation based on 365 days a year) Profit Payout Monthly Permissible Currency PKR Charges as per the SOBC Cheque book 10 leaf “account payee only” ONLY ATM/Debit Card Yes with higher withdrawal limit of 50,000 Virtual Banking, MCB Mobile and Call Center Available Zakat Zakat is deducted as per the Zakat & Usher Ordinance, 1980 Withholding Tax Withholding Tax is deducted on Profit as per the Government’s policy. Eligibility Individuals, Firms (Sole Proprietor, Partnership), Companies (Public and Private Limited), Trust/ Clubs/ Societies and Associations B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 26 1.3.7 Salary Club Gold Account Benefit A Payroll Account offering no minimum balance requirement and a host of free services such as PO s, DDs and more Account A ctivation Deposit PKR 10 Min Balance Requirement PKR 0 Profit 5% p.a. (as per expected rate of return) Profit Calculation Minimum Monthly Balance (calculation based on 365 days a year) Profit Payout Quarterly Permissible Currency PKR Transaction Limit Unlimited withdrawals and deposits Charges As per SOBC Note: Salaries are processed via centralized operations of Transaction Banking Division at a fixed charge per salary disbursement. If customer is unwilling to pay salary processing charges, then branch may process salaries on their own, as per existing salary disbursement process (Manually or via RB Upload) Facilities Discounts and Waivers on Cheque book (new and recurring), Demand Drafts and Pay Orders, Smart Card , Online Transactions (within a nd intercity). Free SMS alert on Salary Credit. Zakat Zakat is deducted as per the Zakat & Usher Ordinance, 1980 Withholding Tax Withholding Tax is deducted on Profit as per the Government’s policy. Eligibility Individual employees who maintain their salary account with MCB and their respective employers have signed up for the payroll account for their organization with minimum 50 salary accounts along with average salary of PKR 15K per employee Before signing o n any new company, branches are required to consult and take approval from Salary Club Product Team. Mandatory Requirements Company to sign Legal Agreement (available from Salary Club Product Team) Customer's address will always be the customer's office address (company’s office address) B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 27 1.3.8 365 Savings Account Benefit A Daily Product for Medium net worth customers with monthly returns and higher profit. Account A ctivation Deposit PKR 1000 Min Balance Requirement PKR 300,000 Profit 5% (as per the expected rate of return) Profit Calculation Daily Ending Balance (calculation based on 365 days a year) Profit Payout Semi -Annually Permissible Currency PKR Transaction Limit Unlimited withdrawals and deposits. Charges as per the SOBC ATM/Debit Card Yes Virtual Banking, MCB Mobile and Call Center Available Zakat Zakat is deducted as per the Zakat & Usher Ordinance, 1980 Withholding Tax Withholding Tax is deducted on Profit as per the Government’s policy. Eligibility Individuals, Firms (Sole Proprietor, Partnership), Companies (Public and Private Limited), Trust/ Clubs/ Societies and Associations B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 28 1.3.9 Smart Saving Foreign Currency Account Benefit A Foreign Currency Account with ease of banking in Pakistan Account A ctivation Deposit USD 500 Min Balance Requirement USD 500 Profit expected rate of return (Min. Bal. required USD 10,000/ - to qualify for Profit ) Profit Calculation Minimum Monthly Balance (calculation based on 360 days a year ) Profit Payout Semi - Annually Permissible Currency USD Transaction Limit Unlimited withdrawals and deposits. NO Smart Card Charges as per the SOBC ATM/Debit Card No Virtual Banking, MCB Mobil e and Call Center Not Available Zakat Not Applicable Withholding Tax Withholding Tax is deducted on Profit as per the Government’s policy. Eligibility Individuals, Firms (Sole Proprietor, Partnership), Companies (Public and Private Limited), Trust/ Clubs/ Societies and Associations B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 29 1.3.10 New Foreign Currency Savings Account Benefit A Foreign Currency Account with ease of banking in Pakistan Account Activation Deposit FCY 500 Min Balance Requirement FCY 500 – To avoid min. balance charges Profit expected rate of return (Min. Bal. required FCY 10,000/ - to qualify for Profit ) Profit Calculation Minimum Monthly Balance For USD: calculation based on 360 days a year For GBP/ EUR/ JPY: calculation based on 365 days a year Profit Payout Semi - Annually Permissible Currency USD / GBP / EUR/ JPY Transaction Limit Unlimited withdrawals and deposits. Charges as per the SOBC ATM/Debit Card No Virtual Banking, MCB Mobile and Call Center Not Available Special Features Waiver and discounts on Lockers, Bank Statements and Loans Zakat Not Applicable Withholding Tax Withholding Tax is deducted on Profit as per the Government’s policy. Eligibility Individuals, Firms (Sole Proprietor, Partnership), Companies (Public and Private Limited), Trust/ Clubs/ Societies and Associations B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 30 1.3.11 Enhanced Savings Account ( Discontinued ) Account A ctivation Deposit PKR 1000 Min Balance Requirement PKR 5000 Profit 5% (as per the expected rate of return) Profit Calculation Minimum Monthly Balance (calculation based on 365 days a year) Profit Payout Quarterly Permissible Currency PKR Transaction Limit Unlimited withdrawals and deposits. Charges as per the SOBC ATM/Debit Card Yes Virtual Banking, MCB Mobile and Call Center Available Zakat Zakat is deducted as per the Zakat & Usher Ordinance, 1980 Withholding Tax Withholding Tax is deducted on Profit as per the Government’s policy. Eligibility Individuals, Firms (Sole Proprietor, Partnership), Companies (Public and Private Limited), Trust/ Clubs/ Societies and Associations B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 31 1.3.12 Rupee Maximizer Account ( Discontinued ) Account A ctivation Deposit PKR 1,000 Min Balance Requirement PKR 20,000 Profit 5% (as per the expected rate of return) Profit Calculation Daily Ending Balance (calculation based on 365 days a year) Profit Payout Semi Annually Permissible Currency PKR Transaction Limit Unlimited withdrawals and deposits. Charges as per the SOBC ATM/Debit Card Yes Virtual Banking, MCB Mobile and Call Center Available Zakat Zakat is deducted as per the Zakat & Usher Ordinance, 1980 Withholding Tax Withholding Tax is deducted on Profit as per the Government’s policy. Eligibility Individuals, Firms (Sole Proprietor, Partnership), Companies (Public and Private Limited), Trust/ Clubs/ Societies and Associations Note: All Saving accounts as discussed above are Profit bearing accounts. Branch must ensur e to educate the customer on all features. In -case customer’s need necessitates a non -profit bearing product; he/she should open a current account. Saving accounts cannot be mis -constituted/ operated as Non -Profit bearing account. In -case the customer carry’s a Saving Account and wants to shift to Current Account, a New Current account will be opened. This clarification is being provided explicitly as few cases have been reported in the past where branches forcefully convert Savings accounts into Current A ccounts by changing ‘Interest Parameters’ in the system which is strictly prohibited . B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 32 1.4 TERM DEPOSITS 1.4.1 Flexi Deposit Account Min Deposit Requirement PKR 500,000 Profit expected rate of return Profit Calculation Based on 365 days a year Permissible Currency PKR Tenors Available 1 month, 2 months, 3 months, 6 months, 9 months, 1 year, 2 years, 3 years and 5 years Profit Payment Options Quarterly, Semi Annually, Annually and Maturity. Charges as per the SOBC Zakat Zakat is deducted as per the Zakat & Usher Ordinance, 1980 Withholding Tax Withholding Tax is deducted on Profit as per the Government’s policy. Eligibility (Existing Account Holders) Individuals, Firms and Companies. It is a mandatory requirement for booking a Term Deposit to have a checking account (Current/Savings) in the Bank. 1.4.2 Mahana Profit Account Min Deposit Requirement PKR 500,000 Profit expected rate of return Profit Calculation Based on 365 days a year Permissible Currency PKR Tenors Available 2 months, 3 months, 6 months, 9 months, 1 year, 2 years, 3 years and 5 years Profit Payment Monthly Charges as per the SOBC Zakat Zakat is deducted as per the Zakat & Usher Ordinance, 1980 Withholding Tax Withholding Tax is deducted on Profit as per the Government’s policy. Eligibility (Existing Account Holders) Individuals, Firms and Companies. It is a mandatory requirement for booking a Term Deposit to have a checking account (Current/Savings) in the Bank. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 33 1.4.3 Special Foreign Currency Term Deposit - SFTD Tenor Options 3 Months, 6 Months & 1 year Fixed Deposits Min Deposit Requirement USD 10,000 Profit expected rate of return Profit Calculation Based on 360 days a year Profit Pay Out Criteria Minimum retent ion period is 01 month . Cash payment of Interest amount is not allowed Profit Payment Options On Maturity for 3 & 6 months and Semi Annually for 1year booking Permissible Currency USD Charges as per the SOBC Privileges Free of charge Locker and bank statement 50% Discount on Processing charges of Personal Loan and Car Loan Zakat Not Applicable Withholding Tax Withholding Tax is deducted on Profit as per the Government’s policy. Eligibility (Existing Account Holders) Individuals, Firms and Companies. It is a mandatory requirement for booking a Term Deposit to have a checking account (Current/Savings) in the Bank. 1.4.4 Special Term Deposit Receipt – STDR (Discontinued) Min Deposit Requirement PKR 100,000 Profit expected rate of return Profit Calculation Based on 365 days a year Tenors Available 3 months, 6 months, 1 year, 3 years and 5 years Profit Payment Options On Maturity for 3 & 6 months and Quarterly for 1, 3 & 5 year booking Permissible Currency PKR Charges as per the SOBC Zakat Zakat is deducted as per the Zakat & Usher Ordinance, 1980 Withholding Tax Withholding Tax is deducted on Profit as per the Government’s policy. Eligibility (Existing Account Holders) Individuals, Firms and Companies. It is a mandatory requirement for booking a Term Deposit to have a checking account (Current/Savings) in the Bank. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 34 1.4.5 Special Notice Deposits - SND (Discontinued) Options 7 days and 30 days Min Deposit Requirement PKR 500,000 Profit expected rate of return Profit Calculation Based on 365 days a year Profit Pay Out Criteria If encashed AF TER 7 days (both 7 and 30 days SN D) Profit Payment Options Maturity Permissible Currency PKR Charges as per the SOBC Zakat Zakat is deducted as per the Zakat & Usher Ordinance, 1980 Withholding Tax Withholding Tax is deducted on Profit as per the Government’s policy. Special Notes If a depositor withdraws deposit on a date prior to the date of declaration of profit rates, the profit due can be paid at the rate of profit declared for the last half year. This, however, shall be a provisional payment with the prior approval of Regional Head . If the rate declared for said half year is more than what was paid to such deposit holders then the difference shall be paid through Payment Order. In case rate of profit announced on Special Notice Deposit is less, then cust omer should pay the difference. It will be appropriate if an undertaking from the customer is taken in this respect. Eligibility (Existing Account Holders) Individuals, Firms and Companies. It is a mandatory requirement for booking a Term Deposit to have a checking account (Current/Savings) in the Bank. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 35 1.5 REMOTE CHANNELS 1.5.1 Call Center Features i. MCB Mobile Registration/Activation/De registration ii. Virtual Banking Activation/Blocking iii. Debit Card Activation/Blocking iv. Internal Funds Transfer v. Utility Bill Payments vi. Mobile Postpaid Bill Payments/Top ups vii. Credit Card Bill Payments viii. TPIN Maintenance/Issuance Eligibility All customers having singly operated accounts in MCB Bank Limited Charges as per the SOBC 1.5.2 ATM Features i. Fast Cash ii. Cash Withdrawal iii. Funds Transfer from one registered account to another iv. Mobile Banking Registration v. Virtual Banking Registration vi. Utility Bill Payments vii. Mobile Bill Payments viii. Mini Statement ix. Balance Inquiry x. MCB ATM/Smart Card PIN Change xi. Block Smart Card xii. PIN Reset for MCB Mobile users xiii. IDP Relief Fund Collection xiv. Credit Card Cash Advance transaction Eligibility Any customers having MCB Smart Card/Credit Card/Prepaid Card or any other banks account holder having Debit/Credit Card with M-NET/1 -LINK/Cirrus/Maestro/VISA logo can utilize the ATM machine Charges as per the SOBC B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 36 1.5.3 Smart Card Features i. Secure and convenient deposit access instrument for payments ii. 24 hour access to deposit account iii. Bill payments iv. Cash withdrawals v. Fund transfers vi. Statement Requests vii. Utility Bill Payments viii. Account enquires ix. MCB remote banking channels registration through remote banking channels Acceptability Locally : accepted at over 4,000 M -Net & 1 -Link ATMs Internationally : Cirrus & Maestro supported ATM & POS Eligibility ONLY one Smart Card can be issued against one account. All CASA holders are eligible for MCB Smart Card with exception to the following: i. FCY accounts ii. Jointly operated account iii. Photo accounts iv. NRP accounts (Non -Resident Pakistanis) – Ref: SBP Cir cular # 10 of 2004 Categories Categories Daily Withdrawal Limit Daily POS Limit International Gold 25,000 150,000 International Classic 15,000 100,000 Saving Maximizer* 50,000 250,000 Salary Club* 25,000 150,000 Privilege* 50,000 250,000 * These cards are only issued against their respective account types Charges as per the SOBC B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 37 1.5.4 Pre-paid Visa Card Benefits A Prepaid Card is pre -funded reload -able card that is easy to use and is safer than cash. Operating in a similar fashion to debit card accounts, but with greater flexibility and lesser risk. Visa prepaid cards can be used to access previously deposited fun ds in a Prepaid account. The funds in the account may be spent by the cardholder through purchase transactions or cash withdrawals. Acceptability MCB VISA Prepaid Card can be used to withdraw cash, shop, dine, fuel and make online payments locally and in ternationally at more than 29 Million outlets including 35000 local merchants in 160 countries worldwide. Each purchase is debited directly from your card balance, making it easy for you to be Cash free. Travel Insurance Avail free travel inconvenience insurance coverage on your card. Travel inconvenience Insurance Coverage Delay of Flight (exceeding 06 hours) PKR 15,000 Delay of Baggage (exceeding 06 hours) PKR 15,000 Loss/Damage to Baggage PKR 30,000 Annual Aggregate Limit PKR 3,000,000 Note: Travel insurance coverage only available on the Freedom Package. Cash accessibility The Card can be used over more than 450+ MCB, 4000+ M -Net and 1 -Link ATMs nationwide. The card is also accepted at over 1 million VISA ATMs around the world. E-statement & SMS View Card transactions free of cost, directly through your email. Get an SMS alert as a receipt, every time card is used MCB VISA McDonald’s Co-brand Card Upsize every regular meal free of cost every time card is swiped at McDonald’s Card Limits As per Policy & Product Program Charges as per the SOBC Eligibility Prepaid Card issuance is based on the providing following mandatory requirements. Copy of CNIC is mandatory requirement which is acceptable after original seen. Source of Income is mandatory (to fill up in the Application Form in the section “ For Branch Use ”.) B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 38 1.5.5 Virtual Banking Features i. Detailed Account Summary of all listed accounts. ii. Mini -statements/ Statement -by-Period iii. Transfer of Funds iv. Scheduled Payments v. Payment of utility bills, credit card bills vi. Donations vii. Bulk Salary Tr ansfer for Corporate Customers viii. Cheque Book Request ix. Personal Alerts x. Buy Internet Hours xi. Mobile Recharge facility for all mobile companies xii. Purchase Mutual Funds & Stocks Eligibility The customer must have an MCB ATM Smart Card (not mandatory for abroad and corporate customers) Charges as per the SOBC B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 39 1.5.6 Mobile Banking Features i. Non Financial ii. Do a Balance Inquiry iii. View Mini -Statement iv. Turn your Smart Card off ( card will activate after EOD) v. Receive Transaction Alerts via Push SMS vi. Add/Remove Frequent Payees vii. Financial viii. Make Uti lity Bill payments for KESC ,HE SCO ,IESCO, SSGC, SNGPL & PTCL ix. Make MCB VISA Credit card bill payments x. Transfer funds to any MCB Account xi. Buy Mobile pre -paid top ups for all Telecom companies xii. Make a Mobile po st paid bill payment for Telecom companies xiii. Make donations xiv. Purchase Insurance Eligibility i. MCB Account Holder ii. Active ATM/Smart Card iii. Cell Phone Number iv. Customer data registered at call center Charges as per the SOBC Mobile Limit i. 10 financial transaction in a single day ii. Financial transactions limited to PKR 100,000 per day. (credit card payment do not fall under limits) B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 40 ACCOUNT OPENING AND MAINTANENCE SECTION 2 ACCOUNT OPENING Section Summary: This section encompasses Account O pening documentation , KYC, Account Opening Process flows, G eneral policies & guidelines , Symbols Account/ Service/ Restraint / Currency and Interest types. Account Operating Instruc tions for all kinds of accounts are detailed. Classification of accounts covering instructions on dormancy and Inoperative accounts and its related processes are documented. Additional to the above, Cheque Book Management, Term Deposits, KYC and Zakat Dedu ction/ Reporting are detailed in this section . SECTION 2 B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 41 Chapter 1 ACCOUNT OPENING DOCU MENTATION & GENERAL POLIC IES 1.1 DOCUMENTATION REQUIR EMENT The details of required documents to be obtained for opening of different ty pes of accounts are as follows: 1.1.1 Individuals Accounts i. Duly filled Account Opening Application ii. Specimen Signature Card ( SF-6A2A2 ). iii. Photocopy of Computerized National Identity Card (CNIC) or copy of Passport of the individual attested by BM or BOM or Designated Authorized Officer of the bank. ( When copy of CNIC/Passport is attested by the authorized officer of the bank he/she must affix the stamp “Original Seen” along with AS/IBS number under his seal and signature). iv. CNIC of the individual must also be verified through NADRA on -line VeriS ys System. v. In case the CNIC does not contain a photograph, the bank in addition to CNIC, should also obtain any other document such as driving license etc. that contains a photograph. However, if the individual does not have any other valid document which bears photograph following documents should be obtained:  A copy of the photograph duly attest ed by gazetted officer or Nazim  A copy of CNIC without photograph duly attested by the same person who attested the copy of photograph as per above. ( Ensure that t he CNIC and the photograph are of the same person whose account is being opened.)  A confirmation in writing to the effect that the individual have no other document bearing photograph. vi. In case of a salaried person, attested copy of his/her service card / salary slip or any other acceptable evidence of service, including but not limited to a certificate from the employer. vii. In case of non -salaried/un -employed individual, KYC should be conducted with extra vigilance and source of income/ funds should be validate d prudently. viii. In case of illiterate person, a passport size photograph of the new account holder besides taking Left and Right thumb impression s on the account opening application & Specimen Signature Card (SSC) . ix. In case of a customer with shaky signatures the account should be opened as ‘Photo Account’ . All cheque withdrawals are in physical presence of customer. x. In case the signatures mismatch with CNIC, undertaking as per Annexure XXII to be obtained from him/her. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 42 1.1.2 Sole Trader / Proprietorship Bank should exercise extra care in view of the fact that constituent documents are not available in such cases to confirm existence or otherwise of the proprietorships. All efforts should be made to obtain Relevant document(s) in o rder to establish the existence of the sole trad er / proprietorship concern. F ollowing documents must be obtained: i. Duly filled Account Opening Application ii. Specimen Signature Card ( SF-6A2A2 ). iii. Copy of CNIC or Passport of the individual attested by an officer of the bank. (Authorized officer of the bank must affix the stamp “Original Seen” along with AS/IBS number under his seal and signature). iv. CNIC must also be verified through NADRA on -line VeriSys. v. In case CNIC does not contain a photograph, the bank in add ition to CNIC, should also obtain any other document such as driving license etc. that contains a photograph. However, if the individual does not have any other valid document which bears photograph following documents should be obtained:  Photograph duly a ttested by gazetted officer or Nazim.  Copy of CNIC with photograph duly attested by the same person who attested the photograph as per above. (Ensure that the CNIC and the photograph are of the same person whose account is being opened).  A confirmation in writing to the effect that the individual have no other document bearing photograph. vi. In case of illiterate person, a passport size photograph of the new account holder besides taking Left and Right thumb impression s on the account opening application & Spe cimen Signature Card (SSC) . vii. In case of a customer with shaky signatures the account should be opened as ‘Photo Account’ . All cheque withdrawals are in physical presence of customer. viii. In case the signatures mismatch with CNIC, undertaking as per Annexure XXII to be obtained from him/her. 1.1.3 Partnership Account i. Duly filled Account Opening Application ii. Specimen Signature Card ( SF-6A2). iii. Copy of CNIC of all the Partners attested by an officer of the bank. (Authorized officer of the bank must affix the stamp “Original Seen” along with AS/IBS number under his seal and signature). iv. CNIC of all the Partners must also be verified through NADRA o n-line VeriSys System. v. Attested copy of “Partnership Deed” duly signed by all partners of the firm. vi. Attested copy of Registration Certificate with Registrar of Firms. In case the partnership is unregistered, this fact should be clearly mentioned on the Acc ount Opening Form. vii. Authority letter in original, in favor of the person authorized to operate the account of the firm duly signed by all partners. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 43 1.1.4 Companies registered under companies ordinance 1984 i. Duly filled Account Opening Application ii. Specimen Signature Card ( SF-6A2) iii. Resolution of Board of Directors for opening of account specifying the person(s) authorized to operate the company account (Duly Signed by all Directors OR Company S ecretary along with One D irector) and company seal affixed however the signatories on Board of R esolution for opening an account shall be governed by Authorities spelled out in the M emorandum & Articles of Association. iv. Certification of the following documents by Company Secretary/ Notary Public :  Memorandum and Articles of Association  Certificate of Incorporation.  Certific ate of Commencement of Business (not required for Private Ltd companies)  Latest List of Directors on Form 29 issued by the Registrar SECP. v. Copies of CNIC of all the Directors verified through NADRA Online VeriSys and attested by an officer of the bank. Note : Authorized officer of the bank must see the Original documents and affix the stamp “Original Seen ” along with AS/IBS number under his seal and signature before placing the copies in record In case of Companies of Foreign Origin: The condition of obtaining Board Resolution and Certificate of Commencement of Business for opening bank account has been relaxed for only such foreign companies/entities belonging to countries where said requirements are not enforced under their laws/regulations. However such foreign companies will have to furnish the following documents in lieu of resolution passed by BOD for opening of account and Certificate of Commencement of Business to the satisfaction of the bank: i. Power of Attorney from the competent authority duly notarized for opening bank account. ii. A certificate from the company secretary, duly authorized by the Board, clearly stating that the company/ entity started its business from certain date and that Certificate of Commencement of Business is not issued in that country. iii. Approval to open branch/office in Pakistan from concerned departments of Government of Pakistan. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 44 1.1.5 Clubs, Societies & Associations i. Duly filled Account Opening Application ii. Specimen Signature Card ( SF-6A2). Certified copies of:  Certificate of Registration issued by the Registrar of Co -operative Societies/ Registration Authority.  Bye-Laws/ Memorandum & Articles of Association of the Society containing official seal of the Registration Authority on each page thereof. iii. Resolution of the Governing Body/Executive Committee for opening of Account authorizing the person(s) to operate the account and attested copy on CNIC of the authorized person(s). ( It must be ensured that the m andate for operations of account given in the resolution is not in violation of the provision of by -laws/memorandum & articles of associations) . iv. List of the members of the Managing Committee duly certified by the Registrar of Co -operative Societies. v. Permis sion of the Registrar of Co -operative Societies for opening of account in the name of society is required under Section 37 (d) of Co -operative Societies Act 1925. vi. In case of Associations, permission of the Registration Authority for opening of account in t he name of Association as required under Section 7 © of Voluntary Social Welfare (Registration & Control) Ordinance 1961. vii. An undertaking signed by all the authorized persons on behalf of the institution mentioning that when any change takes place in the p ersons authorized to operate on the account, the banker will be informed immediately. viii. Bank should obtain copies of CNICs of all the members of Governing and Executive Bodies of DHA etc, or ask for delegation of power to Administrator under section (7) & (8 ) of the Pakistan Defense Housing Authority Order, 1980 and accept copy of CNIC of Administrator as well as authorized signatories for the purpose of opening accounts of DHA or similar other authorities subject to the condition that all other requirements laid down under PR -M1 shall be complied with in letter and spirit. ix. CNIC must also be verified through NADRA on -line VeriSys System. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 45 1.1.6 Agents Accounts i. Duly filled Account Opening Application ii. Specimen Signature Card ( SF-6A2). iii. Certified copy of “Power of Attorney” iv. Copy of CNIC of the Agent attested by an officer of the bank. (Authorized officer of the bank must affix the stamp “Original Seen” along with AS/IBS number under his seal and signature). v. CNIC of the Agent must also be verified through NADRA on -line VeriSys System. 1.1.7 Executors and Administration i. Duly filled Account Opening Application ii. Specimen Signature Card ( SF-6A2). iii. Photocopy of Computerized National Identity Card (CNIC) of all the Executor/Administrator attested by an officer of the bank. (W hen copy of CNIC is attested by the authorized officer of the bank he must affix the stamp “Original Seen” under his seal and signature). iv. CNIC of the Executor/Administrator must also be verified through NADRA on -line VeriSys System. v. Certified copies of Letter of Administration or Probate. 1.1.8 Trust Accounts i. Duly filled Account Opening Application ii. Specimen Signature Card ( SF-6A2). iii. Certified copy of Registered Instrument of Trust OR Trust Deed by Registrar of Trust. please check purpose, source of funds and dissolution clause of the trust (Requirement for obtaining ‘Certificate of Registration’ for trust account has been abolished vide SBP Circular Letter No. 10 of 2007 & BPRD/BLRD -09/2010 -872 dated Feb 06, 2010). iv. Resolution duly passed by the Trustees regarding opening and operation of Account in the Bank in the name of Trust. It must be ensured that mandate for operation of account given in the resolution is not in violation of the provision of Trust Deed. v. Copy of CNIC of all the Trustees attested by an officer of the bank. (Authorized officer of the bank must affix the stamp “Original Seen” along with AS/IBS number under his seal and signature). vi. CNIC of the Trustees must also be verified through NADRA on -line VeriSys System. vii. List of Trustees duly certified at least by two Trustees should be obtained. viii. Certified copies of Letter of Administration/ Instrument of Trust or Trust Deed. Bank may open accounts of Trust covered under secti on 227 of Companies Ordinance 1984 including Provident Fund, Gratuity Fund and Pension Fund after obtaining evidence of registration with any Government Authority. Branch Manager has to ensure that the opening of Trust Account and subsequent operation in t he account is in accordance with the spirit of KYC, Customer Due Diligence (CDD) and other Money Laundering/Combating Financing of terrorism (AML/CFT) safeguards. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 46 1.1.9 Minor Accounts - (Age below:18) A Minor is a person who has not attained the age of 18 years, if the Court appoints guardian of his/her person or property, then the period of his minority extends to the age of 21. i. Duly filled Account Opening Application ii. An account in the name of minor is allowed to o pen by his guardian, jointly in the name o f guardian and Minor, payable to either or survivor opener of the Account. iii. Title of Account is on the Minor’s Name (As per Form –B) & word “Minor” be added to the Title of Account. iv. Account/Client must be opened by using the CNIC No. of the Minor which is p rovided in the Form B v. In the Account Opening Application, the particulars of the Guardian will be filled out in the column of “Personal Information”. vi. Photocopy of Computerized National Identity Card (CNIC) of the Guardian attested by an officer of the bank. (When copy of CNIC is attested by the authorized officer of the bank he must affix the stamp “Original Seen” along with AS/IBS number under his seal/ signature). vii. CNIC of the Guardian must also be verified through NADRA on -line VeriSys System. viii. Attested p hotocopy of Form -B of Minor. 1.1.10 Illiterate / Disable/ Blind Persons / Photo Accounts i. Duly filled Account Opening Application ii. Specimen Signature Card ( SF-6A2). iii. Photocopy of Computerized National Identity Card (CNIC) of the individual attested by an officer of the bank. ( Authorized officer of the bank must affix the stamp “Original Seen” along with AS/IBS number under his seal and signature). iv. CNIC of the individual must also be verified through NADRA on -line VeriSys System. v. Two passport size attested Photographs. (One photograph shall be pasted on the Account Opening Form and the other one will be pasted on Specimen Signature Card. vi. Left and Right thumb impression s on the account opening application & Specimen Signature Card (SSC). vii. In case of a customer with shaky signatures the account should be opened as ‘Photo Account’ . All cheque withdrawals are in physical presence of customer. 1.1.11 Government Accounts It must be ensured that government accounts are not opened in the personal names of the government official(s). Any such account, which is to be operated by an officer of the Federal/Provincial/Local Government in his/her official capacity, shall be opened only on production of a special resolution/authority from the concerned administrative department duly endorsed by the Ministry of Finance or Finance Department of the concerned provincial or Local Government. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 47 1.1.12 MCB Employee Salary Accounts i. Duly filled Account Opening Application ii. Specimen Signature Card ( SF-6A2). iii. Copy of CNIC or copy of Passport of the individual attested by BM or BOM or Authorized Officer of the bank. ( Authorized officer of the bank must affix the stamp “Original Seen” alon g with AS/IBS number under his seal and signature). CNIC of the individual must also be verified through NADRA on -line VeriSys System. iv. Request email/ letter from the Manager or Unit or Department head v. Accounts for MCB Employee & Spouse & MCB retired staff that is getting pension will be opened under “STF” client type whereas employees of Outsourced companies will be opened under “OSS” client type. 1.1.13 Non -Resident Accounts Obtain following additional documents along with the documents mentioned for opening an individual account: i. Copy of Passport 1st 4 pages . ii. Copy of the page of the passport where last -entry into Pakistan was stamped . iii. Copy of Valid Visa of Pakistan for foreigners . iv. Copy of Valid Visa of the relevant country for Non -Resident Pakistanis . v. Copy of “ Work Permit” or “Employer Certificate” or “Employer Card” . vi. Written request to open an account which clearly states that he/she is a foreign national and purposes of account opening. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 48 1.2 SYMBOLS ACCOUNT TYPES, CURRE NCY, SERVICE TYPES & INTREST TYPES Following are the Symbol Account Types, allowed Currency and Default Service Types for all Products. All branches are advised to ensure strict adherence while opening accounts in SYMBOLS. Current Accounts Symbols A/C Type Allowed Currency Default Service Type Applicable Interest Type i. Current Account CUR PKR SVC Not Applicable ii. Basic Banking Account BBA PKR N/A Not Applicable iii. Current Life Account LIF PKR SVL Not Applicable iv. Business Account BUS PKR SVB Not Applicable v. New Foreign Currency Current Account NFC USD / GBP / EUR / JPY SVC Not Applicable vi. Collection Accounts CCA PKR N/A Not Applicable vii. Call Deposit Receipts Manual Issued PKR N/A Not Applicable viii. FCY Current Account CUR Discontinued - Not offered to Customers Saving Accounts Symbols A/C Type Allowed Currency Default Service Type Applicable Interest Type i. (PLS) Savings Account PLS PKR SVP PLS ii. Smart Savings Account SSA PKR SVP SSA iii. 365 Savings Gold Account GLD PKR SVG GLD iv. Khushali Bachat Account KBA PKR SVK KBA v. Savings Xtra Account MSX PKR SVX MSX vi. Salary Club Gold Account MEA PKR N/A MEA vii. Savings Maximizer Account MSM PKR SVP MSM viii. New Foreign Currency Savings Account NFS USD/ GBP/ EUR / JPY SVP NFS ix. Smart Saving Foreign Currency Account SSF USD SVP SSF x. 365 Savings Account 365 PKR SVM 365 xi. Enhanced Savings Account ESA Discontinued - Not offered to Customers xii. Rupee Maximizer Account RMA Discontinued - Not offered to Customers xiii. Dollar Khushali Bachat Account KBF Discontinued - Not offered to Customers xiv. PLS FCY Saving Account PLS Discontinued - Not offered to Customers Term Deposits Symbols A/C Type Allowed Currency Default Service Type Applicable Interest Type i. Flexi Deposit Account (FDA) F1M PKR N/A FDA F1Y PKR N/A FDY F2M PKR N/A FDA F2Y PKR N/A FDY F3M PKR N/A FDA F3Y PKR N/A FDY F5Y PKR N/A FDY F6M PKR N/A FDA F9M PKR N/A FDA FHD PKR N/A FDD ii. Mahana Profit Account (MPA) 1MY PKR N/A FDY 2MM PKR N/A FDA 2MY PKR N/A FDY 3MM PKR N/A FDA 3MY PKR N/A FDY 5MY PKR N/A FDY 6MM PKR N/A FDA 9MM PKR N/A FDA iii. Smart Foreign Currency Term Deposits (SFTD) Manually booked USD N/A N/A iv. Special Notice Deposit (SND) Manually booked Discontinued - Not offered to Customers v. Term deposit Receipts (TDR) Manually booked Discontinued - Not offered to Customers vi. Special Term Deposit Receipt (STDR) Manually booked Discontinued - Not offered to Customers vii. Fixed Deposit - FCY Manually booked Discontinued - Not offered to Customers B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 49 1.3 ACCOUNT ACTIVATION D EPOSIT Account Activation Deposit can be accepted in cash or as a cross cheque from the customer once account is opened i.e., account number is generated and communicated to the customer. Cheques may only be accepted as part of Account activation deposit in case of undoubted parties and on the personal responsibility of Branch Managers. In all such cases, the cheque must be crossed by the customer before being lodged for clearing / collecti on. If cheque is deposited before the account number is generated it will be kept in safe custody under dual control. In case the cheque is returned unpaid it is the responsibility of the Branch Manager to re -conduct the KYC and ensure activation deposit i s made in the account. Above requirement applies across the board unless approved otherwise by the competent authority in the Product Program for specific products 1.4 COMPUTERIZED NATIONA L IDENTIFICA TION CARD (CNIC) /ONLINE VERIFICATION / VALIDATION i. Valid CN IC of the customer and its on -line verification from NADRA’s VeriSys system is one of the prerequisite for new account opening and must be strictly followed. To evidence that the verification of CNIC was performed branches are required to print copies of c ustomer’s CNIC from VeriSys system and retain the same with account opening forms. Ensure CNIC verification through NADRA Online VeriSys BEFORE opening of account/ establishment of any relationship. ii. In case where the customer do not have a ‘valid’ CNIC the bank may open the account on the basis of expired CNIC and a receipt issued by NADRA evidencing that customer has applied for renewal of his CNIC along with an undertaking in writing stating that the valid CNIC will be submitted within 15 days of the issu ance of CNI C as evidenced by the receipt. Further, in case of ‘registered aliens’ who wish to open a bank account in Pakistan in Pak Rupee, the bank may accept a copy of valid ‘Alien Registration Card’ issued by National Aliens Registration Authority (NARA ) instead of CNIC. Likewise, bank may also accept copy of National Identity Card for Overseas Pakistani (NICOP) & Pakistan Origin Card (POC) issued by NADRA in lieu of CNIC for opening of account in Pak Rupee or Foreign Currency (same verification process applies as for CNIC). Proof of Registration (PoR) issued by NADRA to Afghan Refugees is not acceptable for opening of account. Note: if the account is Opened with expired CNIC and hence on basis of receipt issued by NADRA, it is prime responsibility of the Branch Manager/ Operations Manager to keep close liaison with the customer and update the CNIC number in the system/ bank records as soon as the customer gets his new CNIC. In -case the customer is unable to furnish the same within 30 days , BM/ BOM should immediately block the account for any further withdrawal activities (irrespective of the mode of payment) and mark restraint type ‘STW’ to the account . iii. While opening the account Authori zed Officer should check that customer address provided on Account Opening Form (AOF) is the same as given on CNIC. In case the address given on AOF is different from the one given on CNIC, proper justification /documentary evidence should be obtained from the customer. Documentary evidence could be a copy of the Utility bill OR Original Registration of the new residence . In case of rental residence, lease / tenancy agreement OR a letter from the landlord along with Landlord NIC/ Utility bill stating that t he person wishes to open the account lives in his or her property as a tenant etc. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 50 iv. Branches will not recover “CNIC verification charges” from their accountholders and/or prospective customers. The verification of CNIC is not a direct service to the customers rather it is an effort of the bank towards mitigation of its own risk. v. All the documents mentione d above MUST be seen in original by an authorized officer of the bank. After seeing the original documents the authorized officer will affix a rubber stamp on its copies saying “Original seen & copy attested” along with AS/IBS number under his/her si gnatur e/stamp. vi. While opening the account Authorized Officer should check that customer Signature provided on Account Opening Form (AOF) is the same as per CNIC. Incase Signatures differ; an undertaking of the fact mus t be obtained from the customer as per Annexure XXII Note: NADRA Verification facility is meant to be used strictly for bank’s internal operations / purpose as prescribed by the bank / regulations it should not be used for any other purposes and any such verification pri nt out to remain with banks record. In case of misuse it is a clear violation of VeriSys service agreement with NADRA. Guidelines for E xisting Customers with In-Valid NIC: SBP had given the final opportunity to banks for regularizing accounts without CNIC up to Dec 31, 2009 . Upon expiry of this deadline bank is required to adopt the following procedure : (BPRD Circular letter No. 30 of 2009)  Inform its customers through print a nd electronic media that upon expiry of extended deadline of Dec 31, 2009 accounts without CNIC will be blocked for all debit transactions/ withdrawals, irrespective of mode of payment until subject regulatory requirement is fulfilled.  Debit block option s hould be exercised after one month prior notice is served upon to such customers who have not submitted copies of their CNICs. Remove the debit block from the accounts upon submission of copy of CNIC.  Remove the debit block from accounts upon submission o f copy of CNIC. In light of the above regulation from SBP, BM/ BOM can exercise debit Block option; restraint type “STW” to block withdrawal from customer’s account Note: As per BPRD Circular letter # 32 of 2010 dated 22 -dec, 2010, Credit Transactions are allowed in accounts where Bank/ DFI does not have latest attested copy of CNIC. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 51 1.5 CLEARANCE OF ACCOUNT HOLDER’S NAME FROM U N/ OFAC / BOE/ EU / OTHER LISTS UN: Al-Qaida & Taliban List of United Nations OFAC: List from Office of Foreign Asset Control BOE: Sanctions List from Bank of England EU: Sanctions List from European Union i. Another prerequisite for opening of customer account is to check and get clearance of account holder name from UN / OFAC / BOE/ EU and other lists for Black listed names . These lis ts are updated and sent to branches by Compliance Group (CCG) from time to time; also is available at from MCB Intranet Portal  Compliance  Compliance Library  SDN Lists ii. Branch Manager (or BOM in absence of BM) should notify on AOF “NAME CLEARED FROM UN/OFAC / BOE/ EU LISTS” along with AS/IB S number under his signature. iii. In case of any positive match the query should be sent to Compliance under a copy to respective GM for further check and necessary action. 1.6 EXEMPTION FOR SE NIOR CITIZENS TO OPE N AN A /C AGAINST EXPIRED CNIC For senior citizen having age of 65 years or above Central Bank has allowed banks to open an account on the basis of expired CNIC . This change in the policy is based on the fact that NADRA has provided a relaxation to the senior citizens from renewing their CNICs after attai ning the age of 65 years or above. (Refer SBP circular BPRD/BLRD -09/2009 -3857 dated June 09, 2009). 1.7 OPENING OF CONSUMER CUSTOMER’S COLLECTIO N ACCOUNT (CCA) i. Opening of CCA accounts is to be handled by Consumer Asset Operations and NOT Branches. ii. The purpos e of such accounts (CCA) is to collect Customer Consumer Loan Periodic Installments iii. All CCA accounts will be a non -checking account where no cheque book and ATM will be issued and no minimum balance and/or service charges will be applicable and no dormancy should be placed to this account iv. Once account is opened by a nd regularized by Consumer Sales Staff and Consumer Asset Operations , all documents will be sent to nominated branches (as under) for their record . Central North South Lahore : Allama Iqbal Town Faisalabad : People’s Colony Sialkot : Trunk Bazar Gujranwala : Model Town Multan : Mall Plaza, Cantt. Rawalpindi: Murree Road Islamabad: Super Market Karachi : Gulistan -E-Joher Hyderabad : Latifabad No.8 B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 52 1.8 RESTRAINT TYPES The following Restraint Types can be used by Branches. BMs/ BOMs are advised to mark the correct restraint type according to the need. No other restraints other than the ones given bel ow are to be used by branches. Type SYMBOLS SYSTEM DESCRIPTION Purpose/ Instructions AAD Account Activity - Deseized To restrict account transaction forcefully e.g. In case of a customer's death. As a precaution, Branch should amend Customer's name in the System and add "Deceased" after the name. In -Case of" AAD" is marked; Service Type ZAK mu st be removed from the account. AAS Account Activity - Seize To block the account ’s financial transactions on the request of customer OR instructions of Court Or any other Competent Authority. It is Mandatory to record the details in the Narration field in the system. ASC Account Seize Consumer To block the account activity with regard to Consumer Product Operations BSW BSA Stopped Activity To stop Withdrawal from Business Sarmaya A/c CLA Classified Accounts To mark classification on Loan accounts CNI Computerized NIC Update This is an Informatory Restraint. Provide information about Customer CNIC Expiry. Computerized NIC need to be updated in the account EPZ EPZ Branch Account This is an Informatory Restraint. Provide information that this is an "EPZ Branch account". This restraint should be used by EPZ Branch Only. CMD CMD Corporate Clients Provide Information about CMD customers. CSH Cash Only To restrict customer to Cash transactions ONLY EUN Exempted Unclaimed Account This is an Informatory Restraint. Provide information about exemption of an account from being marked as 'unclaimed' EWT Exempted Withholding Tax This is an Informatory Restraint. Provide information about an account being Exempted from W/H Tax FOH Funds -On-Hold In case of Garnishee Order/ Legal or investigation cases, Funds can be restricted on amount. STW Stop Withdrawal To Stop Withdrawal in an account due to any specific reason mentioned by branch e.g. documentation issues (specially Expired CNIC) , customer requests etc PRB Charges Waived PO/DD/TT/etc. This is an Informatory Restraint. Provide information about waiver of Service charges on a particular product/ account as per SOBC SCB Stop Cheque – BT To Stop particular Cheque(s) for payment in BT STC Stop Cheque To Stop particular Cheque(s) for payment in EOC SDA Stop Any Deposit To Account To Stop deposit in any particular account on special instructions STA Staff Account This is an Informatory Restraint. Provide information about a staff account TZA Zakat Applicable On TDA This is an Informatory Restraint. Provide Information about Zakat applicability on TD. WAU Whereabouts Unknown This is an Informatory Restraint. Provide information about return of "Letter of Thanks/ Bi -annual statement/ any other correspondence" and that the customer address is incorrect. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 53 1.9 EXEMPTION OF SERVICE CHARGES i. Accounts maintained by Employees of Government /Semi Government institutions for Salary, Pension & Benevolent Fund purpose including widows/children of deceased employees eligible for family pension / benevolent fund grant etc. in any manner whatsoever. ii. Accounts opened and maintained by School Management Committees (SMCs) duly constituted by Education Department, Government Sindh shall not be transferred/flagged a s “Dormant” and shall be exempted from levy of ‘Service Charges’ on account of non maintenance of minimum balance requirement. (BPRD Circular Letter # 02 dated Jan 25, 2010) iii. Where an account has become ‘Dormant’ as per the approved policy of the bank, no ‘ Service Charges’ shall be deducted from these accounts. (BPRD Circular No. 02 of January 02, 2010). \ iv. Students v. Mustahqeen of Zakat. vi. Zakat accounts maintained for collection and disbursement of Zakat funds vii. MCB Employees and their spouses. viii. All Basic Banking (BBA) Accounts. ix. ‘MCB Privilege’ Banking Customer x. All Collection Accounts i.e. Non -Checking accounts from where the balances/funds as per standing instructions, are transferred to customers’ main collection account whether daily or on periodic basis. The a bove exemption would be applicable only on those accounts where account holders have provided documentary evidence to the branch. 1.10 LETTER OF AUTHORITY i. Branches are allowed to accept a Letter of Authority from a customer / account holder who wishes to give authority to a third party such as Father, Mother or any other family member etc; to operate account on his/her behalf through Letter of Authority or through Standard Form 67 ( SF-6A27).This ‘authority’ must be duly signed, completed and be backed by a wri tten request giving therein the reasons / relationship amongst the account holder(s).  For third party mandate holder, Branch is required to perform/complete KYC requirements also on a separate KYC Form. ii. Branches are also permitted to open Bank Account on the basis of Letter of Authority provided Donee is specifically empowered to open and operate the Bank Account. iii. The branches will retain the original Letter of Authority if it is exclusively for opening a nd operation of Bank Account. In case it is for various other transactions, original can be returned after retaining an attested copy thereo f and a stamp like one below shall be affixed on the original and copy thereof and the serial number noted on them. MCB BANK LIMITED, Branch : _______________________ Regist ered Number: ______________ iv. When Power of Attorney lapses or is revoked, proper marking/noting must be made in the system/signature cards wherever applicable. v. When Letter of Authority is revoked/cance lled by the constituents the cancellation/effective date must be recorded on Attorney form or SF-6A27. Moreover, clearly mark SF-6A27 as CANCELLED. An index to the Power of Attorney Register, giving the names of both the grantor(s) and the grantee(s) of ea ch power of attorney must be maintained. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 54 vi. A Power of Attorney is required to be stamped in accordance with the provisions of the Stamp Act. A Power of Attorney executed abroad for use in Pakistan must be authenticated by Pak Embassy or Consulate General of Pakistan abroad in the country in which it is executed but it must be stamped within three months of its first arrival in Pakistan. vii. The Power of Attorney executed in Pakistan should either be registered under the Registration Act or authenticated by Notary Public or Class -I Magistrate. viii. Important clauses of the Power of Attorney shall be scrutinized specially with regard to the opening of account and the borrowing powers. ix. The exercise of powers by the agent must be watched to ensure that the same does not exceed the authorized limits. A general authority to transact business does not give an agent power to draw, accept and endorse bills nor does an authority to draw bill, confer authority to accept or endorse and vice versa. If government securities are to be dealt with, specific reference to such securities must be made; a general reference for dealing in securities will be insufficient. In the event of an attorney delegating any of his power to a third party, it must be ascertained that substitution is pro vided for in his Power of Attorney. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 55 Chapter 2 CUSTOMER DUE DILIGEN CE / KNOW YOUR CUSTOMER 2.1 ELEMENTS OF BANKS CD D/ KYC POLICY 1- Customer Identification: Establishing the identity of customers is central to the CDD / KYC policy both for the customer acceptance or rejection decision and for the on -going monitoring of customers' accounts and transactions. By identifying customers effectively, you are able to deal with them in the appropriate manner and comfortably. 2- Customer Acceptance: The point at which a new customer is accepted or rejected is the easiest point at which the risk of dealing with illegal money can be avoided. By following good customer acceptance policies, you can avoid dealing with entities and individuals who might en gage in illegal transactions. 3- Accounts & Transactions Monitoring: In an effective CDD / KYC policy, customer accounts and transactions are properly classified in terms of risk and are regularly monitored. Through checks and thresholds, unusual activiti es or activities by high -risk customers are detected and reviewed. 4- Risk Management: To ensure that the risks posed by money laundering / terrorist financing and other criminal customer activities are consistently dealt with, good risk management practi ces are essential. In this way the Bank can 'scale' its operations by remaining vigilant about customer -driven risk. 2.2 CDD/ KYC POLICY The general misperception of Branch Managers on Customer Due Diligence (CDD) / KYC / AML policy is that SBP regulations m ake the new account opening difficult. On the contrary, proper account documentation and CDD / KYC procedures provide satisfaction and protection to the Branch Managers / staff against unforeseen events and assist in establishing relationship in accordance with the bank’s policies. Getting maximum reliable information about the customer is the basic principle of good banking which enables the Bank to make correct decisions to meet with customer’s genuine banking requirements promptly. Branch officers / staf f must ensure that all the necessary documents have been obtained at the time of account opening or at the time of ongoing reviews of CDD / KYC formalities. The Bank has a statutory obligation to know its customers (which includes Customer Identification ( CI), Customer Acceptance (CA), Assigned Risk Rating (Normal or High) and subsequent monitoring of transactions). It is also obligatory to understand the nature of the business to be conducted with us, beneficial ownership(s) and 3rd party mandates. This ap plies to all type of customers regardless of who they are, their personal status (For PEPs see Section 4.12 of CDD -AML -Handbook), or the type of account or service that they require. Knowing your customer means: i. Seeking evidence of identity and address an d independently confirming that evidence at the start of a business relationship with the Bank. ii. Seeking information regarding the nature of the business that the customer expects to conduct with the Bank, establishing sources of income and expected patter ns of transactions, and keeping that B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 56 information up to date, to show what might be regarded as normal activity for that customer. iii. All resident prospective customers for accounts with MCB must be seen face to face except those customers who are living abroa d and wants to open a non -face -to-face/on -line account; adequate measures in this regard should be taken, for example, independent verification by a reliable 3rd party, client report from the previous bank / DFI of the customer, etc. Branch Manager: Will b e responsible for reviewing all HR Accounts once in a year and NR accounts once in three years. 2.3 COMPLETION OF ACCOUN T OPENING & KNOW YOU R CUSTOMER FORMS All prospective customers must completely fill -in all the appropriate columns of Account Opening Form (AOF) and provide the necessary documentary evidence of identity and financial information. If any column on AOF is not applicable it should be stroked ou t as “N/A”; and no section should be left blank. The customer must be interviewed by the Branch Manager (BM) and he MUST sign the KYC Form. (In the absence of Branch Manager BOM may interview and sign the KYC Form which at a later stage MUST be ratified and signed by the Branch Manager). Having completed the CDD/KYC requirements the AOF be handed over to Branch Operations Manager (BOM). Branch Operations Manager (BOM) must sign the AOF in order to keep intact the maker - checker policy of the Bank. The details of the AOF must invariably be input in the system by the BOM. The system generated report after this input MUST be checked by the BM. i. Any additional information obtained during the interview about the customer’s background, country of origin, public or hi gh profile position (PEP), nature of business and financial standing should be recorded by the branch manager and kept in customer’s file. ii. No account will be opened until the Account Opening & Know Your Customer Forms have been completed and all documents have been received and examined to ensure that they are valid. 2.4 THRESHOLD LIMITS All transactions across accounts, above the following specified financial thresholds, will be reviewed and signed off as being in line with CDD / KYC information retrospect ively by the respective Branch Managers . System generated reports will be produced for accounts with a debit or credit transactions or turnover above the following threshold limits: High Value Transactions Limit PKR 1,000,000 and above Personal and Business Accounts : Thresholds will be input into the system as per the account holder’s profile. For Sole Traders / Partnership accounts branch managers will decide the expected debit and credit turnover in the account after a thorough interview with the p rospective customer, and in case of personal accounts, individual’s monthly income / salary will be input as threshold limits in the system. Corporate Accounts & All Other Accounts : In line with the financials or expected turnovers in corporate accounts, Branch Managers / Regional Head will decide the respective parameters to be used as threshold limits for accounts falling into this category. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 57 The above limit has been put in place to monitor the accounts’ activities and by no means suggest that any transac tion exceeding the limits will constitute a “Suspicious Transaction”. Branch managers should use their judgment when they review such transactions and must refer to their respective RH / GMs or Business Heads when in doubt. 2.5 EXCEPTION REPORTS Income / Sal ary / Turnover Exceptions Report This report shows all the accounts where income/salary or Dr/Cr Turnover exceeds the financial profile set in the account. This report will be basic tool for monitoring KYC. The parameters will be updated as and when the KY C is updated as per the CDD / EDD criteria of the Bank. High Value Transactions Report In order to monitor the exceptions, the above report is generated by Knowledge Manager (KM) and forwarded to respective branches on very next day; which will be a vital tool for monitoring customer transactions: i. This report will include the high value cash transaction over the counter for PKR 1,000,000 /- and above as well. Responsibility of the Branch Manager i. Will be to review these reports and take actions where neces sary and update KYC as per CDD / EDD procedures as well as make notation on the above mentioned reports as to what action has been taken. These reports will be checked /audited by the respective RCO during the visit of the branch. ii. Any change in client’s pr ofile (change in turnover) already established in the record/system must be supported by source document. For further details on the Policy guidelines, please refer “CDD/KYC & AML Procedures Hand Book” from Compliance Group that is available on MCB Portal. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 58 Chapter 3 ACCOUNT OPENING PROCESS FLOW S 3.1 OVERVIEW There are multiple kinds of account opening processes that are to be followed by different type of branches/ channels which are listed as under: 3.1.1 Normal Branches (Other than E2E ) As a general rule, customer’s in -person presence is required for establishing the new account relationship with the bank. Fulfillment of account opening requirements, obtaining the required documentation and compliance with institutional and SBP mandated ‘ Know Your Customer’ policy related requirements is the direct responsibility of the concerned branch. Role and responsibilities of the staff involved in account opening process ar e defined in 3.2 - Account Opening – Normal Branches (other than E2E) 3.1.2 E2E Account Opening – by Centralized Branches ( Accounts being opened at CPUs) Account Opening Function is centralized at Central Processing Units in two cities (Lahore & Karachi) . Fulfillmen t of account opening requirements, obtaining the required documentation and compliance with institutional and SBP mandated ‘Know Your Customer’ policy related requirements is the direct responsibility of the concerned branch whereas data entry, Account # g eneration, completion of docs, generating/dispatching LOT and record keeping ( e-filing ) etc are performed by respective CPUs. Role and responsibilities of the staff involved in account opening process are defined in 3.3 - Account Opening – Centralized Branches 3.1.3 Direct Sales Channel: Accounts being opened by Direct Sales Force For handling the new account relationship by designated branches of CBBG under the umbrella of ‘Direct Sales Channel’ there are approved exceptions to the general rule in terms of roles of staff involved in soliciting and processing the new accounts. Thes e exceptions are defined in Section2: 3.4 - Account Acquisition by Direct Sales Force IMPORTANT NOTE : For Sub -Branches : Ref. to BPRD Circular # 15 of 2007 Revised Branch Licensing Policy, Account opening & issuance of account number and other formalities including Know Your Customer (KYC) and Cu stomer Due Diligence (CDD) shall be performed by the controll ing branch (not by sub -branch) B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 59 3.2 ACCOUNT OPENING – NORMAL BRANCHES (OTHER THAN E2E) Customer: comes into the branch and requests for opening an account. Designated officer: delivers the Account Opening Application along with the Terms and Conditions (AT&C) and relevant documents to the customer. Customer: receives the Account Opening Form (AOF) from Designated officer and submits duly completed AOF and relevant documents to the Designated officer . Designated Officer: i. Checks that all the fields in the Account Opening Form have been duly filled, and the relevant account documentation required from the customer depending on the type of account are completed and attached. ii. Obtain customer’s signatures on the AOF and SS Card (in person). Only Black Ink to be used on SS Card. iii. Moreover one signature card will be used to capture per signature of the client (In case of Joint Account Holders use additional signature card). Stamp of Mandate Confirmation should also be affixed on SS Card . iv. Ensures that all un -used blank fields/ sections of Account Opening Application are crossed/ cancelled. v. Subsequently takes the form to the Operat ions Manager and Branch Manager for verification and authorization. Operations Manager (BOM): i. Verification of CNIC through NADRA’s online VeriSys system and attach a copy of the same with AOF. i. Checks all required documents along with CNIC in original and affixes “Original Seen” Stamp on copies along wi th his/her authorized signature & AS/IBS number ii. Admits customer signature. iii. Sign-off and affix stamp on the Account Application. iv. Forwards AOF & Client Profile Form to Relationship/Branch Manager . Branch Manager (BM): i. Interviews the customer. ii. Check & ensure that the individual is not listed in UN/OFAC / BOE/ EU list ( from MCB Intranet Portal  Compliance  Compliance Library  SDN Lists ) for black listed names. BM or (BOM in absence of BM) should notify on AOF with the wording “NAME CLEARED FROM UN/OFAC / BOE/ EU LISTS” under his signature and AS/IBS number . iii. In case of any positive match the query should be sent to Compliance with a copy to respective GM for further check and necessary action. iv. Completes and sign off Know Your Customer (KYC)/ Client Profile Form. v. Returns the same to the Designated Officer for further processing. Designated Officer: i. Selects SYMBOLS Branch Teller Module > Transaction > Non -Financial Transaction > Client Definition (Screen # BT41) to create a client. ii. Insert Client Short Name. This is used as the default Title of Account whenever an account is opened. iii. Input Client full Name.  Pop-up box will appear on the screen:  Input or select appropriate ID Type & insert CNIC/Passport number & press OK. (Box will close automatically) iv. Insert Country Code, State, Country of Citizen, Country of Risk. v. In the next section of the same screen, insert Client Indicator as “N” Normal, or “S” Sta ff B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 60 3.2 ACCOUNT OPENING – NORMAL BRANCHES (OTHER THAN E2E) vi. Input address as written in Account Opening Application vii. Select Account Executive & Client Type then press F -10 or click save icon available on Tool Bar. System generates the client number and Pop -up box appear on the screen with the following message: “SUCCESSFULLY OPENED 09 DIGIT CLIENT NO xxxxxxxxx” viii. Designated Officer notes down the client number on the account opening form. ix. In case of joint account holders , separate client numbers will be given to each client. Account Opening: i. Uses SYMBOLS BT Module > Transaction > Non -Financial Transaction > Account Opening > select type of account Current or PLS (Screen # BT42) and for Term Deposit (Screen # BT4 2). ii. Input Account Type, insert Client Number and press enter. Client information will be retrieved on the screen Account Details: i. Input Title of Account in Account Description. ii. Input or select Account Currency. iii. Select Statement or Passbook. iv. Select ownership as Association, Single, Joint or Succession. I f Designated Officer will select Joint, JOINT ACCOUNT TAB will be activated. (Link secondary clients with the account) v. Select Client Indicator as “N” Normal or “S” Staff vi. Free Cheque (Optional field) vii. Input or Select appropriate SBP Classification code. viii. Tolerance Amount & Auto fund transfer fields (Optional). Joint Account: i. Input client number and press Enter, Client name and address will appear on screen. (If secondary client will not be linked with account then ownership type will be changed into Single). Account Statement: i. Select Contact Type as PO or PO1 ii. If customer's existing address is different from the already opened account then BOM will insert customer's address which is mentioned in the Account Application in the Kernel Module >> Static >> Client Information >> Client - screen # FM 144 (Contact infor mation in the field of Address. Contact Type will be defined as PO1 or PO2) iii. Address given in PO1 should be attached with the second account by using Deposits Module>> Static >> Acct Maint >> Current or Savings >> Account Open Maintenance RB212. (In the St atement Option, Contact Types will be defined as PO1). iv. Select Default Statement Frequency or as per customer’s request from List of Values (LOV). v. Select Statement Handling options from LOV as MA for Mail & CO for Collection. (Collection - CO will only be us ed in case where customer wishes to have a Hold Mail facility). Service Charges: Service Charges TAB shows following two charges attached with the account.  Service Charges – Select appropriate ‘Service Type’ according to Section 1: 1.2 SYMBOLS Account Types, Currency, Service Types . Service Charges are not link ed with th e exempted accounts. (The exemption to Service charges would be applicable only on those accounts where account holders have provided relevant documentary evidence to the branch) B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 61 3.2 ACCOUNT OPENING – NORMAL BRANCHES (OTHER THAN E2E)  Withholding Tax on Cash Withd rawal: Ensure that restraint type “CSW” is marked on all accounts . For exceptions refer to Section 2: 4.25 Procedure to mark Tax Exemption Restraint  ZAK- Zakat Service Charge i. Zakat Deduction service charge type (ZAK) is only attached with the accounts where Zakat Declaration Form is not submitted by the customer (Only for Muslims). In case of joint account Declaration is required for both. Zakat deduction is not applicable on N on-Muslims. ii. Select ZAK as Type , ZK as frequency & press enter Next Charge Date by default appears as for the next year. For example : If account opening date is 07th November, 2006 than Next Charge date should be 07th November, 2007. Note: ZK is the auto frequency type for Zakat Deduction. System generates the account number: i. Designated Officer notes down Client &/or Account Number on the Account Opening Application and Deposit slip. ii. Provides the Activation Deposit slip to the customer. iii. Forwards the Account Opening Form, relevant documents, cheque book requisition & ATM Request to the Branch Operations for further processing. (For Cheque book & ATM procedural guidelines, refer to the relevant chapters) Customer: Deposit cash & obtains t he receipt from the teller and leaves the branch. Operations Manager: Admits custome r’s signature, affix stamp & sign -off the Application / SS Card. Verifies customer data with the Account Opening form & other documents. Designated Authorized Officer/ Operations Manager: Scanning and tagging Specimen Signature Card (SSC): Scanning and tagging Customer’s Specimen Signature Card (SSC) will be done after account is opened. Designated Authorized Officer will write respective a ccount numbers on SSC, scan SSC and tag it in SYMBOLS, as mentioned in the process below: Note: For photo Accounts, paste Photograph on the front side of SSC Step 1: Client Activation in BT: i. “Client activation” is a prerequisite for customer signatory activity. The Designated Officer logs into relevant branch’s Branch Teller (BT) Module for carrying out this exercise. BT  Enquiry  Customer information. Screen BT 51 will show up. ii. Insert compl ete 9 digits Client Number of the Primary Client. iii. Press Enter, system automatically retrieves Primary Client data on screen. iv. This will activate the particular client’s information on BT. Designated officer then exits the screen by clicking “exit” icon. Step 2: Customer Signature Scanning & Uploading Activity: i. Designated officer scans all properly filled and stamped SSCs for a particular account and saves in a separate folder. Designated Officer logs into Screen BT 44 with the following path: BT Module  Select B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 62 3.2 ACCOUNT OPENING – NORMAL BRANCHES (OTHER THAN E2E) Transaction  Non-Financial Transaction  Customer Signatory  Screen (BT 44) will show up. ii. The Designated Officer inserts 9 -digit Primary Client number in the relevant field and presses Enter key. The system asks for Name of Signatory and Descripti on. iii. The Designated Officer inputs required information of Primary Client and presses Enter Key. iv. The Designated officer then clicks Scanning button for loading specimen signature(s) from file. System displays a dialogue box asking for loading a pre -scanned image. v. The Designated Officer clicks “Yes” Icon and defines path of the folder where SSCs are stored. vi. The system loads image and displays a preview of SSC. vii. After re -checking the loaded image with the SSC, t he Designated Officer presses F10 to save the SS C, at Client level, in the BT module. Note: i. The Designated Officer has to repeat this activity individually for each SSC to be tagged with a client. ii. The Designated officer exits the screen by clicking “Exit” icon Step 3: Attach SSC with Account on BT Module i. To attach SSC with Account, Designated Officer performs the following exercise: BT Module  Select Transaction  Non-Financial Trans  Account Signatory. Screen BT 45 will show up. ii. Designated Officer inputs 16 digit account number and presses Enter key twice. A window will show the account details. iii. The cursor reaches by default to “Signatory Number” field which shows primary client number. The processor presses “Enter” key. iv. System displays Primary Client’s details. Designated officer presses “Enter” key in limit field, start date and end date field and reaches to Signature Number field. Here the Designated officer assigns serial number to the SS Card and presses “F10” key. v. System displays 3 dialogue box windows for confirmation of saving the data. De signated Officer presses OK in all of them. vi. Exits the screen by clicking the “Exit” icon Step 4: Attach SSC with EOC (Deposit Module): i. Signatures captured on BT Module have to be attached to EOC so that the signatures are available throughout the networ k, otherwise Cross Branch Transactions cannot be performed. Following activity has to be performed for attaching SSCs to their respective accounts in EOC: ii. EOC  Deposits  Static  Acct Maintenance  Current Account/ Saving Account. Screen RB 211 will show up. iii. Designated Officer will insert 16 -digit account number. iv. Press F8, customer details appear on Screen; v. Designated Officer clicks “SG Capture” icon vi. Another window RB49 opens up. Designated Officer enters 9 -digit Primary Client number in “Client Number” field and presses Enter key. vii. Cursor will move to Signatory Number field, where designated officer will insert the serial number of SSC, fed earlier in BT. System will display preview of SSC. viii. Cursor will move to “Start Date” and “End Date” field showing default date of the particular day of account opening. Designated Officer will keep the Start Date same and change the End Date to 2099 and press Enter key. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 63 3.2 ACCOUNT OPENING – NORMAL BRANCHES (OTHER THAN E2E) ix. Designated Officer cross -checks the SSC preview with details appearing on the system in order to ensure correctness of signature tagging. x. Designated Officer also check -marks “Attach” field to confirm data correctness and presses “F10” key to save the data. xi. Presses “Exit” icon to exit from the screen. Keep Specimen Signature Cards (SSC) in fire proof cabinets. Designated Officer: i. Selects Kernel Module > Static > Client Information > Client (Screen # FM144) and completes client opening screen # 144 in Kernel Module (Financial Management). ii. Ensure Information regarding ‘Client Turn -over ’ and ‘Client Stat us’ (NR/HR /PEP etc) on FM -144 >Client Data is complete in every aspect. iii. Ensure correct ‘Ownership’ e.g. SG for Individual accounts and JN for joint accounts on FM -144>Client information is mentioned iv. Ensure correct ‘ID type’ e.g. NIN for Pakistan i residents and FIN for Pakistanis residing abroad etc on FM-144>Client information is mentioned v. Dispatches Thank You Letter to the customer . Designated Authorized Officer/ Operations Manager: i. Keep Account Opening Forms & the relevant documents in the Fire Proof Cabinets or Vault for record. ii. Keep Signature Cards in the Fire Proof Cabinets in a sequential order. iii. If there is any undelivered Letter of Thanks , BOM will mark Restraint on the account by using Deposits Module >> Transaction>> Acct Facility >> Restraint Setup (Screen # RB 51). iv. Enter Account Number; account details will appear on the screen. Select Restraint Type from LOV (WA U- Where About Unknown). v. Press enter, effective date will auto appear in the field of “St art Date”. Press enter, Popup box appear on the screen for Narration. vi. Input Narration in the popup box and press ok, End date appear. Press F10 to save. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 64 3.3 ACCOUNT OPENING – CENTRALIZED BRANCHES (E2E) Customer walks in to branch and requests to open an account Designated Officer delivers the Account opening Application along with necessary guidance to Customer. Customer receives the Account Opening Form (AOF) from Designated Officer and submits duly completed AOF along with required relevant documents back to Designated Officer. Designated Officer checks all the fields in the AOF are filled in properly and the required relevant documents (depending on the type of account) are attached. Ensures that all un -used blank fields/ sections of Account Opening Application are crossed/ cancelled. In case of any discrepancy, Designated Officer returns the AOF to the customer for regularization otherwise the AOF is forwarded to Branch Manager/Operations Manager for KYC, N ADRA verification Branch Manager/Operations Manager/ PBA/ ASM interviews the Customer. i. Fills the KYC form and signs off the same ii. Verifies CNIC via NADRA VeriSys (Online Verification System) and attaches the same with AOF iii. Checks all required documents along with CNIC in original and affixes “Original Seen” Stamp on copies along wi th his/her authorized signature and AS/IBS number. iv. Check & ensure that the individual is not listed in UN/OFAC / BOE / EU list (from MCB Intranet Portal  Compliance  Compl iance Library  SDN Lists ) for black lis ted names. BM or (BOM in absence of BM) should notify on AOF with the wording “NAME CLEARED FROM UN/OFAC / BOE/ EU LISTS” under his signature and AS/IBS number . v. In case of any positive match the query should be sent t o Compliance with a copy to respective GM for further check and necessary action. vi. Obtains customer’s signatures (In Person) on Specimen Signature Card (SSC) . Only Black Ink to be used on SS Card. Stamp of Mandate Confirmation should also be affixed on SS C ard. vii. After completion of initial account opening process, customer leaves the branch. *KYC of customers with turnover of 1 Million PKR and above will be carried out by BM only. viii. Dispatches the AOF and all required relevant documents, except the Specimen Sig nature Card (SSC), along with a covering sheet, in a sealed envelope to CPU via courier service . The branch will retain SSCs with them. *SSC, Cheque book and ATM request forms will NOT be sent to CPU with AOF as this activity does not come under CPU’s ambit . *Keep Specimen Signature Cards (SSC) in fire proof cabinets CPU : i. CPU coordinator receives the sealed envelope containing original AOFs along with relevant documents. ii. Counter matches details with covering sheet received from the respective branch. Information of these forms is entered into an MIS and AOFs are distributed among designated staff for scrutiny CPU: Designated Officer scrutinizes the forms. i. If these do not contain any discrepancy, same are forwarded for processing. ii. In case of any discr epancy, the concerned branch is informed via email. iii. Depending on the nature of discrepancy, AOF is either held till regularization or is returned to the branch for rectification. iv. For the regularization of discrepancies, branches mostly reply by fax and fo rward scanned images of B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 65 3.3 ACCOUNT OPENING – CENTRALIZED BRANCHES (E2E) documents through email. v. Designated Officer checks the discrepancies resolved by the branches. He should ensure resolution of all discrepancies before forwarding the AOFs for further processing. Note: Compliance team has been deputed with centralized processing dep artment for reviewing all the ‘High Risk’ accounts before any final decision in made by the business on all such accounts." CPU: Client Generation in Kernel Module i. Path for Client Opening in Kernel Module: EOC  Kernel Module  Static  Client Information  Client (Screen FM 144). ii. Input complete detai ls of client in required fields (mandatory) vi. Ensure Information regarding ‘Client Turn -over’ and ‘Client Status’ (NR/HR/PEP etc) on FM -144 >Client Data is complete in every aspect. vii. Ensure correct ‘Ownership’ e.g. SG for Individual accounts and JN for joint accounts on FM -144>Client information is mentioned viii. Ensure correct ‘ID type’ e.g. NIN for Pakistani residents and FIN for Pakistanis residing abroad etc on FM-144>Cli ent information is mentioned iii. After completion of all the fields, press F10. iv. System opens another window (RB 7F) and generates 9 digit Client Number. v. Marks Statement Frequency and Next applicable statement date. vi. Note down client number on account opening form. Note: Incase Client already exists go on next step for Opening of an Account. CPU: Account Opening in Deposit Module: After the client is generated on Kernel module, account opening is done through the following process: i. Path for Account Opening in Deposit Module: ii. EOC  Deposit Module  Static  Account Maintenance iii. Select Account Type i.e. Current Account (RB 211) or Savings Account (RB 212). iv. Press Ctrl Q for inserting product type i.e. BBA, Current, KBA, Business, etc. v. Press enter key. Cursor will move to “Customer No” Field. vi. Insert 9 Digit Client Number and press Enter key. System will show client details on the screen. vii. In the “Branch Code” field (default code set at 0000), insert 4 digit code of the branch where customer wishes to open his account. A pop -up window will show up for authorization. Processing Officer will either authorize it or request designated officer fo r authorization (this depends on the role and rights given to the processing officer). viii. Screen will show various fields to be filled in. Processing Officer inputs all the necessary information. Presses F10 key to save the data. ix. System generate 16 (sixteen ) digit Account Number . x. Notes down the account number on AOF in appropriate field. CPU: Information to Branch via Email For Opened Account: Complete Account Number along with Customer Name, Type of Account and Date of Account Opened & PBA code is emailed to the concerned branch. CPU: Report Checking: After completion of opening of an account, Processing Officer generates two reports, FM -9149 (client details listing) and RBA -26 (Account Opening/ Maintenance Details) for verification of details inputted. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 66 3.3 ACCOUNT OPENING – CENTRALIZED BRANCHES (E2E) For FM -9149 Report Generation: i. EOC  Kernel  Reports  Client Information  Client Details. ii. Insert 9 -digit client number and press F10 key. System will generate the required report. Take a print out for validation of information against AOF. Upon completion of review exercise, the checker will sign and affix REVIEWED stamp on the report. In case of any discrepancy, the checker will get the information rectified through the processor. For RBA -26 Report Generation: i. EOC  Deposit  Reports  Operational  Account Open Maintenance. ii. Detail Screen (RBA26) will show up; insert branch code, account type and account number, and press F10 key. System will generate the required report. Take a print out for validation of information against AOF. Upon completion of review exercise, the checker will sign and affix REVIEWED stamp on the report. In case of any d iscrepancy, the checker will get the information rectified through the processor. CPU: Generating Letter of Thanks (LOT) i. Processing Officer generates "Letter of Thanks" via MCB Reports by following path: MCB Reports  Letter of Thanks  RBMR059: Runtime Parameter Form. ii. The officer inputs Branch Code(s) and Date in the respective fields and presses Enter key. iii. System generates LOTs for each account opened for the particular date and shows a preview in Screen RBMR059 – Previewer. iv. The Proces sing Officer saves the generated LOTs for e -filing and also takes a print out of these for signing by authorized officer and dispatching to the customer. Dispatch of Letter of Thanks (LOT): Designated officer dispatches original copy of LOT to customer and obtains shipment advice from the courier company. Shipment advices are attached with respective AOFs. Returned LOT: i. In case LOT is returned by the courier, the same is dispatched to conce rned branch after being properly entered branch wise in MIS of LOT returned . ii. An email is sent to the branch providing details of returned LOT(s). Restraint Marking for Returned LOT i. A restraint "WHERE ABOUT UNKNOWN" has to be marked on the account where L OT has been returned undelivered. ii. EOC  Deposits  Transactions  Acnt Facility  Restraint. Restraints screen will appear. Processor inputs complete 16 -digit account number and press F8 key. System will show all the details of the account. iii. Processor sele cts the appropriate restraint type i.e. WAU and presses enter. Presses enter key twice to set the default dates (start date and end date). Thereafter, a dialogue box will appear that requires updating with information about restraint reason. Processor inpu ts “LOT Returned” and presses F10 to save the transaction. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 67 3.3 ACCOUNT OPENING – CENTRALIZED BRANCHES (E2E) CPU: Record Keeping – E-filing on daily basis i. Proper E-filing of All AOF forms opened in a day, with their LOT is done. ii. In exceptions and deferral cases, approval emails from BH/GM for the account opening are also made a part of E-filing in the same day. For special cases (PEP, etc), which are forwarded to Compliance and Controls Group for obtaining World Check Report, repl y of the Compliance and Controls Group is also made a part of E-filing . CPU: Dispatch of AOF: i. Designated officer dispatches processed AOFs for branch record and unprocessed AOF for discrepancy resolution at branch end. ii. Individual branches envelops are prepared with individual branches summaries which contains all AOF details. iii. A courier summary, which acknowledges the details of all AOFs, is dispatched to branches along with envelopes. iv. A receiving of all envelopes handed over by CPU is also obtained by courier representative. v. Branches also send back the receiving copy of summaries to confirm that they have received those forms. Branch : Scanning and tagging Specimen Signature Card (SSC): Scanning and tagging Customer’s Specimen Signature Card (SSC) wil l be done at branch after account is opened at CPUs. Upon receipt of original processed AOFs at branches , concerned personnel at branch will write respective account numbers on SSC, scan SSC and tag it in SYMBOLS, as mentioned in the process below: Note: For photo Accounts, paste Photograph on the front side of SSC Step 1: Client Activation in BT: i. “Client activation” is a prerequisite for customer signatory activity. The Designated Officer logs into relevant branch’s Branch Teller (BT) Module for carrying out this exercise. BT  Enquiry  Customer information. Screen BT 51 will show up. ii. Insert compl ete 9 digits Client Number of the Primary Client. iii. Press Enter, system automatically retrieves Primary Client data on screen. iv. This will activate the particular client’s information on BT. Designated officer then exits the screen by clicking “exit” icon. Step 2: Customer Signature Scanning & Uploading Activity: i. Designated officer scans all properly filled and stamped SSCs for a particular account and saves in a separate folder. Designated Officer logs into Screen BT 44 with the following path: BT Module  Select Transaction  Non-Financial Transaction  Customer Signatory  Screen (BT 44) will show up. ii. The Designated Officer inserts 9 -digit Primary Client number in the relevant field and presses Enter key. The system asks for Name of Signatory and Descrip tion. iii. The Designated Officer inputs required information of Primary Client and presses Enter Key. iv. The Designated officer then clicks Scanning button for loading specimen signature(s) from file. System displays a dialogue box asking for loading a pre -scann ed image. v. The Designated Officer clicks “Yes” Icon and defines path of the folder where SSCs are stored. vi. The system loads image and displays a preview of SSC. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 68 3.3 ACCOUNT OPENING – CENTRALIZED BRANCHES (E2E) viii. After re -checking the loaded image with the SSC, t he Designated Officer presses F10 to save the SSC, at Client level, in the BT module; the Designated Officer presses F10 to save the SSC, at Client level, in the BT module. Note: i. The Designated Officer has to repeat this activity individually for each SSC to be tagged with a client. ii. The Designated of ficer exits the screen by clicking “Exit” icon Step 3: Attach SSC with Account on BT Module i. To attach SSC with Account, Designated Officer performs the following exercise: BT Module  Select Transaction  Non-Financial Trans  Account Signatory. Screen BT 45 will show up. ii. Designated Officer inputs 16 digit account number and presses Enter key twice. A window will show the account details. iii. The cursor reaches by default to “Signatory Number” field which shows primary client numbe r. The processor presses “Enter” key. iv. System displays Primary Client’s details. Designated officer presses “Enter” key in limit field, start date and end date field and reaches to Signature Number field. Here the Designated officer assigns serial number t o the SS Card and presses “F10” key. v. System displays 3 dialogue box windows for confirmation of saving the data. Designated Officer presses OK in all of them. vi. Exits the screen by clicking the “Exit” icon Step 4: Attach SSC with EOC (Deposit Module): i. Signatures captured on BT Module have to be attached to EOC so that the signatures are available throughout the network, otherwise Cross Branch Transactions cannot be performed. Following activity has to be performed for attaching SSCs to their respective acc ounts in EOC: ii. EOC  Deposits  Static  Acct Maintenance  Current Account/ Saving Account. Screen RB 211 will show up. iii. Designated Officer will insert 16 -digit account number. iv. Press F8, customer details appear on Screen; v. Designated Officer clicks “SG Capt ure” icon vi. Another window RB49 opens up. Designated Officer enters 9 -digit Primary Client number in “Client Number” field and presses Enter key. vii. Cursor will move to Signatory Number field, where designated officer will insert the serial number of SSC, fed e arlier in BT. System will display preview of SSC. viii. Cursor will move to “Start Date” and “End Date” field showing default date of the particular day of account opening. Designated Officer will keep the Start Date same and change the End Date to 2099 and pres s Enter key. ix. Designated Officer cross -checks the SSC preview with details appearing on the system in order to ensure correctness of signature tagging. x. Designated Officer also check -marks “Attach” field to confirm data correctness and presses “F10” key to save the data. Presses “Exit” icon to exit from the screen. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 69 3.4 ACCOUNT ACQUISITION BY DIRECT SALES FORCE i. Solicitation of new account relationship - outside the bank premises. ii. Fulfillment of account opening requirements and documentation. iii. KYC will be done by ASM / BM of the concerned branch iv. Account opening o n the system will be done as per processes mentioned above i.e., Normal & E2E branches as applicable i. Sales Acquisition Responsibility: Direct Sales Consultants (DSC), Area Sales Manager (ASM)  DSC u nder the supervision of Area Sales Manager (ASM) will contact the prospective customers outside the bank premises through appointments to solicit new account relationships.  Provide all required information and AOF/KYC Forms to the customer.  Complete “KYC” Form in consultation with the customer as per KYC policy.  Collect Account Opening Form (duly filled -in by the customer) along with the copy of CNIC, KYC Form and other required documents.  Check completeness of the documents and ensure that all required in formation is provided in AOF & KYC Forms.  Fills out Sales Visit report, mention the DSC code and signs the report.  Affix ‘Direct Sales’ stamp and his code on Account Opening Form.  DSC code is required for input in the system at the time of account opening ii. Vigilance & KYC Certification: Responsibility: Branch Manager (BM); Area Sales Manager (ASM); Personal Banking Advisor (PBA)  Scrutinizes AOF/documents and ensures that they are complete in all respect.  Verifies original CNIC with NADRA’s on -line VeriSys system.  It is mandatory for BM or ASM or PBA to meet the customer in -person to interview him and ensure that information provided on AOF/KYC Form is correct and complete. BM or ASM or PBA who meet and interview the customer will perform the following:  See the ‘originals’ of all the documents including CNIC submitted with AOF and attest the copies thereof.  Admits customer’s signature on AOF and Specimen Signature Card – (SSC). Only Black Ink to be used on SS Card. Stamp of Mandate Confirmation should also b e affixed on SS Card  Sign off the AOF & KYC Form to evidence that all above requirements are met.  Branch Manager / Area Sales manager shall approve/authorize the account opening under his signature / Stamp & mention his IBS/AS number. Notes:  Where the custo mer does not come to the branch, BM/ASM or PBA will visit the customer at his place and verify his business and complete the KYC formalities and admission of his specimen signatures.  No account will be opened or forwarded to Centralized Processing Unit (CP U) without face -to-face interaction of the customer with BM/ ASM or PBA.  It is mandatory for the Branch Manager to conduct KYC requirements himself if the account turn - over exceeds PKR 1 million per month. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 70 3.4 ACCOUNT ACQUISITION BY DIRECT SALES FORCE iii. Account Activation Deposit :  The DSC may collect the account activation deposit in the form of Cross Check or Pay Order or Demand Draft in favor of customer’s name only. If needed, DSC will provide acknowledgment of the receipt of activation deposit to the customer on the copy of the i nstrument. BM / BOM has to ensure that all such instruments pick up from the customer are kept in safe custody under dual control until account is opened. The same will be lodged in clearing / collection the same day . DSC is strictly NOT allowed to pick up Cash from the customer outside the bank premises. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 71 Chapter 4 ACCOUNT OPERATING AN D MAINTENANCE 4.1 JOINT ACCOUNT An account in the name of two or more, other than partners or trustees is called a Joint Account. Operational instructions in the Application for Account Opening must be filled in clearly. The following points should be kept in mind regarding the Operations of Joint Account. i. Cheques are signed appropriately i.e. according to the operational instructio ns. ii. All Joint Account holders must sign “Letter of Authority or SF-6A27” while delegating authority to operate the account by the third party(s). iii. While making payments of cheques drawn jointly, care should be exercised to verify each signature. iv. In case of Death of any Joint account holder: CREDIT BALANCE DEBIT BALANCE Return cheques signed by “DECEASED” presented for payment. Stop withdrawals in the account in order to preserve bank’s rights against the deceased party. Cheques signed by SURVIVOR may be paid, if the account is operated under the either or survivor operational instructions. Refer the case to Regional Office for guidance giving full details including securities held if any. 4.2 PROPRIETORSHIP ACCOU NT A Business Account Opened/ Operated by a single person. Sole proprietorship is a business that legally has no separate existence from its owner. A sole proprietorship can operate under the name of its owner or it can do business u nder a fictional name. The ficti onal name is simply a trade name --it does not create a legal entity separate from the sole proprietor owner . 4.3 PARTNERSHIP ACCOUNT Partnership is defined as an association of two or more persons who have agreed to share profit of a business carried on by all or any of them act ing for all . The terms and conditions are either spelled -out in a properly drawn partnership deed or formally agreed upon between partners without incorporating them in a partnership deed, however, where the partnership deed is not made or it is made but s ilent on any point then the Partnership Act 1932 will apply. Procedure for opening of Accounts should be followed and operation in the account is allowed according to the instructions contained in partnership deed. Letter of Authority ( SF-6A27) / Power of Attorney should be obtained signed by all partners, if power is to be delegated for operation of account. Section - 14 of the Companies Ordinance 1984, provides that an association or partnershi p consisting of more than 20 persons requires to be registered compulsorily as the company under the Companies Ordinance 1984. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 72 4.3.1 Minor as a Partner: i. A minor who is otherwise incapable of binding himself by contracts can be admitted as a “Partner” to the benefits of partnership but his position is a peculiar one. A person who is a minor according to the law to which he is subject may not be a partner in a firm, but, with the consent of all the partners for the time being, he/she may be admitted to the benefits of partnership. ii. He/ She has a right to such share of th e property and of the profits of the firm as may be agreed upon and as to liabilities such minor is liable for the acts of the firms, but he/she is not personally liable for any such act. His/ Her position is, therefore, identical with that of a shareholde r in limited companies. 4.3.2 Minor Attaining Majority: At any time within six months of his attaining majority, or of his obtaining knowledge that he/she had been admitted to the benefits of partnership, whichever date is later, such person may give public no tice that he/she has elected to become or that he/she has elected not to become a partner in the firm and such notice shall determine his/her position as regards the firm. Provided that, if he/she fails to give such notice, he/she shall become a partner in the firm on th e expiry of the said six months 4.3.3 Death of a Partner: The following actions should be taken in case of Death of a Partner: i. If there is a provision in partnership deed that the partnership is NOT DISSOLVED by death of partner, the remaining pa rtners may continue the business and operate the account uninterrupted if in credit. ii. Cheque signed by the deceased partner alone before his death but presented after notice of his death, may be paid with the consent in writing of surviving partners. iii. If the partnership deed provides that the partnership be DISSOLVED, the surviving partners may continue operation of the firm’s account, if in credit, for the purpose of winding up the business. iv. The balance is payable to surviving partners, who will account for to the heirs of the deceased partner for his share of the firm’s assets. If the account is overdrawn : v. Stop operation in the account, whether the firm stands dissolved or not, to establish the liability of the deceased partner’s estate towards the bank in r espect of firm’s debts. vi. A fresh account, to be kept in credit, may be opened for continuing the firm’s business or for winding it up. 4.3.4 Retirement of Partner: i. Until notice of Retirement is received by bank from a partner, he/she is liable for firm’s debts i ncurred after date of his/her retirement. ii. In case Bank Finance is being availed against the securities relating to retiring partner, fresh securities as well as charge forms may be obtained if replacement is desired. iii. If the account is overdrawn: Further withdrawals from account should be stopped and facilities to be reviewed keeping in view the existing partners. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 73 4.3.5 Admission of New Partner: i. He/ She can only be admitted with consent of all the existing partners. ii. He/ She is liable for the firm’s debts incur red after date of his/her admission, he/she will also be liable for debts prior to his/her admission in partnership business provided he/she agrees and accepts such liabilities. Documents to Be Obtained: i. Take a fresh mandate signed by existing and new par tner to cover future operations. ii. Obtain his/her acknowledgement of joint and several liabilities. iii. It may be noted that there is no need to stop operation of the account. 4.3.6 Insolvency of Firm: i. Stop operation in the account, whether in credit or debit. ii. Refer the case to Circle Office an d Regional Office for guidance. 4.3.7 Dissolution of a Firm: The dissolution of a firm means the dissolution of partnership between all the partners of the firm. Firms may be dissolved in the f ollowing five ways: i. Dissolution by Agre ement ii. Compulsory Dissolution iii. Dissolution on the happening of certain contingencies iv. Dissolution by notice of partnership at will v. Dissolution by Court As soon as banker receives an order or notice of bankruptcy petition or information through reliable source s, banker should s top operation of account, as the power is not vested in an Official Liquidator besides this, operation on all private account of partners should also be stopped because bankruptcy of firm means bankruptcy of each and every partner. It is pertinent to note that: i. All creditors of firm will be first adjusted from the firm balances and similarly private creditors from credit balances of partner’s private accounts. ii. The remaining balance in the accounts will be paid to firm and private creditor s as the case may be. For a banker, when there is credit balance it should be put on the disposal of an Official Liquidator and when there is debit balance a claim should be lo dged with Official Liquidator. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 74 4.4 TRUST ACCOUNTS A “Trust ” has been defined in Se ction 3 of Trust Act, 1882, in the following terms: “A ‘Trust’ is an obligation annexed to the ownership of property and arising out of a confidence proposed in and accepted by him for the benefit of another, or of another and the owner.” i. All trustees shou ld preferably sign the Application for Opening Account. ii. Trust Deed for relevant extracts must be obtained and filed. iii. All withdrawals from the account shall be allowed under joint signatures of Trustees named in the Trust Deed unless power is given t o the trustees for operating the account singly. iv. Cheques or Credit vouchers issued in favor of Trust Account should not be collected for credit to the private account of the trustees. 4.5 COMPANIES REGISTERED UNDER COMPANIES O RDINANCE 1984 A Companies registered under companies ordinance 1984 is an association of persons who contribute funds to raise capital of the company. The persons to whom the capital belongs are referred as members (share -holders) of the company. Following guidelines must be followed: The Me morandum and Articles of Association must be carefully read . The Memorandum is the constitution of the company an d the Articles define the powers of the directors ; when these powers are not clear, the company should be asked to explain what procedure has b een adopted to regularize the position . A company cannot do business of a character not included in the Memorandum, but usually these powers are very extensive. The Memorandum will show what are the borrowing powers, etc; and what was the capital of the co mpany at the time of formation. 4.6 CLUBS/ SOCIETIES/ AS SOCIATIONS No cheques drawn on the accounts of Clubs, Association or Societies shall be collected for credit of private account of the office -bearers of Clubs, Association or Societies. Death of an Auth orized Officer: In case of transfer or death of any of the office -bearer of Clubs, Associations or Societies operating the account, all withdrawals in the account should be stopped till the receipt of fresh resolution passed by Managing Committee delegatin g powers to the new Office -bearers. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 75 4.7 LOCAL BODIES ACCOUNT Local bodies are defined as Municipalities, District Boards, Development bodies etc; whose functions and powers are governed by the respective Acts creating them and rules and bye -laws made in pur suance of such Acts from time to time. These bodies usually have at their disposal substantial funds and banks regard them as desirable customers, but their accounts must be conducted strictly in accordance with the statutory rules and regulations. 4.7.1 Conduct of the Local Bodies Accounts: i. Local authorities are to be regarded as trustees of the funds under their control and therefore all banking transactions must always be consistent with the rules and bye -laws and within the scope of their respective authority . ii. Local bodies have no implied power to borrow money as a general rule, unless some statutory power exists to authorize borrowing, a local authority cannot validly contract a loan. Before considering the grant of a loan to such bodies, reference must be made to the relevant Act & Rules governing their power to borrow, limitations if any and authorized form of borrowing. In some cases the prior sanction of the Provincial and Federal Government is necessary. iii. It is important to remember that not only the bor rowing is strictly in accordance with the provisions of the statute under which it takes place but the money borrowed is to be utilized for the purpose for which it was raised. iv. After looking into all these aspects it would be necessary to get a resolution passed by the local authority through its governing body/managing committee in accordance with its constitution. Since a number of legal technicalities are involved, proper legal advice would have to be taken before entertaining proposal for advance from legal affairs div through consultation with region/circle offices 4.8 LOCAL / DISTRICT ZAK AT/ USHR COMMITTEE A CCOUNT These accounts are opened, maintained and operated upon in accordance with Banking Procedure as laid down in the “ Operational Arrangement for Local Zakat Fund ” Booklet supplied to the branches. i. After the constitution of a Local Zakat Committee (LZC) has been formally notified by the District Zakat Committee, the LZC will meet to pass a resolution on Form LZ - 01 to open a Current Account to be known as LZF Current Account with the branch. ii. After the said resolution has been passed, the Chairman of the LZC will write on Form LZ - 02 to the bank manager concerned, requesting to open a Current Account in terms of the LZC resolution. iii. Each LZC will op en and maintain only one account. iv. Once the said account has been opened, it will not be shifted nor closed, nor any other change with regard to its operation effected, except with the prior knowledge and clearance from the PZA (Provincial Zakat Administrat or). B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 76 4.9 MINOR ACCOUNT These are Joint accounts opened in the joint name of Minor and Guardian However the Title of account can be of “Minor” in the System. The account is operated by the Guardian till the Minor attains age of 18 4.9.1 Death of Minor: If the A ccount was opened by Natural Guardian, jointly with or in the name of Minor , if minor is dead , survivor account holder will be allowed to withdraw the balance and close the Account. 4.9.2 Death of Natural Guardian: In case of death of Natural Guardian, operation in the Account will be stopped. The Minor will be allowed to withdraw after attaining age of majority by producing evidence in this regard and after getting Legal Opinion from Legal Affairs Division. If the Minor is survivor and has not yet reach ed the age of majority, the balance can be paid on the production of Guardianship Certificate from the competent Court of Law. 4.9.3 Guardian Appointed by Court: In case of Account opened in the name of Minor and operated by the Guardian appointed by Court, the withdrawal in the account will be stopped on the death of Minor or Guardian. If the Guardian is dead, operation will be allowed after appointment of new Gua rdian by the Court and in case, Minor is dead; instruction of the Court will be followed. 4.9.4 Minor attaining Majority: Cases where a minor account is converted into a major account following are the documents required : i. Request letter from the minor to conve rt his/her a/c to major upon presentation of Original CNIC. ii. A request letter from the guardian is also required to convert the minor account to major requesting to delete his/her signature from the account. iii. A new specimen signature card from the major to b e taken iv. Branch Updates Account personal information after conducting a fresh KYC of the Customer 4.10 STUDENT ACCOUNT Student account s are account opened specifically for students and have been exempted from levy of ser vice charges by the State Bank o f Pakist an as per BPD circular no. 23 dated: July 04, 2003 . Whi le opening account of students ; banker should ensure the bonafide of the applicant as a student by asking for the students school / college ID card or if required a letter from the institution confirming the applicant as regular student of their institute . The PBA should also inquire about the term of the applicant as student o f that institute. It is the responsibility of the banker to convert the account to normal account (for application of service charges) after completion of the term of the applicant as student. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 77 4.11 ILLITERATE/ DISABLE/ BLIND PERSONS BANK A CCOUNTS i. Account sho uld be opened with a photograph affixed on the Account Opening Application as well as on the Specimen Signature Card (Front side) along with a stamp “All Drawing in Person” . The photograph must be attested by an independent person and the Branch Manager / Branch Operati ons Manager with his/her AS/IBS number under his stamp and signature. ii. In case a disable/ blind person can sign, his/her signature plus his/her thumb impression should be taken on the Account Opening Application as well as on Specimen Signatur e Card (Front side) along with the stamp “Thumb impression affixed in my Presence ” which must be attested by the Branch/ Operations Manager. iii. These accounts should be marked in Bold Letters on the Account Opening Application as well as Specimen Signature Ca rd and Cheque book “All Drawing in Person” . iv. Further, the Branch Manager is required to put a note on the Account Opening Form to the effect that the visually impaired person has been informed about the terms & conditions of the operations of the account un der his signature/name. Note : Keeping in view the risk involved MCB ATM Smart Card will not be issued to ‘visually impaired / blind’ account holders until the time required technology (voice guided ATMs with brailed keyboard) are introduced. i. For the purpose of Withdrawal from the account of illiterate/blind person, he/she must visit the parent branch personall y, produce the Cheq ue book, and affix his/her right /left hand thumb impression on the cheque in the presence of the Branch /Operations M anager. However, if a visually impaired person is capable to sign then he should sign the cheque ii. In case of withdrawal of large amounts in excess of PKR 10,000/= it is advisable that the thumb impression should be affixed in the presence of an independent witness known to the Branch Manager or Operations Manager and his full name and address should be recorded below his signatures. iii. In case of Deposits in an individual account of visually impaired / blind person may be made by representative of the account holder in any Branch. 4.12 SHARES COLLECTION AC COUNT Current account should be opened for Share Collection Account after receiving instructions from Region/Circle/Group Office . Operating Instructions are as follow: i. Separate account shall be opened for each company for Share Subscription which should be closed immediately after the entire funds are transferred to the Main Branch. ii. Account Opening Application will be used for opening Shares Subscription Account. Account Title and Account number should be writte n clearly on Account Opening Form. Relevant circular should be attached with the form for future record and reference. iii. An attested copy of CNIC should be obtained from appli cant of Share Application. iv. Subscription amount should be received from applicant in the form of cheque drawn on applicant’s own account or Bank’s Cheque. v. Refund to unsuccessful Share Applicants will be credited in the respective accounts directly by responding the refund Advice received from Main Branch. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 78 4.13 COLLECTION ACCOUNT There are two types of collection accoun t facility provided to customer i. Main Collection Accounts ii. Subsidiary Collection Accounts i. Main Collection Accounts: Main collection accounts are normally chequing collection accounts . All the collections from customer’s subsidiary collection accounts are transferred to the main collection accounts as per standing instructions on daily or periodical basis. Main collection account will be opened/ maintained in Current Account category, if not specified by the customer. ii. Subsidiary Collection Accounts: Subsidiary collection accounts are normally non-chequing collection accounts . These accounts are opened for customer funds collections and balance/funds are transferred to customers main collections account on daily or periodical basis as per standing instruction. 4.14 NON -RESIDENT ACCOUNTS Accounts of individuals, firms or companies r esiding in countries outside Pakistan are termed as Non -Resident Accounts. All nationals of Pakistan and persons domiciled in Pakistan except persons holding office in the service of Pakistan, who go out of Pakistan for any purpose such as employment, stud y, business tour, pleasure trip etc are treated as Non -Resident, for so long as they remain outside Pakistan. All such accounts are considered for the purpose of Foreign Exchange regulations as accounts of countries in which the account holder is residing. 4.14.1 Categories of Non -Resident Accounts: There are four major categories of Non -Resident Accounts: i. Non -Resident accounts of Pakistan Nationals permanently residing and domiciled aboard. ii. Non -Resident accounts of Pakistan Nationals who are abroad for short vis its. iii. Non -Resident Accounts of Foreign Nationals residing abroad. iv. Non -Resident accounts of Foreign Nationals ordinarily resident in Pakistan but gone abroad for short visit. 4.14.2 Change in Status of Accounts: Non -Resident Accounts in the following categories sh ould be treated as resident on account holder’s permanent return or his temporary visit to Pakistan for which permission of the State Ban k is not necessary and there is no restriction on the account holders operating these accounts: - i. Non -Resident accounts of Pakistani Nationals who had gone abroad for short visit. ii. Non -Resident accounts of foreign nationals who are permanently residing and domiciled in Pakistan but had gone abroad on temporary visit. iii. Non -Resident accounts of Pakistani nationals permanently r esiding and domiciled abroad. iv. Non -Resident accounts of foreign nationals residing abroad. v. The accounts are to be re -designated as Non -Resident immediately after an account holder leaves the country. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 79 Non -Resident Accounts of Pakistanis who come s to Pakista n on temporary visits are to be treated as Resident Account during the period of their short visit without prior approval of State Bank of Pakistan. The accounts are to be re -designated as Non -Resident immediately after the account holder leaves the countr y. 4.14.3 Accounts of United Nations and its Organizations: In terms of Section 05 of Article -II of the Schedule appended to the United Nations (Privileges & Immunities) Act, 1948 the accounts of United Nations and its organizations are free from financial contr ols. Therefore, branches shall treat these accounts as “Resident Accounts”. 4.14.4 Joint Accounts of Resident and Non -Residents: There is no restriction on non -residents maintaining accounts jointly with residents. These accounts should be treated as non-resident accounts irrespective of the fact that whether these accounts are to be operated solely or jointly by the residents. 4.14.5 Opening of New Non -Resi dent Accounts of Persons Other t han Banks: New non -resident accounts in the names of persons or firms or companies other than banks may be opened without the prior approval of the State Bank where accounts are to be opened with funds received from abroad through banking channel or with Rupee funds which have been accepted by the State Bank for remittance a broad. Reference of the Monthly Exchange Returns or the State Bank approval number, as the case may be, should be quoted in the relevant Form A -7 (Annexure I) covering the credit. 4.14.6 Accounts of Foreign Nationals Resident in Pakist an- Form “Q.A.22”: The accounts of all foreign nationals who are resident in Pakistan and the accounts of companies or firms (other than banks) whose head offices or controlling interests are outside Pakistan but the accounts are operated on by persons in Pakistan may be treated as resident accounts. The account holders or persons in Pakistan authorized to operate on such accounts must sign Form “Q.A.22” ( Annexure II) accounts. The said form should be obtained by the branches fro m the customers in duplicate and a copy should be forwarded to the State Bank for record as and when the account is opened. Prior approval of the State Bank for opening such accounts is not necessary. In case of non -resident accounts, declaration on form “Q.A.22” is not necessary. 4.14.7 Issuance of MCB ATM/Smart Cards to Non -Resident Rupee Accounts: Branches are authorized to issue MCB ATM/Smart Cards as well as supplementary MCB ATM/Smart Card in order to facilitate the non -resident account holders. The withdr awals through MCB ATM/Smart Cards should, however, only be allowed in Pakistan. The existing requirement of filling in Form A -7 (Annexure I) on account of all withdrawals in Pak Rupee from the above accounts for personal expenses would not be applicable to the ATM transactions. However, the banks would be required to submit a consolidated statement showing ATM transactions in the said accounts to the Director, Statistics Department, SBP, Karachi on monthly basis. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 80 4.14.8 Operation on Non -Resident Accounts of Persons, Firms and Companies other than Banks: Unless it is prescribed otherwise by the State Bank in respect of any particular Rupee Non -Resident Account of persons, firms and companies other than banks, Authorized Dealers may raise following debits / credits to Non -Resident Accounts: Debits: i. Payments on account of the account holder direct to the institutions concerned in respect of insurance prem ium, club bills or other payments of a regular nature provided payments are supported by bills and vouchers. ii. Government and Municipal dues provided payments are supported by official claims and payments are made directly to the Government or Municipal agen cies. iii. Debits on account of disbursements in Pakistan limited to the extent of the funds received from abroad through banking channel. iv. Debits representing payments through cheques direct to the carriers or the travel agents for travel within the country by rail or air for self, wife, children and parents and against valid “P” form approvals for travel abroad. v. Debits on account of purchase of shares of public limited companies and / or securities of the Government of Pakistan, NIT Units, Prize Bonds, Defence Savings Certificates etc., provided such shares / public securities are purchased by the Authorized Dealers themselves on behalf of the account holder on the basis of non-repatriation of capital, dividend / interest etc. and registered at their Pakistan ad dress and also retained by the Authorized Dealers in their custody on behalf of their constituents concerned so long as he resides outside Pakistan. Sale proceeds of such investments and dividends / interest etc., accruing thereon should be credited to the Non -Resident Account only. vi. Payments against bills for hotel expenses in Pakistan of the account holder and his family member provided payment is being made direct to the hotel by cheque. The concession is restricted to first class hotels only. vii. Cheques dra wn for self or in favor of his dependents resident in Pakistan for maintenance. viii. Debits in reversal of previous credits. ix. Debits in respect of approved remittances in foreign exchange. x. Payments of installments of loans directly to the financial institution from whom the account holder had obtained loan. Credits: i. Receipts on account of salary, allowances, bonus, commission etc. directly from the employers by cheque. ii. Dividend and interest income on investment in shares and securities directly from the Company by cheque. iii. Income from landed property and agricultural rent against identity of the depositor. iv. Credits of remittances received from abroad through banking channel. v. Interest accrued on the amount lying in Non -Resident Accounts. vi. Amounts representing the mat urity proceeds / surrender / paid up value of insurance policies and proceeds of the shares of the public limited companies and / or securities of Govt. of Pakistan purchased. vii. Refund of amounts previously debited or over charged. viii. Sale proceeds of landed pr operty as evidenced from the registered sale deed. All other debits and credits require prior approval of the State Bank of Pakistan. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 81 4.15 NEW FOREIGN CURRENCY ACCOUNTS SCHEME, (F. E. 25) SBP have allowed opening of new foreign currency accounts under new scheme with effect from 22 -June -1998 by Residents as well as Non -Residents, Pakistani and Foreign Nationals, Firms, Companies and other Legal Entities. 4.15.1 Opening of Account: Branches authorized to deal in Foreign Exchange or having restricted license for ha ndling Foreign Currency Accounts can open new Foreign Currency Accounts under new scheme with the prescribed initial deposit from time to time. Presently branches are allowed to open following types of Accounts in US Dollars, GB Ponds, Euro & Japanese Yen . i. Current Deposit Accounts ii. Savings Account iii. Fixed Deposit Account (Only in US Dollar) Formalities / precautions applicable for opening of all types of Pak Rupee accounts mentioned in this Manual are also to be observed in case of Foreign Currency Accounts. 4.15.2 Eligibility for Opening of New Foreign Currency Accounts: Accounts can be opened in the name of Resident Pakistani Nationals, Resident Firms / Companies including foreign nationals, firms, companies and other legal entities. Joint Accounts of individuals or accounts of Proprietorship and Partnership concerns can also be opened. Ref to Cir. Letter No. 26/EPP.16(326)NFCA -2000 , All Banks are advised to obtain an undertaking from Corporate bodies/legal entities that their foreign currency balances maintained with them are being fed exclusively from the remittances received from abroad and not through the foreign currency funds generated fr om kerb (open) market. 4.15.3 Acceptance of Deposits: Deposits can be accepted in the shape of foreign currency notes of the same currency in which the account is opened or other acceptable foreign currency notes at the prevailing exchange conversion rate. i. Foreign Currency Demand Drafts. ii. Inward Remittances received in the name of account -holder. Foreign Exchange obtained/earned in the following cases cannot be deposited in Foreign Currency Accounts. i. Travelers Cheques issued in Pakistan. ii. Exchange released by SBP for any specific purpose. iii. Foreign exchange representing sale proceeds of goods exported from Pakistan. iv. Payments received for services rendered in Pakistan. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 82 4.15.4 Withdrawals from Foreign Currency Account: Withdrawal from Foreign Currency Current Accounts is allowed by cheque for any amount within the available balance in the account. Payment can be made in the Foreign Currency Notes or in equivalent Pak Rupees 4.15.5 Payment of Profit: i. Rate of profit on various types of deposits varies according to the period o f deposits as well as status of accounts (i.e. old frozen accounts / new foreign currency accounts). Rates of profit are determined and declared by Trea sury & FX Group , through their circulars on the basis of av erage London Inter Bank Offer Rate (LIBOR) pr ovided b y British Bankers’ Association . ii. Provision for payment of profit is made by branches at the end of each month. However, payment of profit on outstanding SNDs/TDRs is made at the time of encashment of these deposits whereas payment of profit on PLS a ccounts is credited on half yearly basis as per declared rate on 30th June and 31st December each year. 4.16 DECEASED ACCOUNT With the death of customer, the mandate comes to an end. Operation of the Bank account is ceased immediately on receipt of information of the death of the customer and no withdrawal is allowed except in the joint account where the operational instructions of survivorship apply. i. As soon as information is received either through newspaper or some reliable source about the death of an account holder, the date of death, source of information and time of information received shall be noted and account shall be immediately marked as “Deceased Accounts”. ii. All operations in the account shall be stopped, no debits will be allowed in the account however, proceeds of any cheque/bills sent for clearance/ collection shall be credited into the deceased account. iii. On realiza tion of Cheque/Bill, collection and postages charges of the bank shall be debited from the Deceased Customer’s account. iv. In case of PLS Savings Account of a deceased person profit shall continue to be payable till the balance is finally paid off to the lega l heirs. v. Unused cheques should be obtained from legal heirs of the deceased account holder and should be destroyed/ discarded. In case un -used cheques are not returned, a letter should be taken from legal heirs stating reason for non -submission of un -used cheques. vi. Branches should invariably make payment of the amount lying in the account of the deceased account holder only by means of a Payment Order issued in the joint names of all the heirs disclosed in the indemnity bond. 4.16.1 Payment of Credit Balance aga inst Succession Certificate: The request received from the legal heirs for release / payment of credit balance against production of Succession Certificate (copies) duly verified by the Branch through Bank’s authorized representative will be referred to th e Regional Office along with a Certificate regarding satisfaction of claimant by virtue of Succession Certificate. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 83 Regional Head can facilitate the request of PKR 100,000/ - per case while the request exceeding PKR 100,000/ - will be forwarded by the Regio nal Office to the Circle Office and will be approved by the General Manager on proper scrutiny and after being satisfied. If the Succession Certificate has been issued in the joint names without mentioning the share of the recipient the payment may be made in the joint names of all the recipients involved. In such cases if the recipients wish to authorize any one of them to receive and collect the amount, the payment will be made against Power of Attorney duly attested / authenticated by a Notary Public. In all cases payment should be made after proper verification and identification of the heirs or their attorney holding proper and valid Power of Attorney. 4.16.2 Payment of Credit Balance without Succession Certificate: i. The credit balance lying in the account of a Deceased Customer is paid to the legal heirs either on production of Succession Certificate or against Bond of Indemnity -cum -Guarantee . ii. Request for payment of amount up to PKR 100,000/ - without Succession Certificate can be entertained by the Branches ag ainst Bond of Indemnity -cum -Guarantee. iii. The legal heirs may request for paym ent of balance not exceeding PKR 100,000/ - without production of Succession Certificates. The request of the legal heirs may be entertained provided following documents are produce d: Letter of Indemnity -Cum -Guarantee: Letter of Indemnity -cum -Guarantee on appropriate stamp paper according to the provincial stamp duty, contains under noted two parts: Part I: of the letter covers application from the legal heirs and is signed by all th e adult legal heirs or by a natural guardian on behalf of the Minor legal heir(s). Part II: of the letter relates to the Guarantors for the legal heirs and is signed by two respectable persons maintaining Accounts in a Bank, preferably in one of our Branches. Two witnesses will also sign -off the Letter. Death Certificate: Issued by the competent authority confirming the death of the customer will be obtained. On receipt of the above documents, Branch Manager will compile a report on the financial standing and integrity of the guarantors/ indemnifiers and will retai n the originals and forward the photocopies thereof to the Regional Head along -with his report on financial standing and integrity of the guarantors/ indemnifiers and a Certificate regarding satisfaction about claimants. The Regional Head can approve cases of payment up to PKR 50,000 /- while General Manager is empowered to release an amount up to PKR 100,000/ - The Branch, Regional Head or General Manager may, if any of them is not satisfied, at their own discretion, insist for production of Succession Certificate even if amount involved is within their limits. 4.16.3 Document Retention and Mode of Payment: The photocopy of Account Opening Form, attested copy of succession Certificate/Original Letter of Indemnity -cum -Guarantee and other relevant documents will be placed in a separate folder and kept in safe custody under dual control. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 84 After obtaining necessary approval/s from Regional/General Manager , branch will debit the deceased’s customer’s account and release the payment through Payment Order as per the terms of Succession Certificate/ Lette r of Indemnity cum Guarantee. After the release of payment to heirs, account shall be immediately closed. 4.16.4 Profit Payable to Deceased Customer’s Account: The Profit on PLS Savings Accounts of the Deceased Customers shall invariably be applied at the rates announced by the Bank from time to time, on half yearly basis until such time the funds are released to the legal heirs. In most of the cases, Succession Certificates granted by the Court of competent jurisdiction provides for payment of Profit/Interest. E ven in such cases where the words Profit/Interest were not mentioned, the Bank may pay the same at its discretion, even in the cases where the payment is released without Succession Certificate. 4.17 ACCOUNT CLOSURE In SYMBOLS, account closure option is avail able in Branch Teller Module as well as Retail Banking Module. i. Branch Teller Module > Transactions> Non -Financial Transaction > Account Closure (Screen # BT48) ii. Retail Banking Module: (Deposits) > Transactions > Non -Value Transaction > Account Closure (Screen # RB41). System only closes an account but the Client remains open in the system and it cannot be closed. On the basis of the Client number, customers can any time open another account with the Bank. 4.17.1 Pre-formatted Account Closure Request Letter: To inculcate the control culture and to ensure uniformity of account closure requests which meets the institutional and regulatory requirements the format of ‘customer request’ has been standardized. The standardized Account Closure Request Letter which is assigned a proper stationery code SF -2 has the following distinctive feature: i. Provision to accommodate account closure request of both PKR and FCY accounts. ii. Contains a comprehensive checklist ( printed on the back ) to facilitate the branch in ensuring fulfillment of the required tasks/approvals from other departments before closure of account. iii. Contains a disclaimer clause to be signed by the customer as ‘Full & Final Settlement’ of his/her account. iv. The checklist on the back of Account Closure Request Letter must be completed and signed by Branch Operations Manager & Branch Manager before closing the account. Note: i. It is mandatory for the branches to ensure that customer request for account closure is obtained on ‘Pre-formatted Request Letter SF -2’ except fo r the instances where customer request for account closure is received via mail. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 85 ii. Once the account has been closed in the system, the same account cannot and should not be activated. If the customer requests for activation of a closed account, branches a re instructed to decline customer request and open a new relationship in the system with a new account number. 4.17.2 Account Closure Instruction Received Via Mail: i. Customer written request for closure of account if received by mail will be accepted by the branch (branches will NOT insist for request on Standardized ‘Account Closure Letter’ - SF-2). ii. Operations Manager should ensure that Account closure application received along with the unused leaves of cheque books/MCB ATM/Smart Card(s). iii. Debit customer’s account and mark account as closed after verification of signature. iv. Prepare Payment Order or d emand draft for the entire balance after deduction of remittance and postages charges as per the tariff & dispatch the same at the address recorded with the Bank. 4.17.3 Payment of Profit on Closed Account: Profit on PLS Accounts which are closed before declara tion of half yearly profit rates, profit will be paid on the Provisional rates advised to the bra nches for that specific period. Non compliance to the same can attract penal ty by SBP. 4.18 PROCEDURE FOR ACCOUN T CLOSURE Customer : Presents duly completed Accoun t Closure Request Application (SF-2) to the CSO giving the reasons for account closure. Designated Officer: Receives account closure application (SF -2) from customer and forward it to Authorized Officer for action. Operations Manager: i. Verifies customer’s signature on Account Closure application (SF -2) and perform following steps: ii. Check if any ‘restraint’ is marked on the account. In case of a restraint was marked based on customer’s instructions then inform the customer to submit a written application to remove the restraint from the account . {In case the restraint was marked internally by the bank (i.e. other than the customer originated instructions) it should not be removed without the written consent of the authority who had asked to mar k the restraint}. Removal of Restraint: To remove the restraint select the option “Deposit Module >> Transaction >> Account Facility >> Restraint Set up ” (RB51) . Recovery of Account Closure Charges: Recover Account Closure charges and FED as per bank sc hedule of charges from the customer. Recovery of charges through debit to customer account: i. Login Deposit Module >> Value Transaction >> Withdrawal (RB32) Form. ii. Insert Account Number and press F -8 to retrieve account information. iii. Validate account informati on and recover the account closing charges using transaction type “ACSC” and FED with “FEDC” iv. Press F -10 to save the transaction. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 86 4.18 PROCEDURE FOR ACCOUN T CLOSURE Payment of Accrued Interest: i. Select “Deposit Module >> Non -value Transaction >> Account Closure” (RB 41). ii. Insert account number and press F-8 to retrieve the account details. iii. Verify the account details against customer request & press ‘ENTER’. iv. For payment/recovery of interest insert “P” (up to previous day) in payment option field’ and press ENTER. (Do not use other available opti ons i.e. “A” (up to last accrued date) & “F” (Forfeit Interest Accrued ). v. System will show the ‘unpaid interest accrued amount’ and Tax thereon (if applicable). Net interest will be added in the closing balance of the account. vi. If the balance amount in the account exceeds PKR 25,000 and customer requests for its payment in ‘cash’ then calculate applicable Cash Withdrawal charges manually and obtain cheque from customer for remaining balance amount. vii. Perform the transaction using Withdrawal option appearing on top of account closure screen and debit the cheque with transaction type “ CQWR ” and Tax with “ WHCW ” respectively. viii. If customer request for transfer of remaining balance in another account then perform the transaction using “Transfer” option available on to p of account closure screen. ix. Before closing the account, ensure that account balance is ‘zero’ and the reason given for closure of account is updated on the system. x. System will prompt the message for confirmation of account closure. Select “Y” and press F -10. xi. System will perform account closure activity & generate the accounting entries. xii. Having closed the account, generate “Closed Account List” from Deposit Module >> Reports >> Daily Activities >> Closed Accounts List (RBA13). xiii. Validate the transaction agai nst customer request and sign off the sheet. xiv. Keep the signed off sheet along with customer request in “Closed Account File” as an audit trail. Note : To avoid any change in ‘Accrued Interest Amount’ all above activities should be completed the same day. i. Operations Manager or Designated Authorized Officer destroys the lower right hand portion of all un - used cheques in order to prevent the misuse of unused cheques. ii. De-activate & discard the punched MCB ATM/Smart Card. iii. File Account Closure application along w ith the cancelled cheque book leaves and Specimen Signature Card. 4.19 NOTICE UNDER SECTION 140 OF THE INCOME TAX ORDIN ANCE - 2001 The Commissioner Income Tax under section 140 of the Income Tax Ordinance – 2001 for the purpose of recovering any tax payable by the taxpayer may, by notice, in writing, require any person to pay to the Commissioner so much of the money as set out in the notice by the date set out in the notice. Branches, on receipt of such notices, are advised to seek further guidance and clarif ication from the Regional Office/Circle Office or Legal Affairs Div and respond accordingly. 4.20 POWER TO CALL FOR IN FORMATIO N BY THE INCOME TAX OFFICER (ITO ) Under Section 176 of the Income Tax Ordinance, 2001, the ITO or any officer authorized in this behalf by the Commissioner or the Central Board of Revenue, may, by notice in writing, require any person including a banking company, to furnish such information or such statements or accounts as may be specified in such notice. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 87 The notice must be in resp ect of a specific account / client. General information required need not be furnished by the Branch and the matter be immediately referred to the Compliance & Control group for guidance. However, it is advised to seek further guidance or clarification fro m the Regional Office/Circle Office or Legal Affairs Division. 4.21 ATTACHMENT OF CREDIT BALANCE (GARNISHEE O RDER) When a creditor has knowledge that the person indebted to him/her has a credit balance in his/her bank account, he/she may obtain a court order f or attachment of the said credit balance in the hands of banker. The person obtaining such order is the “ Judgment Creditor ” and the bank against whom such order is passed is known as “ Garnishee ”. On receipt of such court orders, the branches should take t he following action. i. When an attachment order is received, manager should thoroughly check / verify the names / title of the account, addresses and other particulars and also the fact whether said order is binding on Bank. ii. Right of set -off should be used i f there is any claim of the Bank on the customer. iii. If the court order specifies an amount to be attached, the said amount should be put on hold (refer to Section 2: 4.22 - Procedure for Marking Funds on Hold ) and customer will be at liberty to utilize remaining balance in the account. iv. If order does not specify the amount then withdrawals from the account of said customer should be stopped altoget her by marking restraint type SW v. Branch Manager upon receiving Garnishee Orders marks restraint according to the order and immediately send a copy of the Order to the Legal Affairs Division for their opinion before releasing/sending the amount to the court. vi. The customer should be duly intimated about the order and attached amount should be duly deposited with the said court when called upon to do so. 4.22 PROCEDURE FOR MARKIN G FUNDS ON HOLD Concerned Department: Requests the Authorized Person to hold the funds. Authorized Officer: Uses SYMBOLS EOC Module > Deposits > Transactions > Account Facility > Restraint Setup. Inserts account number and other mandatory information and execute the query. i. Marks FOH in the Restraint Type ii. Enters today’s date iii. Restraint Expiry date is auto -selected by the system i.e., “year 2999” iv. New Input box Opens  Enters the amount to be held  Enters the narrative mentioning the Department and Reason for the funds held.  Click Okay v. Save the restraint by pressing F -10. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 88 4.23 STOP PAYMENT OF CHEQ UES i. Stop Payment instructions should always be obtained in writing on standard form SF -18R duly signed by the Account holder. ii. SF-18 has 2 copies – “A” as Original meant for branch’s record and “B” Carbonized copy to be delivered to the Customer. Terms and conditions are printed on the face of the memo. iii. Operations Manager will verify account hold er’s signature on the form, put ‘date’ and ‘time’ and sign off the SF -18R form. Handover the copy of SF -18R to the customer for his record. iv. After receiving the Stop Payment Request the authorized officer will immediately enter the pertinent details of the cheque, payment of which has been stopped, in the system. v. If a Cheque is presented, payment of which has been stopped, the stamp “Payment Stopped by Drawer” must be affixed on the top left -hand corner of the Cheque or written in red ink and returned to the Payee with Cheque Return Memo. In such cases, Stop Payment instructions shall be cancelled from the Account with a note “Cheque Returned on (Date & Time)” duly initialed by the Authorized Officer. vi. When the customer withdraws his Stop Payment instruction s or the cheque in question is returned unpaid by the branch, suitable remarks indicating withdrawal of instructions or return of the cheque (as the case may be) should be recorded on the copy “A” of SF -18 in bold letters in red ink. vii. Stop Payment Applicati ons / Letters received from the Customers / Accountholders shall be filed in the “Stop Payment File”. 4.23.1 Important points for consideration: i. Stop Payment application be routed through Dak Inward Register and affixed with Dak Receiving Rubber Stamp thereon along with Dak Received Number. ii. While receiving the Stop Payment application it should be confirmed from the system that the cheques required to be stopped for payments have already not been paid. iii. In such cases the A/C hold er should be informed accordingly on the spot. iv. In case of Stop Payment instructions received through FAX, intimation through Letter/Fax should immediately be sent to account holder concerned that we have noted your instructions. 4.23.2 Procedure to mark Stop Pay ment: Branch Teller Module: Transactions >> Financial Transactions >> Restraint Setup Screen # BT43 i. Enter Account number, press enter. ii. Press F9 for List of Values (LOVs) ; select SCB- Stop Cheque - BT in the field of Restraint Type. iii. Press enter; effective d ate will appear in the field of “Start Date”. iv. Pop-up Box will appear on the screen, enter Cheque number(s). Input narration as “Cheque Stop Payment” and also mention the request time given on the form. v. System will automatically select End date (100 years from the system date) vi. Press F10 or click on save icon. Similar option is also available in Enterprise Operation Center (EOC) : Deposit Module >> Transactions >> Account Facility >> Restraint Setup Screen RB51. SCB Stop Cheque i. BT must be selected in the field of Restraint Type for changing the status of cheque from ‘Active’ to ‘Stopped’. ii. Please do not use Screen RB 1814 ; as any cheque marked ‘stop ’ from this screen will remain stop ped only for few days and after that reque st status will automatically be changed into Expired. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 89 Note: BOMs are advised to review the request received every day to ensure all requests are properly marked in the system. 4.23.3 Revoking/ Removal of Stop Payment Instruction : i. In case of application for revoking the Stop Payment instructions the Branch Manager should follow the same procedure as for receiving the application for Stop Payment. The Manager should properly verify the cheque number minutely, record in application fo r revoking of Stopped Cheques and remove the instructions of Stop Payment cheques according to the application of revoking instructions. ii. In case of any instruction in respect of Stop Payment received verbally over telephone, we have to take precautionary measures accordingly but no commitment will be made by us over telephone to avoid any misunderstanding between the Customer and Bank. The presence of Customer is required to complete the Bank’s procedure (in writing) for the stop payment of cheques. iii. As per revised specimen of Stop Payment Memo (SF -18) condition is given that the Stop Payment instructions / marking should be invalid after expiry of 06 months from the date of delivery of SF -18, which may be considered. iv. Branch will be fully responsible for the payment of any Stale/ Post dated / Out of date cheque (after 6 months since the date of its issuance). Payment of which was stopped by the account holder. v. Stop payment against a blank cheque/ cheque book will remain enforce continuously. 4.24 PROCEDURE TO MA RK ACCOUNT ACTIVITY SEIZE “Account Activity Seize” option in SYMBOLS is used by the branches in case where Customer or Competent Authority requests to seize the account in order to restrict the financial transactions. i. Designated Authorized Officer (DAO) selects Transactions >> Financial Transactions >> Restraint setup Screen # BT43. ii. Enter or select Account number from the List of Values (LOV), select “AAS - Account Activity Seize” in the field of Restraint Type. iii. Press enter, effective date appears in the field of “Start Date” iv. Pop-up Box will appear on the screen, input narration as “Account Activity Seize on request of Customer, or any Banking or Government Authority”. Further the name of the officer who authorized to mark activity seize and the code of th e branch performing the activity seize maintenance should also be provided. v. System will automatically select End date. (End date validity should be for a longer period otherwise “Active” status of restraint will be automatically changed into Expired and t ransaction will be executed without any indication/message). vi. Press F10 or click on save icon. 4.25 PROCEDURE TO MARK TAX EXEMPTION RESTRA INT “Tax Exemption Restraint” option is available on SYMBOLS to mark an account for tax exemption. For this purpose, a re straint type “EWT (Exempted WHT) is created. This option can be used by the branches in case where an account genuinely falls under tax exemption category. To facilitate the understanding of branches certain parameters of exemptions provided in Section 49 of the Income Tax Ordinance 2001 are given below: B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 90 4.25.1 Persons / Recipients exempted under the law: i. Federal Government. ii. Provincial Government or; iii. A Local Authority 4.25.2 Persons / Recipients requiring ‘valid tax exemption certificate’ i. A Corporation ii. A Company iii. A Regulatory Authority iv. A Development Authority v. Other body or institution established by or under any law of authority. 4.25.3 Process to mark tax exemption To mark tax exemption restraint the designated Authorized Officer (DAO) will: i. Login SYMBOLS >> Deposit Modul e >> Transaction >> Account Facility >> Restraint Setup (RB51). ii. Insert account number and press F8, system will display account details that needs to be validated. iii. Input restraint type “EWT” and press enter. iv. Input start date i.e. day which customer submit ted the valid request and press enter. v. Input validity date that is available in FBR provided tax exemption certificate (for category (ii) above) and 31 -Dec-2999 for category (i) above) and press enter. vi. System will show narrative screen. Input the reference number of FBR letter along with its issuance date and press enter. vii. Press F10 to save the transaction. 4.26 REMOVAL OF RESTRAINT FROM ACCOUNT Authorized Officer will use the above mentioned option for removal of restraint from the account. i. Select the specific restraint which needs to be removed from the account on customer or competent authority’s request and click on DELETE icon available on the Tool Bar. ii. Press F10 or click on save icon. Similar option is available on Enterprise Operation Center (EOC) - Deposits Module >> Transactions >> Account Facility >> Restraint Setup Screen # RB51. i. It should be ensured that all requests are marked from any one of the above options. Operations Managers are instructed to daily review the entire Standing Instructions request received in a day in order to ensure that all requests are properly marked in t he system. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 91 4.27 CHANGE IN CUSTOMER A CCOUNT INFORMATION ( MASTER DATA) In case of any change in customer account information i -e Title, Address, Contact #, E -mail; a written request must be taken from the account holder personally. Signatures are verified fr om the SSC. Please note that CUSTOMER’S PRESENCE is MANDATORY for any change in master data . According to the kind of change request, supporting documents (ref to example below) are obtained from the customer in original. BM/ BOM will approve the same with their signature/ stamp along with AS/ IBS number. e.g. In case of Address change either Updated/fresh CNIC with new address is obtained; If address is different than the one given on CNIC, documentary evidence should be obtained which can copy of the Util ity bill OR Original Registration of the new residence OR lease / tenancy agreement/ letter from the landlord along with Landlord NIC/ Utility bill stating that the person lives in his or her property as a tenant etc. The request along with provided docume ntation will be preserved with Account Opening Application or in a separate file maintained with BM/ BOM . B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 92 Chapter 5 CLASSIFICATION OF AC COUNTS 5.1 DORMANT/ INOPERATIVE ACCOUNTS & FINANCIAL INSTRUME NTS Checking accounts are classified as dormant accounts due to the co nditions mentioned in the table below. The account become dormant if there is no activity in the account (excluding system generated activity e.g. Profit disbursement) shall be classified and flagged by the system as “dormant accounts” . (No financial entry is passed) . However half yearly profit shall continue to be applied as usual on Savings accounts only. Type of Account Dormancy Inoperative Un-Claimed (Escheated) Current Accounts 6 Months 2 Years 10 Years Saving Accounts 1 Year 3 Years 10 Years Financial Instruments - - 3 years from Date of Issuance Note : Accounts opened and maintained by School Management Committees (SMCs) duly constituted by Education Department, Government Sindh shall not be transferred / flagged as “Dormant” and shall be exempted from levy of ‘Service Charges’ on account of non maintenance of minimum balance requirement. (BPRD Circular Letter # 02 dated Jan 25, 2010) 5.2 UNCLAIMED DEPOSIT S & FINANCIAL INSTRUME NTS A debt payable either in Pa kistani currency or any other (foreign) currency is owing by a banking company by reason of a deposit (time / demand deposit or any other kind of deposit) or a financial instrument (Pay slips / Pay orders / DDs / TTs / Travelers Cheques or any o ther financial instrument) not being recorded in the nam e of a minor or a government or a court of law , in respect of which no transaction has taken place and non statement of account has been requested or acknowledged by the creditor during a period of 10 year s as reckoned under Sub -section (1) of Section 31 of BCO 1962 will be classified as unclaimed deposit / instrument. For details refer to i. BPD Circular Letter No. 07 dated July 21, 2006 , ii. BP&RD (SLD -02)/317/X/207-3214 dated April 05, 2007 & iii. BPD Circular Let ter No. 37 dated December 03, 2009 ). 5.2.1 Unclaimed Deposit s – Savings & Current Accounts: Current & Savings Account s not operated for 10 years from the date of last activity in the account (excluding system generated activity e.g. Profit disbursement) will be classified and flagged by the system as “Unclaimed Deposit Account ”. (Accounts are just ‘flagged’ by the system as un -claimed and n o financial entry is passed ). Note : As per SBP BPRD Circular 02 of Jan 05, 2010 banks are NOT allowed to deduct ‘Service Charges’ on customer accounts which are classified as Dormant, In -operative & un -claimed. And it is further notified that B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 93 Bank Statement for such accounts will also not be dispatched after the change of status from active to Dormant. 5.2.2 Unclaimed Instruments: Bank Drafts, Government Drafts, Payment Orders, Mail Transfers, Fixed and Term Deposits etc , if remains outstanding for 03 years from the date of issuance will be classified as Unclaimed and will be transferred from ‘Outstandin g DDs/POs ’ to “Unclaimed DDs/POs ”. No profit/interest is paid on Term deposits transferred to Unclaimed Accounts. Similarly, no service charges are deducted. Payment of Unclaimed Instruments: Un-paid instruments are moved to Respective Unclaimed GLs after 3 years of issuance and if presented for payment before 10 years (for surrender to SBP) of issuance will be paid after due verification and re-validation at Issuing Branch end. For re -validation of instruments please refer to Section 4, Chapter 2: 2.11 Revalidation of Pay Order / Demand Draft 5.3 MARKING OF RESTRAINT FOR E XEMPTION FROM UNCLAIMED To mark the accounts which are exempted from unclaimed category for surrendering of funds to SBP ( refer to Section 2: 5.5 Surrender of Unclaimed De posit to SBP ) a restraint type ( “EUN’ – Exempted Unclaimed Accounts ) is created . Accounts falling under this category which are classified by the system as unclaimed accounts should be identified from the list of ‘unclaimed accounts’ for marking the restraint. Tagging of ‘EUN’ restraint in SYMBOLS will be performed a s under: i. Deposit Module >>>> Transaction >>>> Account facility >>>> Restraint set up (RB51). ii. Insert account number & press F -8. System will provide account details that need to be verified. iii. Input restraint t ype “EUN” and press Enter. iv. System will ask to input start date. Insert the account opening dat e (DD-MMM -YYYY) and press Enter. (Account opening date can be obtained through – Deposit Module >>>> Enquiry >>>> Account Details >>>> Enter (RB7A). v. Input End Dat e as 31 -Dec-2999 (DD -MMM -YYYY). vi. System will show ‘narrative screen’. Input the exemption category i.e. Minor Account, Government Organization, Deposit favoring Court of Law as applicable. vii. Press F -10 to save the transaction. 5.4 ACTIVATION & OPERATION IN DORM ANT, INOPERATIVE & U NCLAIMED DEPOSIT ACCOUNTS Prime responsibility to approve operation and activation of a Dormant, Inoperative and Unclaimed (not yet surrendered to SBP) Accounts as well as payment of a claim lies with PARENT BRANCH ONLY . i. Any request for operation in above accounts should be initiated in-person by the account holder in writing and must be supported by attested copy of valid CNIC (If customer CNIC do not exist in the system, then it is required to verif y it’s genuineness through NADRA’s online VeriSys system ). To evidence the verification, a copy of customer’s CNIC should be printed from VeriSys and retain the same as a record and update customer’s record with CNIC number on the s ystem . Requests received from person other than the account holder himself should not be entertained. ii. Request received by the parent branch for execution of any customer initiated transaction (financial or non-financial) will invariably be referred to the Branch Manager who will scrutinize the request perso nally and satisfy himself beyond doubts as to the genuineness thereof. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 94 iii. After being so satisfied, the Branch Manager and Branch Operations Manager will jointly approve the operation in Dormant, Inoperative and Unclaimed accounts OR will pay to a rightful cl aimant by means of Paym ent Order only, as the case may be. iv. In case any particular does not match with NADRA records with the CNIC provided by the customer, account should not be activated till complete information is not updated on NADRA VeriSys . v. In case wh ere customer is reported as having dual CNIC’s as per NADRA VeriSys , only valid CNIC should be obtained at the time of activation of Dormant Account and this account should be marked as High Risk and should be monitored at regular intervals. Further branch es must ensure that the duplicate CNIC has been surrendered. vi. Where customer is holding dual CNIC as per NADRA VeriSys , and the account was opened against surrendered CNIC, branch should immediately close the account after completing all the formalities / requirements in light of instructions provided in CDD / AML handbook. 5.4.1 In case of Cross Branch Transaction: If customer approaches a Branch other than the ‘parent ’ branch , for operation in Dormant, Inoperative and Unclaimed accounts the concerned branch before execution of customer initiated transaction (financial or non -financial), is required to obtain written approval from the parent branch. For this purpose : i. Concerned branch will f orward customer’s written request to the Branch Manager of parent branch via fax or e -mail with scanned copy of customer request. ii. Branch Manager of parent branch will verify customer signature on customer ’s request, affix signature verification stamp and scrutinize the request personally , and satisfy himself beyond doubts as to the genuineness thereof. Also check the account for complete documentation and KYC / AML requirements. iii. After being so satisfied, the customer request will be jointly approved by the Branch Manager and Branch Operations Manager of the parent branch menti oning their IBS number and will forward the customer request back to the concerned branch thr ough fax or e -mail. iv. This will be done only where the customer visits the paying branch in person. v. Parent branch should retain a copy of the duly approved customer request as a n evidence and record in its dormant account activation file. vi. To ensure better customer service staff at both the branches should ensure that process is completed in shortest possible time. vii. Account status will not be changed to ‘normal’ unti l customer personally performs a financial transaction (deposit or withdrawal) in his account on the counter. viii. Branches will print the “Change in Account Status Report – KM0099 ” on daily basis and file it chronologically as a branch record and for onward review by ROM. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 95 5.4.2 In case of Inward Remittance in Dormant Account: When the Remitter and Beneficiary is the same person: If remittance is received in an account which is dorman t, but the remittance has been sent by the beneficiary himself, the bank will make the account operative and accept the remittance PROVIDED the account is normal otherwise i.e., the account was opened without any discrepancies and a valid CNIC is available for the account. In case the account has discrepancies, BM/ BOM will ensure to complete all formalities to regularize the account. When the Remitter and Beneficiary are different person s: If remittance is received in an account which is dormant and the remittance received has NOT been sent by the beneficiary himself, the Branch Manager/ Branch Operations Manager should make full efforts to contact the customer and complete all formalities to regularize the account. After being satisfied with the purp ose of the remittance and obtaining all relevant information/ documents to regularize the account, Account will be activated a nd the remittance will be accepted Note: It is the prime responsibility of the supervisor to validate and read the “override con ditions” carefully and incase system prompts the message “Account is dormant or inactive”, he must ensure, before authorizing the transaction that all required formalities as discussed above have already been completed. 5.4.3 Review of Activation process & Acti vity over Dormant, Inactive & Un -Claimed Accounts: Regional Operations Manager s (ROM s) during their monthly visit of branches will review the ‘activation’ process and activity performed over Dormant, Inactive and Un -claimed account during the month . For this purpose ROM will review “ KM0099 - Change in Account Status Report s of the branch and will ensure that the above requirements are strictly followed. T o evidence the review, ROMs are required to sign off the related reports. 5.5 SURRENDER OF UNCLAIM ED DE POSIT TO SBP 5.5.1 Reporting Of Unclaimed Deposits to Head Office by Branches: i. Branches are required to report and transfer LCY and Frozen / Unfrozen FCY unclaimed deposits/instruments (excluding deposits/instruments recorded in the name of minor or Government Department/Agency, or Court of Law) outstanding in their books as on Dec 31 at each calendar year to H.O within seven (07) days after the close of each calendar year. ii. For transferring the unclaimed LCY deposits use Transaction Code 3334 . For surrender of F rozen FCY deposits, in coordination with Treasury Back Office, valid contract rates will be provided to branches in the last week of February. Branches will raise credit advices using Transaction Code 3366 and send the same through Regional Offices under i ntimation to treasury back office. For detail Batch Processing, please refer to Section 7: 1.4 Transaction processing In GL Module iii. Branches are required to report the same via thei r respective Regional Offices. Regional Office MUST ensure the information being reported are checked and verified by Area Audit Head and Regional Manager to avoid SBP criticism and penal action. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 96 iv. SBP Reporting Unit will consolidate the details of all uncla imed deposits/ instruments at country level and will Submit report in last week of January and surrender funds of unclaimed deposits/instruments in first week of April to SBP Note: i. For detailed instructions & required formats, please refer to  SBP BPRD Master Circula r No 07 dated July 21, 2006  COD Circular No. POK/CO D/FEX/46 dated August 07, 2006  BPRD Circular Le tter No.16 dated May 27, 2009  COD Circular No.COD/ GEN/2009 -136 dated June 01,2009 ii. Reporting of any irrelevant or inconsistent data in violation of provision of law and laid down procedure for unclaimed deposits shall invoke the penal provisions of law. 5.5.2 Notice to the Holder of Unclaimed Deposits/ Instruments: i. Upon completion of a ten year time period as stipulated in relevant provision of Sub -section (1) of Section 31 of BCO 1962, branches are required to serve a three month notice in writing by registered post acknowledgement due to the creditor or the beneficiary of the deposit /instrument on his/her address last made known to the bank. ii. Apart fr om giving a notice to the respective account holder at the end of 10 year period, branches will also make cognizable effort from time to time to contact such account holders where there has been no activity in the respective accounts for a considerable per iod. iii. Branches are required to maintain complete record of letters/ env elopes etc posted at the address of the Unclaimed Deposit/instrument holder. iv. Branches are also required to intimate in writing to the government departments/agencies, court of law and mi nors (after acquiring the age of maturity) for settlement of their deposits/ instruments lying with them for more than 10 years. 5.5.3 Preservation of Documents: Branches are required to preserve all signature cards and documents indicating the “Signing Authori ties” given to them and other documents relating to the debt or instrument in the dual custody of Operations Manager and Designated Authorized Officer until informed by SBP in writing that they need not be preserved the same any longer. 5.5.4 Display of Unclaim ed Deposits Information: An updated list of Unclaimed Deposits surrendered to State Bank of Pakistan should be kept available with CSO and a notice to this effect should be displayed on the notice board of the branch for customer information. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 97 5.6 REFUND P ROCEDURE FOR UNCLAIM ED DEPOSITS SURRENDE RED TO SBP Claims lodged with the Branches for refund of Unclaimed Deposits / Instruments already transferred to State Bank of Pakistan (SBP) will be forwarded to Centralized Operations Division, SBP Reporting Unit, Karachi through respective Circle Offices for onward submission to State Bank of Pakistan. Before submitting any claim request to SBP Reporting Unit it is the concerned Branch Manager’s responsibility to satisfy itself on the genuineness of the customer/c lient and will ensure that: i. Customer / client signatures are verified. ii. Necessary documents are obtained from customer and verified from branch record. iii. Certificate on Annexure III (SBP Revised Annexure “C”) also available with BPRD Circular Letter No. 20 dated July 29, 2009 (COD Circular No. PO/COD/GEN/204 dated August 04, 2009) is prepared with all pertinent details. This certificate MUST be signed by the Branch Manager and Head of Internal Control (Audit) iv. Having completed the above requirements, forward the claim request Annexure III (Certificate on SBP specified Revised Annexure C) along with all necessary documents) to SBP Reporting Unit through Circle office under their cover lette r. 5.6.1 Required Documents i. Original application for refund along with verification of attested signature/thumb impression of the claimant by the Branch Operations Manager or Designated Authorized Officer containing signature and stamp with name/designation/ba nk name/branch name. ii. Copy of 3 months notice served by the branch to the holder of unclaimed deposit/instrument. Duly attested, signed and stamped by branch manager showing his/her name and designation. iii. Attested copy of CNIC of the claimant with signature /name/ designation of branch manager. iv. Copy of the relevant portion of ( SBP Annexure - A) detail of Unclaimed Deposits Surrendered to SBP as available on SBP website. v. Succession Certificate (in case of deceased customer). Duly attested by branch manager and Area Audit Head and stamped showing name and designations of the signatories. vi. Indemnity bond on PKR 100/= stamp paper duly signed by Branch manager and Area Audit Head, in case of any inconsistency/error/omission in above noted documents. On receipt of c onfirmation from Centralized Operations Division (SBP Reporting Unit) in coordination with SBP Reconciliation Department, of receipt of proceeds from State Bank of Pakistan, same shall be paid to the Claimant. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 98 Chapter 6 CHEQUE B OOK MANAGEMENT 6.1 GENERAL INSTRUCTIONS FOR NEW ACCOUNT HOLD ERS i. To ensure compliance of KYC Policy, cheque books to the new accountholders shall ONLY be issued on production of Letter of Thanks by the account holder that was dispatched to him/her by CPU/branches on the given address. A copy of Letter of thanks produced by the customer will be filed by the branch along with Account Opening Form. ii. In case of any undelivered ‘Letter of Thanks’ for new account holder, Designated Authorized Officer (DAO) will mark “whereabouts unknown – WAU ” restrain t on the relevant account and file the customer copy of Letter of Thanks returned undelivered along with AOF. For accounts marked WAU , message will pop-up, whenever account holder will make any financial transaction on the branch’s cash counter. Designated Authorized Officer will inform the customer about the same on his/her visit to branch and request him/her to validate the address, In case of incomplete/ incorrect address the customer should submit a written application in order to update the address in order to provide proper verification of his/her whereabouts to the bank. iii. Customer can authorize his/her representative for the collection of cheque book by signing off the same. (Customer’s signature should be duly verified as per the required practice). 6.2 GENERAL INSTRUCTIONS FOR EXISTING ACCOUNT HOLDERS i. Customer is required to approach his/her parent branch for issuance of cheque book. Prior to issuance of a new cheque -book, branch should ensure that the account is not dormant/ blocked or in -operative ii. Cheque book will NOT be issued to a customer if the status of his/her account is marked/flagged as Dormant, Inoperative or Unclaimed. To change the status of account from Dormant, Inoperative or Unclaimed to ‘Active’ refer to Section 1: 5.4 Activation & Operation in Dorm ant, Inoperative & Unclaimed Deposit Accounts iii. Cheque books should be issued to the account holder or his/her authorized representative at the Bank’s counter if designated authorized officer is fully satisfied. However, in case of doubt a call back confirmation may be obtained from the account holder on his/her phone numbers available in bank’s record. Under no circumstance should the cheque book be dispatched through mail. iv. In case of loss of original ‘cheque book requisition slip’ by the customer, the issuance on MF-80R should only be allowed in customer’s personal presence and after proper verification by BOM. v. For Cheque book issuance, t he customer is required to sign on the requisition slip at two different intervals i-e One at the time of requisition and other at the time of delivery allows the bank to keep a stringent control on the issuance of the Cheque books. vi. In case customer require multiple Cheque books and have one requisition slip; a written request must be furnished clearly spelling out total no. of leafs/ cheque books required. Designated Authorized Officer to verify account #/ signatures on the same and get approval from BOM. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 99 6.3 PROCEDURE FOR ISSUAN CE OF CHEQUE BOOKS (NIFT) Customer: Visits the branch and presents cheque book requisition slip. (Available in the existing cheque book) In case of new customers or lost requisition slip/Cheque book, customer fills out a cheque book Requisition slip (MF-80 R) in person . GBO / Designated Of ficer: i. Receives requisition slip from the customer and enquire about the status of existing cheque book/leaves from the customer. In case of lost cheque book/leaves stop payment request should be obtained from the customer and stop payment must be updated on the system before issuance of new cheque book. ii. Confirms Account balance from the Branch Teller Module > Enquiries > Account Enquiries > Account Balance (Screen # BT521). Also confirm the status of account (Active, Dormant, and Inoperative). iii. CBR System does not permit the processor to submit the cheque book request by disabling the “SUBMIT” icon on the screen, if account has dormant or inoperative status. iv. Forwards cheque book requisition slip to Designated Authorized Officer to verify customer’s signature from the Branch Teller module - BT. Designated Authorized Officer/ Branch Operations Manager: i. Verifies customers signature through Branch Teller Module > Transactions> Non -Financial Transactions > Customer Signatory (Screen # BT44). ii. Input accoun t number, press enter, account information & signature appears on the screen. iii. Sign-off and affix stamp “Signature Verified” stamp on the requisition slip. iv. Returns requisition slip to GBO for further processing. GBO / Designated Officer (Input USER): i. Receives Requisition Slip. ii. Log in to Cheque book Registration System (CBR). iii. Input Account Number & click on submit icon. iv. Next screen shows the customer’s account details. (At the bottom of the screen all the Cheque Book Request that are linked to the custo mer’s account are shown along with their status). v. Click to the option “Proceed” available on the above screen. Another screen appears; the top portion shows the SYMBOLS Account Information for the customer. Input “Number of Leaves” as requested by the cust omer. vi. Click on submit icon, system saves the cheque book request with the “New” status. Designated Authorized Officer/ Branch Operation Manager (Approver): i. Approver inserts Login ID and password in the Cheque book Request System in order to approve the cheque book requests. Click on submit icon. ii. Main Menu Bar screen appears, clicks on View Request Tab on the top Menu Bar. iii. Click on customer’s Name link, Cheque book Request Details will appear on the screen. iv. Check details with the Requisition Slips and se lect Application Status as “Accepted” v. Click on “ SUBMIT” ICON. Approver ensures that all the above fields are properly filled by the Input user and approve the Cheque Book Request accordingly. i. Generate “Cheque book Request Report” for the day from CBR syst em. Match the total number of cheque books requested for the day with system generated report. ii. Keep Cheque book Requisition Slips in the Fire Proof Cabinets under Dual Control. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 100 6.3 PROCEDURE FOR ISSUAN CE OF CHEQUE BOOKS (NIFT) Centralized Operations Division (COD): i. Receives Text File from Printer and reconcile the data ii. Main Menu Bar screen appears, clicks on Print Cheque book Tab on the top Menu Bar. iii. Screen will show the details and total number of reques t received from all the Branches. iv. Click on “Print” Icon & system gives following message “The Chequ e book Request has been set to Printed”. v. Details of the Cheque book Request automatically upload in the text file. vi. Forwards Text File to NIFT via e -mail. NIFT: Forwards Text file to Printer for marking “Magnetic Ink Character Recognition” (MICR) & Accoun t Details (Number & Title of Account) Printer: i. Receives cheque book requisition slips from the NIFT for marking MICR codes. ii. After one Business day, delivers the same to the NIFT for onward delivery to respective branches al ong with the covering schedule. iii. Forwards the details (Via e -mail - Text file) of the printed cheque books to the CPU for reconciliation Centralized Operations Division (COD): i. Receives Text File from Printer and updates the cheque series in the system. ii. After uploading the series in the system, “Printed” status automatically changed into “Received”. Designated Authorized Officer: i. Receives processed cheque books from NIFT along with the covering schedule. ii. Mark received on the cheque book covering Schedule (report) and sign off the same. iii. Notes down cheque series on the Cheque book requisition slip on which customer’s signature is already verified. Note down the receipt date on the right corner of the cheque book. iv. Attach requisition slips with the respective cheque books. v. Log onto EOC, enter customer a/c #, transaction code: CBIC and debit customer a/c with charges. vi. Keeps the cheque books in the safe custody under dual control. (Strong Room or Fire Proof Cabinets). vii. Designated Authorized Officer daily delivers the cheque boo k Box to Designated Officer for onward delivery to the customers. 6.4 COLLECTION OF CHEQUE BOOK BY THE CUSTOMER (NIFT) Customer : Visits the branch to collect his/her cheque book. GBO / Designated Officer: i. Retrieves the cheque book from the box. ii. Detach requisition slip from the cheque book. iii. Obtains Customer’s signature (acknowledgment) on the cheque book requisition slip & Issuance Report. iv. Forwards cheque book requisition (acknowledgment) slip to Designated Authorized Officer to verify customer’ s signature from the Branch Teller module - BT. Designated Authorized Officer/ Branch Operation Manager (BOM): i. Ensure that customer signatures on both side/portions of MF -80 match with one another. In case of disagreement between signatures matter will be referred to BOM for guidance. ii. Verifies customers signature through Branch Teller Module > Transactions> Non -Financial Transactions > Customer Signatory (Screen # BT44). B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 101 6.4 COLLECTION OF CHEQUE BOOK BY THE CUSTOMER (NIFT) iii. Input account number, press enter, account information & signature appears on the screen. iv. Sign-off and affix stamp “Signature Verified” stamp on the requisition (acknowledgment) slip. v. Returns requ isition (acknowledgment) slip to GBO / Designated Officer for further processing and activation of the cheque book. vi. Without having a valid authority from the customer/account holder no cheque book should be issued to ‘third party’. GBO / Designated Offic er: i. Ensures that the signatures are duly verified. ii. Delivers the cheque book to the customer. Customer: Collects cheque book and leaves the branch. GBO / Designated Officer: i. On the basis of acknowledgement of delivery of cheque book duly signature verified: ii. Attach Cheque book series with the account by using Branch Teller - BT >> Transactions >> Non - Financial Transactions >> Cheque book Issuance (BT -47) iii. Input or Sel ect Account Number, press enter iv. Input appro priate Size Type e.g. “S” Small, Select Boo k Type as STUB v. System will show Number of Leaves. Input Start Cheque Number, system shows the End Cheque Number. vi. Press F10 or Click on save icon available on the tool bar. vii. GBO / Designated Officer enter Login ID & Password in CBR system in order to change the “Received” Status to “Delivered”. Designated Authorized Officer: i. Receive ‘ Cheque book Issuance Report’ generated by CMIS team through KM and verify the number and details of Cheque books delivered & activated on the report against the requisition (acknowledgment) slips and ensure that all the requirements have been fulfilled before the activation of cheque books in the system. ii. There is a report available in SYMBOLS that provides details of the entir e cheque books issued to all the account holders in the branch since the account opening date. iii. Report is available in Deposit Module >> Reports >> Cheque Processing >> Cheque Number Issued (Screen # RBA22). iv. Back Office files all the cheque book requisiti on slips & Reports in the relevant file for the record. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 102 6.5 ISSUANCE OF MANUAL C HEQUE BOOKS Customer : Visits the branch to get his/her cheque book. Manual cheque book is not issued without prior approval of BM/ BOM. BM/ BOM interviews customer and know the reason why customer need manual cheque book. BM/ BOM signs requisition slip and authorize manual cheque book issuance. Designated Authorized Officer : i. On BM/BOM approval, Designated Authorized Officer takes out the required number of cheque books from the stock after due verification of customer’s signature. ii. Affix Account number stamp on every cheque leaf. iii. Note down the cheque series in the requisition slip and SB -6. iv. Note down the account title & number and issue date in SB -6. v. Obtains customer’s acknowledgement on requisition slip and SB -6 vi. Affix Account # before delivering cheq ue book to customer vii. Hands over cheque book to customer under proper acknowl edgemen t. viii. Log onto EOC, enter customer a/c #, transaction code: CBIC and debit customer a/c with charges. ix. Logs into BT and selects cheque book issuance screen and enters account number, number of leaves and serial number to mark cheque book as 'active' and save record to complete the transaction x. DAO generates and print 'cheque book issuance'/ cheque book activated report and 'RBA 11' report' and verify against NIFT cheque book report/ requisition slip and sign off. Requisition slips are attached with the re port to be sent to BOM for verification/ counter sign off. BOM receives report (cheque book issuance/ cheque book activated report and RB 11 reports) and slip, verify against serial number and sign on the report . 6.6 MANUAL CHEQUE BOOK S TOCK ENTRY & MAINTENANCE Branch receives new stock/consignment of cheque books for issuance without MICR coding from Centralized Stationery Department along with the covering invoice. Branch takes the following steps: i. Designated Authorized Officer matches the cheque bo ok series from the invoice. ii. Checks and verifies that the entire cheque leaves are intact. iii. Affix Branch’s Name stamp on each cheque book. iv. Note down the stock details in the Cheque book Stock & Issuance Register - SB-6 in the separate folios allocated for current and Savings accounts. v. Weekly balance the physical stock of cheque books with the Cheque book Stock Register - SB-6. vi. After issuing manual cheque book to the customer, note down the cheque book series, account title & number in SB -6 in the relevant se ction and simultaneously update the cheque book stock. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 103 6.7 MICR ENCODED CHEQUE BOOKS BY NIFT - FEATURES National Institutional F acilitation Technologies (NIFT) arranges to supply MICR (Magnetic Ink Character Recognition) encoded and personalized cheque books to the branches. The MICR encoded cheque books are issued to the customers of MCB branches at selected centers for checking accounts. Contents of MICR Cod ed Cheque are as under : The serial number of cheques along with other banking data appears at the bottom of printed MICR cheque books. The cheque is numbered as follows: “0014051” 0621 473  : 0000005378 “000” The numbers on cheque as appearing above when decoded will read as under: i. The first seven digit of the cheque from the left hand side on bottom of the cheque i.e. 0014051 denotes serial number of the cheque. ii. The next “3” digit after the “7” digit serial number of cheque from left side i.e. “062” deno tes Bank’s code i.e. MCB Bank Limited. iii. The next “4” digit after the cheque serial number and bank code number i.e. “1473” denotes branch code of the respective branch. iv. The next “10” digit from left hand side after cheque serial number, Bank code and branc h code i.e. 0000005378 denotes Account Number of the customer. v. The last “3” digit from left hand side of the cheque i.e. “000” represents as under:  1st “2” Zero denotes that the type of instrument is cheque.  The last one Zero denotes that currency of the instrument is Pak Rupee. vi. The symbol resembling comma/colon is transaction symbol and will be ignored while reading the numbering. vii. All Computer Operators, data entry operators and concerned office and staff will note that cheque serial number will be read f rom the first “7” digit from the left hand side at the bottom of the cheque and this number will only be noted/recorded wherever cheque serial numbers are required to be recorded and not the entire numbers appearing on the cheque at the bottom line. 6.8 NIFT CHEQUE BOOK STOCK EN TRY & MAINTE NANCE NIFT rider delivers printed cheque books to branch in bag attached with covering schedule (detail Scroll) including customer name, account number, number of leaves, total number of cheque books and type of account. Branch takes the following steps: i. Designated Authorized Officer counts the cheque books received. ii. DAO matches the cheque books against the covering schedule provided by NIFT iii. Checks and verifies that the entire cheque leaves are intact. iv. Mark received on the cheque book covering Schedule and sign off the same. v. DAO segregate cheque books according to the requisition slip vi. Notes down cheque series on the Cheque book requisition slip on which customer’s signature is already verified. vii. Note down the receipt date on the right corner of the cheque book. viii. Attach requisition slips with the respective cheque books. ix. Note down the details (cheque book serial number, account number title and date received from NIFT) in the Issuance Register - SB-6 and sign -off the same. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 104 x. Log onto EOC, enter customer a/c #, transaction code: CBIC and debit customer a/c with charges. xi. Keeps the cheque books in the safe custody under dual control. (Strong Room or Fire Proof Cabinet) xii. Weekly balance the physical stock of cheque books with the Ch eque book Stock Register - SB-6. 6.9 HANDLING OF UNDELIVE RED CHEQUE BOOKS All processed cheque books that remain uncollected by the customers for six months from the date of issuance must be destroyed by the branches after the recovery of Cheque book issuance charges and Excise Duty (If any). i. The cheque -book custodian (Designated Authorized Officer) records the details of all such cheque books in the “Statement of Uncollected Cheque Book Register” specimen as under. ii. STATEMENT OF UNCOLLECTED CHEQUE BOO KS As on _________________________________ S. No Date of Receipt Account Number/ Type Title Of Account Cheque Serial Number 1 2 Signature of Authorized Officer Signature of Operations Manager iii. Branch Operation Manager would approve the list for destruction and sign -off. iv. Custodian (Designated Authorized Officer) destroys the books/leaves in the presence of the Branch Operation Manager and obtains his/her signature. v. Ensure proper notation on cheque -book issuance Report for the books de stroyed. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 105 Chapter 7 TERM DEPOSIT ‘Term deposits ’ are profit -beari ng fixed deposit accounts offered by the bank to its existing and prospect customers . 7.1 TERM DEPOSIT PRODUCTS Presently, following products are being offered by the Bank: i. Flexi Deposits Account (FDA) – Centralized Product ii. Mahana Profit Account (MPA) – Centralized Product iii. Smart Foreign Currency Term Deposits (SFTD) – Non -Centralized iv. Term Deposits Receipts (TDR) – Discontinued – Existing bookings are being phased out v. Special Term Deposits Receipts (STDR) – Discontinued – Existing bookings are being phased out vi. Special Notice Deposits (SND) – Discontinued Centralized products are being handled E2E by Centralized Processing Unit Karachi (CPUK) as per defined frequency, w hereas, the non -centralized products are being handled by the branches manually. 7.2 TERM DEPOSIT APPLICATION FORM (SF 265-NEW) The new TD Application form has the following distinctive features: i. Set of three carbonized copies – (1st copy for CPU Karachi , 2nd copy for Customer and 3rd one for Branch record) . ii. Field for m arking of Zakat and Tax Exemption details. iii. Field to provide the Customer C urrent or Savings account n umber to credit the deposit amount at maturity. iv. Has a facility for marking of pay out frequency. v. Has separate space available to mention the relationship (Client No.) of Customer. 7.3 INSTRUCTIONS FOR TER M DEPOSIT i. All details on the application form should be provided / filled by the customer, clearly indicating the required action on maturity, i.e. principle to be credited back to linked account or rollover with/without profit. ii. Before booking New Term Deposit for the existing customer, branches should ensure that the said application is signed by the accountholder(s)/ authorized signatory. iii. Signature(s) on th e TDA should be verified religiously by the authorized officer of the Bank . iv. Moreover, d esignated Authorized Officer should ensure that the requ ired funds are available in customer’s account before accepting the application for further processing. v. As a sta ndard rule TDs will be established with pre -established interest rates. However, if the branch wishes to offer a better rate (depending on the value of deposit or relationship with the customer) Branch Manager is required to obtain proper written approval from Group Head Business & Treasury for the ‘special rate’ as per the existing process before establishing the TD. vi. Roll over of Term Deposits which were opened prior to centralization and were being handled by the branches at their end shall now be handle d as new booking under FDA/MPA products through B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 106 Centralized Processing Unit (CPUK). Please refer to Section 1, Chapter 2: 1.4.1 Flexi Deposit Account and 1.4.2 Mahana Profit Account 7.4 PROCESS – BOOKING OF FDA / MPA (CEN TRALIZED PRODUCT) Customer: Request for Issuance of Fixed Term Deposit in the branch. Branch i. Designated officer delivers the TD Application Form SF -265-Revised to customer along with necessary guidance about the product. ii. For New Customers - He/she is required to open a checking account in order to make the placement. TD Application form has 3 copie s. One for Bank (C OD) copy, 2nd is Branch copy and 3rd one is Customer Copy. Customer will fill first copy with others being carbon copies. Branch officials will approve all 3 forms. Customer receives the TD Application from Authorized Officer and submits it duly completed. (Customer must be an existing client of MCB Bank with a n active account in any branch ). Branch Scrutiny i. Designated officer receive TD application from customer and check it thoroughly. Validate complete application and their relevant information. ii. After proper validation, TD application is forwarded to Branch Manager for authorization. iii. Branch Manager interviews the customer. iv. Check all details in TD Application & check that whether there are sufficient funds in customer’s account for TD opening. v. After proper validation of TD application note down the existing client number of customer on TD application. In case of new customer branch should request customer to open relationship (CASA) account. vi. Update the customer of the applicable interes t rate. (In case of ‘special rate’ Branch Manager should get the required approval from Group Head – Business/Treasury through proper channel as per the existing procedure). vii. Obtain Customer’s Signature on TD Application verify signatures, signoff TD appli cation (all copies of TDA) by Branch Manager or any Authorized Officer with IBS/AS and forward to designated officer for further processing. (In case of any discrepancies in TD application, request customer for updating and hold the application till Regularization) Customer obtain customer copy of TDA (duly signed and stamped by Branch Manager or Branch Operation Manager and any Authorized Officer with IBS/AS) and leave the branch. Branch i. Designated officer will scan duly authorized TDA (COD Copy). ii. Send via email (either BM or BOM) to Central Processing Unit, Karachi (CPUK) at COD email ID (td.cpu@mcb.com.pk ) on specific email template (Annexure -E) for further processing. iii. In case scanning could not be done, Fax TDA to CPUK with all details of TD men tion in the email. iv. Keeps TDA Branch Copy for record. v. Mark Original TD Application as (already faxed/scanned when they are scanned / faxed. vi. Dispatch TD application Bank Copy to CPUK through courier / Rider. CPUK (Day -1): i. Designated Officer/Unit at Central Processing Unit, Karachi will receive scanned TD Application via B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 107 7.4 PROCESS – BOOKING OF FDA / MPA (CEN TRALIZED PRODUCT) email from branch on specific email template (Annexure -E). ii. TD Applications received till CUT -OFF time of 1.00 pm will be processed on the same day. The application that received after CUT -OFF time i.e. 1.00 pm will be entertained in next Business day as per product features (PPG and T&C). iii. Authorized officer check TD application thoroughly and send to processor for TD account opening. Incase Request is received via FAX the same is checked wit h email details, signed and stamped by receiving officer. iv. In case of ‘special rate’ ensure that the required approval is obtained by the branch and attached with the TD application. (In case of any discrepancy such as blur/improper scan of incomplete details an intimation is sent to branch for regularization and returned upon branch request) i. Open Term Deposit account on Deposit Module. ii. Use SYMBOLS >> Deposit Module >> Term Deposit >> TD Account Open/ Maintenance (RB213), Select type (Term select from LOV) of account for Term Deposit, insert client and other required information. iii. Note down the system generated account # on TD application. iv. Generate Report “Account Open / Maintenance Details -RBA26” from EOC. v. The authorized officer verifies the data from report on case to case basis which is input by processor. In case of any miss -postings rectifies the same by processor. vi. Placement of Funds: SYMBOLS >> Deposits Module >> Term Deposit >> Placement >> Transfers (RB332). Input the TD Account # and press F8, s ystem will show the account details, after verification input withdrawal account # and amount which should be equal to principle amount. Press F10 to save the transaction. vii. Generate Account Placement Report (Annexure -G) viii. System will generate auto entries in customer branch books: ix. Fund placement transaction report RBA11 will be validated by supervisor. In case of miss postings processor will rectify and supervisor will validate and sign -off. Inform to branch : TD account details send to branch via Email (Branch Wise) on specific email template (Annexure -E). Branch information received of TD Open / Issued. CPUK (Day -2): i. Dispatcher receives TD application in sealed envelope, affix the receiving date on TDA and hand over to concern staff (COD) for further processing. ii. The authorizer matches original TD Application with the scanned copy/fax and mark it, (Matched with scanned/fax copy) and sign -off. iii. TD Advice (A nnexure -B) is generated from KM Module for record. iv. TD Advices are emailed on specific email template to respective Branches automatically through KM Module. v. Keep Soft Copy of T. D. Advices at Central Processing Unit, Karachi for record. Branch i. Branch receives T D Advices, take two prints and hand over one copy to customer. Obtain acknowledgement on seco nd copy and keep it with TDA for record. ii. Keep the record in fire proof cabinet for Audit/Compliance trail. Customer will receive the TD advice from branch after acknowledging/signing the branch copy as evidence. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 108 7.5 PROCESS – MATURITY OF FDA / MPA (CEN TRALIZED PRODUCT) CPU Karachi i. CPUK staff will generate a report, T. Ds to be matured during the day (A nnexure -D) from KM Module. Maturity/Encashment in System i. Based on the report (A nnexure -D) CPUK staff will come to know the T Ds that are to be matured on the proceeding day. They will perform following activities for this transaction. ii. Log into System and perform activity. iii. Use EOC > Deposit > Term Deposit > Redemption/ Pre -termination & Int. payout > RB62. ( Annexure -J) iv. At every day end, CPUK staff will gener ate a report of TDs Matured/Encashed for the day (A nnexure -C) for validation purpose. v. Generated Reports are validated by supervisor and sign off. vi. Authorized officer conveys (via email on specific email template (Annexure -E) the information of TD Maturity to respective branches for their information, record and necessary customer relationship. vii. Branch intimation proof is kept in fire proof Cabinet for Audit Trail. Branch i. Branch receives the details of matured T.D Account No. from CPUK. ii. BM / BOM review the details and branch books / GL iii. Maintain TD record in fire proof cabinet. System i. Account mentioned by Customer earlier is credited with due profit and debited with necessary deductions, i.e. WHT@10%, and Zakat ( if any). (Refer to TD Acc ounting Manual for accounting entries if any) ii. System will pass auto entries as per prescribed bank procedure. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 109 7.6 PROCESS – PREMATURE ENCASHMENT OF FDA / MPA (CEN TRALIZED PRODUCT) Customer Submit request for prematur e Maturity on Encashment Slip (A nnexure -I) along -with T.D. Application (customer copy) to Bank / Branch Manager Stamp and sign. Branch (Day -1) Designated officer receive encashment Slip (filled by customer) and T.D. Application (customer Copy) i. Verify all details mentioned in encashment Slip and T.D. Application (customer Copy) ii. Verity the signature of Term Deposit Authorized Signatory. iii. Authorized officer endorse the customer request with stamp, signature and scan the encashment slip. iv. TD account details and encashment slip scan copy send to CPUK via Email on specific email template. v. Dispatch the original Encashment Slip to CPUK. CPU Karachi Intimation received for Term Deposit Premature Encashment. Requests received till CUT -OFF time of 1.00 pm will be processed on the same day i. Designated staff at CPUK receives email; verify all details and customer request duly endorsed by branch. ii. Calculate Penalty and Zakat deductions (if any) amount as per the product features and forward to concern staff for further processing. Zakat will be calculated after finalization of mechanism as explained in PPG (refer page # 4, point 8 of PPG). iii. Refer to TD Accounting Manual for accounting entries if any Premature Encashment in System i. Log into System and perform premature Encashment activity. ii. For Premature Encashment: Use EOC >> Deposit >> Term Deposit >> Pre -termination & Int. payout >> RB62. (Annexure -J) iii. For Zakat Deductions transaction: Use EOC >> Deposit >> Transactions >> value Transactions >> Withdrawal (RB3 2). (Annexure -K) iv. Penalty amount will be recovered through Symbols >> Deposit >> Transaction >> Value Transaction >> Transaction File Process (RB371) v. Authorized officer will accept the batch through Symbols >> Deposit >> Transaction >> Value Transaction >> Transaction File Authorization (RB372) vi. At every day end CPUK staff will generate a repo rt T. Ds Enchased for the day (A nnexure -C) for validation purpose. vii. Intimation sent to branch via email on specific email template (Annexure -E) viii. Generated Reports duly che cked, validated and sign off along with branch intimation proof are kept in Fire proof Cabinet for Audit Trail. ix. Encashment Slip received via Courier at CPUK (Day -2): x. CPUK Staff check the status of request and mark it. Branch i. Branch received the T.D Account No. and details from CPUK. ii. BM / OM review the details and branch books / GL and note for balancing purpose. iii. Maintain TD record and keep in safe custody. System Account mentioned by Customer earlier is credited with due profit and debited with necessary deductions, i.e. WHT@10%, Prepayment penalty and Zakat (if any) B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 110 7.7 PROCES S – LIEN MARKING / RELEASING OF FDA / MPA (CEN TRALIZED PRODUCT) In case request received from MCB Branch Branch: i. Request for Lien Marking/Releasing on Specific T.D. Account shall be prepared on prescribed format providing pertinent details of the Term Deposit. ii. The request shall be approved/signed off by two authorized officers (one of the signatories must be IBS / AS holder) under their seal and signature. iii. Request for Lien Marking/Releasing shall be forwarded to CPUK through e -mail along with the scanned copy of the approval. CPU Karachi – Scrutiny & Processing: i. Designated officer receive the email from the branch and thoroughly check the contents of email ii. Validate authorized IBS / AS signature of requesting branch staff. iii. Forward the branch request to processing staff. iv. Processor Log into Symbols EOC and Mark/Release Lien on relevant T D Account as requested. (refer t o Annexure -L) v. At Day -end CPUK will generate report. Supervisor will validate the contents of the report, sign off and keep for record. vi. Send intimation mail to respective branch for Lien Marking/Releasing activity. Branch receives the intimation email and keeps it for record. In case Branch request on behalf of other Bank / Agency Branch i. Will seek approval from their Regional Head or Regional Operations Manager and send “Other Bank / Agency request for Lien Marking/Releasing. ii. Branch request received at RH/ROM Office. iii. Respective RH /ROM duly authorize / forward branch request after taking necessary approvals from respective offices (CRC) as per normal procedure or defer branch request in case of non -approval f rom concerned office (CRC) and send to branch for further action. iv. In case Approval received from RH/ROM office. v. Request for Lien Marking/Releasing on Specific T.D. Account (s) is sent on email along with scanned approval by Regional Head or Regional Operat ions Manager of relevant branch on Other Bank/Agency Letter Head. CPU Karachi – Scrutiny & Processing: i. Designated officer receive the email from branch and check thoroughly the contents of email. ii. Validate authorized IBS / AS signature of requesting branc h staff. iii. Forward the request to processing staff. iv. Processor Log into Symbols EOC and mark Lien on relevant T D Account as requested. (refer to Annexure -L) v. At Day -end CP UK Staff will generate report (A nnexure -L). Supervisor will validate the contents of report, sign off and keep for record. vi. Send intimation mail to respective branch for Lien Marking/Releasing activity. Branch receives the intimation email and keeps it with Original Letter and record. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 111 7.8 ANNEXURES & ACCOUNTI NG FOR FDA/ MPA ( CENTRALIZED P RODUCTS ) There are several specific A nnexure for Centralized Term Deposit Products. For detail of Annexure and related accounting entries please refer to MCB Intranet Portal Operations Circulars “Automation and Centralization of Deposits Dated June 20, 2009” 7.9 SMART FOREIGN CURREN CY TERM DEPOSITS – (NON CENTRALIZED PRO DUCT) Smart Foreign Currency Fixed Deposits are not centralized and will continue to be handled by the branches at their end until further notice. 7.9.1 Booking Process – Non -Centralized Product – SFTD Customer requests for creating a Term Deposit in the branch. Customer Service Officer (CSO) delivers the Term Deposit Applic ation SF - 265 Revised. Designated Authorized Officer (DAO): i. Customer submits duly completed SF -265 Revised. ii. Reviews the form. (TDA is a customer’s authorization to debit his/her account). iii. Checks availability of funds in the account before accepting the application for further processing. iv. Forwards TDA to the CA/SA Incharge for customer’s signature verification. Designated Officer / TSS: i. Verifies the customer’s signature. ii. Sign-off along with the IBS/AS number. iii. Affix “Signature Verified” stamp on TDA. iv. Forwards the same to the Operations / Branch Manager for admitting the signature. v. In case of signature differ, returns the form to DAO, in order to obtain another signature on the form or fill -out another TDA. Designated Authorized Officer: i. Re-check the application. ii. After scrutiny of the application, sign -off and also mention IBS/AS number on TDA. iii. Affix “Signature Admitted” stamp. iv. Debits customer’s account on the basis of debit authority, for creating a Term Deposit. v. Prepares and issues Term Deposit Rece ipt. vi. Term Deposit Receipt bears the stationery control number on the face of the receipt. vii. Affix Branch stamp. viii. Note down the amount in figures and words. ix. Mention beneficiary’s name and date of maturity. x. Forwards the same along with TDA to the Operations Ma nager to sign -off TDR. Operations Manager: i. Verify the amount from TDA. ii. Sign-off and mention IBS/AS numbers on TDR. (On customer’s receipt and Bank’s copy) iii. Removes TDR from the Term Deposit Receipt Booklet. Retains Bank’s copy in the Booklet. iv. Delivers TDR to the customer. Customer collects the TDR and leaves the branch. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 112 7.9.1 Booking Process – Non -Centralized Product – SFTD Designated Authorized Officer: i. Makes necessary entries in the PLS Term Deposit Receipts/ Certificate Register (SB -9 Revised) ii. TDA will be used as a Credit voucher (Term Deposit) and DAO will prepare Debit voucher for debiting the customer’s account. iii. Notes down the vouchers in the Transfer Sheet. iv. DAO and OM sign off the vouchers and forwards the same to processor for posting. v. Review End of day reports with the source documents. Supervisor: i. Reviews the vouchers with the source document. ii. Forwards the same to the processor for posting in the system. For detail Batch Processing, please refer to Section 7: 1.4 Transaction processing In GL Module 7.9.2 Issuance of Deposit Receipt: The branch must e nsure that the “Term Deposit Receipt” is issued to the depositor, and mention the indicative rate of profit on the receipt. 7.9.3 Payment of Profit of FCY Term Deposit: Profit amount will only be credited into the depositor’s linked/specified current or Savin gs account. Cash Payment of profit is not allowed. Branches are required to maintain maturity and profit payment dates for each account so that there is no delay in payment of profit to the depositor. 7.9.4 Pre-mature Encashment: Minimum retention period for the term deposit is 01 month, irrespective of the tenor for which the deposit is booked. In case the depositor wishes to encash the depositor before completion of one month, only principle amount will be paid to the customer. If the customer wishes to enca sh the deposit after completion of 1 month, but before maturity, the branch will pay at the Savings rate on such deposit for the number of days completed. If interim profit payment has been made to the depositor, in case of 1 year deposit, then the differe ntial will be recovered from the principle amount. 7.9.5 Normal Encashment: On maturity date, the profit will be credited to the depositor’s checking account. When the receipt is presented to the branch, the principle will be credited to the customer’s checking account. 7.9.6 Renewal/ Rollover: Rollover of principle only or principle plus profit amount, upon maturity will be processed by the branch if instructions have been provided by the customer before the maturity of the deposit. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 113 7.9.7 Overdue Account: In the absence of renewal instructions, the principle and profit will be transferred to the overdue account and a new term deposit will be placed on the date when fresh instructions are received. The depositor will be eligible for profit at the prevailing Savings account rate for the overdue period. 7.9.8 Financing against Smart Foreign Currency Term Deposit: Smart Foreign Currency Term Deposit can be used as a security/collateral and the depositor can avail up to 90% of the principle amount in Pak Rupee. The depositor also has the option of increasing the financing limit up to 95% of the principle amount, upon obtaining the necessary approvals from the relevant authority. The tenor of the financing facility should be within the maturity date of the deposit. The Pak Rupee limit of 90 -95% would be calculated based on the exchange rate, which is applicable for such purposes from time to time. 7.9.9 Monitoring and Controls: Designated Authorized Officer (DAO) notes down the accounting entries in Registers and Ledgers under a separate category. Also note down the profit/ interest rate payable on each deposit for payment and accrual of profit on the due dates. 7.10 MANAGEMENT OF TDR/STDR/SND (OPENED PRIOR TO C ENTRALIZATION) 7.10.1 Rollover of TDR/STDR (Opened Prior to Centralization) Roll over of Term Deposits which were opened prior to centralization and were being handled by the branches at their end shall now be handled as new booking under FDA/MPA products through Centralized Processing Unit (CPUK). Please refer to Section 1, Chapt er 2: 1.4.1 Flexi Deposit Account and 1.4.2 Mahana Profit Account i. For rollover of a Term Deposit branches are required to submit the rollov er requests supported by new TD Form (SF -265-New) duly filled in and signed by the customer clearly mentioning the date, rate, amount and other necessary details. ii. As per the institutional and regulatory requirements, no Term Deposit can be booked / renewe d without having a linked Current/Saving account with the bank. iii. Before forwarding the roll over request to CPUK branch must ensure that customer maintain account relationship (Current or Savings Account) with the bank and the related account number is pro vided in TD Form SF -265-New. iv. The profit amount will be credited by the system directly in the related Current/Savings account and same will be the case with principle at maturity. Note: Branches across the country and respective ROMs/RHs should ensure tha t all new requests for booking of “PKR Term Deposits” are forwarded for processing through Centralized Processing Unit, Karachi. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 114 7.10.2 Maintenance of Term Deposit Register for Non -Centralized Products: i. The Date, Deposit Number, Deposit Receipt Number, SBP CPUK, Name of Depositor, Period of Deposit Accepted, Amount and Due -Date of every deposit receipt will be entered before it is issued in Term Deposit Register (SB -9). The layout of Term Deposit Register is as under: SB-9 (Revised) PLS TERM DEPOSIT RECEIP TS / CERTIFICATES REGISTER (Category: SND/ TERM DEPOSIT) Date of Deposit Deposit Number Deposit Receipt No SBP Code Depositor's Name Period of Deposit in Months AMOUNT Rupees Due Date Initial 1 2 3 4 5 6 7 8 9 Date Profit Paid Period Profit Paid Profit Paid (PKR) Initials Disposal of Receipt / Certificate Initials Remarks Days Months Years Date Paid Date Trf . to Overdue A/c Date Renewed Period Renewed 10 11 12 13 14 15 16 17 18 19 When deposit paid or renewed or transferred to PLS Overdue Term Deposit A/c, details thereof should be noted in appropriate columns provided for this purpose in the register. i. SB-9A (REVISED) ii. The Term Deposit Category Ledger (SB -9A) will be written daily from the Day Book where category -wise receipt/withdrawals will be written separately and should be checked by authorized officer. This Ledger will be written Term -Group -wise. Separate account will be opened in each category of term deposits. In this way, “9” accounts will be opened for deposits of 1 -month, 2 -months, 3 -months, 6 months, 1 year, 2 years, 3 years, 4 years and 5 years & above and posting in this ledger will be don e in relative account according to period of deposits. iii. The columns and layout of Term Deposit Category Register (SB -9A) is given hereunder: - Profit Register SB-9A (Revised) (SND / TERM Deposit) Date of Issue Deposit Number Deposit Receipt Number Debit Withdrawal (PKR) Credit Receipts (PKR) Balance Deposits Outstanding (PKR) 1 2 3 4 5 6 7 Tenure _____________ Days / Months / Years Number of Days Products Debit Profit Paid (PKR) Credit Profit Payable (PKR) Balance Profit Payable ( PKR) Initial Remarks 8 9 10 11 12 13 14 iv. Deposits if not paid on reaching maturity will be transferred to "OVERDUE PLS TERM DEPOSIT ACCOUNT" in the Supplementary Ledger (SB -3) and these overdue TDRs receipts should be transferred to the last few pages of SB -9 which are allocated for this purpose (according to the needs) irrespective of categories of deposits. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 115 7.10.3 Balancing of Ledger At the end of last day of the month amount of outstanding receipts must be jotted on SF -12 from SB -9. The total thereof shall agree with the General Ledger Balance. It should be ensured before taking jotting on SF -12 from Register (SB -9) entries in columns of DATE PAID /DATE TRANSFER TO OVERDUE Account has been made otherwise balance will not tally with General Ledger. Balancing of the PLS Overdue Term Deposits should also be done on monthly basis at the end of the last day of the month. Amount of outstanding receipts should be jotted down on SF -12 from SB -9 (where few pages are reserved at the end for this purpose). Total of such receipts s hould tally with General Ledger Balance of " PLS Overdue Term Deposits". 7.10.4 Distribution of Profit: i. Profit and loss will be distributed on half -yearly basis on receipt of the rates for the preceding half year from the Head Office. ii. Profit and loss for a period beyond the close of the half year will not be outright settled, at the time of encashment of a term deposit on maturity and the depositor will have to leave his instructions for the receipt / payment of profit / loss pertaining to the un -accounted period which will be settled after the closing of the relevant half year. e.g. if a term deposit received on 15 -05-1999 is encashed on 15 -05- 2000, the depositor will be paid profit for the period 15 -05-99 to 31 -12-99. The profit for the remaining period i.e.: 01-01-2000 to 15 -05-2000 will be paid to him after the closing of the next half - year when profit is declared. iii. On expiry of the deposit period, the deposit will cease to be eligible for sharing in the profits at the Term Deposit Rate. It will be transferred to an account to be called "Overdue PLS -Term Deposit Account" and the depositor will be advised accordingly. Provided , however, if within a period of one month after the expiry date, the depositor requests for renewal, the PLS Term Deposit will be renewed for the desired period from the date immedia tely following the expiry date. In case, the depositor fails to turn up for giving renewal instructions, the overdue deposit will be eligible for payment of profit at PLS Savings Account Rate. iv. If PLS Term Deposi ts withdrawn from the bank within a period of less than “7” days, the deposit holder will not be paid any profit. v. If one month and over but less than two months PLS TDR is withdrawn after seven days before maturity will be eligible for sharing of profit, i f any, at PLS -SND seven days rate. vi. If PLS Term Deposits withdrawn after completion of two months but before maturity will be eligible for sharing of profit, if any, at the rate determined for PLS Savings Accounts. vii. While paying the amount of return at Savin gs account rate the branch shall ensure that any return paid for the preceding half year has been deducted from the amount of return payable against encashment before maturity. For example, if a PLS TDR of PKR 10,000/ - issued for one year on 1st April, 199 9 is presented for encashment on 16th October, 1999, the branch shall calculate the return, assuming that the profit rate declared for the preceding half year (30.06.1999) was 7% P.A. for PLS Savings Account, and 10.5% P.A. for PLS Term Deposit, in the fol lowing manner. Return on PKR 10,000/ - at Savings rate for “197” days 01 -Apr-99 to 15 -Oct-99 at 7% P.A. PKR 377.85 Less: return already paid on PKR 10, 000/ - For “91” days (01 -Apr-99 to 15 -Oct-99) @ 10.50% (P.A.) at PLS TDR rate PKR 261.81 Net return payable to the depositor PKR 116.04 B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 116 NOTE: In case the amount of return already paid for the preceding half year is higher than the amount of return payable at Savings Account rate, the difference shall have to be deducted from the principle amount of the PLS TDR. i. The profit on PLS Term deposit to be disbursed to the depositors through credit of PLS Savings/Current account (where it is maintained)/bank's payment order on receipt of circular from Head Office on half year basis. With -holding ta x would be deducted as per rules from the gross amount of profit to be paid / credited in GL 1090601020 WHT ON MARK -UP PAID –SEC 151 before deduction of the amount of Zakat as per rules unless otherwise specified. In case any deposit has not completed six months, the profit to be distributed at pro rata basis. ii. As and when circular received from Head Office for payment of profit to deposit holders, the calculation thereof should be made on processing sheets taking jotting from Term Deposit Ledger (SB - 9). The amount of those deposits will be jotted on the sheets, which are entitled for profit. All outstanding deposits at the end of half year will be jotted down first and balanced with the General Ledger and subsequently other deposits, which are entitled for profit, will be written on processing sheets. A separate sheet should be used for each term -group. The calculation and other particulars should be checked by two authorized officers before payment of profit. 7.10.5 Monthly Provision of Profit: i. Profit payable on all deposits should be calculated on monthly basis by the branches and shown as expenses to be paid before arriving at a monthly Profit /Loss figures in monthly Provisional Statement of Income & Expenses. ii. Product should be worked out in Term Deposit Catego ry Ledger (SB -9A) in 'PRODUCTS' column on the basis of total deposits outstanding under each Term -group. At the end of the month, the column of 'No. of days' should be totaled and it should be ensured that total of number of days correctly worked out. Products should also be totaled at the end of each month and it should be ensured that total of Products is progressive up to the end of half year i.e.; January to June and July to December. iii. The products and the working as well as balance should be checked by two responsible officers. iv. No entries are to be passed for the provisions. The net amount of profit payable under each category will be shown under column 'D' as expenses to be paid under the relative head of account in the monthly Statement of Profit a nd Loss. However, at the time of Annual Closing i.e.; 31st December provision entries will be passed to the debit of appropriate head of Expenses A/c and crediting relative head of account of Profit/Mark -up payable on Deposits. This entry should be reverse d on 1st January. v. While reporting the figures of provision for the month of January in statement of Provisional Income & Expenses, branches should report the amount in column 'D' provision made on 31st December plus provision for the month of January in ca se amount of provision made for 2nd half year not distributed up to 31st January as generally profit for half year ending 31st December are paid in the month of February. vi. Similarly, reporting of figures of provision for the month of July should be reported correctly i.e. provision made up to June plus provision for the month of July in case distribution of profit for the half year ending 30th June NOT made in the month of July. vii. It should also be ensured that provision for profit payable on Overdue Term Depo sits have also been made at applicable rates up to the date of maturity and at Savings rate from date of transfer to Overdue Account till the end of month and it is correctly reported in Monthly Statement of Provisional Income & Expenses. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 117 7.10.6 Payment of pro fit: Profit amount will only be credited into the depositor’s linked/ specified current or Savings account . Cash payment of profit amount will not be allowed. Branch will have to maintain maturity date and profit payment dates for each account so that ther e is no delay in payment of profit to the depositor. 7.10.7 Pre-mature E ncashment: i. Minimum retention period for a deposit is 1 month. In case the depositor wishes to encash the deposit before completion of one month, only principle amount will be paid to the customer. ii. If the customer wishes to encash the deposit after completion of 1 month, but before maturity, the branch will pay the PLS Savings rate on such deposit for the number of days completed. iii. If interim profit payment has b een made to the depositor (in case of 1, 3 and 5 years deposit) than the differential amount will be recovered from the principle iv. SNDs of any category encashed before “7” days will not be eligible for profit. However, SNDs issued for “30” days and encashe d after “7” days will be eligible for profit payable for “7” days Notice Deposits. 7.10.8 Normal Encashment: On the maturity date, the profit and the principle will be credited to the depositor’s checking account. The branch will not wait for the depositor to pr esent the receipt. 7.10.9 Financing Facility against Term Deposits: This deposit can be used as a security/collateral and the depositor can avail up to 75% of the principle amount upfront. The depositor also has the option of increasing the financing limit up to 90% of the principle amount, upon obtaining the necessary approvals from the relevant authority. The tenor of the financing facility should be within the maturity da te of the deposit. 7.10.10 Monitoring and Control s: i. Entries in Registers and ledgers will be made under a separate category and profit rate payable on each deposit will also be registered for payment and accrual of profit on the due dates. ii. Separate GL codes in t he Statement of Affairs are allocated so that product volumes and deposit mix can be monitored. iii. Branches are required to submit a monthly report to their Circle Office indicating customer wise information, so that an independent check can be conducted. 7.11 MANAGEMENT OF MATURE D/ OUTSTANDING CAPIT AL GROWTH CERTIFICAT ES  Outstanding CGCs must be transferred in Over Due CGC account immediately after maturity and should stay there unless & until the beneficiary claims it or acknowledges the receipt of “Notice sen t to customer before Surrender to SBP”. These CGCs should not be transferred in Unclaimed Account (Subsidiary).  If a CGC remains overdue after maturity (outstanding in overdue liability head) for a period of 10 year, Principal along with Profit shall be su rrendered to SBP. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 118 Chapter 8 GUIDELINE ON DEDUCTI ON OF ZAKAT 8.1 ZAKAT ON PLS SAVINGS & OTHER SIMILAR ACCO UNTS (ASSET CODE: 101) On 1st of Ram adan every year, Zakat is deducted at source on all categories of PLS saving and other similar Accounts (Asset code 101) except those fulfilling the exemption criteria as per Zakat & Usher ordinance 1980 . 8.2 ZAKAT ON TERM DEPOSI T PRODUCTS (ASSET CO DE: 103) On 1st of Ram adan, Zakat will be calculated on all Term Deposits except those fulfilling the exemption criteria as per Zakat & Usher ordinance 1980. Please note that a ll term deposits that are liable for Zakat, there will be no actual deduction of Zakat on 1st of Ram adan from principal amount of Term Deposits. The amount will be calculated and noted by the respective staff in thei r Term Deposit registers against each eligible Term Deposit . Definitions of some the terminologies and calculation/deducted process is mentioned below: Sahib -e-Nisab: Means a person who owns or possess assets not less than “Nisab” as announced by the Administrator General Zakat each year before the start of Ram adan Rate of Zakat: The current rate of Zakat is 2.5% Valuation Date: The 1st day of the Zakat year (i.e. 1st of Ramadan ). 8.3 ZAKAT EXEMPTION S Following are exempted from Zakat as per Zakat & Usher Ordinance 1980: i. A person who is not a “Sahib -e-Nisab” . ii. All Non -Muslims & All Non -residents . iii. Customers who died on or before 1st of Ramadan . iv. Federal Government, Provincial Government or a Local Authority . v. Any organization which is owned wholly, directly or indirectly, by the Federal or Provincial Government or a Local Authority . vi. Subsidiary of any organization which is owned wholly, directly or indirectly, by the F ederal or Provincial Government or a Local Authority . vii. National Investment (Unit) Trust . viii. Investment Corporation of Pakistan & Its Mutual Fund . ix. A Recognized Provident Fund . x. Any Unit fund maintained by Defense Services including Civil Armed Forces . xi. A Zakat Fu nd. xii. All registered charitable organizations . xiii. A deeni madrassah registered by Zakat Department . xiv. A mosque . xv. A registered orphanage . B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 119 xvi. A Workers Participation Fund . xvii. Customers who have submitted the certificate/affidavit of Zakat Exemption (CZ -50) before 1st Shabban in their respective Branches . xviii. All FCY Accounts/FCY Term Deposits . 8.4 PROCEDURE FOR CALCUL ATION & DEDUCTION OF ZAKAT ON TERM DEPOSI TS 8.4.1 Calculation of Zakat: Zakat calculation will be calculated using the following formula: 2.5% X Pr incipal Amount o f Term Deposit Please note that any accrued but unpaid profit or profit that has already been paid will not be taken into account for Zakat. 8.4.2 Deduction of Zakat: i. According to rules profit on PLS TDRs irrespective of its maturing date is paid twice in a calendar year. Such payments are to be treated as interim payments and Zakat @ 2.5% from such assets which existed on the valuation dates should be deducted on the face value of the asset only once in each Zakat Year at the time of disbursement of first pr ofit. It may also happen that there may not be sufficient amount of profit available then in such cases the remaining amount of Z akat, should be recovered at the time of disbursement of second profit. The reporting of such assets should be shown under asset code 103 in the reporting form CZ -07. ii. For assets belonging to this category where return becomes receivable by the asset holders on a certain date in a Zakat year, but is not collected by him, Zakat shall be deducted for each Zakat year involved of i f the return had been collected by the asset holder when receivable by him. iii. The amount of Zakat deducted will be entered date -wise in the relevant folio of the “ Zakat Deduction/Refund Register for Assets Other than Savings::(CZ -02). iv. The amount of Zakat De ducted will be credited to the “CZ Collection Account - Other Assets” and will be reported in the quarterly Report (CZ -07) under Asset code 103. Zakat Amount will be deducted at the 1st profit payment or maturity whichever comes first after the 1st of Rama dan. The calculation for deduction of Zakat will be as follows:  Profit to be paid – Zakat Amount – WHT  With -holding tax will be levied on the profit left after the deduction of Zakat amount. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 120 Example: Principal Amount Rs 1,000,000 Rate: 12% Profit P ayment Frequency: Quarterly Zakat Amount = 1,000,000 X 2.5% = Rs 25,000 8.4.3 Recovery of Zakat Un -realized: Where the amount of Zakat due cannot be fully reali zed due to the return payable to the asset holder, at the time when he calls for receiving his first return/profit being less than the amount of Zakat due (as could be the case with Short Term Deposit & Term Deposit), the amount of Zakat unrealized, if any, may be entered in the “Remarks” column in CZ -02 against the respective entry. The respective Short Term Deposit shall also be endorsed accordingly so that the amount of Zakat Unreali zed is recovered at the time of payment of subsequent return(s) or payment of maturity/encashment value, whichever be earlier. The above mentioned calculations /method ologies will apply for all tenors and all products of Term Deposits (Term Deposits, STDR etc). 8.5 PROCEDURE FOR CALCUL ATION & DEDUCTION OF ZAKAT ON PLS SAVINGS & OTHER SIMILAR ACCOUNTS 8.5.1 Procedure necessary prior to deduction of Zakat : It is important that branches have updated Zakat Deduction status of all accounts so to enable correct levy of Zakat. In this branches are provided with the following CMIS/KM reports: Zakat Applicable Report: Other than current accounts, this report shows all accounts whereby Zakat service charge ( ZAK for savings accounts and TZK for term deposits) is marked. Zakat Not Applicable Report: Other than current accounts, this report shows all accounts on which Zakat service charge (ZAK for savings accounts and TZK for term deposit s) is NOT marked. Current Accounts with Zakat Check: Report shows all current accounts whereby Zakat service charge (ZAK or TZK ) has been marked. Using the above reports, Branches were advised to confirm the Zakat status of their customer accounts well be fore the deduction time. The following accounts may please be noted for exemption of Zakat: i. Accountholder is a non -Muslim as per the original AOF; ii. Accountholder has submitted CZ-50 Form which is attached to the original AOF. If the above conditions are not fulfilled by your accountholders, their accounts in SYMBOLS – CBS must be marked with the following: B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 121 Conventional i. Service charge type ZAK (in case of savings accounts) or ii. Service charge type TZK (in case of term deposits). Islamic i. Service charge type TZK (in case of savings and term deposits) The above reports also bear complete set of instructions for convenience and prompt action. 8.6 DEDUCTION OF ZAKAT i. Zakat will be deducted centrally on 1st Ramadan every year and deducted amount will automatically be credited to 1090801690 – Collect A/C Cent. Zakat Fund. ii. Branches will Validate the Zakat deduction report (KM_KM_0025) provided by CMIS with their General ledger (1090801690 – Collect A/C Cent. Z akat Fund) on Valuation date iii. The outstanding amount in Zakat Collection GL Code will be transferred to Head Office on the same day under transaction code 9090 8.7 REPORTING PROCEDURE FOR BRANCHES / CIRCLE OFFICES Saving Accounts whereby ‘ZAK’ or Term Deposits Accounts whereby “TZK” service charge is not marked on the 1st of Ramadan would be treated as exempted accounts. CMIS team would produce the account listing of such accounts along with the actual balances which will then be forwarded to CAD. Following ca tegories are available for exemption cases as per Zakat & Usher Ordinance/directives: i. Non -Muslim/ Non -Pakistani ii. Due To Fiqh iii. Other Reasons CAD will e -mail the Account listings of exempted accounts to the respective Circle Offices, who will further route th e information to each branch in its jurisdiction. Branches are required to identify the reasons of Zakat exemption against each account and submit the sheet to their respective Circle Offices timely by deadline communicated (as provided for each year). Circle Offices will furnish Branch -wise summary of Zakat exempted account on the following format (Below NISAB accounts not included): Br. Code Br. Name Exemption Reason (Other than Below NISAB) Non -Muslim/ Non -Pakistani Due to Fiqh Other Reasons No. of A/Cs Value ( PKR) No. of A/Cs Value ( PKR) No. of A/Cs Value ( PKR) 1 2 3 4 5 6 7 8 The above information must reach to CAD on timely basis (as provided each year). B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 122 CASH MANAGEMENT & TELLER SERVICES SECTION 3 CASH MANAGEMENT & TE LLER SERVICES Section Summary: This Section entails policies , process es & Operating guidelines for cash management ; discussing in detail cash related functions like Daily Cash Balancing, Cash handling, sorting, insurance, arrangements with cash houses, cash feeding branches, handling of foreign curre ncy etc. The section also documents all processes related to Cash Deposit/Withdrawal, Inward & Outward Clearing, Inward & Outward Collection (LCY & FBC), Internal Funds Transfer, Utility Bills ma nagement & Prize bonds . SECTION 3 B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 123 Chapter 1 CASH M ANAGEMENT 1.1 DAILY CASH BALANCING At every end of day, the following cash balancing process needs to be followed: i. Teller views the screen of Teller Totals BT  Totals  Teller Totals . This will ensure that Teller has totaled his/ her own TIL. ii. Teller generates following reports to validate daily postings :  For Current/Saving transactions: EOC  Reports  Daily transaction by branch/officer  For GL transactions: EOC  Reports  Daily Activities Daily Batch listing per user iii. For any differences, generates BT  Enquiry  Electronic Journal and verifies that all transactions are successfully posted in BT to ensure there is no transaction which is “Rejected by Host” or “Unknown” or “Hold”. If any entry is found in any of the above statuses, the same should be cancelled and re -posted. iv. Generates “Cash Detai ls” report from MCB reports. Ensure that Net -off of ‘Cash Details ’ report (debit & credit) added to the opening balance of the same day should be the Closing Cash -in-hand of the day. v. Generates “Daily Cash D ay’s journal” from MCB reports. Validate all trans actio ns in order to detect any Flying entry/transaction. vi. Generate ‘GL Balances’ report to check the Cash in Vault and LCY Coins Balance for balancing purpose. Compare this report with ‘Cash Detail s’ report (generated from MCB reports). Total Physical Cash -in- Hand must tally with Cash -in-Vault and LCY Coins. vii. A summary of cash transactions of the day must be recorded in Cash Book SB 57 and signed by TSS. Branch Operations Manager signs off the Cash Book after proper validation and scrutiny of few Cash Packets, on a random basis. Moreover, Operations Manager fortnightly reviews/checks the entire Cash in Hand and the Cash Book is counter signed by Operations Manager as a token of this verification. Also mention narration “Checked and Verified”. viii. Keep Cash in Vault along with the Cash Received and Paid Stamp under dual custody of Designated Teller and Operations Manager. ix. Keep Cash Book in Fire Proof Cabinets. Besides performing the above steps for balancing; BOM should perform following steps : i. All Cash related batches should be accepted at the day end and no batch should remain opened. ii. On the following days BOM must validate the closing balance of Cash in vault of GLA -91 with Closing Balance of Cash Book and should confirm that both the balances should tally. Any difference if traced should be investigated and if required should b e reported to Region/ Circle Offices. 1.2 CASH HANDLING & CASH POSITION STATEMENT This is a prerequisite for the branches to maintain Daily Cash Position Statement as per the Annexure I V Tellers and Operations Manager have to ensure that cash must be organized in the following manner: i. Branches are required to maintain, on a daily basis, minimum surplus cash balance in sorted re -issuable balances of at least ONE DAY’S average requirement for the preceding month. While calculating B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 124 Average, th e following transactions will be excluded from the payments i) Cash deposited in their accounts with the main/feeding branches , chests/sub -chests and/or SBP offices. ii) Issuance of MTs, TTs and DDs via account. ii. Once a packet of banknote is sorted the sorting bank/branch shall clearly identify/stamp on the wrapper of the packet as “SORTED” along with the name of the bank, branch and the date of sorting. Once such packets are in circulation, further sorting would not be required till the packet is broken into pieces. iii. Cash must be sorted, arranged and ban ded (denomination wise) in packets of “100” notes each and in a lot of ten packets duly tied into a bundle called a RING. iv. Affix “Sorted” stamps on the sorted packets of Banknotes. v. Removing Staple pins from the packets of Banknotes (If there are any). vi. Sort out cut/soiled/mutilated and defective notes and transfer/ surrender to Cash House/Cash feeding branch for onward submission to SBP. vii. At the end of day, sorted and un -sorted /defective / soiled shall be separately placed in cash vault and separately record ed in SBP register in separate columns. viii. As per SBP ’s instructions, use Electronic Banding Machines (EBM) for banding of b ank notes . However branches that have not so far been provided with EBM are advised to use manual banding of Currency Notes through Pap er Tapes. Stapling of Banknotes ruin the notes and reduces its longevity. ix. Prepare Cash Position Statement and clearly mention the number of packets and amount in the respective columns. x. Cash received in a day should be properly sorted before using for the same payments over the cash counter. xi. Branch should make extra effort for on spot sorting of Bank Notes (PKR 100 and above) over the Counter immediately once received especially in case where average daily payment is exceeding PKR 1.5 Million. Not complyin g with the same can attract SBP penalty. NOTE: Branches must ensure strict adherence to the above guidelines. For ref. please refer to SBP Master Circular # 1 as of March 05, 2004 . 1.3 PROCEDURE FOR CASH F OUND EXCESS There are multiple instances where Cash can be found excess at the Branch cash counters at the day end balancing. Few are stated as under: i. Customer after depositing cash took along cash deposit voucher. ii. Utility bill deposited in cash and bill is returned to customer without detaching the stub iii. Excess cash deposited by the customer as opposed to amount filled in the deposit slip. iv. Short counting of notes by the Sorter during sorting of cash packets However, to handle such scenarios, following process need to be strictly followed Process Steps On physical counting of entire cash at the end of the day including utility bills collection, the Teller/ Supervisor find out Excess Cash Teller’s conducts detailed scrutiny of the said amount i.e. rechecking & recounting of Physical Cash, Ticking of Voucher s against RBA - 11 to verify the amounts on the vouchers & amount posted. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 125 Teller/ Supervisor reports the cash excess of PKR xx to the BOM. Teller also notes the entry in the Cash Excess Register and signs it. BOM himself investigates for the said differen ce. If the difference is not traced, books the excess cash in GL head "Cash Found Excess" on cash credit voucher. The amount stays in the GL Head for a maximum of 30 days In case claim is Received within 30 days , BOM asks the claimant to produce evidence such as PAY in Slip, utility Bill etc. Branch also requires an application from the claimant and copy of CNIC to honor the claim. After proper verification branch Debits "Cash Found Excess GL head" on cash debit voucher and hands over the claimed amount to the claimant or Credit customer's account as per customer’s request. In case claim is NOT received within 30 days , BOM remits excess cash through HO credit advice SF -0179 in OGL Head "Cash Found Excess, Account # 1051100003 & Transaction code 3900”, Central Accounts Division (CAD). In case claim is received After 30 days and branch has transferred the funds to CAD, Branch forward the case to CAD along with all supporting documents mentioned above and requests f or refund of Excess Cash transferred CAD after proper verification issues Credit advice SF -0179 to the branch for the claimed amount 1.4 SECURITY ARRANGEMENT S FOR CASH Security of Cash Department is an important matter hence branches are required to adopt the following measures for safe guarding the security aspects of the Cash Department: i. Cash Department of the Branch should be in a separate area, within which entry of Customers is not allowed. ii. Burglary alarm/ security system should be installed and activa ted in the branch. iii. Cash holding at the branch counters should be kept at minimum to the specific requirements of Cash Counter. iv. Maintain a file of updated record (Photo, copy of CNIC etc) of sec urity company guards. 1.5 CASH IN HAND & CASH IN HAND INSURANCE LIMIT Branches are required to maintain their daily Cash -in-Hand (CIH) limit within their pre -established Cash -in-Hand ceiling. However, in case the total Cash -in-Hand (PKR + PKR equivalent of Foreign Currency + Prize Bonds ) exceeds the “Cash -in-Hand Insur ance Limit ”, the same must be reported to Centralized Insurance Unit (CIU) as per the format given under. Branches should not get confused with CIH Insurance Limit and CIH limit. The matter should be referred to CIU only if closing CIH on a certain day ex ceeds CIH Insurance Limit. BRANCH NAME BRANCH CODE DATES OF EXCESS TOTAL CASH IN HAND CIH INSURANCE LIMIT EXCESS CASH IN HAND XXX XXXX dd-mm-yy 10,000,000 9,000,000 (1,000,000) B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 126 1.6 CASH DEPOSIT BY BR ANCHES WITH CASH HOUSE / CASH FEEDING BR ANCH Branches are required to transfer their daily excess/surplus cash to Cash House via Debit Advice (SF -180). Following procedure will be followed: i. If the amount of cash being transferred is WITHIN the pre -established ‘threshold limit’ of PKR 10M, the BOM with joint approval of BM contacts their respective Cash House Centers via e -mail or fax and requests them to collect excess/surplus cash from the branch . Further the requests through e -mail or fax will carry AS/IBS number of BM/ BOM. ii. In case the amount of cash being transferred EXCEEDS the pre -established ‘threshold limit of PKR 10M, BOM with joint approval of BM before arranging the shipment will first send an e -mail or f ax to their RH/ ROM inform ing them of the shipment and total amount of cash being transferred and requesting for their approval. On receipt of approval from RH/ ROM , the BOM/ BM will contact their respectiv e Cash House Centers via e-mail or fax request ing them to collect excess/sur plus cash from the branch. Further the requests through e -mail or fax will carry AS/IBS number of BM/ BOM.  Pre-established “Threshold Limits” are defined in Section 7: Chapter 13 : Branch Transactional Authorities & Threshold L imits iii. Designated Authorized Officer (BOM/TSS) prepares Inter Branch Debit Advice (SF -180) in quadruplicate drawn on the Cash House and also prepares Shipment Receipt in triplicate. The details of denominations of currency notes must be written in the debit advice. iv. Two authorized officer (BOM/TSS/GBO) sign off the Debit Advice & Shipment Receipt. For detail Batch Processing, please refer to Section 7: 1.4 Transaction processing In GL Module v. Enters the amount of cash in Cash Book SB -57 in t he Payments Column. vi. Operations Manager of the branch verifies the identity of the staff members of Security Service Agency from the photographs and signatures supplied by the Cash House. vii. Delivers cash along with the 1st copy of Debit Advice and the Shipme nt Receipt to the authorized person of the Security Service Agency. viii. The two staff members of the Security Service Agency deputed by Cash House for collection of cash from the calling branch will count the bundles/packets of cash as per denominations mentioned in the cash debit advice SF -180. ix. After the bundles/packets of cash are counted and found correct, the Security Service Agency keep s the cash in canvas bag (s) which is provided by the Security Service Agency in presence of BOM/TSS. x. The two copies of transit/shipment receipt and the original cash debit advice SF -180 along with its quadruplicate will also be handed over to the Security Service Agency. xi. When the cash is packed in bag (s), the same will be tied with plastic numbered seal (s) by the Design ated Authorized Officer (BOM/TSS) . xii. Designated Authorized Officer (BOM/TSS) obtains acknowledgement for cash receipt on the Shipment Receipt from the two staff members of Security Service Agency . xiii. Operations Manager must ensure that the cash delivered by the m to the representative of Cash House (Security Company) has been properly noted and duly entered in the Cash Book SB -57 and necessary accounting entries are posted in the system. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 127 1.7 CASH DEPOSIT BY UP -COUNTRY BR ANCHES WITH CASH HOUSE / CASH FEEDING BR ANCH i. Up-country branches having surplus cash informs their Regional/Circle offices which in turn takes up with the Head of Cash Houses for making necessary arrangements for cash deposit with Cash house. ii. On receipt of approval from Regional/Circle offices branches prepare debit vouchers for the amount being deposited by them using Inter Branch Debit Advice (SF – 180). iii. Cities where there is no road transport arrangements are available t he surplus cash (along with the related Debit Advice) will be transferr ed to Cash House by Air through BOM/ Teller Services S upervisor and for other cities the shipment will be made through Security Service Company (Phoenix Armor/ Wackenhut/ Askari Guards). iv. The Cash House receive the cash from branch by signing and affixing cash received stamp with date on the face/back of D copy (SF -180) of voucher by authorized officer and cashier a s an acknowledgment. v. The cash received is also entered in Cash House Register in the presence of branch official and will be initialed by the a uthorized officer of Cash House / Chief Cashier. 1.8 CASH TRANSFER FROM C ASH HOUSE TO BRANCH ES i. Branches within the jurisdiction of Cash House intimate their cash requirements in the evening prior to working day as well as in the morning to the Cash House through telephonic message, e -mail or letter conveyed through fax. ii. If the amount of cash being requested by the Branch WITHIN the pre -established ‘threshold limit’ of PKR 5M , BM/ BOM contacts their respective Cash House Centers via e -mail or fax and requests them for the cash. Verbal request via telephone for requisition of supply of cash will not be entertained. Further the requests through Fax or e -mail will carry AS/IBS number of BM/ BOM. iii. In case the amount of cash being requested EXCEEDS the pre -established ‘threshold limit of PKR 5M, BOM with joint approval of BM will first send an e -mail or fax to their RH/ROM for their approval. On receipt of approval from RH/ ROM, the BM/BOM will contact their respectiv e Cash House Centers via e- mail or fax requesting them for the cash. Further the requests through e -mail or fax wil l carry AS/IBS number of BM/ BOM.  Pre-established “Threshold Limits” are defined in Section 7: Chapter 13 : Branch Transactional Authorities & Threshold L imits iv. On arrival, Designated Authorized Officer in the branch verifies the identity of the staff members of Security Service Agency from the pho tographs and signature supplied by the Cash House, who attend the branch for delivery of requisite cash. v. Security Service Agency provides the original Cash Debit Advice on SF -180 along with its quadruplicate copy of the same. Designated Authorized Officer checks that the exact amount of cash is supplied by the Cash House. xiv. Verify the embossed/printed numbers of seal on the cash bags with the transit/shipment advice. xv. Ensures that the seals as well as cash bags have not been broken / tempered . vi. When it is foun d that the bundles/packets count is correct and in accordance with the denominations of the currency notes mentioned in the cash Debit Advice on SF -180 and transit/shipment Receipt, Designated Authorized Officer acknowledges receipt of the cash on the quad ruplicate copy of SF -180 and original of transit/shipment receipt and delivers the same to the staff of Security Service Agency and retains the original Debit advice for accounting and record purpose. vii. Enters the amount of cash in Cash Book SB -57 in the Rec eipts Column. Also post the relevant a ccounting entries in the system. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 128 1.9 TRANSFER OF CASH FRO M CASH HOUSE TO SBP i. Cash Houses on receipt of cash from branches both local/up -country respond the debit vouchers by debiting to their cash -in-hand account. ii. All the cash received/deposited is entered in the cash book of Cash House on daily basis and is balanced with the cash in Affairs/General Ledger and Cash in Vaults of the Cash House. iii. Cash Houses will pass the entry to the deb it of main branch of the city maint aining the bank account with S BP Banking Services Corporation with an exception to Cash House KHI which deals with SBP through Treasury & Foreign Exchange Group . 1.10 CHARGES FOR CASH COU NTING AND SORTING OF CASH i. MCB Employees Foundation has arranged sorters for counting and sorting of cash. Sorters are paid their charges for cash counting and sorting periodically, for the total number of bundles of cash counted and sorted during a fortnight as per rate prescribed by the Bank. The Charges Paid for cash counting and sorting are debited to "CASH SORTNG CHGS TO FOUNDATION” -Symbol GL Code 4040122040. ( Instead of branches). 1.11 HIRING CHARGES FOR A RMORED VEHICLES OF S ECURITY SERVICE AGEN CY i. Cash House has hired armored vehicles from Security Service Agency who provide CIT service and supply of plastic pre numbered seals which are used to seal cash bags. The cash is transported to and from branches in these sealed bags. Cash House pays total C IT bill including cost of seals received, overtime and trip based charges on monthly basis as per the agreement with CIT company. Cash House pays their bills through “CIT SERV CHGS TO SECURITY COMP” - GL Symbols code 4040124150. The charges are recovered f rom the respective branches, being provided cash supply and collection facility through security service agency. This amount is credited into income account “Central CCH Charges recovered - GL Symbols code 3080101270”. ii. The figures for cash carries will be worked out on the basis of transit/ shipment receipts of Security Service Agency as well as relevant cash debit advices for supply and collection of cash to and from branches. 1.12 CASH HOUSE CHARGES F OR SUPPLY AND COLLEC TION OF CASH Cash House recovers charg es for cash supply and collection from the affiliated and non -affiliated branches at the prescribed rate per bundle of each denomination of currency notes. 1.13 CASH TRANSFER FROM CASH FEEDING BRANCH TO BRANCHES i. In every region outside the purview of Cash Ho uses , one or more branches have been nominated as Cash Feeding Branches for delivery or collection of cash to and from all other branches of their region. ii. The cash -feeding branch collects the requisitions for supply or collection of cash up to 30 minutes after the commencement of office hours, either in writing or over the telephone, with proper identification of B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 129 the person calling from the other side. iii. If the amount of cash being requested by the Branch WITHIN the pre -established ‘threshold limit’ of PKR 5 M, BM/ BOM contacts their respective Cash Feeding Branch via e -mail or fax and requests them for the cash. Verbal request via telephone for requisition of supply of cash will not be entertained. Further the requests through Fax or e -mail will carry AS/IBS number of BM/ BOM. iv. In case the amount of cash being requested EXCEEDS the pre -established ‘threshold limit of PKR 5M, BOM with joint approval of BM will first send an e -mail or fax to their RH/ROM for their approval. On receipt of approval from RH/ ROM, the BM/BOM will contact their res pective Cash Feeding Branch via e- mail or fax requesting them for the cash. Further th e requests through e -mail or fax will carry AS/IBS number of BM/ BOM.  Pre-established “Threshold Limits” are defined in Section 7: Chapter 13 : Branch Transactional Authorities & Threshold L imits v. The TSS notes down all the requisitions in a register and notes down Branch Name, amount supplied/coll ected and Debit Advice Control number. In addition to the above, the chief cashier will arrange the required amount of cash and delivers the same to staff of Security Service Agency in order to perform the following functions:  After the bundles/packets of cash are counted and found correct, the same will be placed, in canvas bag(s) which is provided to the Staff of Security Service Agency by the Cash Feeding branch.  Also keep Debit Advice - SF-180 and transit/shipment receipt in the cash bags.  Attach plasti c numbered seals with the cash bags.  Security Service Agency delivers requested cash, Debit Advice - SF-180 and Transit/Shipment Receipt.  Staff of Security Service Agency provides packed cash bags, original Cash Debit Advice on SF -180 along with the quadruplicate copy of the same.  Ensures that the seals as well as cash bags have not been broken / tempered  Designated Authorized Officer in th e branch checks that the exact amount of cash is supplied. Also verify the embossed/printed numbers of seal on the cash bags with the transit/shipment advice.  When it is found that the bundles/packets count is correct and in accordance with the denominatio ns of the currency notes mentioned in the cash Debit Advice on SF -180 and transit/shipment Receipt, Designated Authorized Officer acknowledges receipt of the cash on the quadruplicate copy of SF -180 and original of transit/shipment receipt and delivers the same to the staff of Security Service Agency and retains the original Debit advice for accounting and record purpose.  Enters the amount of cash in Cash Book SB -57 in the Receipts Column. Also post the relevant accounting entries in the system 1.14 PROCEDUR E FOR TRANSFER ING FOREIGN CURRENCY TO MAIN BRANCH BM/ BOM of Branch es dealing in Foreign Currency Cash are required to contact the Main B ranch via email or fax for surrendering of surplus cash in excess of pre-established ‘ threshold limit ’ (equivalent Pak Rupee) after getting the required approvals of their respective ROM/RH. Further the requests through Fax or e -mail will carry AS/IBS number of BM/ BOM. i. Designated Authorized Officer (BOM/TSS) prepares Inter Branch Debit Advice (SF -180) in quadruplicate drawn on Main branch and also obtain the triplicate copy of Shipment Receipt from Security Company. The details of denominations of currency notes must be written in the shipment receipt. ii. Two authorized officer (BOM/TSS/GBO) sign off the Debit Advice & Shipme nt Receipt by BOM / TSS B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 130 iii. Teller services supervisor delivers cash along with the 1st copy of Debit Advice and collects the Shipment Receipt from the authorized person of the Security Service Agency. iv. The two staff members of the Security Service Agency deput ed by the Cash House for collection of cash from the calling branch will count the bundles/packets of cash as per denominations mentioned in the shipment receipt v. After the bundles/packets of cash have been counted and found correct, the Security Service Ag ency keeps the cash in canvas bag and tie s them with plastic number seal/s in presence of BOM / TSS. vi. The two copies of transit/shipment receipt and the original cash debit advice on SF -180 along with its quadruplicate will also be handed over to the Securi ty Service Agency. vii. Security Company sign -off the debit advice and acknowledges the receipt of cash. viii. BOM / TSS must ensure that the details of cash shipment are properly recorded in the Cash Book SB -57 and necessary accounting entries are posted in the syst em. ix. On receipt of cash the authorized official of Main Branch will send “D” copy of debit advice SF -180 after affixing “cash received” stamp to the branch as an acknowledgment having receipt the cash. On monthly basis, branch receives Cash In Hand Service s and Insurance Charges Inter Branch Debit Advice - SF- 180 along with the Original Bill from Centralized Main Branch. After proper scrutiny of Debit Advice - SF-180, Branch respond s the entry accordingly 1.14.1 Centralized Main Branch performs the following functi ons: i. Calculates Cash in Transit (CIT) service charges (FCY) and number of days during Cash in Transit. ii. Apply Foreign Currency Translation rate, calculate CIT service charges and pool expenses amount in PKR. iii. Convey total amount of charges to the branch. iv. Contact Security Service Agency to transport Foreign Currency cash amount with insurance coverage. v. After receiving the cash bags from branch along with the Debit Advice and Shipment Receipt, count cash and respond to the Inter Branch Debit Advice SF -180. vi. Note down the transaction amounts of Cash & Sundry Creditors in the Cash Book and Sundry Creditors Register. vii. Designated Authorized Officer is required to reconcile daily General Ledger balances with the Manual Register (where applicable). On monthly basi s: i. Centralized Main Branch receives Cash in Transit Services/ Insurance Coverage Charges (Domestic) from Security Service Agency. ii. Centralized Main Branch originates Inter Branch Debit Advice - SF-180 for each Foreign Currency branch. iii. Attach Original Bill with the Inter Branch Debit Advice - SF-180 and retain original summary sheet for record keeping. iv. Credit the Security Service Agency account 1.14.2 Branch: (Designated Authorized Officer) i. Branch converts total Foreign Currency amount into Pak Rupees by applying F C translation rate. ii. Deducts total expenses amount from converted PKR amount. iii. Originate net amount Inter Branch Debit Advice in favor of Main Branch. iv. Keep total Foreign Currency amount and Debit Advice in packed Cash bags provided by Security B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 131 Service Agency . v. Close cash bag with the plastic numbered seal. vi. Prepare Shipment Receipt and delivers the same to the staff of Security Service Agency. vii. Staff of Security Service Agency affix stamp & acknowledges the copy of Shipment Receipt and delivers the same to Bra nch for their future record. 1.15 PROCEDURE FOR RECEIV ING FOREIGN CURRENCY FRO M MAIN BRANCH BM/ BOM i ntimate their Foreign Currency Cash requirements in the evening prior to working day to the Centralized Main Branch through e-mail or fax after getting approval of their respective RH/ ROM i f the amount exceeds the pre -established ‘threshold limit’ (Equivalent PKR) . Further the requests through Fax or e -mail will carry AS/IBS number of BM/ BOM. i. Upon arrival of cash at the branch the Designated Authorized Officer ( Teller services supervisor ) in the branch verifies the identity of the staff members of Security Services Agency from the photographs and signature supplied by the cash house. ii. Designated Authorized Officer (BOM/TSS) obtains the triplicate copy of shipment receipt and inter - branch debit advice (SF -180) from Security Company. The details of denominations of currency notes must be written in the shipment receipt. iii. Designated Authorized Officer (BOM/TSS) check that the exact amount of cash is supplied by the Cash House. Also verify the embossed/printed numbers of seal on the cash bags with the transit/shipment receipt. iv. Upon verification and authentication of cash shipment amount / denomination the Authorized Officer (BOM/TSS) acknow ledge receipt of the cash on the transit/shipment receipt IBCA (SF -180) by affixing cash receipt stamp and deliver the same to the staff of Security Service Agency and retain the duplicate copy of transit shipment receipt for records. v. Enter the amount of c ash in Cash Book SB -57 in the receipt column. Also post the relevant accounting entries in the sys tem. 1.15.1 Centralized Main Branch performs the following functions: i. Calculates Cash in Transit (CIT) service charges (FCY) and number of days during Cash in Tran sit. ii. Apply Foreign Currency Translation rate, calculate CIT service charges and pool expenses amount in PKR. iii. Prepare Inter Branch Debit Advice - SF-180 & Shipment Receipt. Contacts Security Service Agency to transport Foreign Currency cash amount with ins urance coverage to the branch. iv. After the bundles/packets of cash are counted and found correct, keep cash in canvas bag/s which is provided to the branch by the Security Service Agency. v. When the cash is packed in bag/s, the same will be tied with plastic numbered seal/s by the Designated Authorized Officer. vi. Security Service Agency provides the original Inter Branch Debit Advice on SF -180 along with its quadruplicate copy of the same. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 132 1.16 LATE RECEIPTS The amount of cash deposited by a customer in late hours, after the close of cash counter is also required to be noted in the Cash Book - SB-57 and; i. Clearly mark “Late Receipt” on the Deposits Slip. ii. Designated Teller & Operations Manager will sign -off the Deposit Slip and affix “Cash Received” stamp on the slip. iii. Keep cash along with the Deposit Slip in vault under dual control. iv. On the next working day, upon opening of the branch, promptly credit customer’s account. 1.17 TELLER CASH TRANSFER i. During counter hour s, Tellers can transfer cash from one teller to another Cash Teller in order to meet his/her cash requirement. Such transactions of cash, between the two Tellers are performed under the supervision of the Teller services supervisor. ii. In SYMBOLS, the option is given to handle transfer of Cash between the two tellers on the system. Teller selects BT Module >> Transactions >> Cash Management >> Cash Transfer >> (Screen # BT - 22). iii. The Teller services supervisor supervises all Cash transfer transactions. Message appears on the Teller services supervisor’s Screen for override, when Teller services supervisor authorizes the transaction. Transaction completion message will appears on the Teller’s system screen. 1.18 KEYS & KEY REGISTERS i. All Keys of the Branch including Strong Room, Cash Safe, and Main Door etc. should be recorded in Key Register SB -80 with name of the Custodian duly acknowledged by them. ii. All Movements i.e. Handing and Taking over of Keys in case of leave or transfer of staff are also recorded in the said Register with Date and Signatures of respective staff. iii. Besides, Test Keys, Morning / Evening / Utility Cash Received Stamps should also be recorded in the said Register duly acknowledged by the respective staff. iv. Duplicate Keys in sealed packets should be placed with the Main Branch of the bank or NBP/SBP branch, duly recorded in Key Register. Acknowledgement thereof is placed as Safe Custody Item. v. At the time of transfer of Manager, incoming Manager must exchange Duplicate Keys with the Set of Keys alread y in use of the Branch. 1.19 APPLICATION OF TEST i. Operations Managers have to ensure that all outgoing documents, advices and instruments should be signed by two IBS and/ or AS holders in the branch. Officers who do not bear IBS/AS number are not eligible to sign-off the above documents. ii. Test should be applied on all the Inter Branch & Head Office Debit/Credit Advices amounting PKR 25, 000 and above. iii. All Advices must be duly signed -off by Two Authorized Officers holding Inter Branch signatory or Authorized S ignatory number.  Inter Branch Signatory (IBS): IBS holder is only authorized to sign off (Jointly with another IBS/AS holder) the documents, instruments and advices which are originated with in the Bank Branches and/or Offices. (Includes Payment Orders, Local Demand Draft, Local Telegraphic Transfer an d other B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 133 inter branch/office Advices/documents)  Authorized Signatory (AS) : Authorized Signatory is authorized to sign off the instruments/documents on behalf of the Bank. All Letter of Credit, Foreign Demand Drafts and all other formal documents of the Bank should be signed by Authorized Signatory jointly with any one IBS/AS holder. 1.20 RESTORE OFFLINE FINA NCIAL TRANSACTIONS Customers can withdraw cash from the branch counter in an “off -line” mode of SYMBOLS. In order to accommodate the customers, system modi fications have been made where Cash Withdrawals can be processed on BT Module even if the branch is in “off -line” mode. The following conditions however apply: i. The branch has been in the off -line mode for 15 minutes. ii. The customer is an account -holder of t he off -line branch (i.e. customers of other branches will not be serviced in an off -line mode). iii. Cash withdrawal will be restricted to a maximum of Rupees Fifty Thousand only (PKR 50,000) per day per customer. 1.20.1 Process for performing Offline transactions a re as follows: i. Teller receives cheque from the customer & uses SYMBOLS (BT)> Transactions> Single Transactions > Current/ Savings account> CHEQUE WITHDRAWAL SCREEN# BT3214” and processes the transaction. (Transaction Type CQWR) ii. In case of Insufficient Bala nce or Stop cheque marked in the account message will appear on the screen with override option “RF not Set for this Account” or “Stop Cheque” respectively. If transaction is accepted by the supervisor, transaction will be executed in off -line mode. iii. As br anch becomes online, Teller services supervisor or Supervisor selects Branch Teller Module > System Admin > Other Functions > Initiate Off -line File Transmission > Initiate Store & Forward >> screen displays option “Yes”. Press Yes. iv. If there are any un -posted transactions on the system (Performed in “off –line” mode), total number will appear on the BT Main Screen. As Teller services supervisor /Supervisor successfully performs the above function on the system, the entire un -posted tra nsactions will be updated on the system. v. Report of transactions processed in off -line mode generate d from Deposits (RB) module> Reports > Cheque Processing > Off -line Cheque exceptions - Screen No - RB A84. vi. Teller services supervisor reviews the report and if there are any un -posted transactions, will post the same on the system. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 134 1.21 USAGE & SAFE CUSTODY OF CASH RECEIPT/PAID ST AMPS There are two Cash Received stamps: i. Cash receipts below 100K – To be used by designated TSO (as per their assigned limit) ii. Cash receipts above 100K – To be used by TSS/ BOM for approval above TSO limit. Cash received and paid Stamps will be handed over to designated TSO at the start of the banking hours and will be preserved back by TSS/ BOM at the close of the banking hours ‘Cash Received’ or ‘Cash Paid’ Stamps should not be left open or handed over to any other unauthorized officer of the branch. Responsibility to safeguard any misuse of stamps during banking Hours lies with the TSO whom the stamp is assigned. Cash Receive d and Paid stamps should be placed in vault under dual custody of TSO/ TSS and BOM 1.22 IMPOSITION OF SBP PE NALTIES Sr. Nature of Violation Scale of SBP Penalties 1 For not maintaining the prescribed Statement of Daily Closing Cash Balance. PKR 5,000/ - per instance plus PKR 500/ - per day during which the default continues. 2 Non -maintenance of minimum One Day’s fresh / re - issuable balance in accordance with the average daily cash payment requirements. PKR 5,000/ - per instance plus PKR 500/ - per day during which the default continues. 3 For not properly sorting Bank Note Packets / Bundles into issuable/non -issuable condition over the payment counters. PKR 5,000/ - per instance plus PKR 500/ - per packet of un -sorted /non -issuable Currency Notes of any denomination, if caught, being pushed into circulation 4 For not providing extra effort for on spot sorting of Bank Notes over the Counter in case where average daily payment is exceeding PKR 1.50 Million. PKR 5,000 /- per instance. 5 For not affixin g SORTED” stamps on packets of Bank Notes. PKR 500/ - per packet of any denomination is caught on -site examination and PKR 500/ - per packet in case any stakeholder along with evidence of the same lodges a complaint. 6 For not accepting small denomination Bank Notes of PKR 10/- as well as Cut / Soiled / Mutilated and Defective. PKR 10,000/ - per case with evidence. 7 For not removing the Staple Pins from packet of PKR 10/- denomination Bank Notes and not properly banding them. PKR 500/ - per packet. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 135 1.23 BASIC GUIDELINES FOR MCB COLLECTION S YSTEM FOR TB D TRANSACTIONS TBD does not designate all MCB branches for all TBD customers. While receiving any TBD deposit, branches must ensure that they have been designated by TBD for r eceiving the Collections for a particular TBD customer. While designating any branch TBD sends designation letters/emails to the branches along with the process to be followed in that collection. Branches must retain the record of said designations. In cas e a depositor comes at a branch & the branch is not a designated branch it should not receive the deposit & should report the instance to TBD so that TBD can handle the situation accordingly 1.23.1 Guidelines While Receiving TBD Deposits at Branch Counter i. Specific stationeries have been prescribed to receive various deposits of TBD. Branches are supposed to accept the deposits only on prescribed stationery. ii. Branches must monitor the stock of the prescribed stationery. Stationeries must be requisitioned from MCB Employees Foundation in time to avoid any shortage. Receiving deposits on "Photocopies" of the deposit slips etc is strictly not allowed. iii. Deposits should only be received in branch banking hours. Deposits if received after banking hours should be take n in next working date & be processed accordingly the next day. iv. Proper stamps are supposed to be affixed for Cash, Internal Transfer & Local Clearing Instruments acknowledgements. Use of incorrect acknowledgement stamps may be risky for branch/bank. v. For br anch deposits there are two main Collection Products. One is "Collectplus" & other is "Remitplus". Deposits in the form of Cash, Internal Transfer Cheques, & Local Clearing Cheques can be accepted under "Collectplus" mode of Collection. Deposits in the for m of Cash, & Internal Transfer Cheques, can be accepted under "Remitplus" mode of Collection. Local Clearing Cheques cannot be accepted under " Remitplus" mode of Collection. vi. Instruments that do not come under the local clearing i.e. Outstation Instruments/ OBCs cannot be accepted in any circumstances in both modes of Collections (Collectplus & Remitplus). Branches must not receive such instruments from depositors. vii. Post dated instruments cannot be accepted by branches. viii. Branches are strictly prohibited for iss uance of any post dated "Remitplus Receipt" under TBD's "Remitplus" arrangement. ix. Guidelines For Posting Of TBD Transactions x. Keeping in view the real time online status of all MCB branches, branches are supposed to post all TBD transactions at the same time the deposit is received at branch coun ters. Late posting is strictly not allowed. xi. Branches must use TBD's Collection System for TBD transactions. xii. Branches must take extra care while making posting in TBD's Collection System. All fields either mandatory/ optional must be filled in with accurately with the information available on the deposit slip. Branches must take extra care while selecting the "Payment Type" while posting in TBD's Collection S ystem. Posting with incorrect " Payment Type" may result in th e form of unbalanced accounting / GL heads of the branch. xiii. No back dated reversals/debits are allowed from TBD's Collection Accounts being maintained at Global Transaction Banking Branch (GTBB - 0069). If there is a need to do a back dated reversal, branch must seek written approval from TBD. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 136 1.23.2 Guidelines For Intimating TBD i. All "Returned" instruments along with the "Return Memo" must be dispatched to TBD Karachi & should not be handed over to the depositor. ii. No deposit slip copies, scrolls are required at T BD. Branches should not send any such document to TBD. SECP's Challan copy is an exception here & branches must send TBD's SECP Challan's copy to TBD Karachi. 1.23.3 Asking Help From TBD TBD runs a help desk for the convenience of our branches. Branches are supp osed to interact with TBD in case they are confused in anything related to TBD & want guidance from TBD. 1.24 CURRENCY TRANSACTION REPORTING (CTR) This is Applicable to all Cash Transactions (Receipts & Payments) PKR 2.5M & above Reference to latest provisions of Anti Money Laundering (AML) Act, 2010 whereby Currency Transaction Report (CTR) has to be submitted to Financial Monitoring Unit (FMU) regarding the currency transactions of PKR 2.5M & above on daily basis through Compliance & Controls Group (CCG). To combat against money laundering and terrorist financing branches are advised to ensure that all cash transactions (payments / receipts) of PKR 2.5M and above are properly scrutinized. In this regard branches are advised to take the following pr eemptive measures before executing the transactions:  Retain the copy of CNIC of the Person conducting the Transaction.  Verify CNIC of the person through NADRA VeriSys.  Record the purpose of the transaction.  Ensure that the transaction is in line with the customer profile/ KYC. (If the cash transaction is not in line with customer profile/ KYC, BM will take supporting documents for the transaction and re -conduct/ update KYC) In order to monitor the cash transactions and maintain proper records for ready r eference; Branch Manager and Branch Operations Manager are advised to verify each cash transaction of PKR 2.5M and above and fill out necessary information of the person conducting the cash transaction as per “CTR Form ” (Anne xure XXIII ). Please note, in case the customer is present in the branch conduc ting the transaction, CTR Form will not be filled however ‘Purpose’ of the t ransaction will be recorded for future reference. Please note that it will be the responsibility of t he transacting branch to provide the complete information of the transaction(s) performed through their counter. “CTR Forms” will be filed/ preserved by the branch and shall be furnished upon request of CCG. All Branches /field staff / Controlling Offices are advised to go through the contents of AML Act, 2010 thoroughly (available on MCB portal) and ensure strict compliance / adherence in letter & spirit. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 137 Chapter 2 CASH DEPOSIT & WITHDRAWAL 2.1 PROCEDURE OF CASH DE POSIT Customer presents duly filled Deposit slip to the Teller along with cash. Teller: i. Receives deposit slip along with cash. ii. Counts and checks the currency notes. iii. Verifies the amount from the deposit slip. iv. Checks the deposit slip for completeness e.g. Date, Title of Account, Account n umber, Depositor’s Signature and depositors contact no. (mandatory) Teller uses SYMBOLS (BT)> Transactions> Financial Transactions >> Single Transactions > Current/Savings account> CASH DEPOSIT (SCREEN # BT3211) and pr ocesses the transaction. (Transaction Type -CASD) i. Input or select Transaction Type from the list of values. (Cash Deposit - CASD) ii. Input or select Currency from the list of values. iii. Inserts the account number (List of values available) iv. Inputs the transaction amount. v. Affix “posted” and “Cash Rece ived stamp (as per his/her assigned limit stamp )” on the deposit slip. vi. Sign off the same and gives the Copy (B) to the customer. vii. Keep cash in the box. In-case the transaction is over Teller Limit: i. TSS/ BOM authorizes/approves the transaction via remote override BT> Override > Remote Override (Screen # BT002020). ii. Affix “Cash Received Stamp” and signs the deposit slip. Customer receives the copy B of deposit slip and leaves the branch. Teller/ DAO : i. Validates the source documents (Deposit Slips & Cash Vouchers) with RBA -11 report and arranges filing of the same. ii. In case of any discrepancy, transactions will be thoroughly reviewed by the Branch Operations Manager & necessary action will be taken accordingly. Subsequently amended report will be re -printed for final review. iii. After the complete validation of the reports, two (02) authorized officers will sign -off the same. 2.2 PROCEDURE FOR CASH D EPOSIT REVERSAL Teller: i. Select the BT Module>Enquiries> Electronic Journal. ii. Selects the required details (account number & reference) for extracting the particular transaction to be reversed. iii. The journal displays the relevant transaction(s) iv. Select/highlight the transaction to be reversed. v. Press <Alt -9> for execution of the reversal (transaction type "CSD#" automatically generates - Cash deposit reversal) vi. A pop -up appears to confirm the reversal of the transaction. vii. Upon clicking "Yes" screen pop -up message for the supervisor's over ride. viii. Once authorized by the Supervisor/Teller services supervisor, the system shall then automat ically reverse the transaction B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 138 2.3 PROCEDURE FOR CASH W ITHDRAWAL VIA CHEQUE Customer comes to the branch to withdraw cash from his/her current/Savings account via cheque. Customer presents a cheque for the required amount to the Teller. Teller receives cheque from the customer and examines details: i. Date and signature. ii. Amount in words and figures is same. iii. No crossing stamp is there. iv. It’s a bearer cheque. Note: All cheques exceeding PKR 50,000 should be carefully examined under ultra violet lamp to detect the chemical alteration, if any. It is preferred to affix stamp “UVL carried out by (name of teller) ”. Teller uses SYMBOLS (BT)> Transactions> Single Transactions > Current/Savings account> CHEQUE WITHDRAWAL SCREEN# BT3214” and processes the transaction. (Transaction Type CQWR) i. Inserts account number (Customer & Account information will be displayed on the screen). ii. Verifies customer’s signature and affix ‘Signature Verified’ Stamp iii. Input or select Currency. iv. Verifies the transaction amount. (System checks the same with the available balance in the account) v. Enter Effective Date and press en ter. vi. Input the Reference (Cheque) Number. (If transaction amount exceeds the Teller’s limit or any Restraints are attached to the account, screen pop -ups “Authorization Required” message. Teller services supervisor authorizes/approves the transaction by using BT> Override > Remote Override Screen# BT002020) after verifying credentials on original instrument. i. Deliver Cash to the customer. ii. Affix ‘Cash Paid’ Stamp on cheque. iii. Override transactions will be displayed on the Remote Override Screen # BT002020. iv. Authorize the transaction and message will be appeared on Teller’s system. Sign -off the instrument and delivers the same to Teller for Cash Payment. Customer receives cash, counts the same and leaves the Branch. Back Office i. At End of Day, Pass all the paid cheques to the Back Office for checking along with the transaction report. ii. Check the cash transaction report with the paid cheques. iii. Files the report and paid instruments. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 139 2.4 PRECAUTIONS AGAINST FAKE/ CHEMICALLY ALTERED / RUBBED / DEFACED CHEQUES i. Examine all cheques for inconsistencies, whether in size, the quality of Printing or the general appearance of the cheque.  The finishing may feel un -even or softer than normal in fake cheques  The Paper color may be Grayish, stained or the ink color somewhat different  Chemical reaction may appear on the back -side of cheques printed on chemically sensitive paper (easy Pull up) if they contact with chemical solvents ii. Inspect the cheques under UVL by holding the cheque up to the light at a 45 -degree angle. Watermark and/or micro printing could be faint or non -existent in case of alteration iii. In case of doubt, make the presenter sign the cheque in front of the TSS/ BOM who then checks the same with copy of CNIC. This stops fraudsters taking time to perfect a forgery prior to committing the Fraud. In case of doubt on the copy of CNIC, Check it with NADRA VeriSys iv. Branches are also provided with BLACK INSTANT VERIFICATION (BIV) MARKERS . An original cheque will change color to ‘black’ once applied. A fak e/forged cheque will not change any color. Tellers are advised to validate all high value transactions by setting a spot or a small line at the back of the cheque/instruments. Further these markers can also be used on presented cheques/ instruments for any kind of suspicion. 2.5 PROCEDURE FOR CHEQUE WITHDRAWAL REVERSAL Teller i. Select the BT> Enquiries>Electronic Journal - BT- 56 Online. ii. Enter the required details (Transaction date and reference) and press Alt+ 8 for extracting the particular transaction to be reversed iii. The Journal displays the relevant transaction(s). iv. Selects particular transaction. v. Press <Alt -9> for execution of the reversal (transaction type "CQW#" – Cheque Withdrawal Reversal) vi. A pop -up appears to confirm the reversal of the transaction. “Do y ou want to reverse the transaction” vii. Upon clicking "Yes" screen pop -up message for the supervisor's override. Teller Services Supervisor Once authorized by the supervisor/Teller services supervisor, the system shall then automatically reverse the transaction. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 140 2.6 PAYMENT OF ON -LINE CASH CHEQUES OV ER BRANCH COUNTERS Branches are required to follow the revised process which is as under: Threshold for on -line cheque transaction amount for ‘over the counter payment’ requiring verification from/by the Parent Branch If presented by 3rd Party / Bearer including presentment at the Parent Br More than PKR100,000 (Rupees One Hundred Thousand only) If presented by the customer himself/ herself at a br. other than the Parent Br More than PKR5,00,000 (Rupees Five Hundred Thousand only) Verification Procedure: Following steps must be taken by the branches for verification of a transaction above the threshold in the respective category stated above: i. The branch receiving the cheque will send copy of the cheque thru FAX / Email (scanned image) to the Branch Operations Manager (BOM) of the Parent Branch with a request for verification of the transaction. ii. The BOM of Parent Branch will refer the cheque to the Branch Manager (BM) or the designated Personal Banker (PB) and either one of them will make Call Back to the account holder (customer) at his/her last known phone/cell number provided to the bank and will inquire about the issuance of the cheque with pertinent details such as cheque number, date amoun t and beneficiary name from the customer for confirmation. iii. Date, time and phone number of all such calls made must be entered at the back of the cheque (for 3rd party/bearer cheques above the threshold limit presented in the Parent branch) or on the FAX copy, as applicable, evidenced by signature of the calling executive/officer for record. iv. In case of no response on the provided contact numbers, the transaction must be referred to the Branch Manager and in the absence of the Branch Manager, to the Branch Op erations Manager who will make a judgment and decide whether to approve the transaction based on pattern of previous transactions and his/her comfort with the customer’s KYC/relationship with the bank etc. Any such approval will be evidenced through the BM /BOM’s signature on the cheque/FAX copy. Details of the call(s) attempted (date, time, phone number) must also be entered on the back of the cheques/FAX copy before authorizing/ making payment. v. The BOM at the Parent Branch will sign the FAX copy of cheque along with his/her IBS/AS number and branch’s stamp after verifying the signature on the FAX copy and confirming BM/PBA’s call back or BM or BOM’s approval and return it through FAX to the requesting/paying branch. vi. Minimum time must be taken by the Parent Branch to verify to verify or decline the requested transaction, adhering to the Service Quality turn -around -time (TAT) standards at all times. Note: Detailed Call Back Confirmation Process and Script is detailed under Section 3: 2.8 Call Back Confirmation Process (CBC) B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 141 2.7 PROCEDURE FOR PAYMEN T OF PKR AGAINST FCY A/C CHEQUE Custome r visits the branch to encash Foreign Currency Cash Cheque and wants to obtain equivalent Pak Rupees. Presents Cash Cheque on the counter. Teller: i. Receives Cheque and verify the instrument by ch ecking:  Date  Amount in Words and Figures .  Signature on the instrument. ii. Process the transaction on System by using Branch Teller Module >> Transactions >> Financial Transactions >> Single Transactions >> Current/ Savings Account >> Cheque Withdrawal (BT-3214) iii. Input Foreign Currency Account number & press Enter account information will appear on the Cheque Withdrawal screen. iv. Input or select the appropriate Transaction Type (Cheque Withdrawal Cash - CQWI) v. Input effective date and press enter vi. Input Curre ncy (PKR), Cross Rate pop -up box will appear on screen. vii. Check Exchange Rate. In case of Frozen Accounts obtain Exchange Rate from Daily Rate Sheet and insert exchange rate in the Cross Rate Box. Click Ok. viii. Input Transaction Amount. (System checks the trans action amount with the available balance in the account) (If transaction amount exceeds the Teller’s limit, pop -up message regarding “Authorization Required” appears on screen. Teller services supervisor authorizes/approves the transaction). ix. Input the ref erence number - (Cheque number) x. Press F10 or Click Save icon xi. Affix posted stamp and sign -off the cheque as per the assigned limit. xii. Count and deliver Cash to the customer. xiii. Affix Cash Paid Stamp. At End of Day, Pass all the paid cheques to the Back Office f or verification with the system generated report. Customer receives cash and leaves the Branch. Back Office checks the cash transaction with the system generated report with the paid cheques. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 142 2.8 CALL BACK CONFIRMATI ON PROCESS (CBC) Following steps must be taken for verification of a transaction from the Customer. This process is to be followed in case the transaction is above the defined transactional threshold limit / KYC or is necessitated due to account status/ restraints marked. i. The BOM of will refer the cheque / Instrument to the Branch Manager (BM) or the designated Personal Banker (PB) and either will call the account holder (customer) at his / her last known phone / cell number provided to the bank and will inquire about the issuance of the cheque with pertinent details such as cheque number, date amount and beneficiary name from the customer for confirmation. Following script will be used: Dear Sir/Madam, I am <Name> calling from MCB bank <branch name, city name> regarding c onfirmation for a Cheque that has been presented to us for Cash Payment/Clearing/ Funds Transfer bearing This call -back is being conducted for your security. 1. Can you please confirm (ask some business/ profile related question other than CNIC info) 2. Can you kindly confirm that you wrote cheque # <xxxxx> amounting to PKR <xxxxx> drawn in the name of Mr. / Ms. <name>? (Once the customer confirms positively) Thank you for your time and confirming. The cheque will be processed and as per your instructions the amount stated on the cheque will be debited from your account. Khuda Hafiz. i. Date, time and phone number of all such calls made must be entered at the back of the cheque / Instrument evidenced by signature of the calling executive / officer for record. ii. In case of no response on the provided contact numbers, Branch Manager or Branch Operations Manager (in absence of BM) will make a judgment and decide whether to approve the transaction based on pattern of previous transactions and his / her comfort with t he customer’s KYC / relationship with the bank etc. Any such approval will be evidenced through the BM / BOM’s signature on the cheque/Instrument. iii. In-case of negative verification, the issue is immediately brought in notice of BM/ BOM for appropriate action Note: All Transactions above PKR 1M should be closely reviewed by BM and CBC to be conducted by BM . 2.8.1 In case the transaction is taking place at a branch other than Parent Branch: i. The transacting branch will send copy of the cheque through FAX / e -mail (scanned image) to the Branch Operations Manager (BOM) of the Parent Branch with a request for verification of the transaction. ii. Parent Branch will conduct Call -back C onfirmation as per the process g iven above. iii. Paying Branch will execute the transaction according to the fate provided by the Parent Branch. Note: Minimum time must be taken by the Parent Branch to verify or decline the requested transaction, adhering to the Service Quality turn -around -time (TAT) standards at all times. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 143 2.9 PROCEDURE FOR CREDIT CARD PAYMENTS AGAINS T CASH - ONLINE PAYMENT FACIL ITY OVERVIEW On-line branches across the country are authorized to handle cash payment of Credit Card installments by customers. Salient Features are as follows: i. The main Collection Account for receiving Credit Card payment is opened in Sheikh Sultan Trust Branch (0842), Karachi, in the SYMBOLS Data base. The account number is (0071956831001326). The type is Current Account with the title of “Visa Card Collection Account ”. ii. This facility is available for existing customers or walk -ins for deposit of cash for on -line transfer to the said collection account in SST Branch. (Walk -in refers to Credit Card customers that do not maintain branch banking rela tionship). PROCEDURE Customer fills out a Special Credit Card Cash Payment Deposit Slip that already has the account number (on beneficiary field) of VISA CARD COLLECTION A/C mentioned on it for customer’s ease along with the Cash Payment and depositors contact no. (Mandatory) . Teller: Receives deposit slip, count cash as per deposit slip and ensure that all the prescribed control requirements are fulfilled. i. Select EOC Icon, input user ID and password for login. ii. Click on Deposit Module. Select Transaction >> Value Transaction >> Deposit screen (RB31) iii. Insert Account # (0071956831001326) and press F8, system show the account information. iv. Verify the information with Cash Deposit Slip and press enter. v. Input Transaction Type "CHPM" (CTL Cash Payment) , Effective Date (press enter), Currency (PKR) and Transaction Amount (excluding service charges) & select option "N" right side on the screen Narrative Box will appear capture customer's credit no. then select the credit card # & press CTLR+F12 (Hot Key ) to authenticate and validate card number. vi. Press F -10 or click save icon to save the transaction. Screen shows system alert Message. "Transaction complete: 1 record applied and saved". vii. Affix cash received stamp on deposit slip & deliver B copy to the custo mer. viii. Forwards the instrument to Teller services supervisor after sign off on the deposit slip. Teller services supervisor: i. Receives posted instrument(s) Scrutinize the deposit slip and validate the input. ii. Verify the posted transaction by using Deposits >> Enquiry >> Account Transaction History (RB75) iii. Prepare batch entry for service charges. iv. GL Module >> Transaction >> Batch Maintenance >> Entry (GL21) Deposit slips forward to back office for batch verification & acceptance Back Office Operations: Receiv es deposit slip & ensure that all the requirements are completed. Accept the batch by using GL Module >> Transaction >> Batch Maintenance >> Acceptance (GL22). Verify and sign off. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 144 Generate following report for validation / record purpose: i. Deposits >> Report >> Daily Activities >> Daily Trans by branch/office (RBA11) ii. General Ledger >> Report >> Daily Activities >> Daily Batch Listing per user (GLA90). Forward the day's Transaction report (RBA11) with 3rd copy of Deposit Slip to Credit Card Division for their validation/record purpose. IT OPERATIONS: i. At EOD, IT Operation will generate a file in the "BRNSIN" format from SYMBOLS in order to update the daily transaction in CTL (Credit Card System) and "PCHLHO" for Card Division GLBS system (accounting purpose). ii. They send the CTL Transaction upload & exception report to Card Operation on daily basis. 2.10 PROCEDURE FOR CREDIT CARD PAYMENT THROUGH CHEQUE – DROP -BOX FACILITY OVERVIEW Card OPS ensures the placement of Drop Boxes in the designated MCB Branches. Branches will be responsible to collect all the Material from Drop Box (of their own branch) on a daily basis which normally contains on the following items. Drop Box Items i. Cheque ii. Stubs iii. Customer complaints / Letters iv. Cut cards v. Marketing material HANDLING PROC ESS Valid cheques (with 16 digits card number or with stub) Branch officer will prepare daily MIS of all valid cheques / Stub which will contain the following information and send it to Card Operation (Karachi / Lahore / Rawalpindi) through email. Karachi = ipu@mcb.com.pk with CC to aba.muhammad@mcb.com.pk Lahore = altaf.ansari@mcb.com.pk with CC to syed.rehman@mcb.com.pk Rawalpindi /Islamabad = abdulhafeez@mcb.com.pk with CC to Irfan.khalid@mcb.com.pk i. MCB Cheques / Payment Stub: As per branch practice all the MCB cheques (Transferred cheques) will be cleared on same day and funds will be credited in MCB Visa Card Collection account # 0000 -1951 -8100 -1803 maintained at MCB Sheikh Sultan Trust Branch – Karach i -0842. ii. Clearing Cheques: As per Branch practice all the clearing cheques will be sent in clearing on first working day and on second working day when funds / fact of cheques are received from NIFT, branches will credit cleared cheques funds into MCB Vis a Card Collection Account # 0000 -1951 -8100 -1803 maintained at MCB Sheikh Sultan Trust Branch Karachi -0842. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 145 iii. Collection / Out of city cheques: All the collection (Out of city) cheques will be sent for clearing to the respective city as funds received branch es will post credit in MCB Visa Card Collection Account # 0138 -7989 -4100 -2986 maintained at MCB Sheikh Sultan Trust Branch Karachi -0842. In addition to the above Branches have to make photocopies of all individual cheques and send these with MIS of above to Card Operation -Karachi through normal mail. iv. Post Dated Cheques: Branches’ officers will keep all the post dated cheques in their safe custody and will present on their dates for clearing and thereafter, will be treated same as mentioned above and will be credited MCB Visa Card Collection Account # 0000 -1951 -8100 -1803 maintained at MCB Sheikh Sultan Trust Branch Karachi -0842. The below items must be mailed to Cards Operations Karachi / Lahore / Rawalpindi on a daily basis.  Discrepant, Returned / dishonored cheques  Personal Loan / other bank / Miscellaneous Cheques  Stubs / Customer Complaints / Cut Cards  Marketing Material Branch officer will prepare another MIS of all above other items on excel sheet and will dispatch to Card Operations Karachi / Lahore / Rawalpindi for the necessary action on the following address es: Karachi Lahore Rawalpindi Attention: Aba Muhammad / Ishtiaq Ahmed Abro Item Processing Unit Credit Card Operation 3rd Floor SST Building Beaumont Road, Karachi Phone # 111 -800-800 Ext 207 - 632 Fax # 021 -5651366 Attention: Ammad Uddin Ghauri / Syed Abdul Rehman Ali Shah MCB Bank Limited Credit Card Operation MCB Building 2nd Floor Main Market Gulberg – Lahore UAN: (042) 111800800 Direct: (042) 35763473 Fax: (042) 35762433 Attenti on: Irfan Khaliq / Abdul Hafeez MCB Bank Limited Credit Card Operation 1st Floor al -Gillian Building Murree Road – Rawalpindi 0333 -5610864 / 051 -4581198 Note: Cheques dropped in Lahore/ Karachi/ Islamabad branches will be picked up by Designated Courier and Branches are not required to send the same through courier. 2.11 PROCEDURE FOR CASH A DVANCE TO CREDIT CAR D CUSTOMERS OVERVIEW This facility provides an alternate to all card holders, in addition to the ATM, for Cash Advance through Branch Network, according to card -holder’s Cash advance entitlement under the Credit Card Scheme. Salient features are as follows: i. The facility is available in all branches across the country. ii. There is a main disbursement Account for withdrawal of funds by branches under the facility, opened in Sheikh Sultan Trust Branch (0842), Karachi, in the SYMBOLS Data base. The account type is Current Account with the title of “MCB Cards - Cash Advance through POS”. (The account number is B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 146 0036154311001494). iii. The POS terminal is availab le in each selected branch. These terminals are connected via phone network to the main CTL system for on -line transaction approvals. iv. The relevant Branch staff (Branch Operations Manager, the Teller services supervisor and one senior Teller) is adequately trained to operate the POS and execute the transaction. The facility is available to both MCB Card member (on -us) and other Card holders (off -us). PROCEDURE Customer: i. The Cardholder (‘on -us’ and ‘off -us’) will visit the branch and approach the Teller at the Cash Counter. Branch: i. The designated teller will ask for the Credit Card. For ‘off -us’ card holder additional identification (CNIC or a valid passport copy) will al so be required. ii. The Teller will swipe/dip the Card to the Terminal and input the desired Cash withdrawal amount. iii. The on -us customer will be asked to approach the desk and input the Pin -Code (for validation). iv. The scroll/slip validating the approval of th e transaction will be printed in two copies. Each transaction will have an approval code and a unique trace number printed on (right side of the) slip. v. The Teller will ask the card holder to sign the slip. The signature will be matched with the signatures on the back of the Card. vi. The Off -us card holder will be asked to provide copy of the CNIC or valid passport for branch records. vii. Once the approval process via POS is complete the branch will disburse Cash (as given on the slip) as per the required denomi nations according to the Cash Withdrawal process on the branch counters. viii. Before disbursal, the processing Teller will validate the transaction, confirm the amount and put his/her initial on the slip as confirmation. ix. Teller will disburse Cash and put the Cash Paid stamp on the back of the slip and initial. Upon receipt of Cash, the card holder will be requested to sign the same slip on the back as receipt. x. Teller will be required to keep a log of each transaction with approval number and the amount for End of Day (EOD) reconciliation. xi. At EOD the branch will print the summary of all the day’s transactions for validation against all approved slips and reconci le the Cash paid over the counters against POS. xii. At EOD, finally, the Branch authorized official will key -in the settlement of total cash ‘sale’ transactions for the day as per the recommended guidelines for the handling of POS terminal. xiii. After the settlem ent entry, the POS terminal will be un -hooked and securely placed in the main Vault. xiv. Finally, the Teller will forward the details of total transactions for the day (each individual slip with the matching summary scroll duly validated) to the Operation Man ager for further processing. xv. Branch will pass one consolidated transaction for the day for total cash withdrawal by debit to the main Disbursement Account (0036154311001494 in SST Branch, Karachi) as per the regular Cash Withdrawal transaction (Transactio n Type: CASW) in the Deposit (EOC) in a Branch xvi. Branches will validate each transaction against the main Summary of POS Scroll extracted at end of day. xvii. The Branch Operations Manager will validate and initial on the Summary in confirmation. Following repor ts will be reviewed and filed duly signed -off by Branch Operations Manager:  Generate report from Symbols (EOC): RBA11 (for the CASA activity validation)  Generate report from Symbols (EOC): GLA90 (for the GL validation -Symbols) B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 147 Chapter 3 INWARD & OUTWARD CLEARING Clearing of Bank Instruments includes collection and payment of chequ es, Demand Draft, Payment Order and Dividend Warrants etc. ‘Collection ’ and ‘Payment ’ of instruments are known as Outward and Inward Clearing respectively. 3.1 OUTWARD C LEARING 3.1.1 Scru tiny of the Deposit Slip: Deposit slips and the cheques/instruments should be properly sc rutinized before accepting them.  Title and Account number are mentioned.  Amount tallies with that of cheque(s).  The amount in words and figures are same.  There are no unauthorized alterations.  The amount, account number and the title of account in the customer copy are same as in the Original /pay -in-slip.  The pay -in-slip bears the depositors signature and contact no. ( Mandatory ) at the specified place. 3.1.2 Scrutiny of Cheque/Instruments: Following points should be properly checked:  The cheque is not post dated or undated or stale dated or invalid dated or incomplete dated.  There is no unauthorized alteration o n the cheque.  Payee name and Drawee Signatures is Present.  Particulars of a cheque should be written with Permanent Ink  The amount in both words and figures is required and both should match.  Any endorsement and special crossing are in order.  Nothing on the cheque indicates that the depositor is not entitled to receive the amount.  The cheque payable to a firm, company or institution should not be accepted for credit to the account of partner, director, agent, attorney, manager or any employee.  If the payee is a Government Department / Official or a Trust, a chequ e should not be collected for a person other than the payee.  Cheque Crossed / Marked “Payee Account Only” must be deposited in customers account ONLY and should not be deposited in another the Payee account  Order cheque being deposited in other account is properly endorsed by the Payee in favor of depositor and also signed by the depositor. “Non -Transferable” instruments should not be collected for a person other than the payee After the complete scrutiny of the cheque and deposit slip, affix “Clearing Date Stamp” on the deposit slip and on the instrument(s). B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 148 3.2 PROCEDURE FOR OUTWAR D CLEARING – NIFT BRANCHES Customer presents duly completed deposit slip along with the instrument(s) (Other than MCB instruments) to the Clearing teller. Clearing Processor: (Day One) i. Receives deposit slip and instrument(s). ii. Checks deposit slip  Account number and Title of account  Signature on the deposit slip along with depositors contact no. (mandatory)  Amount in words and figures is identical.  Instrument amount tally with amount mentioned on deposit slip. iii. Scrutinizes Instruments:  Validate the customer account number.  Endorsement and special crossing (if any) are in order.  No un -authorized alteration.  Amount in words & figure are identical.  The i nstrument is neither post dated nor undated or stale.  Instruments pertain to within city.  Inter -city Instruments will be sent via Inter -city clea ring or Collection arrangement. iv. Affix bank’s Clearing Stamp and sign -off deposit slip and return customer copy (B) to the Depositor. Customer receives “B Copy” of slip and leaves the branch. Clearing Processor: (Day One) i. Endorse & sign off on the reverse of instruments as per the requirement. ii. Detach Deposit Slips from the instruments. iii. Enter details on manual register (SB-70) OR on an Ms-Excel sheet. Details include; a/c #, title of the beneficiary, bank drawn on, branch, cheque # and amount. If Ms -Excel Sheet is maintained, it should be printed and duly signed and preserved. iv. Make stack of 50 instruments (50 instruments in each stack). v. Add list the total of 50 instruments in a stack and attach the list with the stack. vi. Makes a summary of the received instruments along with the bundle cover. vii. Deliver the instruments to NIFT rider in the even ing for realization of funds. viii. Forward deposit slips along with the summary to Teller services supervisor/ Supervisor for safe custody. Note : i. For inter -city instruments , prepare same set of documents as stated above for each city in pre -printed city envelo pes ii. No accounting entry is passed on Day 01 i.e. on the day branch receives deposit instruments from the customers. NIFT (Day One) i. NIFT receives instruments from the branch along with the covering schedule. ii. Process them for onward delivery to the concerned banks for clearance of funds next day (i.e. Day 2) (Day Two) i. NIFT delivers HO 2242 Voucher along with Inward Clearing. ii. In second half, NIFT rider delivers “Cheques Returns” to branches. iii. NIFT rider will also deliver HO 2293 (difference amount) Voucher along with Scroll Summary showing branch wise consolidated amount of Total Return “RECEIVED & DELIVERED” with “NUMBER OF ITEMS Clearing Processor – (Day Two) Outward Clearing Credit B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 149 3.2 PROCEDURE FOR OUTWAR D CLEARING – NIFT BRANCHES i. Receives the deposit slips along with the summary from Teller services supervisor/ Supervisor. ii. Select SYMBOLS BT >> Transactions >> Financial Transactions >> Single Transactions >> Current/Savings Account >> Cheque Deposit – BT 3213.  Input Account number (select from LOV) & press enter.  Input or select from LOV the a ppropriate transaction type ‘CQCC”  Input or select currency - PKR.  Input the transaction amount.  Input the bank, branch & issuer account number.  Input the effective date and press enter.  Pop-up window appears asking for the voucher number.  Press enter on Float Days “2” and input the reference (cheque No).  Press F10 or click ‘Save’ icon on the tool bar. Message will appear for transaction acceptance). If transaction amount exceeds the Teller’s limit or any restraints are attached to the account, the overrid e screen with appropriate message will appear. Designated Officer authorizes/approves the transaction by override either locally or remotely. iii. Press the appropriate option of local or remote override. iv. When Supervisor authorizes the transaction Confirmation message will appear on teller’s screen. Clearing Returns: i. In the late hours, NIFT Rider delivers Cheques Returns” to the branches. ii. Cheques returned in the clearing MUST be posted (reversed from customer account) by the branches on the same day without any fail. Select EOC – Deposits >> Transactions >> Value Transactions >> Withdrawal -RB32: Input account number and press F -8 i. Customer & account information will be displayed. ii. Input the appropriate transaction type - “CQCR”. iii. Input the effective date and press enter. iv. Input the currency – PKR v. Input the cheque amount. vi. Press F10 or click ‘Save’ icon on the tool bar. vii. Communication with Custome r viii. Note down the details of Returned Cheque in the Cheque Return register SB -15. ix. Inform the customer about the Returned Cheque via telephone and note down the appropriate remarks on the reverse of Return Memo. x. On customer’s visit to the branch, Teller delivers original instrument and Return Memo to the customer after taking the proper acknowledgment from the customer on SB -15. xi. If customer does not come to collect the Return Cheque from the branch within 05 working days, Teller intimate the customer by s ending SF -20 along with copy of Returned Cheque and Return Memo. GL Entries: Branch will post HO -2293 (difference amount) voucher, delivered by NIFT rider along with returned cheques. Daily Activity of Clearing Operations i. Designated Officer will verify t he total figure of clearing sent to NIFT on Day One with the NIFT Scroll – “CLEARING DELIVERED BY YOU” on a daily basis. ii. Designated Officer is also required to generate transaction report (RBA -11 & GLA -11) and forward to supervisor with source documents fo r verification and sign off. iii. After posting of returned clearing, designated officer will validate GL Clearing Control Head (GL1150101140) of their branch. It should reflect ‘ZERO’ balance. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 150 3.2 PROCEDURE FOR OUTWAR D CLEARING – NIFT BRANCHES iv. Operations Manager will sign off the relevant reports and ensure t hat Clearing Control Head (GL1150101140) balance is ZERO. Float Adjustment: i. Select EOC Deposits >> Transactions >> Non -Value Transactions >> Float Adjustment by Branch – RB442. ii. Change the date of those transactions where Float Days is “2”. iii. Press F10 or click ‘Save’ icon on the tool bar. 3.3 PROCEDURE FOR OUTWAR D SAME -DAY CLEARING – NIFT BRANCHES Customer presents duly completed deposit slip along with the instrument(s) (Other than MCB instruments to the Clearing Processor Clearing Processor: determines whether it is a 'same day' clearing. Same is categorized as below: i. Amount 500k and above ii. Both Receiving and Paying Banks/Branches are members of "Same day clearing - NIFT" iii. Cheque is received before 9:30AM Clearing Processor: i. Receives deposit slip and instrument(s) ii. Checks deposit slip  Account number and Title of account  Mention Bank and Branch Name and Instrument No.  Signature on the deposit slip along with depositors contact no. (mandatory)  Amount in words and figures is identical.  Instrument amount t ally with amount mentioned on deposit slip. iii. Scrutinizes Instruments:  Endorsement and special crossing (if any) are in order.  No un -authorized alteration.  Amount in words & figure are identical.  The instrument is neither post dated nor undated or stale.  Instruments pertain to within city  Affix bank’s Same -day Clearing Stamp and sign -off deposit slip and return customer copy (B) to the Depositor. Customer receives “B Copy” of slip and leaves the branch. Clearing Processor: i. Endorse & sign off on the reverse of instruments as per the requirement. ii. Detach Deposit Slips from the instruments. iii. Enter details on manual register (SB -70) OR on an Ms-Excel sheet. Details include; a/c #, title of the beneficiary, bank drawn on, branch, cheque # and amount. If Ms -Excel S heet is maintained, it should be printed and duly signed and preserved. iv. Make stack of 50 instruments (50 instruments in each stack) v. ‘Add list’ the total of 50 instruments in a stack and attach the list with the stack. vi. Place in Same -Day Clearing envelope wi th the summary sheet. vii. Summary sheet has 3 carbonized copies. An acknowledgement is given by GBO to NIFT by stamping their copy viii. Prepare bundle cover. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 151 3.3 PROCEDURE FOR OUTWAR D SAME -DAY CLEARING – NIFT BRANCHES ix. Deliver the instruments to NIFT rider NIFT Representative collect the Same -day clearing cheques before 9:30AM NIFT Representative Delivers HO 2242 Voucher along with Inward Clearing. Delivers HO 2293 (difference amount) Voucher along with Scroll Summary showing branch wise consolidated amount of Total Return “RECEIVED & DELIVERED” with “NUMBER OF ITEMS Clearing Processor Outward Clearing Credit i. Receives the deposit slips along with the summary from Teller services supervisor/ Supervisor. ii. Select SYMBOLS BT >> Transactions >> Financial Transactions >> Single Transactions >> Current/Savings Account >> Cheq ue Deposit – BT 3213.  Input Account number (select from LOV) & press enter.  Input or select from LOV the appropriate transaction type ‘CQCC’  Input the transaction amount.  Input the bank, branch & issuer account number.  Pop-up window appears asking for the voucher number.  Press F10 or click ‘Save’ icon on the tool bar. Message will appear for transaction acceptance). If transaction amount exceeds the Teller’s limit or any restraints are attached to the account, the override screen with appropriate message wi ll appear. Designated Officer authorizes/approves the transaction by override either locally or remotely. iii. Press the appropriate option of local or remote override. iv. When Supervisor authorizes the transaction Confirmation message will appear on teller’s screen. GL Entries : Branch will post HO -2242 voucher, delivered by NIFT rider SAME -DAY Clearing Charges deduction: Clearing Teller will debit applicable charges (as per SOBC) from customer account through EOC: Deposit  Value transaction  Withdrawal. Clearing Returns: i. By 12PM, NIFT Rider delivers Cheques Returns” to the branches. ii. Cheques returned in the clearing MUST be posted (reversed from customer account) by the branches on the same day without any fail. Select EOC – Deposits >> Transactions >> Value Transactions >> Withdrawal -RB32: Input account number and press F -8 iii. Customer & account information will be displayed. iv. Input the appropriate transaction type - “CQCR”. v. Input the cheque amount. vi. Press F10 or click ‘Save’ icon on the tool bar. vii. Communication with Customer viii. Note down the details of Returned Cheque in the Cheque Return register SB -15. ix. Inform the customer about the Returned Cheque via telephone SAME -DAY and note down the appropriate remarks on the reverse of Return Memo. x. On customer’ s visit to the branch, Teller delivers original instrument and Return Memo to the customer after taking the proper acknowledgment from the customer on SB -15. xi. If customer does not come to collect the Return Cheque from the branch within 05 working days, Teller intimate the customer by sending SF -20 along with copy of Returned Cheque and Return Memo. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 152 3.3 PROCEDURE FOR OUTWAR D SAME -DAY CLEARING – NIFT BRANCHES GL Entries: Branch will post HO -2293 (difference amount) voucher along with HO -2242, delivered by NIFT rider along with returned cheques 3.4 INWARD CLEARING Handling of Inward Clearing for majority of branches is centralized with ‘Centralized Operations Division – (COD)’ and being performed from its centralized Processing Units established in all major cities across the country . For non -centralized branches , processing of Inward Clearing is being performed by the respective branches at their end . 3.5 PROCEDURE FOR INWARD CLEARING – NIFT BRANCHES NIFT Representative delivers Inward Clearing instruments to the Central Processing Unit (CPU) Designated Authorized Officer - (DAO) in CPU receives Inward Clearing instruments from NIFT Representative. Segregate cheques and Payment Orders/ Demand Draft / CDRs etc branch wise. i. Check Clearing and Endorsement stamp on cheques/instruments. ii. Proper scrutiny of cheques/instruments should be done in the same way as it is discussed in Section 3: 3.1.2 -Scrutiny of Cheque/Instruments : iii. Forward cheques to the supervisor for Signature Verification. Authorizer/Supervisor in CPU Verifies customer’s signature(s) from the Deposits Module>> Enquiry >> Account Details (Screen # RB7A). Enter account number, press F8, account information appear on the screen, in order to verify the customer’s signature click on SG (signature) tab on the top right of the screen. i. Sign-off the instrument. ii. Forwards instruments to the Processor for posting. In case of Signature untagged on EOC/Unclear operating instructions/Signature Differ : inform the relevant branch through fax or e -mail and take necessary action as per the feedback received from the respective branch. CPU Processo r: i. Process the transaction on the system by using Deposits Module >> Transaction >> Value Trans actions>> Withdrawal ii. Enter Account number in the related field, Press F8. System retrieves account information on the screen. Prior to retrieving the information, system also displays restraints (if any) on the given account like stopped cheque, staff account, closed account etc. User is required to read these restraints carefully and inform the relevant branch. iii. Input/select the Tran Type CQCD - Cheque C learing Debit . iv. Press enter for Effective date and Currency. v. Input transaction amount and cheque number (If transaction amount exceeds the Processor’s limit, screen pop -ups “Authorization Required” message. Authorizer approves the transaction) i. Pop-up box appears on the screen for authorizer’s ID and password ii. Press enter/accept in order to execute the transaction iii. Note down the transact ion reference number on the back side of the instrument and sign off the same. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 153 3.5 PROCEDURE FOR INWARD CLEARING – NIFT BRANCHES Affix ‘posted ’ stamp on the instruments. In case of insufficient balance: If available balance of the account is less than cheque amount inform the respective branch on the prescribed format in order to confirm whether there is any credit in the pipeline. In case of any Restraint Attached with the Account: e.g. “Cheque Stopped” or “Cheque Series” are not updated with account; CPU contacts the relevant branch for confirmation. For Pay order/ Demand Draft Payment: i. Selects Deposit Module >> Cheque Instrument >> Transaction >> Draft/ Bank Cheque Buy (S creen # RB 18361) with transaction type - POCI - Payment Order Buy Clearing Internal or DDCI - Demand Draft Buy Clearing Internal ii. Input cheque details, verify details appearing on the screen with the instrument, if details and instrument are in order, press F 10 or click on Save icon in order to execute the transaction . Branch: i. Receive details of discrepant inward clearing instruments from CPU. ii. Operations Manager or Designated Authorized Officer checks the status of account and provide their feedback accordingly. (cut off time is half an hour) CPU Processor: i. Note down the details of return unpaid cheques. ii. Prepares the Returns Memos as per instr uctions received from Branch along with the NIFT covering schedule, branch wise, and forwards the same to the Authorizer for review and sign -off. iii. Delivers the same to NIFT Representative. iv. Submit a consolidated Daily Return report (branch wise) to all the branches via e -mail or fax. v. Checks daily transaction reports (RBA 11 & 87) for the branch processed by Processor 2 (Maker - Checker) vi. Prepares branch copy documents including covering sheet, return sheet, all reports for processed instruments (RBA 11, RBA 87) , NIFT advice (2242), scroll along with processed instruments and forwards the same to Authorized officer to review and sign -off the same. vii. Saves all the daily transaction reports and branch’s correspondence in soft date for audit record purpose. viii. Post 2242 advices/CDR/Remit Express/Speed cash in General Ledger Module >> Transactions >> Batch Maintenance >> Entry (Screen # GL21) CPU Authorizer: i. Reviews and sign -off the Return memo along with NIFT’s covering schedule. ii. Review branch copy documentation against the covering sheet and sign off the same iii. Forwards reports along with the instruments to Dispatch section in order to deliver the same to the branches. CPU Authorizer/ Supervisor i. Accepts open relevant batches after validating the Batch details with the s ource document from General Ledger Module >> Transactions >> Batch Maintenance >>Entry (Screen # GL 21). ii. Review & sign -off GLA 11 & GL 90 with the source documents. iii. Forwards reports along with the NIFT Advices to Dispatch section in order to deliver the s ame to the branches. Dispatch Section: i. Affix PAID stamp on all the cheques and instruments. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 154 3.5 PROCEDURE FOR INWARD CLEARING – NIFT BRANCHES ii. Hand -over the Paid instruments /Advices along with relevant Reports to the designated courier for onward delivery to the respective branches in a sealed envelope. 3.6 RESOLUTION OF DISCRE PANCIES While processing the Inward Clearing from a centralized location there are certain type of discrepancies where Centralized Processing Unit is unable to take a decision and has to refer the case to the concerned branch and obtain their authorization/approva l before honoring the cheque. Keeping in view the urgency & time constraints involved, communication with the concerned branches is done via e -mail (along with scanned copy of the instrument, where applicable) or through fax (where e -mail facility is not available) . Branches are required to attend and respond these cases on a priority basis. Cases referred to the branches fall in following 3 major categories: i. Account Related Discrepancies:  Cheque drawn against Dormant, Inactive or Deceased accounts.  Insufficient balance in the account  Cheque series not found/updated in the system  Account not found  Debit or Credit turnover limit exceeds  Stop Pay ment marked against the cheque.  Amount exceeding RF limit  Restrain t marked: officer not authorized for the transaction  CNIC not updated, new CNIC copy required . ii. Instrument Related Discrepancies:  Signature Differ  Operating instructions required  SF-6A27 related cases  Signature not tagged with the account  Cheques drawn on P hoto Account  Call back confirmation required: Transaction amount of PKR 1 Million and above iii. Other cases:  All Call Deposit Receipts - CDRs issued by branches  Speed Cash, Remit Express Drafts  Foreign DDs drawn on Global Transaction Banking Branch  Un-signed /singly signed bank drafts  Revalidation required: stale dated bank drafts B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 155 3.7 INWARD CLEARING – CHEQUE DEBIT REVERSA L Processor: i. Select Deposits Module > > Transaction >> Value Transaction >> Reversal – RB34 ii. Enter account number, press F8 for extracting the particular transaction to be reversed. iii. Select particular transaction which needs to be reversed and press F10. iv. Transaction authorization message appears on the screen, supervisor authorizes the transaction. v. Transaction type – Cheque Clearing Debit Reversa l “CCD# ” Authorizer / Supervisor : i. Once authorized by the authorizer / supervisor, the system automatically reverse the transaction Note : For Centralized Branches, Details of cheques returned in clearing are provided by the Centralized Processing Units to all concerned branches on a daily basis. Branches are required to recover ‘cheque return charges’ from the account holder as per the bank’s schedule of charges. Reports & Record keeping of Paid Instruments : After processing of Inward Clearing Che ques, Centralized Processing Units forwards all the posted instruments along with the NIFT daily advices (2242), NIFT scroll, covering sheet, return sheet and signed system generated Reports (RBA -11 & GL -11) to the respective branches for their record and safekeeping 3.8 CHEQUE RETURN MEMO i. Cheque Return Memo (SF -16) is used for informing the beneficiary of the cheque, if it is returned unpaid. The Memo (SF -16) has the following distinctive features: ii. It has a field available for mentioning Account and cheque N umber iii. It has space available to mention the amount of cheque. iv. It has a field available to mention the ‘Name of the collecting Bank ’ to whom branches will return the cheque . v. It has space to mention the “return reason” (should be as per approved return reason list by SBP ) As per the SBP directives banks are not allowed to give ambiguous reasons like “Refer to Drawer” when a cheque is returned unpaid by them for insufficient funds or for any other reason. As a result, the beneficiary of the cheque is not in a position to take action against the issuer of the cheque under the provisions of relevant laws”. Hence, branche s must give definite and clear reasons while returning the cheques to the beneficiary (Whether on Cash Counter or Clearing/Collection). B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 156 Chapter 4 INWARD / OUT WAR D BILLS FOR COLLECTION 4.1 INWARD & OUTWARD LOCAL BILLS FOR COLLECTION S The outstation cheques received for collection are drawn on other banks. While accepting the outstation cheques for collection, it should be ensured that customer fills -out one deposit slip for one city. In case single account holder is depositing more tha n one instrument of different cities or banks, in his/her account than different deposit slip must be used for the same. The following procedure is applicable only for those branches where NIFT is not providing Inter City clearing facility . 4.1.1 Procedure for Local Bills for Collection Customer presents duly completed deposit slip along with the outstation cheques to the Clearing teller. Clearing Teller: i. Receives deposit slip and cheque. ii. Checks deposit slip.  Account number and Title of account  Signature of the depositor along with deposits contact no. (mandatory)  Amount in words and figures is identical. iii. Scrutinizes cheque:  Endorsement and special crossing are in order (if there are any).  No un -authorized alteration.  The cheque is neither post dated nor unda ted  The cheque is not stale (Value date must not be six months earlier)  Amount in words and figures is identical. iv. Affix bank’s Cheque Collection Stamp and sign -off deposit slip and return customer copy (B) to the Depositor. If transaction amount exceeds the teller financial limit, Teller services supervisor approves the transaction. Note: It is the prime responsibility of the branch where outstation cheque is being deposited to ensure that the beneficiary’s account status is ‘ACTIVE’. In case of Dormant / Inactive / Unclaimed , customer should be requested to activate the account before acce pting the cheque for collection. (To activate the account please refer to Section 2: 5.4 Activation & Operation in Dorm ant, Inoperative & Unclaimed Deposit Accounts Customer receives “B Copy” of slip and leaves the branch. Designated Authorized Officer (DAO): i. Sort out all the outstation cheques, arrange them city and bank/branch wise. ii. Note down the Cheque Collection (CC) number, Account title, number, drawee’s bank branch n ame, cheque amount and date of cheque in the Cheque Collection Register (SB -19). iii. Note down the CC number (Serial number obtained from SB -19) at the specified place in the affixed CC stamp on the cheque with prefix of the number of the year of Bank’s establ ishment. iv. Detach instrument from the Deposit slip. v. Prepare Collection Schedule (SF37 -Revised) in duplicate and attach the original copy with the instrument and retain the duplicate with the deposit slip in a Cheque Collection file/ folder. vi. The amount of ea ch collection cheque of the day will be jotted down from the cheque Collection Register (SB -19) and prepare liabilities voucher by debiting “Bills Receivable Bills for Collection - BRBC” and crediting “Bills for Collection Bills Receivable - BCBR” for the to tal amount of outstation cheques sent for collection. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 157 4.1.1 Procedure for Local Bills for Collection vii. Duly endorse and sign -off on the reverse of the instruments. (“Payee account will be credited on realization”) viii. Dispatch instruments along with SF37 - Revised to the local main branch of MCB of that spec ific city via courier service and in places where courier service is not available, use Registered Post. ix. Cheques drawn on other banks at a place/city/town where MCB does not have any branch, the collection to be made preferably through the local main branch of that bank or it may be collected directly from the concerned branch. x. It should be ensured that proc eeds are received within prescribed time i.e. 48 hours from the branches covered by courier service from the date of deposit of cheques and within 72 hours from places not covered by courier facility. xi. Post the above BRBC and BCBR vouchers in General Ledger . Collecting MCB Branch: i. Collecting main branch on receipt of Inward Bill Collection (Out station Cheque) from MCB Branch will: ii. Enter the Inward Bill Collection in Inward Cheque Collection Register (SB -70). iii. Lodge Collection Cheques received in normal cle aring. iv. After realization of funds, the collecting branch will credit the cleared funds directly in to beneficiary’s account through SYMBOLS. v. Select Deposits Module >> Transactions > Value Transactions >Deposits (RB -31)  Enter Account Number or select from List of Values (LOV) & press F8  Enter Transaction Type - (THCR - Transfer Credit (HO Advice)  Select Currency from List of Values (LOV)  Input Amount given on the Deposit Slip.  Press F10 or Click Save Icon. If transaction amount exceeds the Teller’s limit or any Restraints are attached to the account, screen pop -ups “Authorization Required” message. Teller services supervisor authorizes/approves the transaction by using BT> Override > Remote Override (Screen# BT002020 ) after verifying credentials on original instrument. i. BOM or BM will intimate the concerned branch through e -mail quoting the related C.C Reference number that the funds against the out station cheque sent to them for collection have been cleared and the proceeds are credited to beneficiary’s account. ii. Bank charges and postage to be recovered by the beneficiary branch. (This will assist the branch to settle the entry in their “Out station Check Register” (SB90), reverse the contingent liability and deduct related charges). Beneficiary Branch: i. Branch receives e -mail confirmation from the collecting branch that funds have been realized and credited to beneficiary’s account or; ii. In case collection was processed directly through Drawee Bank then the branch receives the proceeds through Bank Draft. (Drawee bank deducts Bank Draft issuance charges before making the Draft). iii. Lodge the Bank Draft in local clearing for realization of pr oceeds. After clearance of funds, credit proceeds into customer’s account through SYMBOLS. iv. Designated Authorized Officer (DAO) credit customer’s account by using the Deposit Slip. v. Select Deposits Module >> Transactions > Value Transactions >Deposits (RB -31)  Enter Account Number or select from List of Values (LOV) & press F8  Enter Transaction Type - (THCR - Transfer Credit (HO Advice)  Select Currency from List of Values (LOV)  Input Amount given on the Deposit Slip. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 158 4.1.1 Procedure for Local Bills for Collection  Press F10 or Click Save Icon. If transaction amount exceeds the Teller’s limit or any Restraints are attached to the account, screen pop -ups “Authorization Required” message. Teller services supervisor authorizes/approves the transaction by using BT> Override > Remote Override (Screen# BT002020) . i. Takes out the copy of Cheque Collection Schedule (SF -37 Revised) and the Deposit Slip from the Cheque Collection folder and note down the payment or funds realization date and commission/postages charges in the Cheque Collection Register SB -19. Weekly Balanci ng: i. Total of the entire outstanding CC Register (SB -19) should match with the GL amount. In case cheques sent for collection are received unpaid: i. Designated Authorized Officer (DAO) note down the cheque return date in the Cheque Collection Register (SB-19) and also mentions cheque returned unpaid. ii. DAO takes out the copy of Cheque Collection Schedule (SF -37) and the Deposit Slip from the Cheque Collection folder and file in Cheque Collection Returned unpaid file. iii. Prepare Debit & Credit Voucher SF -9 & SF-10 for the recovery of Postages Charges from customer’s account. iv. Also prepare consolidated liabilities vouchers (SF -9 & 10) against the cheques realized/returned unpaid on the day to be reversed by debiting “Bills for Collection Bills Receivable” and crediting “Bills Receivable Bills for Collection”. v. Note down the cheque returned details in Cheque Returned Register (SB -15) and deliver the same along with the Bank’s returned memo to the account holder after obtaining acknowledgement. vi. If customer does no t come to collect the Return Cheque from the branch within 05 working days, Teller intimate the customer by sending SF -20 along with copy of Returned Cheque and Return Memo. Authorized Officer or Branch Operations Manager: i. Reviews the Daily Transaction Re port against the source documents. ii. Sign-off the report and binding them with the daily vouchers. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 159 4.2 OUTWARD FOREIGN BILLS FOR COLLECTION Bank also provides the facility of collection of foreign clean bills denominated in foreign currencies and drawn outside Pakistan. Clean Bills such as customer’s/ Banker’s Cheques/ Money Orders/ Foreign Travelers Cheques etc are handled and lodged under FBC. 4.2.1 Procedure for Outward Foreign Bills for Collection Customer: Presents duly filled Deposit slip along with th e Foreign Currency Instrument in order to deposit in his/her Local or Foreign Currency account. Clearing Teller: i. Receives deposit slip and cheque / Instrument. ii. Checks deposit slip  Account number and Title of account  Signature of the depositor along with deposits contact no. (mandatory)  Amount in words and figures is identical. iii. Scrutinizes cheque:  Endorsement and crossing are in order (if there are any).  No un -authorized alteration.  The cheque is neither post dated nor undated.  The cheque is not stale (Va lue date of the cheque must not be six months earlier)  Amount in words and figures is identical. In Foreign Trade Branch: i. Affix bank’s Cheque Collection Stamp on cheque and deposit slip. ii. Sign-off deposit slip and returns customer copy (B) to the Depositor and retains original deposit slip with the instrument. iii. If transaction amount exceeds the teller financial limit, Teller services supervisor approves the transaction. In Local Branches: i. Affix bank’s Cheque Collection Stamp only on Deposit slip. ii. Sign-off de posit slip, retains original and returns customer copy (B) to the Depositor. iii. Note down cheque details in the Foreign Bills for Collection Register (SB -70). iv. No need to affix Collection Stamp on the instrument. v. Forwards instrument to the Designated Area’s Fo reign Trade Branch along with the covering schedule for onward collection of Foreign Bills from the Drawee Bank. vi. Retain copy of covering schedule with the deposit slip & photocopy of instrument in a Foreign Cheque Collection file/ folder. Customer receive s “B Copy” of slip and leaves the branch. Clearing Teller or Designated Authorized Officer in Foreign Trade Branch performs the following functions: i. Sort out all the Foreign Currency Cheques for collection, arrange them city and branch/bank wise. ii. Note down the Cheque Collection (CC) number, Account title, number, drawee’s bank branch name, cheque amount and date of cheque in the Foreign Bills for Collection Register (SB -70). iii. Note down the CC number (Serial number obtained from SB -19) at the specifi ed place in the affixed CC stamp on the cheque with prefix of the number of the year of Bank’s establishment (e.g. 57/1… 57 is the total number of years of Bank’s establishment). iv. Detach instrument from the Deposit slip. v. Prepare Collection Schedule (SF -37A) in triplicate, addressing to either Bank’s own local branch or B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 160 4.2.1 Procedure for Outward Foreign Bills for Collection foreign correspondent along with the proper reimbursement instructions. (Kindly credit our Nostro Account). vi. Attach the original SF -37A with the instrument and retain duplicate with the deposi t slip & photocopy of instrument in a Foreign Cheque Collection file/ folder. vii. The amount of each collection cheque of the day will be jotted down from the Foreign Bills For Collection Register (SB -70) and prepare liabilities voucher by debiting “Bills Rece ivable Bills for Collection - BRBC Foreign” and crediting “Bills for Collection Bills Receivable - BCBR Foreign” for the total amount of outstation cheques sent for collection. viii. Post the above BRBC and BCBR vouchers in General Ledger. ix. Duly endorse and sign -off on the reverse of the instruments. (“Payees account will be credited on realization”) x. Inform Representative of American Express about FBC. xi. Rider of Foreign Correspondent Bank comes to the branch and collects the cheque. Dr: Bill Receivable for Collecti on- BRBC Foreign CR: Bills for collection Bills Receivable - BCBR Foreign Foreign Correspondent Bank: Receives cheque and on clearance of funds, Credit Bank’s Nostro Account. MCB SWIFT Operations: Forwards the SWIFT Messages/ Intimation for receipt of credit in Nostro Account, to the concerned branches after confirming the branch name and code via SWIFT system/Fax or Courier. Branch - Remittance Incharge: Receives SWIFT Message (s)/ Intimation for receipt of credit in Nostro Account, from SWIFT Operatio ns. After proper verification of SWIFT Message. Prepares Annexu re XXI and after completing all the required formalities, forwards the same to Treasury Back Office before the cut -off time for processing at their end. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 161 4.3 FBC - LOCAL BANK’S FCY CHE QUE DEPOSITED IN MCB FCY ACCOUNT In case of FCY Account Holder deposits FCY Account Cheque of any other Lo cal Bank . NIFT provides USD Clearing facility to all the Local and Foreign Banks within Pakistan. Currently this facility is ava ilable only on Monday & Thursday. State of the art data centers for clearing services have been established at Karachi, Lahore, Islamabad, Peshawar, Rawalpindi, Hyderabad, Multan, Faisalabad, Quetta, D.I.Khan, Sialkot, Gujranwala, Sukkur, Bahawalpur, Muzaf farabad, Jhelum, Abottabad, Mirpur, Sahiwal and Sargodha. 4.3.1 Procedure for Outward Foreign Bills for Collection ( NIFT USD Clearing Facility) Beneficiary’s Branch: i. Branch receives FCY Cheque from the customer. After proper scrutiny of cheque & deposit slip affix Clearing Stamp on the Deposit slip and returns customer copy to the customer. ii. Forwards the instrument to the Main Branch Karachi for collection of funds. Main Branch: i. Main Branch lodges the cheque in NIFT - USD Clearing ii. NIFT provides USD local Clea ring facility to all the Local and Foreign Banks within Pakistan. Currently this facility is available only on Monday & Thursday. iii. On clearance of funds, NIFT provides Advic e to the Main Branch (In USD ). iv. Send SF -179 to the respective branch and report the same to the Treasury Back Office through Annexure XXI v. In-case cheques are returned by NIFT, the same are returned back to beneficiary branches same day and reported to Treasury Back Office through Annexure XX Beneficiary’s Branch: Upon receipt of SF -179, Provide Credit to the respective customer. 4.3.2 Procedure for Inward Foreign Bills for Collection (NI FT USD Clearing Facility) Main Branch: i. Receives Inward USD Clearing instruments from NIFT on Mondays & Thursdays ii. Dispatches the instruments to the concerned MCB branches through TCS Courier service the same day Drawee Branch: i. Branch receives FCY Cheque from the Main Branch. ii. Scrutinize of cheque in every aspect for completeness and accuracy. iii. Provides the fate of the received instruments to the Main Branch via Phone/fax/e -mail iv. If the cheque /instrument is c leared, prepares credit advice [SF -179] which is in equivalent PKR ( USD converted into PKR , Translation Rate from the Rate Sheet is applied ) v. If the cheque is not cleared, the original cheque/instruments are returned along with the cheque return memo (stating the reason for return). Main Branch: i. On clearance of funds, receives Credit Advic e [SF -179] from the Drawee Branch , reports the same t o Treasury Back Office through Annexure XX ii. Returned/ un -cleared cheques once received from branches are delivered to NIFT on very next USD Local clearing day for onward delivery to the collecting bank and reported to Treasury th rough Annexure XXI B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 162 4.4 FBC - MCB FCY CHEQUE (OF O THER BRANCH) DEPOSIT ED IN MCB PKR ACCOUN T In case MCB PKR Account Holder deposits MCB Foreign Currency Cheque (of other Branch) in the Account: 4.4.1 Procedure - MCB FCY Cheque (Of other branch) Deposited in MCB PKR Account Beneficiary’s Branch: i. After scrutinizing the instrument affix Cheque Collection Stamp on the instrument and deposit slip. ii. Note down cheque details in the Foreign Cheque Collection Register (SB -70), mention CC nu mber on the instrument. Drawer’s Branch: i. Scrutinize the cheque & Note down Cheque Details in Inward Foreign Cheque Collection Register (SB - 70). ii. Debit customer’s Foreign Currency account. iii. Prepare Inter Branch Credit Advice (SF -179) in PAK Rupees by applying FCY Buying Rate from the Daily Exchange Rate Sheet of the Transaction Date. Beneficiary’s Branch: i. Receives Inter Branch Credit Advice, verify Authorized Officer’s signature & Test. ii. Credit customer’s account and Debit Head Office Account. 4.5 OUT WARD FBC - LOCAL BANK’S FCY CHE QUE DEPOSITED IN MCB PKR ACCOUNT In case MCB PKR Account Holder deposits Other Local Bank’s FCY cheque: 4.5.1 Procedure - MCB FCY Cheque (Of other branch) Deposited in MCB PKR Account Beneficiary’s Branch: i. After scrutinizing the instrument affix Cheque Collection Stamp on the instrument and deposit slip. ii. Note down cheque details in the Foreign Cheque Collection Register (SB -70), mention CC number on the instrument. i. Prepare covering schedule and attach the s ame with the instrument and forwards the same to the Drawee Bank. Moreover, clearly mention beneficiary’s name and account number in the covering schedule. ii. Prepare & post liability vouchers by debiting BRBC & crediting BCBR by applying day’s Exchange Rate. iii. On receipt of Payment Order from the Drawee Bank, prepare Transfer Credit Voucher and lodge the instrument in Normal Clearing in order to transfer funds in the beneficiary’ account. iv. Drawee Bank recovers its charges from the proceeds of the cheque. v. Note d own the payment date in the Foreign Bills for Collection Register. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 163 4.6 INWARD FOREIGN BILLS FOR COLLECTION When MCB customer’s cheque is presented in a foreign bank, foreign bank forwards it to the relevant MCB branch in Pakistan with instruction letter. 4.6.1 Procedure for Inward Foreign Bills for Collection The Forex Officer of the Drawee Branch receives Foreign Currency cheque from foreign bank with letter. Forex Officer verifies genuineness and Scrutinizes cheque:  Endorsement and crossing are in order (if there are any).  No un -authorized alteration.  The cheque is neither post dated nor undated.  The cheque is not stale  Check sign or over -writing Forex Officer enters account # in Branch Teller (BT) module or in EOC. Check transaction code (system genera ted), enter amount and cheque #, Re -enter cheque #. Note: If the cheque is not accepted in the system, Forex Officer mark the reasons on cheque return memo, sign and enter it in cheque return register. Afterwards, Forex officer return the cheque with copy of instruction letter and memo to Foreign Bank through courier. If the transaction amount is above Forex officer limit, the cheque is handed to the Forex Manager/ BOM for authorization. Forex Manager/BOM check the amount, balance and verifies the customer’s signature and authorize transaction, sign on the cheque and hand back the cheque to the Forex Officer for further processing Forex Officer prepare SWIFT message MT -202. SWIFT Message will narrate the bank name to which funds are to be transferred on specific date. Forex Manager/ BOM authorize the SWIFT message on SWIFT server and convert the message in to note pad file. Email it to the SWIFT Ops through attachment. Whereby, SWIFT Ops forward it to th e correspondent Foreign Bank. Forex Officer prepares credit advices (SF -139) in quadruplicate and on basis of these prepares Annexure XX which is approved by Forex Manager and Operations Manager. Annexure XX is then forwarded to two separate Test Key officers for application of test (Part A and B) and later delivered to Forex Manager for transmitting through fax to Treasury Back office. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 164 Chapter 5 INTERNAL FUNDS TRANSFER 5.1 OVERVIEW – APPLICATION FOR INTE RNAL FUND TRANSFER Fund Transfer Application (SF -100R) is used to transfer funds from one account to another account OR to another branch of MCB. Branches should ensure that the information on FTA is complete in every aspect; is signed by the account holder(s)/ authorized signatory; signatures are religiously verified and that the funds are available in the account before accepting the FTA for processing. For strengthening control, Valid Cross Cheques of equivalent amount will be take n from the customer along with FTA. 5.2 PROCEDURE FOR INTERN AL FUNDS TRANSFER Customer: Presents duly completed Funds Transfer Application (FTA) along with a crossed cheque to the teller in order to credit Beneficiary’s account. Teller: i. Receives Funds Transfe r Application from the customer along with crossed cheque ii. Verify the details & customer’s signature given on FTA and Crossed Cheque (both) with the system as per the assigned limit of the teller. If transaction amount exceeds the teller limit, Telle r services supervisor authorizes the transaction. iii. The Status of the Crossed cheque with the FTA should be valid. It will be checked in the system whether it is valid I -e not stopped/serial # activated in the system/ not cancelled etc . Following are the pr ocess steps of the Internal Funds Transfer : i. Login to SYMBOLS Branch Teller (BT) Module ii. Insert User ID and Password iii. Selects Transactions> Financial Transactions > Single Transactions > Current /Savings > Transfer (BT Screen # 3215) iv. System displays the Transfer Screen - Withdrawal From. v. Enter complete account number in the Account Number field. (If complete account number is not given, press F9 to obtain the same from List of Values - LOV) vi. Press Enter to continue. vii. Drawer's account balance will be displayed on the screen and will also show the Pre -defined Transaction Type –TFRD - Transfer Debit. Press Enter, cursor will shift to "Deposits To" Section Account number field of the beneficiary. (LOV available) viii. Insert Account number, all customers’ information wil l be displayed on the screen along with the Pre - defined Transaction Type – TFRC - Transfer Credit. ix. Press Enter, cursor will move to the Amount Field, insert amount. (If transaction amount will exceed the Teller's Limit, screen will pop -up "Requires Authoriz ation" message. Teller services supervisor will approve the transactions by using BT> Override> Remote Override - Screen # BT 002020) x. After inserting the amount, Teller will be able to verify the Customer's signature by clicking on the "SG" tab. Only displ ays Drawer's signature. (If signature matches with the signature on the FTA / Crossed Cheque , executes the transaction) xi. "Debit Account details" pop -up message box will appear on the screen, Teller inserts voucher number in the voucher # field. Click Ok. xii. "Credit Account Details" pop -up message will appear on the screen, Teller inserts voucher number and click Ok. (In case of Insufficient Balance, system will give message "RF Not Allowed") xiii. Message box will appear "Please Save the Transaction" Click Ok. xiv. For Enq uiry of the said Transactions, uses Electronic Journal Option - screen # BT 56 Online. Electronic B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 165 5.2 PROCEDURE FOR INTERN AL FUNDS TRANSFER Journal also gives an option of Transaction Reversal by using Alt 9. Treatment of Cross Cheque obtained along with FTA:  The cross cheque obtained along with the FTA will be marked as used “U” in the s ystem by using following path: EOC – Deposits > Cheque Control > Cheque Maintenance > Cheque Status  The FTA pre -printed serial # will be written on the face of the cross cheque obtained.  The cheque will be defaced/ cancelled / stamped (Transfer) Teller services supervisor After verifying customer details from Original FTA/ Cheque, authorizes the same on the system (if required) by using BT> Override > Remote Override Screen # BT002020. Teller: i. Affix Transfer Stamp and sign -off FTA & Crossed Cheque ii. Forwards the instruments to the Teller services supervisor for validation & record keeping. iii. Delivers Customer Copy to the applicant. Customer: Collects “Customer Copy” of FTA and leaves the branch. Teller services supervisor: Reviews and validates RBA -11 against the source document. 5.2.1 Deviation on “Obtaining Cross Cheque ” with FTA: For any particular transaction, requirement of obtaining cross cheques along with FTA for processing of Fund Transfers can be waived by ROM or RH. BOM/ BM are authorized to take s uch deviation approval after specifying valid reason(s) via e -mail or fax. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 166 5.3 PROCEDURE FOR CHEQUE DEPOSIT (OWN BANK) Customer: Presents duly completed deposit slip along with the cheque to the teller. Teller: i. Verifies the details given on the deposit slip with the Cheque. ii. Before processing the transaction, verify Drawer’s signature and check sufficient funds are available in the account. iii. Process transfer cheques (Drawn on MCB Branches) on the BT> Trans actions > Financial Transactions >Single Transactions > Current/Savings Account> Cheque Deposit. iv. Enter or selects Transaction Type CHQD - Cheque Deposit Internal from List of Values (LOV) v. Inputs withdrawal branch code and client account number and system di splay all the relevant information on the screen. vi. As a result a dialogue box pops -up requesting for Debit details (cheque number) and Credit details (voucher number) vii. If account currency is different from transaction currency, cross rate can be modified if there is a special rate. viii. System shows credit amount and click the save button to process the transaction. (If transaction amount exceeds the Teller’s limit a popup invokes automatically to get authorization from Teller services supervisor/Authorized office r). ix. System debit drawer’s account with Transaction Type CHQW - Cheque Withdrawal Internal. Teller Services Supervisor : After verifying credentials on original instrument, Authorizes the transaction on the system (if required) by using BT> Override > Remote Override Screen # BT002020. Teller: i. Affix Transfer Stamp and initials on the reverse of Cheque. ii. Teller and Teller services supervisor jointly sign -off the deposit slip and deliver the customer copy of deposit slip to the customer. iii. Forwards the instrumen ts to the Teller services supervisor for scrutiny with the RBA -11. Customer: Collects B copy of deposit slip and leaves the branch. Teller services supervisor: Reviews and validates RBA -11 against the source document. 5.4 PROCEDURE FOR TRANSA CTION REVERSALS Teller: i. Select the BT> Enquiries>Electronic Journal - BT- 56 Online. ii. Press Alt+7, transactions details will appear on the screen. iii. Press Alt+ 8 for extracting the particulars of the transaction. The Journal displays the relevant transaction(s).Selects particular transaction. iv. Select by highlighting the transaction to be reversed. v. Press <Alt -9> for execution of the reversal (transaction type "TFD#" Transfer Debit - Reversal, TFC# Transfer Credit - Reversal & "CQD#" Cheque Deposit - Reversal) vi. A pop -up appears to confirm the reversal of the transaction. “Do you want to reverse the transaction” vii. Upon clicking "Yes" screen pop -up message for the supervisor's override. Teller services supervisor: Once authorized by the supervisor/Teller services supervisor, the system shall then automatically reverse the transaction. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 167 Chapter 6 UTILITY BILLS MANAGE MENT 6.1 COLLECTION ARRANGEME NT The Utility Bills collection arrangement exists with PTCL and KESC/ WAPDA/SNGPL/SSGC Branches providing utility services must make the following arrangements for the convenience of consumers, in order to carry out the directives of State Bank of Pakistan. i. All the branches (NO EXCEPTION) shall accept Utility Bills as per the following time schedule: Monday to Thursday & Saturday: From 9 AM to 5 PM Friday: From 9 AM to 5 PM (with 2 hours break from 1 PM to 3 PM for Lunch & Prayers) ii. To display at a prominent place, the following notice both in English and Urdu. “Electric, Gas & Telephone Bills are accepted here”. iii. A Signboard in Urdu & English is to be displayed outside the branch premises indicating the timing of Collection of Utility Bills (Computer Printout or Handwritten). iv. Branch Managers ensures separate / extra counters in case of:  Senior Citizens (Old persons) / Women depositing their bills.  As and when the queue exceeds “15” customers. v. A Box must be placed at prominent place for payment of utility bills through cheques. vi. Provide space inside the premises for queues of depositors of bills. If not possible, shades must be arranged for consumers to provide shelter from sun / heat. vii. Arrange drinking water nearby the counter. viii. Bath room facility may be provided, if possible. ix. Adequate staff be posted at utility counters to avoid queues and SBP pe nalties. x. Machines / computers must also remain in order. In case of power failure, bills must be collected manually. xi. Prompt delivery of bills, stubs and scrolls / statements to designated branches be made, as delay in delivery or misreporting may result i n arrears or disconnection of service to the consumers by the utility company. xii. Manager and staff of utility department must remain aware of any extension in due date for payment announced by any of the utility companies for any reason, whatsoever. xiii. Addition al staff must be posted on utility counters on the specific “Due dates” of the bills. xiv. All the utility bills bear the due date and amount for payment however, provision for payment of bill after due date is also given, but with a surcharge. Utility Bills ha ve two portions:  First Portion of bill is meant for consumer which must be returned to the Customer with receipt duly acknowledged with the Bank / Branch Stamp.  Second portion meant for the Utility Company is to be retained by the Branch. xv. In case of amendm ent in amount on account of the arrears, the corrected amount will be payable. xvi. Bills with mutilated / invisible figures / particulars must be referred back to the utility company. xvii. Bills showing credit balance will not be collected. Normally the bills havi ng credit balance also bear the clause “Not for Payment” B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 168 6.2 TELLER’S LIMIT FOR C OLLECTION OF UTILITY BILLS Cashiers have been authorized to receive Cash against Utility Bills singly with a limit of PKR 5,000/ - (Maximum). For bills above PKR 5,000/ -, dual control as mentioned below will be followed. 6.3 PTCL – UTILITY BILLS COLLEC TION PROCESS MCB Transaction Banking Division (TBD) formally known as (CMD) governs the PTCL Utility bills collection arrangement. With the new arrangement in place, MCB has been given status of “Processing Bank” and hence previous arrangements (prior to April, 2010) are discontinued and no scrolls/ stub are given to NIFT/ Citiba nk or UBL. To facilitate the new process, a new system “Utility Bill Collection System” (UBCS) has been deployed at branches which can be accessed at http://10.0.0.241:7778/forms/frmservlet? config=UBCS . Branches will collect and post PTCL bills in the new system as per the process described below: 6.3.1 Receiving PTCL Utility Bill at Branch Counter i. PTCL utility bills are received at Utility Bill counter of almost all MCB branches during banking h ours. ii. Bill payments can be accepted against cash or cheques. Payment via Cheque requires extra level of caution to ensure that the funds are realized prior to the due date positively. iii. The funds received through bill collections are retained in a separate i nternal PTCL Utility Bill Collection Account. This is a non checking account that is opened in every bill collecting branch. iv. These internal collection accounts of all designated branches are tagged with PTCL's main collection account # 0442658401000426 (ma intained at GTB Branch Karachi) for auto sweeping of funds at day end on a daily basis. v. Every morning, all PTCL bill collecting branches are required to check that the funds collected by them in their internal accounts previous day have been swept to GTB B ranch via the sweeping option or not. In case they have not been swept they are supposed to inform it to TBD Karachi instantly so that the problem can be rectified as early as possible. 6.3.2 Posting of PTCL Bill Into System i. Utility Bills Collection System is a system application developed internally by MCB IT & is supposed to be used for posting of the details of the bills for MIS purposes. UBCS does not pass any financials & only captures the paid bills data. ii. PTCL provides its billing data files to MCB IT fro m where they upload these files into the main data base server. At the time of bill posting by any branch in UBCS, the already uploaded data is called & marked as "Paid". iii. TBD has managed to prepare several MIS reports in UBCS. These reports are provided to PTCL on a daily basis which show the details of all bills collected on a particular day by each MCB branch. iv. Posting of billing data in UBCS is a "must" activity required to be done by the bill collecting branch. If it is not done, the billing data will no t be marked as "paid" at PTCL's end & the consumer will get the arrear hit in next bill. 6.3.3 Disposal of PTCL Bill Stubs Branches are supposed to retain the bills stubs only for 1 month. After that all stubs for the whole previous month should be sent to the local PTCL SRO Office in a single consignment. Details of concerned SRO offices have already been provided to all MCB bill collecting branches. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 169 6.3.4 Branch Commission for Providing PTCL Utility Bill Collection Service i. Branches are entitled to receive a b ill collection commission @ PKR 8.00 per bill collected. But these commissions are not supposed to be deducted by branches at their end. ii. With the help of the monthly commission reports of UBCS, TBD calculates bills commission of all branches. TBD recovers the commission from PTCL & credit the same to all branches via GL upload centrally from GTB Branch. This auto upload gives credit of the commission amount in relevant GL Head of the branches. iii. This activity of giving credit to branches is usually done by T BD in every first week of the month. iv. Branches are not allowed at all for any deductions of this commission at their end. 6.3.5 Processing Error/ Transaction Reversal In case of any processing error, Branch will immediately contact TB D at any of the given contacts: Asim Malik asim.malik@mcb.com.pk 042-337525080 Tariq Mehmood tariqmehmood@mcb.com.pk 042-37525076 TBD Ops Team cash.managementopr@mcb.com.pk 021-32270615 Raza Muhammad raza.muhammad@mcb.com.pk 042-36041171 6.4 KESC – UTILITY BILLS COLLEC TION PROCESS - SPECIFIC/INDUSTRIAL CONSUMERS ONLY 6.4.1 Receiving KESC Utility Bill at Branch Counter i. KESC's Specific/Industrial Consumer utility bills are received at Utility Bill counter of few branches of Karachi City during banking hours. These bills are printed on a yellow color paper. This yellow color paper is used to disting uish the Specific/Industrial consumer bills from the normal consumer bills. ii. Bill payments can be accepted against cash or cheques. Payment via Cheque requires extra level of caution to ensure that the funds are realized prior to the due date positively. iii. The funds received through bill collections are directly credited in KESC's main collection account of Specific/Industrial consumers being maintained at GTB Branch, Karachi. Branches are not supposed to retain funds collected under this arrangement in any of their accounts. 6.4.2 Disposal of KESC Bill Stubs i. TBD's dedicated rider collects the bills stubs from the bill collecting branches on a daily basis & delivers the same to TBD Karachi Office (9th Floor, MCB Tower). MIS report is prepared from these stubs by TBD staff for KESC. ii. The next morning, these stubs along with the print outs of MIS reports are delivered to Citibank Karachi. Citibank Karachi is the main processing bank of KESC. 6.4.3 Bran ch Commission for Providing KESC Utility Bill Collection Service Branches send monthly charges debit advice to Shaheen Branch, Karachi (0054) and Shaheen branch responds to them. Branches are not supposed to debit the account being maintained at Shaheen Branch for commission deduction via online mode. Branches are not a llowed at all for any deductions of this commission at their end. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 170 6.5 UTILITY BILLS STANDA RD COLLECTION PROCES S – KESC/ WAPDA/ SNGPL/ SSGC 6.5.1 Receiving & Posting of Utility Bill at Branch Counter i. Branches are required to collect Utility Bills at designated c ounter. ii. Amount received should be written manually by Collecting Cashier/ Teller under his signature in red ink. iii. There are two stamps one for amounts Upto PKR 5,000/ - in possession of the UB Teller and the other for amounts over PKR 5,000/ - in possession of the Supervisor/ BOM. The Stamp shows, Collecting Bank / Branch, Date of Receipt and the words “Utility Bill” and “Cash Received”. iv. The bill will then be entered in Scroll. v. In case the bill is above Teller threshold, it will be sent to Authorized Officer for counter signing and affixing the Rubber Stamp. vi. The bill (Consumer Portion) will then be delivered to the Consumer, retaining Stub / Branch copy. Necessary equipment (hardware and software) has been provided to most of the collecting branches / centers / booths in big cities for obtaining scrolls and activity reports etc. Proper security arrangements have been taken care of in this system. Computerized reports issued contain the following de tails: -  Collecting branch name  Branch code  Date of receipt  Amount received  Consumer number allotted by utility company Branches, which are not provided with Computer or Cash Register, are also required to collect utility bills and issue necessary receipts. Amount received to be written manually by collecting cashier under his signature. The bill is then entered in scroll and countersigned by Supervisor/ BOM (above PKR 5,000) before delivery to customer 6.5.2 Reversal of Entries and Corrections Generally, reversal of an entry pertaining to an individual utility bill is not permissible. However, in some exceptional situations, the refund of amount or reversal of entry becomes inevitable and the receiving branch has no option except to reverse the entry. In s uch case, the matter will be referred to the officer -in-charge of utility bills and only on his authentication the reversal entry will be passed. The said officer will invariably authenticate any reversal, amendment and cutting on the sheet or scroll. In b ranches having computer, reversal or amendment will only be overridden or authorized by the officer -in-charge or supervising teller / officer through his/her password. The cashier/ Teller and officer/ supervising teller both are jointly responsible for the collection of utility bills activity. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 171 6.5.3 Daily Activity Reports/ Scrolls Statements At the end of the day’s work the branches obtain reports from the computer. These will mainly comprise of the following: Daily Scroll This shows all entries of bills collected. Separate scrolls must be obtained for each category of bill. These scrolls, in addition to date and collecting Bank’s name, also provide the particulars of bills collected, as under : -  Consumer No.  Amount received in cash or through cheque, with its number.  Name of Bank and branch  Remarks Daily Activity Report This report is similar in nature and provides the same information as provided under “Daily Scroll”, except that it also reports reversal / amended entries duly marked ‘A’, in the remarks column. This report can only be obtained through the “Password” of the Supervisor. Branches providing these services manually, also prepare these statements. Following are the prescribed forms which will be used for individual statements: -  Electricity = MF-39 & 39 -A (For KESC). MF-16 & 16A (For WAPDA).  Gas = MF-41.  Telephone = MF-40B Form T&T20. Filing of Scrolls Scrolls of a particular date must be attached with the vouchers of the UB Collection date 6.5.4 Cash balancing of Utility Bills Collected Funds Branches/utility bills collection centers/booths physically count the entire for cash collected and balance/tally the same from the totals appearing in scroll/statements. Number of bills must be tallied from these statements. 6.5.5 Transfer of Collected Funds At Collecting Branches The amount collected at the Branches are transferred to the Utility company “Main collection account” opened in the Designated Branches thus nullifying the Branch collection account Designated Branches with ‘Main Collection Accounts’ i. The branches maintaining Main Collection Accounts of any of the utility companies in big cities are termed as “Designated Branches”. ii. At the end of the day’s work, entire amount in “Main Collection Account” (including amounts collected by the designated b ranch at its own counters) will be transferred to “Main Account” of the company maintained by designated branch itself or remitted to the Bank / Branch maintaining Main Account of company concerned, thus reducing the collection account balance to minimum / nil position. iii. Consolidated statements sent immediately to utility company for updating the respective accounts of consumers at utility company’s end. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 172 6.5.6 Disposal of Stubs for KESC/ WAPDA/ SNGPL/ SSGC  KESC: Stub will be han ded over to NIFT representative (where applicable)/ revenue offices.  WAPDA: Stubs will be dispatched to concerned Revenue Office.  SNGPL/ SSGC: Stubs will be handed over to NIFT representative (where applicable)/ revenue offices. 6.5.7 Branch Commission i. At the end of each month, all branches collect commission @ PKR 8/ bill from the “Designated branches” who maintain the Main Collections Account”. The records maintained in the register introduced at branches will help in recovering commission by multiplyi ng the number of bills with “8” and debiting the amount so calculated, to the concerned designated branch. ii. Where Company’s “Main Account” is not maintained and funds are remitted to some other Bank’s branch, recovery of commission will be made from “Main C ollection Account”. Statements of “Main Account” and “Main Collection Account”, showing recovery of commission, may be provided to each utility company 6.6 UTILITY BILLS COLLEC TION – VIA MCB BOOTHS In order to facilitate our customers and public in general, MCB Utility Bill Booths are opened at various places. These booths are independent and away from parent branch Premises i -e Shoppin g Mall, Bazaar or hospital etc However are governed by and report to the parent branch. These booths are to be equipped with Ca sh O fficer (s), Security Guards, Personal C omputer(s), Printers, LAN, Cash Counting & Binding Machines, Cash Vault/ Insurance, Security Van arrangement for Cash Transportation. The process is the same as described in Section 3: 6.5 Utility Bills Standard Collection Process – KESC/ WAPDA/ SNGPL/ SSGC with addition to the following: 1. Cash received during the day and utility bills vouchers are sent to parent branch through security van with - in next 24 working Hours. 2. Maintain separate cash book for the receiving and balancing of cash received during the day. 6.7 AUTHORITY TO DELETE ARREARS All the utility companies have empowered the collecting Banks to score out the amount of arrears from the total amount of bills, If the bill is deposited w ithin due date, provided confirmation is made by verification of the following : - i. Consumer produces previous “Paid Bill” in original. ii. Previous bill has been paid at the same branch. iii. Branch previous months record / statement shows bill having been collected before due date and reported properly. Supervisor after due verification will encircle the arrear amount and mark date of previous receipt under branch seal and his signature. He will then reduce bill amount to bring it to current month’s dues, which will be collected in the usual manner. In case arrears still appear in the next month and consumer gets worried, branch B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 173 may provide copy of previous statement/scroll, showing payments having been received, to the consumer or concerned utility company for corre cting its record. The relative entry appearing in duplicate statement must be encircled for prompt disposal. In case of repeated mistakes, branch must clarify the position through a letter to the concerned department of the utility company. Under no circu mstances branch will oblige the depositor of bill or consumer if: - i. He is not agreeable to pay late payment surcharge imposed by the company for payment after due date. ii. Last payment is not made at the same branch in case of arrears. However, after clearance from utility company the corrected amount on the bill can be accepted within new date mentioned on the bill B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 174 Chapter 7 PRIZE BONDS Overview: Prize Bonds are as good as cash. As per the existing policy of Government of Pakistan, Prize Bonds are available in the following six (6) denominations: Sr. Denomination (in PKR) SYMBOLS GL CODE 01. 200 2040403020 02. 750 2040403030 03. 1500 2040403040 04. 7500 2040403050 05. 15,000 2040403060 06. 40,000 2040403070 All branches are authorized to sell and en -cash Prize Bonds and are required to keep adequate stock of Bonds with them at all times to meet public demand. However the sale of Prize Bonds will remain suspended during “shut period”. Branches are required to display signboards at a conspicuous place regard ing the sale and purchase of Prize Bonds. 7.1 SALE AND ENCASHMENT T RANSACTIONS i. Entries for sale and encashment transactions are recorded in the respective General Ledger Module (GL). Systems do not provide the facility to automatically monitor and balance th e inventory for the Prize Bonds. ii. At the end of the day, a consolidated amount voucher is posted in the respective GL Heads. All Prize Bonds entries are cash related, the same should be passed through cash debit and cash credit vouchers. All Cash Debit and Credit vouchers must be signed -off by two Designated Authorized Officers of the branch. 7.2 MAINTENANCE O F MONTHLY PRIZE BOND S STATEMENT i. Branches are required to maintain and submit the statement of Prize Bonds to their Regional Office, on the last working d ay prior to the start of “shut period”. Branches with ‘NIL’ Prize bonds are also required to submit a’ NIL’ statement to their region Offices as a confirmation. ii. Circle Office after compilation of figures, furnish consolidated statement of balances of Prize Bonds held by their offices/branches, at the close of business on the last working day prior to the start of “shut period”, to the concerned office of the State Bank of Pakistan within five days of the commencement of the relative “shut period”. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 175 7.3 REQUIREMENT DURING S HUT PERIOD i. Branches shall suspend the sale of Prize Bonds re -purchased across the counter as well as Prize Bonds purchased from State Bank of Pakistan held in stocks for two months before the date of the draw of the relevant denominatio n of the Prize Bonds. ii. In case of Prize Bonds of PKR 200/ -, PKR 750/ - and PKR 1,500/ - the “shut period” will start from the close of business on the 14th of the month preceding the applicable two months of draw related to the series. iii. The “shut period” for PKR 7,500/ -, PKR 15,000/ - and PKR 40,000/ - denomination Prize Bonds will start from the close of business on the last day of the month previous to two months preceding the month of draw related to the series. iv. If the 14th of the month, in case of option (i), and last date of the month, in case of option (ii), fall on a Sunday or a public holiday, then the preceding working day will be treated for the purpose of listing the Prize Bonds which are subject to “shut period”. 7.4 MAINTENANCE OF PRIZE BONDS REGISTER Each page of Prize Bonds Receipt and Sales Register – SB 127 consists of nine columns. i. First three columns from left are assigned to the Prize Bonds “Purchased from Public” in which the date, indicative numbers of Prize Bonds Purchased and the value there of are entered. ii. Next three columns are set aside to record resale of Prize Bonds to public as to date, numbers of pieces of Prize Bonds and value. iii. The last three columns denote two columns balances as to number of pieces of prize bonds with value and the third column is provided for initials of dealing cashier / chief cashier who is assigned the job and to maintain record. The pages of this register i.e. SB -127 shall be segregated and allotted separately for each denomination of new prize bonds. 7.5 MAINTENA NCE OF PRIZE BON DS SHUT PERIOD REGIS TER- SB-107 i. Branches will maintain “Prize Bonds Shut Period Register” SB –107, and all Prize Bonds which are subject to shut period will be recorded individually in this register with series followed by printed machine number. After the entries have been properly checked the total number of Prize Bonds listed and the total value will be written at the end of entries. ii. Teller and the Operations Manager will sign the notation. It should be ensured that there should be no over writing and all alterations in the listing should be properly authenticated by the signatories. Before signing the entries in the register it will be ensured that the number of pieces and the total amount involved matches with the balances shown in Prize Bonds Receipt and Sales Register and the supplementary ledger. iii. The register will be placed in the safe custody under dual control together with Prize Bonds listed in the register in a sealed cover. iv. Immediately after the draw, the bonds held by branches dul y listed will be checked with reference to the relevant draw list either published by Directorate of National Savings or obtained from State Bank of Pakistan’s offices. v. All prizes winning bonds will be segregated from the listed bonds. vi. The prize winning bonds will be forwarded through a forwarding letter to the office at the State Bank of Pakistan with a request to credit the amount of prize money payable on the bonds in question to Government Account and its / their face value to their account maintained with State Bank of Pakistan. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 176 Refer to Annexure V vii. In case the branch is not maintaining account with State Bank of Pakistan then the qualifying bond/s will be delivered to nearest branch of our Bank maintaining account with State Bank of Pakistan for doing the needful under proper acknowledgement and intimation to Accounts Department, Prin cipal Office, Karachi. viii. Tellers must be well informed and remain constantly aware of day -to-day instructions from State Bank of Pakistan regarding Prize Bonds of various denominations. A chart showing dates of draws and shut periods of Prize Bonds of all denominations must remain handy with the Tellers, Teller services supervisors & Operations Manager. This will help them to effec tively maintain and control Prize Bonds stocks. 7.6 PROCEDURE FOR SALE O F PRIZE BONDS (CASH) Customer: Presents equivalent amount of cash to the teller to purchase prize bonds. Teller: i. Checks the availability of prize bonds in vault. ii. Receives cash from the Customer. iii. Counts denomination wise cash and also verifies the notes that they are genuine. iv. Note down transaction details in the Receipt & Sales Register - SB-127. v. Prepares and sign -off Cash Credit Voucher SF -46 and forwards the same to vi. Teller services s upervisor or Operations Manager for second sign -off as per the assigned limits. Teller services supervisor or Operations Manager checks and verifies the transaction and sign -off the Cash Credit Voucher - SF-46 as per the assigned Cash Receipt Limits. Teller processes the payment. i. Counts the Prize Bonds. ii. Deliver Prize Bonds to the Customer. iii. Affix Cash Received Stamp on SF -46 & forwards the same to GL Maintenance Officer for posting in the relevant GL Heads. For detail Batch Processing, please refer to Section 7: 1.4 Transaction processing In GL Module Customer: i. Receives prize bond(s). ii. Counts them. iii. Leaves the branch. Operations Manager accepts General Ledger Batch against SF - 46. Teller services supervisor: At the end of day, validates the GLA - 11 report with the cash voucher SF -46 and arranges filing of the same. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 177 7.7 PROCEDURE FOR SALE O F PRIZE BONDS (DEBIT TO ACCOUNT) Customer: Presents cheque to the teller for the purchase of Prize Bonds. Teller: i. Checks the availability of prize bonds in vault. ii. Receives cheque from the Customer. iii. Scrutinizes the cheque and process the transaction on Branch Teller Module - Transactions >> Financial Transactions >> Single Transactions >> Current/ Savings Account >> Cheque Wi thdrawal (BT -3212) iv. Insert or select account number (from the List of values) and press enter. v. Input transaction type - CQWR, input currency type, Transaction amount, effective date and enter cheque number. vi. Press F10 or click on save icon. vii. Transaction accept ance message will appear on the screen. If transaction amount exceeds the Teller’s limit, screen pop -ups “Authorization Required” message. Teller services supervisor authorizes/approves the transaction. BT>> Override >> Remote Override (Screen # BT002020) . Teller: Notes down the transaction details in the Receipt & Sales Register - SB-127. Prepares and sign -off Cash Credit Voucher SF -46 and forwards the same to Teller services supervisor or Operations Manager for second sign-off as per the assigned limit. Teller services supervisor (TSS) : i. Remotely overrides the transaction. In case of local override, supervisor will have to enter his/her User ID and Password on the Teller’s Terminal. ii. Scrutinizes and verifies the transaction details and sign -off the Cash Cr edit Voucher - SF-46 as per the assigned Cash Receipt Limits. Teller i. processes the payment; ii. Counts Prize Bonds iii. Delivers Prize Bonds to the Customer. iv. Affix Transfer on cheque. v. Prepares Cash Credit Voucher - SF-46, sign -off and forwards the same to TSS for second sign -off. Customer: Receives prize bond(s), counts them & leaves the branch. Teller services supervisor: i. Scrutinizes and verifies the transaction. ii. Sign-off the Cash Credit Voucher - SF-46 as per the defined receipt limits and forwards the same to General Ledger Maintenance Officer for posting the accounting entries in the relevant GL Heads. Note: If transaction amount exceeds Teller’s Limit, Operations Manager/ Teller services supervisor will sign -off the Voucher. General Banking Officer: Teller uses General Ledger Module >> Transaction >> Batch Maintenance >> Batch Entry (Screen # GL -21) Operations Manager accepts GL Batch against SF -46. Teller services supervisor: i. At the end of day, validates GLA - 11 & RBA -11 report with the cash voucher SF -46 and cheque. ii. After validation, arranges filing of the same. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 178 7.8 PROCEDURE FOR ENCASH MENT OF PRIZE BONDS (CASH) Customer presents the Prize Bonds to the teller for encashment. Teller: i. Receives Prize Bonds from the Customer. ii. Verifies the Prize Bonds. iii. Checks the shut period of Prize Bonds. iv. Counts Prize Bonds denomination wise. v. Note down transaction details in the Sales and Receipt Register - SB-127. vi. Prepares and sign -off Cash Debit Voucher SF -23 and forwards the same to the Teller services supervisor or Operations Manager for second sign -off as per the assigned limits. Teller services supervisor/Operations Manager: i. Checks and verifies the transactio n and sign -off the Cash Debit Voucher - SF-23. ii. Returns the same to teller for encashment of Prize Bonds. Teller: i. Processes the payment. ii. Counts equivalent cash. iii. Deliver cash to the Customer. iv. Affix Cash Paid Stamp on SF -23 and forwards the same to GL Maint enance Officer for posting. For detail Batch Processing, please refer to Section 7: 1.4 Transaction processing In GL Module Customer: Receives and counts cash and Leaves the branch. General Banking Officer: GL Officer uses GL Module for posting the relevant Accounting entries in the system. Teller services supervisor: At end of day, validates GLA -11 report with cash debit voucher - SF-23 and arrange fil ing of the same. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 179 7.9 PROCEDURE FOR ENCASH MENT OF PRIZE BONDS (CREDIT TO ACCOUNT) Customer presents deposit slip & Prize Bonds to the teller for transfer into account. Teller: i. Receives Prize Bonds from the Customer along with the Deposit slip. ii. Checks the shut period of Prize Bonds. iii. Credit customer’s account by using Branch Teller Module >> Transactions >> Financial Transactions >> Single Transactions>> Current/ Savings Account >> Cash Deposit. iv. Input transaction type - CASD, input currency type, Transaction amount, and eff ective date. v. Note down transaction details in the Sales and Receipt Register - SB-127. If transaction amount exceeds the Teller’s limit, screen pop -ups “Authorization Required” message. Teller services supervisor authorizes/approves the transaction. BT> Ove rride > Remote Override (Screen # BT002020.) Teller services supervisor / Operations Manager: Verifies the transaction as per the assigned limits. Teller : Processes the payment. i. Affix “Cash Received Stamp” on deposit slip. ii. Sign-off & delivers copy B of deposit slip to the customer. iii. Prepare Cash Debit Voucher - SF-23 and forwards the same to General Ledger Maintenance Officer for posting. Customer: Receives Duplicate copy of Deposit slip & leaves General Ledger Maintenance Officer: GL Officer uses GL Module for posting the relevant Accounting entries in the system. For detail Batch Processing, please refer to Section 7: 1.4 Transaction processing In GL Module Teller services supervisor: At end of day, validates the relevant report with cash debit voucher - SF-23 & deposit slip. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 180 REMITTANCES SECTION 4 REMITTANCES Section Summary: This Section cover s general instructions , guidelines and processes for all kind of Remittances I-e Pay -Orders, Dema nd Drafts (LCY & FCY) , Telegraphic Transfer , Foreign Wire Transfer, Rupee Traveler Cheques & Home remittances SECTION 4 B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 181 Chapter 1 GENERAL INSTRUCTIONS FOR PO / DD 1.1 OVERIEW - APPLICATION FORM Funds Transfer Application ( SF-100R) is used in the branches in order to facilitate the customer’s request for remitting the funds locally or abroad. Branches should ensure that the information on FTA is complete in every aspect; is signed by the account holder(s)/ authorized signatory; signatures are religiously verified and that the funds a re available in the account before accepting the FTA for processing. For strengthening control, Valid Cross Cheques of equivalent amount will be taken from the customer along with FTA. 1.2 SCRUTINY OF DEMAND D RAFT & PAY ORDER When the payee presents a draft or the collecting banker for payment presents it, following should be checked: i. DD is drawn on the branch in which it is being presented. ii. PO is drawn on the city in which it is being presented. iii. Instrument is not more than six months old. iv. There is no alteration or overwriting. v. The Instrument is not mutilated. vi. A proper discharge regarding the disbursement of proceeds is given. vii. Ensure that the name of issuing branch is printed / written or rubber -stamped. 1.3 BALANCING OF PO / DD PAYABLE ACCOUNTS At the dr awee branch DD Payable & PO Payable accounts listed below MUST be balanced on a daily basis . For this purpose, the report of ‘Outstanding Demand Drafts & Payment Orders’ that is generated through KM is provided to all branches by KM team on a daily basis. Branch Operations Manager is required to ensure that the total of all outstanding DDs and POs tally with the balances appearing on the respective GL Heads of branch General Ledger. (For detailed process to balance the DDs & POs refer the guidelines on ‘Ba lancing of Pay Order / Demand Draft Liability Heads’ circulated by Centralized Operations Division to all branches on Jan 29, 2010) 1.4 ISSUANCE OF NEW PAYM ENT ORDER / DEMAND D RAFT SERIES Central Processing Unit (CPU ) is responsible for allocation of PO/DD s eries to all the branches in order to issue Banker’s Cheque to the customers. The purpose of registration of PO/DD is to streamline the process as well as keep stringent and dual controls on the process. The following procedure will be used in the branche s: B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 182 1.4.1 PO/DD Inventory Requisition & Allocation in Branches : i. For new PO/DD series distribution, branches are required to send requisitions to CPD on the PO/DD Request Form at least two days prior to the end of PO/DD inventory. ii. Branch Operations Managers (or their designated backup) are authorized to send request via Branch e - mail address. E-mail address is podd.cpd@mcb.com.pk Fax number 021 - 32270140 iii. Upon receiving the request at CPD from branches, authorized officer updates new PO/DD series in the respective branch’s system for the issuance of PO/DD. 1.5 BALANCING OF PAYMENT ORDER / DEMAND DRAFT LEAVES i. The unused leaves of Banker’s Cheque Stationery in the branch should be counted by the Remittances In-charge at the close of each business day. ii. A proper record should be maintained in the following manner. Date Number of Leaves Issued Balance of Unused Leaves Initials iii. If any Banker’s Cheque leaf is damaged or spoiled, it should be cancelled and retain the same in a separate file for future verification and audit purpose. 1.5.1 Branch Process for Inventory Allocation: i. Branch Operations Manager (BOM) / Teller Services Supervisor (TSS) will assign the PO/DD series to the GBO from the branch cheque registered series by using Deposit Module> Cheque I nstrument> Administration> Cheque Assignments. ii. GBO selects the PO/DD number from the list of values by using F9 option. In case of unavailability of PO/DD series, GBO cannot issue the Banker’s Cheque to the customer. (One GBO can re -assign the PO/DD serie s to another GBO which was originally assigned to 1st GBO). 1.6 TRANSFER OF DDS & PO S TO UNCLAIMED ACCOU NT Demand Drafts and Pay Orders which remains outstanding for more than three years from the date of issuance will be classified as ‘Unclaimed’ and will be transferred to Unclaimed - DD & PO Accounts. (Regarding surrender of Unclaimed DDs and POs to State Bank of Pakistan refer Section 2: 5.2 Unclaimed Deposit s & Financial Instruments B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 183 Chapter 2 PO / DD / CDR & LCY-TT PROCESSES Payment Order is used for making payments within a city. It is neither transferable nor negotiable and as such it is payable to the payee named therein. 2.1 PO ISSUANCE – SELL AGAINST CASH Customer presents duly completed Fund Transfer Application (FTA) alo ng with the cash to the teller. Teller : i. Receives Fund Transfer Application (FTA) along with the cash from the customer. ii. Verifies FTA to ensure that all the relevant information has been provided. iii. Counts cash and verify that all notes to be genuine. iv. Affix Cash Received Stamp on FTA. v. Delivers acknowledgement to the customer. vi. Forward the request to GBO for further processing vii. GBO uses Branch Teller Module, selects Cheque Instruments > Transaction > Draft/Bank Cheque sell menu to issue a Payment Order. (Screen # BT 3291) viii. Input Transaction type – POCS Payment Order Cash Sell, Cheque Type (PO) and other mandatory information. ix. While issuing the P.O full description of beneficiary must be entered in the system. x. Executes the transaction and signs the PO & FTA. (If transaction amount exceeds the GBO’s limit, screen pop -ups “Authorization Required” message. BOM / TSS authorizes/approves the transaction). BOM / TSS: After verifying customer details from Original FTA, authorizes the same on the system (if required) by using BT> Override > Remote Override Screen # BT002020. System : (Branch Teller Module) - Generate the Payment Order . BOM / TSS: i. Checks and sign off the same. (2nd signature along with IBS) ii. In case of error in Payment Order, r eturns the same to the GBO for re -issuance. In case of error in Payment Order: i. Select the option from EOC Menu Deposits> Cheque Instruments> Transactions > Cheque Reversal (Non -Account) ( RB- 35) - (POC# - Payment Order Cash Sale Reversal) ii. Input the requi red information. iii. To reverse the transaction click and press the save button. As a result authorization window pops -up. iv. As soon as authorization completes by the supervisor. v. Keep cancelled Payment Orders in a separate file. vi. Re-issue the Payment Order (Follow the complete Payment Order issuance process, discussed earlier). vii. Delivers the Payment Order to the customer on the counter and attached the duplicate or carbonized copy with FTA. viii. Obtains acknowledgement from the customer on FTA GBO i. Generates RBA-11 report from the system. ii. Checks Report - RBA 11 with the source document and gets sign off from TSS / BOM. iii. Stores the same for record. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 184 2.2 PO ISSUANCE – SELL AGAINST ACCOUNT Customer: Customer presents duly completed Fund Transfer Application (FTA) along with a crossed cheque to GBO. GBO receives Fund Transfer Application (FTA) along with Crossed Cheque from the customer. i. Verifies FTA and crossed cheque to ensure that all the relevant information has been provided. ii. The Status of the Crossed cheque w ith the FTA should be valid. It will be checked in the system whether it is valid I -e not stopped/serial # activated in the system/ not cancelled etc. iii. Uses Branch Teller Module, selects Cheque Instruments > Transaction > Draft/Bank Cheque sell menu to issue a Payment Order. (Screen # BT 3291) iv. Input Transaction type –POTS Payment Order Transfer Sale, Cheque Type (PO) and other mandatory information. v. Verifies customer’s signature on FTA & Crossed Cheque vi. While issuing the P.O full description of beneficiary must be entered in the system. vii. After inserting the required i nformation transaction Charges w indow pops -up for in order to recover charges from the account. viii. Input the Cheque amount, Quantity of PO iss ued, Start No. from LOV in the fields ix. Execute s the transaction and signs FTA & the C rossed cheque x. Delivers acknowledgement slip to the customer. (If transaction amount exceeds the GBO’s limit, screen pop -ups “Authorization Required” message. TSS / BOM authorizes/approves the transaction.) Treatment of Cross Cheque obtained along with FTA:  The cross cheque obtained along with the FTA will be marked as used “U” in the system by using following path: EOC – Deposits > Cheque Control > Cheque Maintenance > Che que Status  The FTA pre -printed serial # will be written on the face of the cross cheque obtained.  The cheque will be defaced/ cancelled/ stamped (Transfer) TSS / BOM: After verifying customer details from Original FTA/ Cheque, authorizes the same on the system (if required) by using BT> Override > Remote Override Screen # BT002020. System: (Branch Teller Module) i. Debit the customer’s account for the amount of Payment Order and charges. ii. Generates the Payment Order. GBO: i. Checks the printed Payment Order against Fund Transfer Application (FTA)/ Crossed Cheque ii. Sign off the same(1st signature along with IBS) iii. Forwards the Payment Order along with FTA /Crossed Cheque to the TSS / BOM for 2nd signature. TSS / BOM: i. Checks and Sign off the same(2nd signature along with IBS) ii. In case of error in Payment Order, returns the same to the teller for re -issuance. In case of error in the Payment Order – GBO will : i. Select Transaction > Value Transactions > Reversal. (POT# - Payment Order Transfer Sale Reversal) ii. Input the required information. (e.g. Account No., Account Type, Client details, Date etc) iii. To reverse the transaction click and press the save button. As a result authorization window pops -up. iv. Keep cancelled Payment Or ders in a separate file. v. Re-issue the Payment Order (Follow the complete Payment Order issuance process, discussed earlier). vi. Delivers the Payment Order to the customer on the counter and retain duplicate with FTA. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 185 vii. Obtains acknowledgement from the customer on FTA. GBO generates the RBA - 11 report from the system. i. Checks the report with the source document and gets sign off from TSS / BOM. ii. Stores the same for record. 2.2.1 Deviation on “Obtaining Cross Cheque” with FTA: For any particular transaction, requirement of obtaining cross cheques along with FTA for Issuance of PO against account debit can be waived by ROM or RH. BOM/ BM are authorized to take such deviation approval after specifying valid reason(s) via e -mail or fax. 2.3 PO PURCHASE – TRANSFER INTO ACCOUN T Customer presents duly completed deposit slip along with the Payment Order to the Teller. GBO i. Verifies the pay order and deposit slip to ensure that all the information given on the pay order and deposit slip is correct and payment has not been made. ii. GBO performs the following steps: iii. Uses Branch Teller Module, selects Cheque Instruments > Transaction > Dr aft/Bank Cheque buy menu to issue a Payment Order (Screen # BT3292) iv. Input Transaction type – POTB Payment Order Transfer Buy, Cheque Type (PO) and other mandatory information. v. Executes transaction. (If transaction amount exceeds the GBO’s limit, screen pop -ups “Authorization Required” message. TSS / BOM approve the transaction.) TSS / BOM: After verifying customer details from Original Instrument, authorizes the same on the system (if required) by using BT> Override > Remote Override Screen # BT002020. GBO: i. Affixes Posted and Transfer stamp on the pay order and Deposit slip. ii. Sign off the same and delivers deposit slip to the depositor. iii. GBO generates RBA -11 report from the system & checks it with source documents and gets sign off from TSS / BOM. iv. Stores the same for record In case of error in Payment Order Purchase: i. Select Transaction > Value Transactions > Reversal. (PO## - Pay Order Transfer buy reversal) ii. Input the required information. (e.g. Ac count No., Account Type, Client details, Date etc) iii. To reverse the transaction click and press the save button. As a result authorization window pops -up iv. Re-issue the Payment Order (Follow the complete Payment Order Purchase process, discussed earlier). Note: Pay Orders will not be purchased against Cash and hence no cash payment will be made against a Pay Order. It is to be credited to account ONLY. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 186 2.4 LCY DD ISSUANCE – SELL VIA CASH Customer presents duly completed Fund Transfer Application (FTA) along with the cash to the teller. Teller i. Receives Fund Transfer Application (FTA) along with the cash from the customer. ii. Verifies FTA to ensure that all the relevant information has been provided. iii. Calculates Draft issuance charges. iv. Counts cash and verify that all notes to be genuine. v. Affix Cash Received Stamp and forwards to GBO for further processing. vi. GBO uses Branch Teller Module > Cheque Instrument> Transaction > Draft/Bank Cheque Sell Menu to issue a Demand Draft. (Screen # BT3291) vii. Input Transaction type DDCS - Demand Draft Cash Sale , Cheque type (DD) and other mandatory information. viii. After the input of transaction details, press Tab, transaction Charges Window pops -up to recover the char ges. ix. While issuing the DD full description of beneficiary must be entered in the system. x. Inputs the Cheque amount, Quantity of DD issued, Start No. from LOV in the fields available in the bottom of the screen xi. Executes the transaction. (If transaction amou nt exceeds the GBO’s limit, screen pop -ups “Authorization Required” message. TSS / BOM authorizes/approves the transaction.) TSS / BOM: After verifying customer details from Original FTA, authorizes the same on the system (if required) by using BT> Override > Remote Override Screen # BT002020. GBO: i. Checks the printed Demand Draft against Fund Transfer Application (FTA). ii. Sign off the same (1st Signature) iii. Forwards the Demand Draft along with FTA to the TSS / BOM for 2nd signature TSS / BOM: i. Checks and sign off the same. (2nd signature) ii. In case of error in Demand Draft, returns the same to the teller for re -issuance In case of error in Demand Draft – GBO will: i. Select the option from EOC Menu Deposits> Cheque Instruments> Transactions > Cheque Reversal (Non -Account) ( RB- 35) - (DDD# Demand Draft Cash Sale Reversal) ii. Input the required information. iii. To reverse the transaction press the save button. As a result authorization window pops -up. iv. As soon as authorization completes the reversal transaction is automatically generated v. Keep them in a separate file. vi. Re-issue the Demand Draft (Follow the complete Demand Draft issuance process, discussed earlier). vii. Delivers the Demand Draft to the customer on the counter and retain duplicate with FTA. viii. Obtains acknowledgement from the customer on FTA ix. GBO generates RBA -11 report from the system. x. Checks the report with the Source document and gets sign off from TSS / BOM. xi. Stores the same for record. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 187 2.5 LCY DD ISSUANCE – SELL VIA ACCOUNT Customer presents duly completed Fund Transfer Application (FTA) along with a crossed cheque to GBO. GBO i. Receives Fund Transfer Application (FTA) and C rossed cheque from the customer. ii. Verifies FTA to ensure that all the relevant information has been provided. iii. The Status of the Crossed cheque with the FTA should be valid. It will be checked in the system whether it is valid I -e not stopped/serial # activated in the system/ not cancelled etc. iv. Selects the Cheque Instruments > Transaction> Draft/ Bank Cheque Sell xi. Verifies customer’s signature on FTA & Crossed Cheque v. Input/Select Cheque Type (DD) and Transaction Type DDTS - Demand Draft Transfer Sale from LOV vi. Fill in the transaction details (e.g.; Account Number, Customer no and Account type etc.) vii. While issuing the DD full description of beneficiary must be entered in the system. viii. Inputs the Cheque Details (e.g. Settle Ccy, Cheque Amount). ix. After that transaction Charges Window pops -up to recover charges for the transaction x. Executes the transaction, sign-off FTA & the Crossed cheque Treatment of Cross Cheque obtained along with FTA:  The cross cheque obtained along with the FTA will be marked as used “U” in the system by using following path: EOC – Deposits > Cheque Control > Cheque Maintenance > Cheque Status  The FTA pre -printed serial # will be written on the face of the cross cheque obtained.  The cheque will be defaced/ cancelled/ stamped (Transfer) TSS / BOM: After verifying customer details from Original FTA/ Cheque, authorizes the same on the system (if required) by using BT> Override > Remote Override Screen # BT002020. GBO: Generates the Demand Draft. i. Checks the printed Demand Draft against Fund Transfer Application (FTA) / Crossed Cheque ii. Sign off the same (1st Signature) iii. Forwards the Demand Draft along with FTA /Crossed Cheque to the TSS/ BOM for 2nd signature. TSS / BOM: i. Checks and sign off the same. (2nd signature) ii. In case of error in Demand Draft, returns the same to the teller for re -issuance. In case of error – GBO will : i. Select Transaction > Value Transactions > Reversal. (DDS# - Demand Draft Transfer Sell Reversal) ii. Inputs the required information (e.g. Account No., Account Type, Client details, Date etc.) iii. To reverse the transaction press the save button. As a result authorization window pops -up. iv. As soon as authorization completes the reversal transaction automatically generated v. Keep them in a separate file. vi. Re-issue the Demand Draft (Follow the complete Demand Draft issuance process, discussed earlier). vii. Delivers the Demand Draft to customer on the counter and retain Duplicate with FTA. viii. Obtains acknowledgement from the customer on FTA. GBO generates RBA -11 report from the system. i. Checks the report with the source documents and gets sign off from TSS / BOM. ii. Stores the same for rec ord. 2.5.1 Deviation on “Obtaining Cross Cheque” with FTA: For any particular transaction, requirement of obtaining cross cheques along with FTA for Issuance of LCY DD against Account Debit can be waived by ROM or RH. BOM/ BM are authorized to take such deviation approval after specifying valid reason(s) via e -mail or fax. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 188 2.6 LCY DD PURCHASE – TRANSFER INTO ACCOUN T Customer presents duly completed deposit slip along with the Demand Draft to the GBO. GBO i. Verifies the Demand Draft and deposit slip to ensure that all the information given on the same are correct and payment has not been made. ii. GBO performs the following steps:  Select the Cheque Instruments > Transaction> Draft/ Bank Cheque Buy (Screen # BT3292)  Input/Select Cheque Type (DD) and Transaction Type - DDTB Demand Draft Transfer Buy from LOV  Fill in the Transaction details (e.g.; Account No., Branch, Customer No., Account Type etc).  Input the Cheque Details (Cheque amount, Settle Ccy etc.)  Inpu t the Beneficiary Contact information (Name, Address etc.)  Executes transaction. (If transaction amount exceeds the GBO’s limit, screen pop -ups “Authorization Required” message. TSS / BOM authorizes/approves the transaction.) TSS / BOM: After verifying c ustomer details from Original Instrument, authorizes the same on the system (if required) by using BT> Override > Remote Override Screen # BT002020. GBO: i. Affix Posted and Transfer stamp on the Demand Draft and Deposit slip. ii. Sign off the same and delivers deposit slip to the depositor. iii. Forwards the instrument to the back office for checking and record keeping. GBO generates RBA -11 report from the system. i. Checks the report with source documents and gets sign off from TSS / BOM ii. Stores the same for record In case of error – GBO will: i. Select Transaction > Value Transactions > Reversal. (DDT# - Domestic DD Transfer Buy Reversal) ii. Inputs the required information (e.g. Account No., Account Type, Client details, Date etc.) iii. To reverse the transaction press the save button. As a result authorization window pops -up. iv. As soon as authorization completes the reversal transaction automatically generated v. Re-Purchase the Demand Draft (Follow the complete Demand Draft Purchase process, discussed earlier). Note: Demand Drafts will not be purchased against Cash and hence no cash payment will be made against a Demand Draft. It is to be credited to account ONLY. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 189 2.7 FCY DD ISSUANCE – SELL VIA ACCOUNT Branch : i. Forex O fficer gives the FTA (SF-100R) to Customer who approa ches branch for Foreign Demand Draft Remittance. On the receipt of Filled FTA (SF-100R) along with Crossed Cheque , Forex Officer check s particulars of the FTA and Crossed Cheque and ensures that the document is completely filled. ii. In case of FCY Account Holder: Forex Officer/ TSS checks availability of funds in the applicant’s account. Crossed Cheque along with SF-100R is received from the customer for the amount of FDD inclusive of charges. Upon availability of funds, customer account is debited. In case Remittance under Specific/General Permission of SBP (Form “M”) against Pak Rupee Account i. In case of purpose of remittance is under general permission of SBP, FTA is further processed with Form -M attached. However in case purpose of remittance is not cover ed under general permission, Certified/Approved Form M from SBP is required. ii. Forex Manager acknowledges Form -M. Forex Officer converts the amount to be remitted using the rates given in daily Forex Rates Schedule obtained daily from Treasury Head Office and calculates charges on remittance as per Bank SO BC iii. Forex Officer/ TSS receives Crossed Cheque along with FTA (SF-100R) and upon sufficient availability of funds, signatures on the cheque are verified and TRANSFER stamp is affixed on Crossed Cheque & FTA. iv. Forex Officer prepares FDD manually, enters the particulars in FDD register and is forwarded to two authorized signatories having AS numbers for approval. After app roval Forex Officer issues FDD. v. Crossed Cheque #, FDD Instrument # & charges are written on FTA (SF-100R) Treatment of Cross Cheque obtained along with FTA:  The cross cheque obtained along with the FTA (SF-100R) will be marked as used “U” in the system by using following path: EOC – Deposits > Cheque Control > Cheque Maintenance > Cheque Status  The FTA pre -printed serial # will be written on the face of the Cross cheque obtained.  The cheque will be defaced/ cancelled/ stamped (Transfer). Preparation and approval of Credit advices and Annexure XX i. On basis of remittance application, Forex Officer prepares credit advices (SF -139) in quadruplicate and on basis of these prepares Annexure XX which is approved by Forex Manager and Operations Manager. ii. Annexure XX is then forwarded to two separate Test Key officers for application of test (Part A and B) and later delivered to Forex Manager for transmitting through fax to Treasury Back office. Centralized SWIFT Division: Forex Officer prepares and sends SWIFT Message to Forex Manager for verification and onward submission to Centralized SWIFT Division Karachi. Officer in Centralized SWIFT Division verifies it and forwards to related correspondents. When Centralized Swift Head Office rec eives SWIFT acknowledgement from Foreign Bank it is forwarded to branch for their record. Branch: Acknowledged copy received from Centralized SWIFT Operations Karachi is to be verified against the source documents by the Branch Manager. 2.7.1 Deviation on “Obtaining Cross Cheque” with FTA: For any particular transaction, requirement of obtaining cross cheques a long with FTA for Issuance of FDD against account debit can be waived by ROM or RH. BOM/ BM are authorized to take such deviation approval after spe cifying valid reason(s) via e -mail or fax. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 190 2.8 FCY DD PURCHASE – UNDER RUPEE DRAWING ARRANGEMENT Direct FIDD are inward remittances that are issued in PKR on MCB Branches with intimation to Global Transaction Branch (GTB). Foreign Agent issue FDD on request of remitter who want to remit money from abroad to Pakistan. The FIDD could be present in any MCB branch. The Branch makes payment and originates HO advice on GTB branch, where agents’ nonresident account is maintained to settle the proceeds of FDD. Process of FCY DD Purchase – Under Rupee Drawing Arrangement Customer presents FDD in bank for payment. Designated Authorized Officer receives FDD and verifies the beneficiary detail from original valid CNIC and also takes a copy of CNIC and stamps it as “Original Seen”. And conduct KYC of customer as per banks KYC and AML handbook. If amount is more than RS. 100,000/ - than confirmation is taken from GTB branch before payment through email/ fax. Email will be forwarded by BOM/ Forex manager with pa rticulars of instrument. Designated Authorized Officer (GTB Branch) checks the FDD detail with record already provided by the foreign agent, after satisfying from the credential or particulars of FDD reply the email and give intimation/ confirmation to br anch through fax Designated Authorized Officer checks Authorize Signature (AS) and Test on demand draft and after being satisfied with genuineness of demand draft counter sign it Note: If Demand Draft is more than USD $10,000/ equivalent amount, then R-Form is required, clearly stating purpose of remittance. However, if remittance is in favor of company/ Firm than R -Form must be obtained from each and every company/ firm regardless remittance amount. Branch obtain signed R -form from customer, verify cu stomer’s signature with branch stamp or if DD presented in clearing than R -Form requirement must be checked that respective bank had sent R -Form along with DD and customer signature is duly verified and forwarded to GTB Branch. GTB Branch submits onward to SBP on monthly basis. DAO after being satisfied with the credential of customer prepares HO debit advice drawn on GBT Branch (0069). Advice and supporting documents are forwarded to BOM/ TSS/ Forex manager for approval. Originated advice must be properl y signed with AS/ IBS number and proper test must be applied by Designated Authorized Officer For detail Batch Processing, please refer to Section 7: 1.4 Transaction processing In GL Module BOM/ TSS/ Forex Manager authorize the transaction after being satisfied with the supporting documents. i. Copy A of advice courier to GTB branch with copy of paid FDD ii. Copy B of advice sent to F orex Department for their record purpose. iii. Copy C of advice retained by Cash department as part of vouchers Payment in Cash : Teller takes customer’s signature on back side of advice/FDD and matches the same with the original CNIC and copy of CNIC attached with advice/ voucher. Teller makes cash payment to customer. Teller posts the advice in system (through batch) and affix the “Posted” stamp. And forward to TSS/ BOM for supervision. Gives Credit to customer account: Designated Authorized Officer gives cre dit to customer account via transaction type “TFRC” Payment through clearing: CPU/ Clearing Officer receive FDD in clearing from NIFT and forward to branch for B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 191 FDD verification and advice preparation. Note: If transaction amount exceeds the Designated Aut horized Officer’s limit screen pop -ups “Authorization Required” message. Designated Authorized Officer forward voucher to next supervision level for system authorization. Financial impact only shown in GL after authorization Day end report generation: Designated Authorized Officer generates Day end reports and Validates the source documents/ Vouchers and arranges filing of the same and sign off. BOM/ TSS counter signs Designated Authorized Officer activity BOM/ TSS/ Forex Manager reviews vouchers and r econciles with report and counter sign off. 2.9 FCY DD PURCHASE – UNDER DOLLAR DRAWING ARRAN GEMENT Direct FIDD are inward remittances that are routed through foreign agent accounts, which exist in ‘Export Promotion Zone Branch’ (EPZ) under dollar drawing arrangements. Foreign Agent issue FDD on request of remitter who want to remit money from abroad to Pakistan. Moreover, the FIDD could be present in any branch whereby after cover conformation from EPZ branch the payment is made to beneficiary. FCY DD Purchase – Under Dollar Drawing Arrangement Forex officer (Branch) receives demand draft directly from foreign agents or beneficiary and update FIDD register. Forex officer (Branch) after verification of interbank signature prepares cover sheet, signs off and forwards it to Forex manager. Forex manager/BOM sign off the cover she et and return back it to Forex officer for onward sending it to EPZ branch. Forex officer (EPZ Br.) receives cover sheet from branch. Cover is checked from the agent account. Transaction is posted in the system as per cover sheet received fr om branch or e lse is escalated according to authorization matrix in case the financial transaction is beyond his limit. For detail Batch Processing, please refer to Section 7: 1.4 Transaction processing In GL Module Forex officer (EPZ Br.) prepares MT 202 and forward to Forex Manager for authorization and the same is transmitted to SWIFT Ops. COD Receives SWIFT messages from EPZ Branch, SWIFT Manager reviews and forwards hard copy of MT 202 and MT 950 to Fund Settlement Unit (FSU). After affixing “Cover Conformation” stamp, the MT 202 is forwarded to concern branch for payment of fund to the beneficiary against presented FIDD Branches on receipt of co vering from FSU, Updates the FDD Register and makes payment to the beneficiary in cash or transfer funds into the customer account. In -Case of Cash Payment, his / her proper verification is required. Beneficiary has to submit his / her valid CNIC (original ) or valid driving license (original) or passport (original) . For detail Batch Processing, please refer to Section 7: 1.4 Transaction processing In GL Module After payments to the customer, Forex officer prepares and sign Annexure XXI . After sign off from Forex manager, forwards it to test key Dept. Two tests are applied (Part A&B) on Annexure XXI by two officers. The same is forwarded to the Forex Dept for onward submission to treasury B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 192 2.10 PO/ DD ISSUANCE – SELL AGAINST HEAD OF FICE ADVISE BOM/ GBO: Receives Head office Approval letter/ email and HO Advice (if required) GBO i. Verifies Completeness and accuracy of the request. Highlights discrepancy if any ii. Verifies Test key iii. Verifies AS/ IBS # on HO Advice (if required) iv. Uses Branch Teller Module, selects Cheque Instruments > Transaction > Draft/Bank Cheque se ll menu to issue a PO/ DD . (Screen # BT 3291) v. Input Transaction type –POSI for PO and DDIS for DD, Cheque Type (PO or DD) and other mandatory information. vi. While issuing the P.O full description of beneficiary must be entered in the system. vii. Executes the transaction (If transaction amount exceeds the GBO’s limit, screen pop -ups “Authorization Required” message. TSS / BOM authorizes/approves the transaction. TSS / BOM After verifying details from Original Advice/ Advise, authorizes the same on the system (if required) by using BT> Override > Remote Override Screen # BT002020. System: (Branch Teller Module) i. Debit the respective GL head for the amount of PO/DD ii. Generates the PO/ DD GBO: i. Checks the printed PO/ DD against HO Advice/ Approval Letter ii. Sign off the same (1st Signature) iii. Forwards the PO/DD to the TSS / BOM for 2nd signature. TSS / BOM: i. Checks and sign off the same. (2nd signature) ii. In case of error in Payment Order, returns the same to the teller for re -issuance. In case of error in the Payment Order – GBO will: i. Select Transaction > Value Transactions > Reversal. (POA#) or (DDS #) ii. Input the required information. (e.g. Account No., Account Type, Client details, Date etc) iii. To reverse the transaction click and press the save button. As a result authorization window pops -up. iv. Keep cancelled Payment Orders in a separate file. v. Re-issue the Payment Order (Follow the complete Payment Order is suance process, discussed earlier). vi. Delivers the Payment Order to the beneficiary GBO/ BOM : GBO makes an Batch posting in the system against HO advice/advise for DD/PO issuance. For detail Batch Processing, please refer to Section 7: 1.4 Transaction processing In GL Module i. BOM verifies and authorizes the Batch ii. GBO f orward the advice to concerned branch (If drawn on other branch) GBO generates the RBA - 11 report from the system. Checks the report with the source document and gets sign off from TSS / BOM. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 193 2.11 REVALIDATION OF PAY ORDER / DEMAND DRAFT Since PO/ DD is payable within six months from the date of its issue, therefore, an instrument being older than six months require s revalidation before payment. Following procedure will be used: i. PO / DD should be presented to the Issuing branch for revalidation. ii. The signature on such letter should be duly verified. iii. Particulars of the PO / DD should be compared with those given in the Branch Teller Module. iv. A rubber stamp reading “Revalidated on ______ ” should be affixed on the PO / DD under signature of two authorized officers of the branch with IBS or AS Numbers. v. An intimation of revalidation should be sent to the drawee branch by authorized signatory giving his IBS/AS number. 2.12 CHANGE OF PAYEE’S NA ME i. Sometimes the purchaser of a dr aft approaches the Bank for the change of payee’s name. In such case it is advisable to cancel the previous draft and issue a new PO / DD. ii. For cancellation of a PO / DD, follow the procedure given under 2.14 Cancellation of Demand Draft and 2.15 Cancellation of Pay Order 2.13 ISSUANCE OF DUPLICAT E PAY ORDER / DEMAND DRAFT In case p urchaser of a PO / DD informs that the draft has been lost or misplaced and requests for issuance of a duplicate demand draft. The followi ng Procedure should be followed: i. Written Application : Such applications should be made to the issuing branch by the purchaser in writing duly signed by him/her, explaining the circumstances of the loss. ii. The signature of the purchaser should be verified from his signature on the original Funds Transfer Applic ation. iii. If the purchaser has signed the PO / DD application form on behalf of some other person / organization, the signature of such other person / authorized officials of Organization should also be obtained on the letter of instruction in respect of issu ance of Duplicate PO / DD. iv. For PO, issuing branch will verify from system and ensure that the PO in quest ion is still outstanding unpaid and mark Stop Payment in the system from EOC >Deposit> Cheque Instruments > Administration > stop cheque capture/mainte nance v. For DD, issuing branch will verify that the DD in ques tion is still outstanding at Drawee Branch. Issuing branch will send an e -mail to the Drawee branch with instrument details specially DD leaf/stationary number (old). The Drawee branch will mark S top Payment in the system from EOC >Deposit> Cheque Instruments > Administration > stop cheque capture/maintenance (RB -1841) and will ensure to input old DD leaf/stationary number in the narration field. vi. An indemnity should then be obtained from the purchaser on CF -15 of required value. Charge Form CF - 15 duly completed in all respect will be kept in Safe Custody after recording in safe custody register. vii. There is a feature available in SYMBOLS to re -print the same PO / DD from the system and with the same/old number . Re-printing of a PO / DD can only be performed with supervisor’s override. On the re-printed PO / DD a stamp should be affixed on face of the duplicate PO / DD reading “Duplicate” issued in lieu of original number _______dated ____ Reported lost. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 194 viii. A note regarding issue of duplicate PO / DD is also given in the original PO / DD application form. Note: At the time of Payment of Duplicate DD, Drawee branch to ensure that the DD which is marked as ‘Stopped’ is not purchased and only Duplicate DD is purchased. 2.13.1 Presentation of original or duplicate PO / DD i. If original PO / DD is presented, after issue of duplicate but before payment of the duplicate, it should be returned unpaid with the remark / reason “reported lost, payment stopped by the drawer”. This remark should be written in “red ink” on the Instrument also. ii. If duplicat e is presented for payment, the same may be paid if otherwise in order. iii. If original PO / DD is presented after payment of duplicate, the same may be returned with the remarks, “Duplicate paid, original reported lost and payment stopped by the drawer”. 2.14 CANCELLATION OF DEMAND DRAFT The issuing branch should cancel the Instrument on the written request of the purchaser as per following procedure. Drawer/ DD Issuing Branch: i. Written Application: The purchaser should make the request in writing for cancellation of the Demand Draft. His signature on the letter should be verified from the original Funds Transfer Application (SF – 100 R). ii. If the purchaser has signed SF – 100R on behalf of some other pe rson / organization, the signature of such other person / authorized official of organization should also be obtained on the letter of instructions in respect of cancellation of DD iii. The original DD should accompany the request letter. iv. If the DD is in favor of a company, government or semi -government body / corporation etc., consent / clearance of the payee should be obtained in writing. v. It should be seen that there is no endorsement on face / back of the draft as the presence of endorsement shows the deliver y and negotiation of the DD. If there is some endorsement on the DD, it should not be cancelled. vi. If DD is found in order according to the above points, it should be cancelled at the issuing branch. vii. The signature of the officers on the cancelled DD should be torn and the same should be marked “Cancelled”. viii. The cancelled DD and customer request should be attached with the case. Remittance Officer prepares inter branch debit advice -SF 180 and send it to drawee branch The advice mentions that original DD is in the possession of drawer branch.. A copy of advice is sent to HO and copy is maintained at branch for record. Deposit slip is filled and cre dit is given to the customer. Cancellation charges are claimed as per Bank Schedule of Charges and DD is torn from signatures and marked as “CANCELLED”. Batch entry on the basis of SF -180 (HO debit advice) through EOC->General Ledger ->Transaction ->Batch Ma intenance ->Entry (GL -21) Debit: Head Office (Payable Branch) Credit: Funds Transfer Control Account Entry through deposit module EOC ->Deposits ->Transaction ->value transaction ->Deposit (RB -31) thorough B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 195 transaction type: THCR . Following auto entry will be generated Debit: Funds Transfer Control Account Credit: Customer account Manual entry (Being cancellation charges debited to customer’ account) Debit: Customer account Credit: 3060601210 -Remittance instrument Cancellation Charges Drawee/ DD Paying Branch: Remittance officer at drawee branch cancels the sold DD via BT> Financial Transactions> Single Transaction> Traveler's/ Banker’s Cheque> Cheque Buy and enter DDBI -Demand draft Buy Internal (DD Cancellation after EOD) The system checks whe ther the amount of the demand draft is within his authorized limits. The system automatically asks for an appropriate over ride to process the transaction. The officer chooses whether to generate a remote override or a local override. After approval of can cellation by Supervisor or Operations Manager depending on the limit, Entry will be made through DD purchase interface (EOC -Deposit - Cheque instruments -Transaction -Cheque buy RB 1836) through transaction type: DDBI. Following auto entry will be generated Debit: D emand Draft Payable Account Credit: Funds Transfer Control Account Entry through batch acceptance , on the basis of SF -180 (HO debit advice) received from Drawer branch/ DD issuing branch Debit: Funds Transfer Control Account Credit: Head Office (Drawer branch/ DD issuing branch) B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 196 2.15 CANCELLATION OF PAY ORDER The issuing branch should cancel the Instrument on the written request of the purchaser as per following procedure. Issuing Branch: i. Written Application: The purchaser should make the request in writing for cancellation of the Pay Order. His signature on the letter should be verified from the original Funds Transfer Application (SF – 100 R). ii. If the purchaser has signed SF – 100R on behalf of some other perso n / organization, the signature of such other person / authorized official of organization should also be obtained on the letter of instructions in respect of cancellation of PO iii. The original PO should accompany the request letter. iv. If the PO is in favor of a company, government or semi -government body / corporation etc., consent / clearance of the payee should be obtained in writing. v. It should be seen that there is no endorsement on face / back of the draft as the presence of endorsement shows the delivery a nd negotiation of the PO. If there is some endorsement on the PO, it should not be cancelled. vi. If PO is found in order according to the above points, it should be cancelled at the issuing branch. vii. The signature of the officers on the cancelled PO should be torn and the same should be marked “Cancelled”. viii. The cancelled PO and customer request should be attached with the case. ix. Cancellation charges will be recovered as per schedule of Bank Charges. Remittance officer cancels the sold PO via BT> Financial Transactions> Single Transaction> Traveler's/ Banker’s Cheque> Cheque Buy and enter POBC -Pay Order Transfer -Buy Cancel The system checks whether the amount of the pay order is within his authorized limits. The system automatically asks for an a ppropriate over ride to process the transaction. The teller chooses whether to generate a remote override or a local override. If remote override is sought then a popup screen opens at the relevant terminal asking for approval. The Local override requires the relevant officer to authorize the transaction at the teller terminal by inputting his ID and Password. After approval of cancellation by Supervisor or Operations Manager depending on the limit Recovers the cancellation charges according to SOBC from cu stomer account or via cash. Pay Order and application is be marked as cancelled and PO is torn from signatures and marked as “CANCELLED”. 2.16 PAYMENT OF CANCELLED PAY ORDER / DEMAND DRAFT (ISSUIN G BRANCH) i. On execution of Reversal option system will reverse the entries i.e. it will debit PO / DD account and credit the purchaser account. ii. For refunding the amount to the purchaser of a draft which has been lost, a duplicate will first be issued, on due complia nce of all the requirements discussed above. The duplicate PO / DD may then be cancelled as discussed above under ‘cancellation of PO / DD’ . B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 197 2.17 ISSUANCE OF CALL DEPOSIT R ECEIPT (CDR) Process Steps CSO delivers CDR Issuance form, SF -253 and assists customer in order to fill application. On receipt of application, scrutiny is done. GBO signs off the SF -253 after ensuring completeness and authenticity of information. TSS conducts customer’s signature ver ification from SS Card and affixes “Signature Verified “stamp and signs off GBO receives the cheque from customer for CDR amount and charges and ensures the following:  Name of the Customer /Requestor (person/company ) is mentioned correctly in the field “Received from” on the CDR .  Name of the Beneficiary is mentioned correctly in the field “on account of” on the CDR .  Date & amount are in order .  Cheque number is written on application form (SF -253) . SF- 253 along with the cheque is forwarded to TSS for final verification. On receipt of application and cheque, TSS verifies the customer’s signatures on the cheque. GBO posts the following entries in Deposit Module: Entry in RB module: Debit: Customer account Credit: Fund Transfer Control acco unt [1150101150] Entry in GL module Manual G.L Debit: Fund Transfer Control account [1150101150] Batch Entry : Credit Call Deposit [1030101030] Entry with CQW: Debit: Customer account Credit: Intra control account Manual G.L Debit: Intra Control Account Batch Entry : Credit Call Deposit [1030101030] “TRANSFER” along with “POSTED” stamp is affixed on the application. TSS will forward the manual batch to BOM for review and acceptance. GBO prepares the CDR and forwards to BOM and BM for review and sign off. BOM and BM reviews the CDR, mention their AS/IBS No. and sign off. CDR is handed over to customer and acknowledgement taken. GBO maintains record of the CDRs issued in a manual register which is weekly reviewed by the BOM B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 198 2.18 PAYMENT OF CALL DEPOSIT R ECEIPT (CDR) Process Steps Customer submits filled deposit slip along with CDR to GBO. GBO matches particulars of deposit slip with CDR, signs off, affixes stamp and handover a copy of deposit slip to the customer. GBO must affix branch cross stamp on the face of CDR in order to avoid any misuse. Important Notes:  Receipt is payable to beneficiary ONLY on Proper discharge through internal transfer/ clearing/ collection.  When the claim is made by the purchaser it must be insured that the receipt is duly endorsed by the beneficiary in favor of the purchaser. Payment of CDR through clearing incase tender is passed: The payment of CDR is routed through clearing incase the tender for which CDR was issued is passed. Payment of CDR through transfer back to account incase tender was refused: GBO receives the cancelled CDR, attaches SF -253 and makes the following entries for payment of CDR through THCR: Credit: Customer account Debit: Fund transfer control account Manual batch entry: Debit: CDR Credit: Fund transfer control account TSS/ BOM reviews and accepts the m anual batch. GBO records Payment date and Payment mode (Clearing or Transfer) in CDR manual register GBO generates CDR Statement which shows details of CDR such as payment and issue date. A GL report at day end is also generated which states all the entries. These reports are forwarded to BOM for review. BOM reviews the CDR statement and GL report. GBO maintains record of the CDRs issued in a manual register which is weekly reviewed by the BOM CDR Balancing: GBO enters No. of CDRs issued and their total amount in MS Excel Sheet. GBO weekly/monthly matches the figures from the MS Excel sheet maintained with him to the GL figures of CDR for balancing/reconciliation. In case of any difference, GBO takes a printout of the CDR MS Excel sheet and CDR GL Figures and resolves the discrepancy. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 199 2.19 LCY TELEGRAPHIC TRAN SFER Transfer of Funds from one br anch to another branch of the same Bank or upon other Bank under special arrangements for the payment to the Beneficiary through Telephone/ Fax is called a Telegraphic Transfer (TT). 2.19.1 Features: i. Telegraphic Transfer is not negotiable ii. The funds remitted by Telegraphic Transfer are not payable to bearer /order but only to the Payee . iii. Telegraphic Transfer (TT) of funds to a branch situated within the same city should not be affected. iv. Remittance can be made for credit of the account of the Payee/Beneficiary if m aintaining account with the drawee branch or may be paid in cash, subject to proper identification or may be collected by the payee through his banker according to instructions. Such instructions for payment are called “Advise and Pay”. 2.19.2 Participants of th e Telegraphic Remittance : i. Applicant: a person, firm, company, or local authority etc who wants to remit funds from one branch to another branch of other city. ii. Remitting or Drawing Branch : Which remits the funds on another branch iii. Drawee Branch: On which a TT is issued. iv. Beneficiary / Payee: The person named in the TT to whom the funds is payable. 2.19.3 General Guidelines: i. TTs instructions regarding payment are sent to the drawee branch telegraphically in a coded language and under confidential number known as “ Test Number”. Test number is the only source authenticating payment instructions of the TT. ii. Non account holders can only deal with the Bank , provided that CDD / KYC is carried out and attested copy of CNIC by branch manager is obtained from the non accoun t holder if the amount is up to PKR 500,000. For amounts exceeding this threshold requires obtaining the duly filled Walk -in Customer Information Form (WICIF) and must be kept with the vouchers. In the case of requests for multiple cash remittance transact ions by the same non -account holder, enquiries should be made to assess whether there are reasons to suspect criminal activity. Any suspicions should be reported promptly as required in CDD/KYC and AML Procedures Hand Book Revised Version 2009 - 5.5.3. 2.19.4 Custody of Test Keys: In order to strengthen the internal controls on the financial transactions, branches are required to adhere to the followings: i. The Branch Operations Manager must maintain a definite segregation between custodian -ship of Test - keys (Par t 1 & 2). No one person should have custody of both tables at any given time. ii. Also the test custodian must not be involved in preparation/origination, responding or input of inter - branch financial transactions or remittance. iii. Both parts should be kept sepa rately with the designated Test Key Custodians in the Fire Proof Cabinets. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 200 2.19.5 Acceptance of Funds Transfer application For TT Issuance: SF-100R should be duly checked. (Applicant and Beneficiary details must be Complete in all respects). Instructions regarding mode of payment should be obtained i.e. whether the amount of TT is to be credited to the Payee’s Account or the Beneficiary should be advised to receive the amount of TT from a drawee branch either in cash on proper identification or through his Banker (it will be an advice and pay instructions). i. FTA (SF -100R) has been signed by the applicant and authorized officials/officers of the branch as per passing and signing schedule. ii. Before preparing a TT message for the drawee branch it should be confirmed that the cash along with charges, where applicable, have been received, Cash Received Stamp has been affixed on the FTA (SF - 100R), whic h has the signatures of Authorized Officer. iii. In case of transfer entry it should be seen that the customer’s account has been debited with the amount of a TT /other charges and SF -100R is duly signed by the Authorized Officer. 2.19.6 Preparation of TT Outward M essages: i. A record in Remittance Outward Register (SB -17) should be maintained for all TTs separately branch - wise. ii. The Serial Number in the Out -ward Remittance Register represents the Remittance Number. “Remittance Number” for each drawee branch should st art with number “One” from 1 st January each year. iii. All TT remittances should be controlled at issuing and paying branches by the above Remittance Number in addition to the Telegram out -ward number (TT number). 2.19.7 Maintenance of TT Register: Besides maintai ning an Outward Remittance Register, a Telegram Dispatch Register (SB -86) is also maintained to allot the Telegram Outward Serial Number to the telegraphic remittance drawn on a particular branch. i. A separate folio (Page) is allotted for each drawee branch and an alphabetical index is accordingly prepared in the beginning of the Register. ii. A separate serial number is allotted to a Telegraphic Remittance for each drawee branch. While making the necessary entries in the Telegram Dispatch Register (SB -86) following points should be kept in mind: i. The entries in the Telegram Dispatch Register should be made on the proper folio i.e. on the folio allocated to a particular branch. ii. A copy of the message should be written in the register. iii. The entries in Telegram Dispatch Register are serially numbered i.e. the first message issued on a particular branch should be given serial number “1” and the next serial number “2”. After “100” messages have been issued, the serial number should again sta rt with number “1”. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 201 2.19.8 Preparation of a TT Message on TT Dispatch Form (SF -119) : While preparing a TT message, the folio allotted to drawee branch in Outward Remittance Register (SB -17) & TT Dispatch Register (SB -86) should be referred to allot the “Ser ial Number of Telegram” and “Remittance Number “respectively. After making the entries in both the Registers, TT should be prepared on Telegram Dispatch Form (SF -119) according to the particulars mentioned on FTA. Sequence of Contents of the Message on SF-119: i. Name of Drawee Branch with Branch code. ii. Date iii. Serial Number of the Telegram. iv. Remittance Number (R). v. The Instructions Regarding Mode of Payment. (Credit / Advise & Pay) vi. The Amount. vii. Name and A/c Number of Beneficiary viii. Two authorize officers apply Test on SF -119. Accounting Entries : Dr: Customer’s account/ Cash Cr: Principal Office A/C. Drawee Branch Cr: Income A/C. Commission on TT. Cr: Income A/C. Telephone/ Fax charges Cr: Tax Deducted on TT etc. For detail Batch Processing, please refer to Section 7: 1.4 Transaction processing In GL Module 2.19.9 Handling of TT AT Paying Branch: A TT Payable Register (SB -90) should be maintained at the drawee branch. A separate folio should be allotted for every TT issuing branch in TT Payable Register and an index should be prepared in the beginning showing folio number allotted to branches. The Authorized Officers/Test Keys holders check the Test Number from the Test Key, which must agree with, the test number mentioned in the TT. At the time of entry/posting full particulars of the remittance shou ld be entered in this register/ System. i. Remittance Serial Number of issuing branch. ii. Date of entry of TT. iii. Date of issue of TT i.e. Date of the Telegraphic Message appearing on the telegram. iv. Telegram Number allotted by the drawer branch. v. Name of the Bene ficiary and Account Number. vi. Amount. vii. Initials of the authorized officer verifying/authenticating the entry. viii. Initials of the processing officer. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 202 Accounting Entries: For the Crediting Customer’s Account: Transfer Vouchers Dr: Principal Office Account of issuing branch (SF -9) Cr: TT Payable Account (SF -10) Dr: TT Payable Account (SF -9) Cr: Beneficiary/Customers Account (SF -10) In case of Advise and Pay Instructions Transfer Vouchers Dr: Principal Office Account of Issuing Branch (SF -9) Cr: TT Payable Account. (SF -10) On presentation of CNIC Dr: TT Payable Account. Cr: Cash For detail Batch Processing, please refer to Section 7: 1.4 Transaction processing In GL Module 2.19.10 Payment of TT at Paying Branch via Clearing: i. Before making payment of TT in clearing it should be thoroughly scrutinized and ensured that: TT paying receipt pertains to the payee branch. Original portion of the TT Payment Receipt ( SF-6A24) should be duly discharged by the payee on revenue stamp of adequate value and the copy should bear signatures without revenue stamp. ii. Collecting Bank’s endorsement is regular. iii. The date of payment should be marked in the TT Payable Register and processing officer should sign the slip after verifying the particulars from the TT payable register. The processing officer should adhe re to the signing and passing schedule of branch approved by the competent authority. iv. In case of entry in TT Payable remains outstanding the payee should be reminded v. The applicant of a telegraphic transfer may approach the issuing branch for cancellation of T.T remitted by him. The written instructions of the applicant may be accepted provisionally, if the amount of the TT has not been credited / paid or advised to the beneficiary. 2.19.11 Cancell ation of a TT: At Issuing Branch i. Application in Writing The appl icant of the TT should apply in writing for its cancellation. ii. Verification of Signatures The signatures of the applicant on letter of instructions should be verified from the original TT application form (SF -100R). B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 203 If the purchaser has signed the TT appli cation form on behalf of some / organization, the signature of such other person / authorized official of organization should also be obtained on the letter of instruction in respect of cancellation of TT. iii. Recovery of Fax Charges The intimation to the dra wee branch should be sent through a Fax. The cost of Fax should be recovered from the applicant and be credited to Telegram / Telex Charges Recovered Account. iv. Intimation to the Drawee Branch The drawee branch should be communicated telegraphically to canc el the TT if not already credited or paid to the payee or has not been advised to the beneficiary to receive amount of TT. Such telegram should invariably be sent coded and tested. v. Filing of Letter of Instruction The letter of instructions from the appli cant should be attached with TT application form SF -100R of that date. Action at Drawee Branch i. Verification of Test Number On receipt of TT advice from the issuing branch the drawee branch should verify the test number, If found correct the Manager/Officer holding Test Keys should certify the TT advice with the word “Test Correct”. ii. Verification from TT Payable Register The Remittances Department s hould refer the TT payable register to confirm whether TT is still outstanding. In case the TT has already been paid no action will be taken and the issuing branch should be informed accordingly. If the said TT is outstanding and the beneficiary has not be en advised to receive the amount of the TT, it should be accordingly cancelled and a note to this effect should be made in TT payable register and other relative record. iii. Preparation of Vouchers at Drawee Branch  After noting the cancellation instruction in the TT payable register, TT payable account should be debited with the amou nt of TT cancelled and Principal Office Account of the issuing branch should be credited. The Voucher should be entered in the vouchers sheet accordingly.  An Advice on SF -179 shou ld be prepared for crediting H.O. Account of the issuing branch giving full details of TT quoting the authority of the issuing branch regarding cancellation.  A set of three copies of credit advice SF -179 should be prepared. Original should be sent to the issuing branch. 2 nd copy should be used as H.O. Account credit voucher and third copy should be used as a debit voucher of TT Payable Account. iv. Intimation to the Issuing Branch by the Drawee Branch The drawee branch should send intimation to the issuing br anch via fax / telephone regarding cancellation of TT as well confirmation that the beneficiary has not been advised to receive the amount of the TT v. Verification of Test Number The issuing branch on receipt of TT advice from the drawee branch should veri fy the test number. It should be seen that the drawee has clearly confirmed that the TT was still B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 204 outstanding with them and has been cancelled as the beneficiary has not been advised to receive the amount of the TT. vi. Payment at Issuing Branch  On receipt of the Credit Advice in respect of TT from the drawee branch, the amount of TT should be refunded to the applicant by crediting his account, or in cash on proper identification or a Pay Order should be issued in favor of applicant to the debit of Principal Office Account.  The payment procedure in cash or transfer should be the same as in case of cancelled Demand Draft. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 205 Chapter 3 FOREIGN WIRE TRANSFE R Processing of Inward & Outward Foreign Currency Wire transfers for all branches across the country (except TSCs for t rade related Outward Remittances) is centralized with ‘Centralized Operations Division – (COD) ’ and being performed from its Centralized Processing Unit (CPU) established at Karachi . 3.1 FOREIGN WIRE TRANSFE R – INWARD While processing the Inward Foreign Currency Wire transf ers from a centralized location, CPU has to refer each case to the concerned branch to obtain the required information, authentication, approval or document before processing the remittance: 3.1.1 For following reasons CPU has to refer the ca se to concerned branch: i. Beneficiary Account number given in remittance details is incomplete. Beneficiary account number and title of account given in remittance details differ. Beneficiary’s account not traceable. Ordering Customer details missing or inc omplete. Beneficiary’s account is on ‘Dormant’ or ‘Inoperative’ status or closed account etc. Purpose of incoming remittance (for Foreign Currency Accounts) is of COMMERCIAL nature. Purpose of remittance differ within the incoming remittance message MT -103 (Field 70 vs. information provided in payment details) or against Form ‘R’ provided by the beneficiary. ii. If purpose of incoming remittance for individual account is “Business Investment” following documents are required from customer:  Form ‘R’ showing bene ficiary’s ‘NTN’ number duly verified by an authorized officer of the bank.  A written declaration advising the bank where the funds are going to be invested and signature verified by the branch manager will be sent to CPU. Branch on Beneficiary’s Request 3.1.2 Return of Funds i. If the beneficiary of the remittance wishes to return the funds to the remitter, concerned branch is required to take an application from the beneficiary authorizing the bank to return the funds. The customer application duly approved will keep a copy of customer request for their record. 3.1.3 Information provided by CPU to branches i. After executing the Inward Foreign Currency payments, CPU will provide the following information/documents to branches at end of day: ii. Credit Advice (PDF file through e-mail) for onward submission to customer. iii. With Holding Tax Certificates (where applicable): Original WHT Certificate will be dispatched to branches under proper acknowledgment for onward delivery to customer. iv. Proceeds Realization Certificates (PRC) where the purpose of remittance is of ‘commercial’ nature. PRC can also be issued against Home Remittance and Salary Remittance on branch request on case to case basis. v. Original PRC will be dispatched to branches under proper acknowledgment for onward delivery to customer. In case original PRC is lost by the customer ‘duplicate’ PRC’ will not be issued without FIR of its loss and SBP approval is submitted by the concerned branch. 3.1.4 Reporting i. Submission of W.H.T. to Government Authorities : Concerned branches will be responsible for submission of Withholding Tax to concerned authorities. (For this purpose, CPU provides break up of WHT deducted and parked in respective GL of the branch on daily basis through ‘daily transaction report’). B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 206 ii. Monthly Reporting to SBP : Mon thly reporting to SBP will be done at branch end by 3rd of each month as per SBP guidelines. iii. CPU will provide all Inward Wire transfer details and related MIS on PDF file on 25th of each month and on last working day of each month (for the remaining days) to concerned branches through e -mail. On receipt of details branches should ensure that ITRS system is updated at their end before 3rd of each month. 3.2 PROCEDURE FOR FOREIG N WIRE TRANSFER – INWARD Funds Settlement Unit Receives SWIFT Messages/Intimation (MT 103 & 202) for the day for branches. Scrutinize the hard copies of payment instructions and: Sort payments by branch & by value date i.e. same day value or future value. Mention mode of payment i.e. credit to FCY account, PKR account, Back -to-back etc. i. Check cover confirmation for same day value payments i.e. receipt of funds in our Nostro Account through MT 940/950. ii. Hold future value payments until receipt of cover. Remittance Unit Receive payment messages for the day through e -mail with attachments (the attached files are password protected). Receives hard copies of payments (MT103 & 202) from Funds Settlement Unit confirming the following: i. Receipt of funds in Nostro Account. ii. Agent code (Remitting bank). iii. Beneficiary br anch code. iv. Upload the soft file of payments for the day on Wire Transfer System (WTS). v. Generate the list and cross check its correctness. WTS system genera tes e -mail to concerned branches providing details of payments received with a request to confirm: i. Beneficiary details (complete account number and title of account. ii. Purpose of remittance and; iii. Special exchange rate (if payment amount exceeds USD10,000) Re-direct the payments pertaining to TSCs, Treasury & FI through Funds Settlement Unit (FSU) with remark “No entry is passed by CPU” for processing at their end. Branches i. Retrieve the CPU e -mail of the ‘daily inward wire transfer details’ and revert back to CPU confirming:  Complete account number & title of account  Purpose of remittance  Other (refer to Section 3: 3.1 Foreign Wire Transfer – Inward ) ii. Reporting of FCY deposits to circle office is the responsibility of concerned branch. Centralized Processing Unit On receipt of confirmation from branches CPU will execute/process the Inward FCY wire transfers at their end and will advise the branches accordingly. (Detailed process is defined in “Inward FCY Remittance User Manual” of Centralized Processing Unit. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 207 3.3 FOREIGN WIRE TRANSFE R – OUTWARD All SMBOLS branches will forward customer instructions for Outward Foreign Currency Wire transfer (except TSCs for trade related Outward Remittances) on prescribed form (FTT or SF -100R) along with copy of customer’s CNIC, necessary documents and SBP approv al to Centralized Processing Unit (CPU) latest by 12:30 P.M (exceptions may be allowed on case to case basis) 3.3.1 Execution of Outward FCY Wire Transfer by CPU: Centralized Processing Unit (CPU) on receipt of Outward Foreign Currency Wire transfer requests and its subsequent confirmation from the concerned branch will execute the remittance same day (if all the requirements are met and required approval/documents are provided). 3.3.2 Information provide d to Branches by CPU: After executing the Outward Foreign Curren cy Wire transfers CPU will provide the following to branches on the next working day: i. Debit Advice : Debit Advices (in PDF file through e -mail) for onward submission to customer. ii. Acknowledgement of MT 103 : Swift acknowledgement of the outward remittance. 3.3.3 Reporting: i. Submission of W.H.T Tax to Government Authorities : Concerned branches will be responsible for submission of Withholding Tax to concerned authorities (For this purpose, CPU provides break up of WHT deducted and parked in respective GL of the bran ch on daily basis through ‘daily transaction report’). ii. Monthly Reporting to SBP : Monthly reporting to SBP will be done at branch end by 3rd of each month as per SBP guidelines. iii. CPU will provide all Outward Wire transfer details and related MIS on PDF file on 25th of each month and on last working day of each month (for the remaining days) to concerned branches through e -mail. On receipt of details branches should ensure that ITRS system is updated at their end before 3rd of each month. 3.3.4 Handling of Queries & Beneficiary Bank Charges: i. Beneficiary claim for non -receipt of funds : Concerned branch, upon customer's intimation, will inform CPU regarding non -receipt of funds to the beneficiary via e -mail along with required details. CPU will take up the case with correspondent bank and will get confirmation of payment of funds. Upon receipt of response CPU will update the concerned branch accordingly. ii. Return of Funds : CPU will inform the concerned branch if the funds of Outward FCY Wire transfer are returned by the beneficiary bank. Concerned branch will get in touch with the customer and provide customer’s written request to CPU of the course of action – either re -effect the Outward Wire transfer or credit customer account. iii. Additional information required by Benefi ciary Bank : To comply with AML policy, Beneficiary Bank may request for additional information of the remitter related to the Outward Wire transfer. It will be the branch responsibility to provide the required information enabling the Beneficiary Bank to process the payment. iv. Beneficiary Bank Charges (Against “OUR’): On receipt of debit in our Nostro Account for beneficiary bank’s charges related to outward wire transfer, branch will recover the same from customer and respond the entry in Nostro Account. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 208 3.4 PROCEDURE FOR FOREIGN WIRE TRANSFER – OUTWARD Customer presents duly completed Remittance Application (SF -100R) along with required documents/approval to the Officer Remittance Department. Branch : Receives the application & affix the receiving stamp with date and time. i. Verify customer signature on customer application, affix branch stamp mentioning IBS/AS number & sign off the application: ii. Customer signature will be verified by an Authorized delegated Officer if the equival ent of wire transfer amount is up to USD 10,000 or less. iii. Customer signature will be verified by Branch Manager (BOM in absence of BM) if the equivalent of wire transfer amount is greater than USD10,000 Scrutinizes the application and performs the following tasks: i. Ensure compliance of KYC requirements/limits (DR/CR limits). In case of breach obtain new KYC form and get it signed by Branch Manager. ii. Update the new limits on the system (EOC) before the stip ulate d cut off time. iii. Ensure availability of funds in customer account. iv. Ensure that customer signature (SS Card) is tagged on EOC with the account on the system. v. In case of joint account, confirm operating instructions. In case of attorney instruction ( SF-6A27) for operating the account get a copy of authority letter from record (for submission to CPU) or tag the SSC of the attorney in EOC vi. Ensure following information is available on the application:  Beneficiary bank SWIFT code.  Bank charges on account of ‘B EN’ or ‘OUR’  Sort code (for remittance intended for UK).  Routing number (for remittance intended for USA).  Transit number (for remittance intended for Canada).  BSB number (for remittance intended for Australia).  Invoices in case of purchase of goods. vii. In ca se the wi re transfer equivalent to US$ 5 ,000 (subject to Treasury daily rate sheet) and is being made with SBP approval against PKR account OR Cross Currency, special rate will be obtained from Treas ury and will be notified to CPU within stipulated cut off time viii. Recover ‘cash handling charges’ from customer as per SOBC (in case wire transfer is against cash deposit in foreign currency account) ix. In cases where the wire transfer request is submitted by a person other than the account holder himself, branch is r equired to get ‘call back confirmation’ (CBC) from the customer. A notation to this effect must be made on the application and signed off by Operations Manager. x. Obtain branch manager approval on the application for execution of Outward Wire transfer. xi. Forwa rd Outward Foreign Currency Remittance application to Centralized Processing Unit (CPU) via e -mail with scanned copies of related documents or through Fax latest by 12:30PM  Remittance application (SF100R) duly signature verified and approved (as mention above).  Form ‘M’ (in case remittance is covered under SBP prior approval category).  SBP approval (for remittances against PKR account). B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 209 3.4 PROCEDURE FOR FOREIGN WIRE TRANSFER – OUTWARD  Invoice(s) in case of purchase of goods.  Copy of customer’s CNIC.  Other relevant documents. Note : Ensure that ‘original set’ of application/documents is forwarded to CPU on the same day. Centralized processing Unit (CPU) : On receipt of branch request for Outward Foreign Currency Remittance through e -mail or Fax will: i. Scrutinize the contents of remittance application and r elated documents for completeness. ii. To mitigate the risk involved in executing the remittance based on e -mail or fax, CPU will re -confirm the details of the remittance (Currency, Amount, Beneficiary Name & Account Number, Beneficiary Bank Name etc.) from th e concerned branch through e -mail. iii. GM's approval is required for High Value Transaction (PKR 5 Million and above) Branch : Branch Manager / Operation Manager will confirm back the genuineness of the request & correctness of the details provided to CPU through e -mail and will also ensure that the ‘originals’ are forwarded to CPU. Centralized Processing Unit (CPU) : On receipt of confirmation from the branch will: i. Process the request and execute the Outward Foreign Currency Wire transfer. ii. Recover the cha rges from the customer as per bank’s schedule of charges. The user is required to refer to the SBP Foreign Exchange Manual for any detailed descriptive information. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 210 Chapter 4 RUPEE TRAVELERS CHEQUES (RTC) 4.1 INTRODUCTION MCB Rupee Travelers Cheques is the best and safest alternate way of carrying cash. It is useful for travelers, businessmen and general public alike in meeting their day to day cash requirements during travel. RTC is safest because the purchaser has the sense of security that should the cheque be lost, he would get a refund easily. It is best because unlike other modes of transfer of Fund/Remittance which are drawn on a particular branch and could be encashed only at that Branch, while MCB Rupee Travelers Cheques can be encashed at any of our Bran ches across the country. 4.2 DENOMINATION MCB Rupee Travelers Cheques have been issued in the following denominations: Series Denomination in Figure Denomination in Word B PKR 1000/ - Rupees One Thousand K PKR 5,000/ - Rupees Five Thousand W PKR 10,000/ - Rupees Ten Thousand The special security features are explained here under: MCB Water Mark: Special paper that has been used for printing bears MCB logo watermark which is incorporated at the time of manufacturing of paper and is next to impossible for any adventurer with false intentions to counterfeit. Intaglio Print: Signature of the Chairm an, lower bottom border and denomination button are embossed and can be felt by running finger on it Extra Small Print (E.S.P): The horizontal signature, date and payee lines are printed in E.S.P. The E.S.P reads MCB Bank Limited and could be clearly read with the help of a magnifying glass. Hidden MCB Logo: MCB logo above the denomination button glows under the UV light. Serial No Bleeding Ink To protect RTC from threat of tampering serial number has been printed in Bleeding Ink. This is much more secured, as it cannot be removed without making a hole in RTC paper. The impression of Bleeding Ink can be seen on the reverse of RTC. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 211 4.3 COMMISSION / TAXES Commission: Branches will recover commission on sale of MCB Rupee Travelers Cheque as per tariff (SOBC) approved by the bank from time to time. Taxes: Branches will recover Govt. Taxes on sale from the Purchaser of the MCB Rupee Travelers Cheque if applicable as per existing law. 4.4 RTC STOCK AND REPLEN ISHMENT Branches will receive stocks of Rupee Travelers Cheques through their respective centers established at various Circles and Regional Offices. Branches which are not affiliated with any RTC Centre would receive th e required stocks from RTC Division P.O. The stock of RTC will be kept under joint custody/control of the authorized officer of Circle/Regional Offices and Officer -Incharge of the Centre. The Officer -Incharge of the Centre will also perform his usual dutie s at Circle/Regional Office. The concerned staff will be responsible for weekly balancing of RTC stock in hand. 4.4.1 RTC Stock and Replenishment - Branches i. Branches will submit their RTC requirement through their concerned Regional/Circle Office to RTC Divisio n, Principal Office. The requirement will be scrutinized by the Division and concerned Centre will be advised to issue approved quantity of RTC’s to Branch. The requisition for supply of stock will be routed through Regional Office on prescribed requisitio n form s available at branches . Request will be approved by GM/RM/ROM and the request will be approved by GM/RM/ROM or his/her designated officer mentioning his/her IBS/AS number thereon. ii. The authorized representative of the Branch preferably a senior officer will approach the Centre with an authority letter from the Branch to collect RTC. Signature of the representative will be attested by the Branch Manager/BOM with their IBS/AS. iii. The Centre, after verifying the signature of Branch Manager/BOM from AS/ IBS signature book, will issue Delivery Challan for the amount of RTC approved by RTC Division. The Delivery Challan (RTC -50) consist of 4 copies marked A, B, C & D. Copies A and B will be handed over by Centre to authorized representative of the Branch, a long with stock of RTC. iv. Banks Authorized Officers on receipt of stock through their representative will immediately physically count the cheques and will ensure that the stock received matches with the details given on Delivery Challan. After being satisfi ed with the correctness of the stock received, Copy B of Delivery Challan which is the acknowledgment copy will be forwarded to RTC Centre immediately through courier service/FAX, duly signed by Branch Manager or GBO holding signing power, with copy endors ed to RTC Division. The GBO will immediately enter the stock in Stock Register RTC 60 and BOM will counter sign it. RTC stocks will be kept in safe in dual custody of BOM and GBO. Copy “A” will be retained for record/Audit trail. v. If, for any reason, the re presentative deputed to collect RTC does not report back to the concerned Branch on the scheduled day and time, inquiry must be made about his whereabouts and necessary action must be taken immediately including report to Rupee Travelers Cheque Division, i f something goes wrong. vi. After physical receipt of stock, branch designated officer will inform RTC Division (RTC Operations Department) immediately or very next day through email at rtcops@mcb.com.pk or B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 212 mcb5440@mcb.com.pk , or fax in the following manner: Email / Fax Subject: RTC Stock Received on [Date] Email Body: Instrument Number Range: [From] - [To] Quantity: Denomination Branch Name: Branch Code: vii. After receipt of e -mail, RTC Division will distribute the ‘RTC series’ on Symbols EOC system. viii. RTC Division will intimate the branches after entering the series in the system through e -mail. After completion of the said process the branches will start chequ e re-assignment. ix. The Branch Manager is authorized to allocate ‘RTC series’ in the system by accessing Deposit Menu > Cheque Instrument > Cheque Re -assignment > and using assigned Password and following the steps as indicated in the displayed screens. BOM c an re-assign cheques to teller s/ GBOs who ever is authorized to sell RTCs at any given point. x. In-put the following fields for cheque re -assignment are: Cheque Type: RTN Currency: PKR From Officer ID : Enter previous tellers Symbols EOC ID To Officer ID: Enter current tellers Symbols EOC ID Denomination: 10,000 Prefix: Press F -9 Key Start No.: Initial RTC Number Quantity: Total Number of RTC End No.: Automatically appearing xi. Liability Entries for the stock of Cheques held by the branches. The follow ing Man ual and Auto entries are passed: Manual Entry: Debit: Stock of Security Customer Liability (2110101160) Credit: Stock of Security banks (1130101220) Auto Entry: Debit: Cheques Distribution (Off Balance) (5010101010) Credit: Cheques Distribution (Off Balance) (5010101020) xii. RTC centers will ensure that sufficient stock of RTCs is always remains with them. The Hub/TC Division will replenish the stock according to Sales/Supply position of each Centre. xiii. ROM should also check physical stock of RTC in hand on their visits to branches. 4.4.2 RTC Stock and Replenishment - Hubs i. For requisition/replenishment of stock from RTC Division Principle Office, the Hub will fax letter of authority signed by General Manager himself or in his absence by the next executive deputizing for him. ii. After scrutiny of stocks required RTC Division will dispatch through approved courier the stocks kept in B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 213 a cotton bag and sealed with plastic tag bearing serial number along with delivery Challan. An intimation of dispatch will be faxe d which contains the courier receipt number, the weight of consignment, date & time and seal number. iii. Upon receipt of stocks consignment representative of HUB will immediately check the seal and weight of consignment. He will also check the seal of each box containing cheques. After satisfaction, he signs of the courier delivery slip and will immediately fax the signed copy of delivery Challan to RTC Division, an intimation of receipt of stocks should be sent to RTC Division. iv. On arrival of stocks at the Hub the Stock will be physically counted immediately by Incharge and entered in Stock Register RTC 60. Stock must be checked and kept under dual control at Hub. Any discrepancy in Stock or delay in arrival of courier must immediately be brought to the notice of RTC Division. v. Hubs will ensure that sufficient/adequate stock always remains with them. vi. At the end of each day, each Hub will Fax the total supply of RTC’s among Centers/Branches to RTC Division on RTC -60 giving denomination wise details and will also s end original statement along with copy C of Delivery Challan by Courier Service on the same day, without fail. 4.4.3 RTC Stock and Replenishment Centre If centers feel that stocks requisition from the assigned HUB is expensive and time consuming they may send r equest to RTC Division as described in (i) & (ii) above. The same procedure will be followed as detailed in HUB Stock replenishment. i. Centers will submit their RTC requirement to RTC Division, Principal Office on the prescribed Performa (Sample attached at the end of the manual). The requirement will be scrutinized by the Division. The concerned Hub will be advised to issue approved quantity of RTCs to Centre. ii. The authorized representative of the Centre preferably a senior officer will approach the Hub with an authority letter to collect RTC. Signature of the representative will be attested by authorized officer with his/her AS/IBS iii. The Hub, after verifying the signature from AS/IBS signature book, will issue Delivery Challan for the amount of RTC Approved by RTC Division. The Delivery Challan (RTC -50) consist of 4 copies marked A, B, C & D. Copies A and B will be handed over by Hub to Authorized representative of the Centre along with stock of RTC. Copy C and D are retained by RTC division for stock issuance a nd audit trail purposes. iv. Centre on receipt of stock through their representative, will immediately physically count the cheques and will ensure that the stock received matches with the details given on Delivery Challan. After being satisfied with correctne ss of the stock received, Copy B of Delivery Challan which is the acknowledgment copy will be forwarded to Hub immediately through Courier Service, duly signed by Senior Official holding signing power, with copy endorsed to RTC Division. The Incharge will immediately enter the stock in Stock Register RTC -60. v. If, for any reason, the representative deputed to collect RTC does not report back to the concerned Centre on the scheduled day and time, enquiry must be made about his whereabouts and necessary action must be taken immediately including report to Rupee Travelers Cheque Division, if something goes wrong. vi. At the end of the day, each Centre will Fax the total supply of RTC’s among designated branches to RTC Division, Karachi on RTC -60 giving denomination w ise details and will also send Original Statement along with Copy C of Delivery Challan by Courier Service on the same day, without fail. vii. RTC Centers will ensure that sufficient/adequate stock always remains with them. viii. Karachi Branches will be delivered R upee Travelers Cheques direct from Rupee Travelers Cheque Division, following the same procedure as outlined for supply of RTC to RTC Centers. ix. ROM should also check physical stock of RTC in hand on their visits to branches. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 214 4.5 RTC SALE PROCEDURE i. Customer wi ll approach branch counter at any of our Branches Authorized in Sale and Purchase of Rupee Travelers Cheque and inform the Incharge/General Banking Officer (GBO) about his requirement of RTC in terms of Amount as well as denomination. ii. The RTC Counter Incha rge/GBO will get a set of Sale receipt (RTC 10) comprising 03 copies (A, B and C) filled/signed by the purchaser. iii. The Purchaser will write his name and address, CNIC /Account number at the upper left portion, quantity, denomination and Amount of RTC required to be purchased at upper right side and put his signature at the lower middle portion of each copy of Sale Receipt RTC -10, A, B and C separately. iv. Customer facing any difficulty in filling the RTC 10 will be assisted by the staff of the Branch. v. After filling RTC 10, the customer will hand it over to the Teller . RTC Incharge/General Banking Officer (GBO) will check and ensure that all the relevant columns have been filled up correctly. He will fill the remaining columns in the RTC 10 like Branch nam e, Branch code; Serial number of RTC’s issued. The total amount of Travelers Cheques sold the amount of commissions, amount of Tax, if applicable, will be computed and written in the cage provided in the Form. If purchaser is a walk in customer, KYC docume ntation may also be completed. Non account holders can only deal with the Bank provided CDD / KYC is carried out and attested copy of CNIC by branch manager is obtained from the non account holder if the amount is up to PKR 500,000 and marked as original s een. And for amounts exceeding this threshold requires obtaining the filled -in Walk -in- Customer Information Form (WICIF) along with CNIC’s attested copy marked as ‘original seen’ and must be kept with the vouchers. NTN Number may also be obtained. For non account holder customer signature on RTC -10 must be matched with signature on CNIC and for account holder signature verification from SS card must be done. vi. After completion of RTC 10, Purchaser will be asked to pay the cost of RTC. In case the customer wi shes to deposit the cost in cash, RTC 10 Form duly complete, will be handed over to him to deposit cash at cash counter. If the Customer wants to pay the cost by debit to his account, he will give a cheque for total cost of cheque in favor of MCB. vii. On pres entation of RTC 10 at cash counter the teller will receive the cash as per his authorized limit & record in SF -14 sheet as mentioned in the forms and will put “cash received” stamp on all the copies. After this the teller will sign the vouchers and send th e same to the TSS/ BOM for 2nd signature. After signature of the officer, Teller will retain Copy B of RTC 10 with himself and return Copy A and C to RTC issuance officer (RTC Incharge). Transactions beyond the authorized limit of the teller/GBO will be signed by Branch Manager/BOM/Teller. viii. If payment is made by debit to customer’s account, RTC 10 along with cheque or voucher raising debit to customer account will be sent to the GBO. The GBO will get the Cheque/Voucher posted in the respective account, if i t is in order, and after posting/passing of the cheque/voucher, will put Transfer Rubber Stamp on all copies of RTC 10 as well as on cheques/vouchers. He will Counter -sign the RTC 10 at the specified place and will return all Copies of RTC 10/cheque/vouche r to RTC Counter/Department. Account Number will be written in RTC 10, below the column “received cash/by cheque”. ix. GBO & BOM (Dual Custody) on receipt of the above request will draw required number of RTC as mentioned on RTC 10 from the stock making sure t hat these are drawn in order of serial. The numbers drawn/issued will be noted in Stock Register (RTC -60). The GBO mentions detail of RTC in register (RTC - 60) and counter sign in column. will check and verify that stock of RTC drawn for issuance has been posted correctly in Sale Register (RTC -60). BOM countersign the register. The entire process of Checking/Posting of RTC will also be supervised by Branch Operations Manager or Senior Officer authorized by Branch Manager. x. After recounting, re -checking the dr awn stock, in respect of quantity, series, denomination and amount, a responsible Officer/Staff of the Branch will affix Rubber Stamp supplied by Principal Office or prepared B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 215 by Branch itself as per design/sample/size approved by Principal Office at the Ba ck of each RTC. It will thereafter be signed by GBO of the Branch, just below the Rubber Stamp. AS/IBS Number will be written below the signature to facilitate the Authentication and verification of transaction. Branches may prepare a Rubber Stamp in the n ame of authorized signatory with his IBS/AS Number and affix it at the back of Travelers Cheque so that the name of authorized signatory and his AS/IBS are clearly legible. xi. After completion of stamping formalities, the purchaser of the cheque(s), will be a sked to sign each cheque leaf at the place marked for signature. The purchaser will sign at lower left portion of RTC. After each cheque have been/is signed by the purchaser in presence of the Officer of the issuing Branch, the cheque(s), will be put in an envelope and handed over to the purchaser, along with Copy C of RTC 10. xii. The purchaser before leaving the Branch will be advised to check the Rupee Travelers Cheque(s), RTC -10 Copy C etc and satisfy himself in every respect. His attention must also be dra wn to the terms and condition of the Sale agreement printed on reverse of the RTC 10. He (customer/purchaser) may also be advised to keep record of all Rupee Travelers Cheques used by him and keep Copy C of RTC 10 separate from RTC’s. This Record/Copy of R TC 10 will help him in obtaining Refund of Rupee Travelers Cheques in case of Loss/Theft. xiii. Copy A of the RTC -10 Sales slip will be dispatched to RTC division for compliance purposes. 4.5.1 RTC Sale Procedure (Posting / Accounting): Branch teller / GBO after getting the cheques assigned, will access the Symbols EOC using his / her user name and password, and access the deposit module, click cheque instrument from the menu bar, select Transaction and select TC Cheque Sell. A screen “TC Cheque Sell” will be disp layed. Input the following fields: 1. Cheque Type: RTN 2. Currency: PKR 3. Tran type: RTCS for sell in cash RTTS for sell in transfer RTSI for sell against lost/stolen/refund 4. Name: Enter customer name 5. ID type/No: Enter NIN | Enter CNIC number of customer (This is mandatory information) 6. Settle Ccy: PKR 7. Cheque Amt: Enter total cheques amount 8. Denomination: Enter denomination of RTC (for example 5000, 1000, 10000 etc) 9. Prefix: Enter prefix of particular denomination or press F -9 key 10. Quantity: Enter total number of RTC to be sold for particular denomination 11. Start No: Enter starting RTC number 12. End No: Automatically appearing 4.5.2 RTC Sold against Cash Payment GBO for the sale of RTC from system, select Deposit then ‘Cheque Instrument’ to ‘Transaction’ and select ‘TC sell’. GBO select transaction type as “ RTCS ” for sale in cash and enter data in relevant fields and affix “posted stamp with date “on the application i.e. RTC -10. Following financial impact w ill be shown in branch books/ GL at the time of series allocation in system/RTC sale. RTC sell against Cash ( Auto entry) Debit: Cash in Vault (2010101010) B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 216 Credit: RTC Payable TC (1060101070) Reversal of Branch Stock Liability Entry (A uto entry) Debit: Stock of Security (Bank Liability) (1130101220) Credit: Stock of Security (Customer Liability) (2110101160) Reversa l of Branch Off Balance Entry (A uto entry) Debit: Stock Received Contra -Off balance (5010101020) Credit: Stock Received Off Balance (5010 101010) Commission Entry at the time of sale against Cash (Manual entry ) Debit: Cash in Vault (2010101010) Credit: Commission on RTC (3030401060) GBO print vouchers from system sign off and forwarded to BOM for counter sign. 4.5.3 RTC Sold against Debit to Account GBO check and verify Apparent feature of cheque (like: post dated cheque, antedated cheque, amount in word and figure differ etc.), customer signature from system and funds are available in customer account then post Cheque using transaction type “ CQWI ” or debit authority using transaction type “ TFRD ” in the system and affix “Posted stamp with date” on the application i.e. RTC -10 and cheque. Following financial impact will be in branch GL. RTC sell against Debit to Account (Auto e ntry) Debit: Customer account Debit (XXXXXXXXX) Credit: Inter -branch Settlement A/c (1091101010) Commission Entry at the time of sale against Debit to Account (Manual entry) Debit: Customer account Debit (XXXXXXXXX) Credit: Commission on RTC (3030401060) (Commission if any) Note: Transaction beyond the authorized limit of GBO will be Supervised /signed by TSS / BOM / BM 4.5.4 RTC System Posting GBO for the sale of RTC from system, select Deposit than ‘Cheque Instrument’ to ‘Transaction’ and select ‘TC sell’. G BO select transaction type as “ RTTS ” for sale in transfer and enter data in relevant fields. Following financial impact will be shown in branch books/ GL at the time of series allocation in system/ RTC sale. Following are the Auto Entries RTC sell against Cash Debit: Inter -branch Settlement A/c (1091101010) Credit: RTC Payable TC (1060101070) Reversal of Branch St ock Liability Entry Debit: Stock of Security (Bank Liability) (1130101220) Credit: Stock of Security (Customer Liability) (2110101160) B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 217 Reve rsal of Branc h Off Balance Entry Debit: Cheque Distribution -Off balance (5010101020) Credit: Cheque Distribution Off Balance (5010101010) RTC-10 copy “A “will be dispatched by branch to RTC Division for compliance purpose. RTC copy “C” hand over to customer 4.5.5 Day-end report generation: At day end GBO generate Pre -Consolidated report for RTC transactions. Issuance officer/user will fetch the transaction posting report (RBA -11) from Symbol and validate the source documents/vouchers and arranges filing of the same and sign off. To generate the Pre -Consolidated report click on Reports>Accounting>Pre -Consolidated Generated Entries , and use the fields to prep are the report. i. Branch Operation Manager / TSS counter sign GBO activity BOM/TSS review vouchers and reconcile with report and counter sign it. ii. Reporting of Sale of 0.5 Million and Above RTCs Branches will report without fail RTC sold amounting to PKR 500, 000 and above in sequential order in a day to one customers on the prescribed format as per previous practice to RTC Division, PO, Karachi for operational control. The report will cover the name of customers, address, CNIC number and sold RTC numbers. 4.6 SURRENDER OF UNCLAIME D DEPOSITS/INSTRUMEN TS TO SBP In compliance of SBP Master Circular, Section 31 of BCO -1962 and BP D circular no.07, dated 21 -07-2006, and BPRD Letter No. 37 dated December 03, 2009 branches will surrender the amount of RTCs that have rem ained outstanding (un -enchased) for a period of 10 years to SBP. Branches will refer to Section 1: 5.5 Surrender of Unclaimed De posit to SBP in this regard. RTC Division will provide date of unclaimed cheques to respective branches. Branches will issue a three month months notice in writing by registered post acknowledgement due/courier to the purchaser on the address available on RTC 10 (branch copy). A copy of notice will be sent to RTC Division for record purpose. In case of return of the mail or no receipt of claim, the amount of unclaimed R TCs will be forwarded to RTC Division for further processing and onward surrender to SBP through TSD. 4.7 RTC PURCHASE PROCEDURE MCB Rupee Travelers Cheques will be purchased by any of our Branches. The Rupee Travelers Cheques may be encashed or accepted for credit to the account of payee by the Branches, subject to the following check list: B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 218 4.7.1 Scrutiny of RTC : i. Genuineness:  Examine that Rupee Travelers Cheques leaves presented for payment is genuine and not counterfeit. This can be checked by comparing them with the specimen Rupee Travelers Cheques supplied to Branch or by referring to circulars issued by the bank from time to time.  If there is any doubt that the RTC is counterfeit/altered/misprinted or its features lack genuineness then immediately contact R TC Division before returning the instrument to the customer. ii. Stamp:  Ensure that Rubber Stamp of Issuing Branch is affixed at the back of the Rupee Travelers Cheque.  Check Rubber Stamp affixed on the back is of same size/design/sample as approved/supplied by RTC Division P.O. iii. Bank Official Signatures:  Ensure that cheques issued have been signed by an authorized official/GBO of issuing Branch mentioning his/her IBS/AS number, just below the Rubber Stamp at the back of the RTC.  Check that signature of the au thorized official/GBO appearing at the back of the RTC matches with the specimen signature of the officer in Bank’s IBS/AS Signature Book.  Signatures of RTC Owner:  See that the Signature of the Owner exists at the lower left corner of the RTC.  See that the counter -signature of the Owner appears in the upper left corner of RTC.  See that both signatures match with each other.  See that signatures are clear, not tampered with or over written.  Stop Payment:  Before payment of MIBBS issued RTCs (Non -symbol) check stop payment bulletin. No payment is to be made, if related RTC numbers appear in Stop Payment list.  Stop payment of a symbol issued RTC against which caution has been marked in the system, the system will deny posting of such cheques. For clarification, branches will require a check status by referring to ‘Cheque Status history Listings’. RTC Division has the exclusive discretion to earmark caution against any RTC which is reported as lost/stolen by claimant duly recommended by reporting branch in real ti me. iv. Cash Payment: Cash payment is made only to original purchasers of RTC on the production of RTC -10 sales slip. Please ensure the following:  RTC bears signature of the owner at the lower left corner of the RTC.  The owner counter -signs the RTC at upper left corner of RTC in presence of the encashing branch officer/GBO.  Both the signatures match with each other and also with the signature appearing on the RTC 10.  Proper identification of the person encashing the RTC has been obtained.  If customer has sig ned at both places, please request him/her to sign the reverse of the instrument. Please watch and compare the signature. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 219  Original identification documents like CNIC and original RTC -10 slip should be examined and Branch should not rely on photocopies. Th e particulars of CNIC with date, place of issue and name of the person in whose name identification documents issued may be noted at the back of each RTC leaf.  Credit to Account:  If RTC is presented for credit to customer’s account, it should be ensured th at it is credited exactly in the same account as is written on the face of the RTC.  When an account holder desires to have the amount of Rupee Travelers Cheque credited to his/her account, he will fill pay -in-slip and deposit it to the designated officer. The Designated Officer will scrutinize the RTCs tendered along with pay -in-slip and satisfy himself that the RTC is in order as per bank guidelines, sign the pay -in-slip and return the counterfoil to depositor.  RTC should not be credited to an account oth er than the one whose name/title has been mentioned in the RTC.  Take all the usual Precautions/Safeguards as applicable to payment of other cheques/negotiable instruments. 4.7.2 RTC Purchase / Encashment Procedure: After each of the RTCs (Symbols and non -Symbol s issued) presented for payment has been scrutinized as per check list defined under Section 4: 4.7.1 Scrutiny of RTC : and branch official/GBO has been satisfied that the presented cheques are in order the designated officer ini tiates the posting of cheques: i. MIBBS / Manual Sold Cheques : RTCs sold by MIBBS/Manual (before Symbolization) will be encashed/transferred to accounts as per old proc edures. Branch will continue to debit RTC Division (5440) by preparing Debit Advice SF -180. ii. Symbols Posting – Payment : Branch teller/GBO/RTC Officer w ill log on Symbols EOC using his/her password access “Deposit Module” and click cheque instrument from the menu bar and then select “TC Cheque Buy” Input screen will be displayed. Input the fields as required by the system: Cheque Type: RTN Cheque CCY: PKR Transaction Type : For Cash Payment: RTCB For Transfer Payment: RTTB For Buy in Clearing: RTCL (Do not use other then above transaction codes for RTC buy) ID Type: Input CNIC/DOC ID/Customer account no for buy in cash/account Input BRN/Input DOC ID for buy in clearing Denomination Input: 5000 -10000 Prefix Input: W for 10000, K for 5000 & B for 1000 Start No : Input start number of RTCs End No : Input end number of RTCs (Please ensure that RTCs are in series) Quantity: Will appear automatically B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 220 iii. Payment of RTC: Cash Teller makes the payment of RTC by accessing the system using his password and accessing ‘Deposit’ then ‘Cheque Instrument’ then select ‘TC Cheque buy’ and fill the respective fields in Symbol as stated above. S elect transaction code “ RTCB ” for buy in cash. Encashment of RTC by issuing branch: Following Auto entries will be generated Cash Payment Debit: RTC Payable. (Liability A/c) (1060101070) Credit: Cash in vault (2010101010) Rever sal of Off Balance Stock Entry Debit: Cheque Distribution - Off balance (5010101010) Credit: Cheque Distrib ution -Off Balance (5010101020) Encashment of RTC issued by other branch: Issuing branch of the presented cheques will be debit ed automatically by the System. Following Auto entries will be generated Cash Payment Debit: HO Account (issuing branch) (1110101010) Credit: Cash in Vault (2010101010) Reversal of Off Balance Stock Entry Debit: Cheque Distribution - Off balance (5010101010) Credit: Cheque Distribution Off Balance (5010101020) Encashment entry auto generated at Issuing Branch Debit: RTC Payable (liability A/c) (1060101070) Credit: HO Account (Purchasing/ Encashment Branch) (1110101010) Note: Transactions beyond the authorized limit of teller will be Supervised / signed by TSS / BOM / BM iv. Payment of RTC: Transfer GBO makes the payment of RTC. GBO access the system using his password and accessing ‘Deposit’ then ‘Cheque Instrument’ then select ‘ TC Cheque buy’ and fill the respective fields in Symbol. Select transaction code “ RTTB ” for credit in account. Following financial impact will appear in GL of branch at the time of purchase of RTC. Encashment of RTC by Issuing branch: Following Auto entries will be generated: Debit: RTC Payable. (Liability A/c) (1060101070) Credit: Inter -branch settlement A/c (1091101010) B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 221 Reversal of Off Balance Stock Entry Debit: Cheque Distribution - Off balance (5010101010) Credit: Cheque Distribution -Off B alance (5010101020) Entry to afford credit to customer account (by using transaction code TFRC): Debit: Inter -branch settlement A/c (1091101010) Credit: Customer Account (XXXXXXXXXX) Encashment of RTC issued by other branch: Following Auto entries will be generated Debit: HO Account (issuing branch) (1110101010) Credit: Inter -branch settlement A/c (1091101010) Reversal of Off B alance Stock Entry Debit: Cheque Distribution - Off balance (5010101010) Credit: Cheque Distribution Off Balance (50101 01020) Encashment entry auto generated at Issuing Branch Debit: RTC Payable (liability A/c) (1060101070) Credit: HO Account (Purchase/encashment Branch) (1110101010) Entry to afford credit to customer account (by using transaction code TFRC): Debit: Inter-branch settlement A/c (1091101010) Credit: Customer Account . (XXXXXXXXXX) Note: Transactions beyond the authorized limit of GBO will be Supervised / signed by TSS / BOM / BM v. Payment of RTC: Clearing RTC officer clear the payment of RTC in clearing. GBO will access the system using his password and accessing ‘Deposit’ then ‘Cheque Instrument’ then select ‘TC Cheque buy’ and fill the respective fields in Symbol. Select transaction code “ RTCL ” for Buy in clearing. Following financial impact will appear in GL of branch at the time of purchase of RTC. Encashment of RTC by Issuing branch: Following Auto entries will be generated Debit: RTC Payable. (liability A/c) (1060101070) Credit: Clearing control A/c (1150101140) Reversal of Off B alance Stock Entry Debit: Cheque Distribution - Off balance (5010101010) Credit: Cheque Distribution -Off Balance (5010101020) Cleared RTC amount will be transferred to co llecting bank through HO a/c maintained with SBP B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 222 Debit: Clearing control A/c (1150101140) Credit: HO Account (1110101010) Encashment of RTC issued by other branch: Following Auto entries will be generated Debit: HO Account (issuing branch) (1110101010) Credit: Clearing control A/c (1150101140) Reversal of Off B alance Stock Entry Debit: Cheque Distribution - Off balance (5010101010) Credit: Cheque Distribution Off Balance (5010101020) Encashment entry auto generated at Issuing Branch Debit: RTC Payable (liability A/c) (1060101070) Credit: HO Account (Purchase/encashment Branch) (111010 1010) Cleared RTC amount will be transferred to col lecting bank through HO a/c maintained with SBP Debit: Clearing control A/c (1150101140) Credit: HO Account (1110101010) Note: Transactions beyond the authorized limit of RTC officer will be Supervised/ signed by TSS/BOM/BM vi. Day end report generation: At day end teller/ GBO/ RTC officer generate Pre -Consolidated report for RTC transaction posting report (RBA -11) from Symbol and Validates the source documents/ Vouchers and arranges filing of the same and sign off. BOM reviews vouchers, reconciles with report and counter sign it. vii. RTC Payable report: Branch official will extract RTC payable report from Symbols KM and will ensure th at balance as KM report matches with balance as per General Ledger. Differences, if any, should immediately be escalated to concerned authorities. viii. Reversal of error/mistake occurs during proce ssing of Encashment transaction:  Branch official should take a ll precautions during input of RTC information into the symbols system. If any mistake in encashment process is occurred, the entire batch will be reversed with the prior permission of ROM.  If any input error is detected before run of EOD (same day) the br anch authorized official may reverse the same using RTC Reversal Option of the system. The entire batch will be reversed and after rectification of error batch will be re -entered into the system. If the error detected after run of EOD the reversal will be made via HO. In both conditions ROM approval is required. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 223 ix. Dispatch of Paid Cheques  After completion of encashment transaction, cheques will be defaced properly by affixing paid stamp on face of the cheques.  Cheques must be punched holes and placed in a s equential order.  After the banking hours, branch/operation manager/RTC in charge will check the data entry; compare it with the paid cheques. In case of reversal of entry, it should be ensured that transaction is validated by ROM.  Branch will retain the SY BMBOLS Paid cheques till next day (following morning) to access ''RTC CLEARING TRANSACTION REPORT" which is generated and released by Symbols KM Team on daily basis. The Cheques will be kept in safe custody till following morning.  On next day branch will r etrieve the stored original paid cheques as detailed in above and dispatch the paid cheques to RTC Division along with “RTC CLEARING TRANSACTION REPORT” containing details of cheques encashed by the branch on previous day. Branch will follow the following procedure while dispatching paid cheques to RTC Division.  Dispatch of Symbol Paid Cheques  Retrieve original paid cheques placed in a sequential order relating to previous day encashment.  Take out print of "RTC Clearing Transaction Report" received from S ymbols KM Team.  Compare all paid cheques with the REPORT and ensure that NO RTC is missing and total amount of paid cheques tallied with the report . Sign and Stamp the Report.  Ensure that all the Symbol paid cheques are sealed off and stitched together pr operly.  Place the paid cheques along with RTC Clearing Report in an envelope and seal the same carefully to avert pilferage/outside intervention.  Write down the details/ information on the envelope: Branch name and code, Total Number of Cheques being dispatched and Courier Receipt Number. Courier receipt obtained from courier company will be kept date wise.  The envelope prepared as above will be placed in another envelope duly addressed to RTC Division, 1st Floor, 124 -P, Block -2, Tariq Road, P.E.C.H.S Karachi.  To avoid any complication particularly incidents of "LOST IN TRANSIT" branches have additional responsibility to follow the steps mentioned herein above judiciously.  There is no change in the encashment procedure of MIBBS cheques. Dispatch of MIB BS paid RTCs will be made as and when the transaction is made without any delay. 4.8 REPORT OF LOST / STOLEN RTC Following procedure will be observed by RTC Division for online earmarking caution against payment of lost / stolen Rupee Travelers Cheques. BM / BOM are required to follow the following guidelines: i. All MCB Branches are authorized to entertain "Incidents of Lost/stolen Cheques" and accept application from an eligible reporter for onward submission to RTC Division duly supported by CNIC and FIR / Roznamcha Report. ii. Report on lost/stolen cheques may be submitted by purchaser of the RTC himself or the person who was carrying the RTC as holder in due course and from whose possession the RTC has been lost. iii. The report must be hand written or typed and shou ld be addressed to the Manager / Operation Manager of the Branch of reporting. The report should be specific and contained Serial Number of lost / stolen cheques, the circumstances under which RTC’s came into his possession and thereafter lost / stolen, pr oof of ownership i.e. C copy of RTC 10, status of lost / stolen cheques (unsigned, singly signed, B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 224 double signed, crossed, uncrossed, double signed and crossed, endorsed but unsigned, endorsed but singly singed etc, Business/Residential Address and Telephon e number of the person reporting the incident. iv. Report of loss will be made to the nearest Police Station simultaneously. Customer will submit the original FIR / Roznamcha to the branch v. As per terms and condition of Sale agreement printed on the back of Sal e receipt (RTC -10) MCB will replace or refund the face amount of any Rupee Travelers Cheques that are Reported Lost/Stolen provided that:  The RTC reported lost was not blank and had been signed by purchaser as the place marked for purchaser’s signature at the time of purchase.  The RTC has not been countersigned by the purchaser at the place specified for countersignature.  Purchaser has not voluntarily parted with the RTC in a manner of his own choice or in connection with a game of chance, wager, confiden ce game or illegal transaction.  RTC has not been seized or confiscated by Government action. vi. In terms of agreement mentioned in the sales agreement, MCB Bank Ltd. is not bound to stop the payment of any RTC, due to any reason. The loss notice received by the bank will, therefore, not constitute an admission of liability. vii. The Branch after receiving the application from the party will verify the contents, check supporting documents and then forward the same to RTC Division through e -mail / fax / courier. Br anch will send all documents received from the person reporting lost/stolen RTC to RTC Division by courier. Contact details are as under: E-mail: rtcops@mcb.com.pk ; or mcb5440@mcb.com.pk Fax: 021-34556308, 021 -34387625 Phone: 021-34553602 -04 Address: Principal Of fice: MCB Building – 1st Floor, Plot #: 124 –P, Block –2, Tariq Road, P.E.C.H.S. Karachi. 4.8.1 Online circulation of Lost/Stolen RTCs serial number: RTC Division upon receipt of lost/stolen cheques report as above will examine the application on merit and may ask all authorized branches to act accordingly in the following manner: i. MIBBS (Non -Symbols) Cheques :  If lost/stolen case of RTC is related to MIBBS / Manual RTC Division will review the case on merit and issue a bulletin with the instruction to amend the record with the missing cheques. Branches will update their record on MIBBS and file the bulletin in sequential order.  In order to safeguard the customers RTC from fraudulent encashment an email may be sent to branches immediate after receipt of lost report. ii. Symbols Cheques If lost/stolen RTC is sold by Symbols, RTC Division will review the case if found consistent to requirement caution against the lost RTC will be marked and circulated online. No bulletin will be issued. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 225 iii. Deletion of Lost/Stolen Cheques (Removal of Cautio n mark)  For deletion cases of cheques that were earlier declared lost/stolen and subsequently recovered, branches will obtain a written request from the complainant confirming therein that the RTC(s) have been recovered. The signature of the customer will be verified by branch official. The branch will then forward the request letter duly signed by the claimant and signature verified by officer carrying authority of IBS / AS to RTC Division.  If the cheques were issued by MIBBS/Manual System RTC Division w ill issue a bulletin for deleting the caution against the payment .  For Symbols sold RTC, caution mark will be deleted by RTC Division and the concerned branch will be notified Note: Branches do not have any authority to mark caution or delete caution. iv. Recovery of Lost/Refund/Deletion Charges: The branch will recover and retain charges from the claimant against services rendered in respect of refund or deletion of caution marked against the payment of lost/stolen cheques as per schedule of bank charges. Following Manual entries will be passed: Debit: Customer A/c/Cash (xxxxxxxxx) Credit: MISC Income/Earnings (xxxxxxxxxx) 4.9 REFUND / REPLACEMENT OF LOST / STOLEN RTC Claimant of lost / stolen cheques may approach concerned branch to get refund against lost / stolen RTC as per laid down procedures mentioned herein: Branch may come across 3 situations while entertaining refund cases: 4.9.1 Situation (A): RTC’s lost by purchaser himself. i. In such case(s), purchaser may contact selling Branch, complete refund application form (RTC 80) ; submit required documents like copy of FIR, copy of CNIC, Indemnity Bond (First Party) and original Copy -C of RTC -10. The Branch on receipt of these documents if in order, will forward the documents to RTC Division Principle Offi ce. ii. Before forwarding the Refund Applications/Documents, the Branch Manager/BOM will attest the signature of the Purchaser on refund application form (RTC -80) after verifying signature from the Branch copy of RTC -10. He will also add his recommendation for Refund. iii. Replacement RTC’s will only be issued by Branch on receipt of Approval from RTC Division, Principle Office, Karachi. The approval for replacement of RTC is accorded on case to case basis. Normally the approval is accorded within 20 days. iv. The appro val for replacement RTC’s is accorded to branch within 20 days from the date of RTC reported/circulated lost/stolen, if the documentations are completed in all respects. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 226 4.9.2 Situation (B): RTC’s have been lost by person other than the purchaser . For seeking refund in such cases, the party claiming refund has 2 options: B.1.Option 1: i. He should contact the Original Purchaser either directly or through the person from whom the cheques were received by him and request him to file refund claim application form wit h the issuing Branch and after re -issue of the RTC hand over the same to him duly signed/counter - singed and endorsed in his favor. ii. In such case an indemnity (First Party) will be executed by original purchaser and claimant jointly on stamped paper of appr opriate amount. In such situation, same procedure will be followed as prescribed for refund in Situation No.1 with the only exception that after issue of the RTC, same will be handed over to the claimant. B.2. Option 2: i. The party claiming refund may approach the purchaser of the RTC and obtain a letter of negotiation/transfer from him authorizing the Bank to issue replacement RTC to the claimant. ii. The negotiation/transfer letter will be obtained. The negotiation/transfer letter will be signed by the purchaser of the RTC and his signatures will be attested by issuing Branch. iii. After obtaining letter of negotiation/transfer from the purchaser in the manner stated above, the claimant will approach the branch where he reported the incident of lost/stolen cheques or any of the authorized Branches of his choice along with Copy A and B of Authority Letter given by purchaser. The Branch will take the following action:  The Authorized Branch approached by the Claimant will first verif y the signature of the official of issuing branch on Letter of Authority from Authorized/Inter Branch Signature Book.  If the Authority Letter is found in order, the Branch will get the RTC -80 filled in by the Claimant, after identification.  A Third Party i ndemnity on appropriate amount of stamped paper, duly witnessed and signed/sealed by the Claimant, will be obtained.  The copy of the FIR/Roznamcha lodged by the claimant should also be submitted along with application/other documents.  If the claimant is an account holder of the Branch, then the signature of the claimant would be verified by the Manager on RTC 80, indemnity bond (Third Party) etc. from branch record. Where party does not maintain account with our Bank, a Letter from his/her Banker authentica ting the signature of the claimant would be obtained by the party and submitted to issuing Branch, along with other relative documents. The letter from other bankers will contain the signature of the claimant, along with their name and addresses duly attes ted by Authorized Official of the Bank. The Signature of the Bank Official on letter, authenticating the signature of claimant, will also be got verified from the nearest Branch of that Bank. iv. The handling Branch will scrutinize the claim documents and if s atisfied and found in order, will forward it to RTC Division for approval. Replacement RTC will only be issued by Branch in the name of claimant authorized by the Original Purchaser on receipt of approval from RTC Division, Principle Office. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 227 4.9.3 Situation(C ): RTC’s have been lost by person other than the purchaser and original purchaser is not traceable. i. In some cases, the party from whom RTC has been lost may be unable to trace out the original purchaser, due to incomplete address recorded at the issuing Br anch. In spite of best efforts of the Party as well as Branch, if the purchaser is not traceable, the claimant may make a representation to Divisional Head, Rupee Travelers Cheque Division, Principle Office, giving therein full facts and circumstances in w hich the RTC’s came into their possession, how they were lost and efforts made by them to trace out the purchaser. On receipt of such representation by RTC Division, the matter would be examined on merit and if the Bank is satisfied about the bonafides of the claim of the party, special approval may be accorded by the competent authority for refund to the claimant in his own name. In such case, a letter of intention will be issued to the Claimant, asking him to furnish the following documents:  A third party indemnity, on stamped paper of appropriate amount, signed by the claimant, duly witnessed and signature attested by their Banker.  An affidavit on Stamped Paper, of appropriate amount testifying that claimant is the bonafide owner of the cheques by virtue of negotiation of RTC to them for value received and that the cheques were lost from their possession. The affidavit will be notarized.  Some Proof/Evidence that subject RTC came into their possession out of bonafide commercial deal.  A credit worthiness re port of the party from their Banker, certifying worth and reputation of the party.  In case the claimant is a Public Limited Company or Corporation or Organization, such other documents to be suggested by Legal Affairs Division or legal retainer may be asked for production.  Name of MCB Branch from where the claimant wishes to get issued replacement RTC. ii. Upon receipt of above documents, RTC Division will convey approval for issuing refund against lost/stolen cheques to nominated branch. RTC Divisional Hea d will seek approval from competent authority. iii. The Nominated Branch on receipt of approval for Refund/Replacement will issue replacement RTC’s only to the claimant as per directives contained in the approval letter. 4.10 PROCESSING OF REFUND APPLICATION / RE-ISSUE / ACCOUNTING i. When application is made by a claimant for Refund against lost/stolen , the Branches obtain an Application on Form RTC -80 and assist him in filling the form properly. ii. The customer will submit proof of purchase in form of Copy -C of Form RTC-10 of Rupee Travelers Cheque lost by him/her. iii. Copy of FIR/Roznamcha lodged wi th the Police station, copy of Computer ized National Identity Card and an indemnity as prescribed in previous chapter, will also be obtained from the customer. iv. Concerned Offic er of the Branch will scrutinize all documents/application form; enquire into the matter as to how RTC’s were lost. He will also check and verify as under:  The name and signature of the customer on the Refund Application Form (RTC -80) will be compared with those on RTC 10 in case Refund is claimed by the original purchaser himself.  Where claim is submitted by another party, the signature will be checked from documents submitted by claimant, as laid down in previous chapter of this manual.  After the Branch i s satisfied that Bank’s interests have been safeguarded, he will sign the Form RTC B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 228 80 in the column in token of having cross questioned the customer and also sign in the recommendation column in support of adding his recommendation.  Refund Application (RTC 80) will be filled in and signed by the purchaser in his own name if the refund is requested by him or requested by him for the benefit of 2nd party to whom Rupee Travelers cheque was transferred. The Application may also be filed and signed by the claima nt (3rd party) in his own name when refund is claimed on the basis of letter of negotiation issued by the purchaser in his favor or specially approved by the competent authority and advised by RTC Division.  After completion of all formalities and scrutiny, Branch Manager will forward (RTC 80) Copy A, B and C to Divisional Head, Rupee Travelers Cheque Division. The application (RTC 80) will be supported with the following documents:  Copy of FIR/Roznamcha duly attested.  Copy of CNIC duly attested.  RTC 10 Copy -C.  Letter of indemnity on appropriate value of stamped paper as per approved specimen. The indemnity first party if the refund is made to original purchaser or indemnity third party if refund is made to anyone other than the original purchaser with consen t of Purchaser. Branch will send the original indemnity to Principal Office and will retain copy of the same for its record.  On receipt of RTC Refund Application, complete with all necessary documents, it will be processed by RTC Division at their end and if found in order, approval will be advised to the concerned Branch by returning Copy A and B of RTC 80, duly signed by the officials authorized to sign for the competent authority retaining Copy C for their own record. 4.11 REFUND PROCEDURE OF RTCS 4.11.1 Refund Procedure for Lost/Stolen Cheques (issued through MIBBS Branches) : On receipt of approval on RTC -80, Copy A and B, the Branch will proceed as under: i. Will check that approval is genuine and bears signature of Authorized Officials of RTC Division. In case of doubt, matter should be reported to RTC Division. ii. For re -issue of RTC, the claimant will be requested to visit the Branch for completion of re -issue formalities like filling in the RTC 10, sign the duplicate RTC and sign on the RTC 80, at the place marke d for acknowledgment. iii. Sales Receipt (Form RTC -10) will be filled in by RTC Incharge/Customer. Procedure of Sale as laid down in Chapter -4 will be followed. iv. Since the transaction will be for refund of lost/stolen Rupee Travelers Cheques, the word “REFUND TR ANSACTION” will be written on top of Form RTC -10 Copy A in bold letters using Red Ink. v. The transaction of RTC refund will be recorded in the RTC Register Form 60 by RTC Incharge. The Incharge will write the words “TRAVELLERS CHEQUE(S) REFUND” in the Remar ks column in Red Ink against each issued cheque. vi. The RTC Incharge will, after carrying out the recording, check and verify that the posting is correct. He will sign in the column “Received/Issued by” opposite the entry posted. A rubber stamp bearing the wo rd POSTED will be affixed on Form RTC -10, Copy A. The posting will be supervised by the Branch Manager, who will sign in the column “Checked by”. vii. NO ACCOUNTING ENTRIES on GL will be passed as the Rupee Travelers Cheques issued are in lieu of the lost/stole n Rupee Travelers Cheques. viii. Only an internal liability entry will be passed to show reduction in stock held. The Sales Receipt B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 229 Copy A and copy A of Form 80 will be dispatched to Divisional Head, RTC Division, 1st Floor, 124 - P, Block -2, Tariq Road, PECHS Karachi. 4.11.2 RTC Refund Procedure Lost / Stolen Cheques (Issued Through SYMBOL Branches) : The branches will submit all necessary documents/papers as mentioned above and ensure completion of formalities as explained. RTC Division will examine the cases on me rit and will accord approval to concerned branch for issuing refund to claimant within 06 working days. The concerned teller/GBO after having received the approval from RTC Division will do the following: i. The teller will check if the stop/lost/stolen RTC was marked as stop via a symbols screen (RB1841) ii. If the said RTC was marked as stop then teller will re -issue the new RTC in lieu of RTC declared as stop/stolen/lost via a symbols screen (RB1835) with transaction type (RTSI -RTC stop/lost/stolen re-issue) iii. Branch will also intimate to RTC division for re -issuance of new RTC number against stop/lost/stolen RTC. iv. RTC division will incorporate the new issued RTC number against already stopped RTC in narrative column of symbols screen (RB1841) v. System will generat e following Auto entries : Debit: RTC payable (1060101070) Credit: RTC payable (1060101070) Debit: Stock of Security (Bank Liability) (1130101220) Credit: Stock of Security (Customer Liability) (2110101160) Debit: Stock Received Contra -Off balance (5010101020) Credit: Stock Received Off Balance (5010101010) Note: Branches are required to input old RTC number in purpose field on screen (RB1835) while reissuing new RTCs 4.12 REPLACEMENT OF TORN / SOILED & DAMAGED RTC S i. Soiled/Torn or Damaged Rupee Travelers Cheques presented for replacement may be paid following usual purchase procedure as laid down in this Manual, provided the cheque is in one piece, the serial number of Rupee Travelers Cheques, signature of purchaser o f cheque at top and bottom left corner of the RTC, is visible and the RTC appears genuine. It is the prime responsibility of the encashing branch to exercise due care while attending such cases to avoid complication. ii. When the soiled/torn/damaged RTC is to rn into small/several pieces, washed away or cheque serial number, signature of the owner are missing, the usual refund procedure as laid down in this Manual will be followed for replacement. iii. No FIR / Roznamcha would be required to be lodged for issue of replacement cheques against such torn/mutilated or damaged RTCs that are submitted by original purchaser along with RTC 10. However, bank may ask any documents including copy of FIR / Roznamcha Report in case of 3rd party. iv. Serial numbers of torn/mutilated cheques would be circulated by RTC Division Principal Office among branches, as an extra precaution to safeguard the Bank’s interests. v. All pieces of soiled/torn/washed out RTC’s would be obtained from the claimant by Branch along with B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 230 refund application fo rm. All pieces will be put into an envelope and will be sent to RTC Division, Principal Office along with refund application/documents. 4.13 SAFE CUSTODY OF RTC i. On receipt of stock from H O / RTC Centre / Hub, authorized representative of the Branch / Centre / Hub will check it as to alphabetical series, block serial numbers, quantity, denomination and packets with the details on the Delivery Challan and will sign on RTC 50, Copy C, as acknowledgment of having received RTCs correctly. ii. When the representative ar rives at his Branch/Centre/Hub, he will deliver the packet to a responsible Officer of the Branch/Centre/Hub, as per arrangement. The responsible Officer, after taking control of RTC Stock, will check/count the RTC from the copy of Delivery Challan (RTC 50 ) and will satisfy himself/herself that the Stocks of Rupee Travelers Cheques are in order after which the Branch Manager/Centre/Hub Incharge will sign on Copy A and B of Delivery Challan. Copy B will, thereafter, be mailed to RTC Division Principal Office , if the stock received from Principal Office, and to respective RTC Centre with copy endorsed to RTC Division, if stock received from Centre. Copy A will be kept by Branch in their file, for future reference for Stock Control. iii. The Office -in-Charge will en ter the stock of RTC received in the RTC Stock Register (RTC 60). Each Denomination of Rupee Travelers Cheques will be entered on a separate folio. The date of stock received, Alphabetical series, serial number of RTC, the quantity and amount will be enter ed in the register. A rubber stamp with the word “posted” will be affixed on delivery Challan Copy A of the branch. The entry will be checked / signed in the received/issued column by the authorized official of the branch. iv. The stock of Rupee Travelers Cheq ue will always be kept in safe vault under joint custody. The safe vault will be kept in strong room. The stock will be checked/counter -checked by Centre/Hub Incharge/Branch Manager once a week. The Centre/Hub Incharge/Branch Manager will sign Stock Regist er in the last column in token of having checked the stock. In case of any shortage of stock, the same must be reported immediately RTC Division, providing full details and circumstances under which the Stock was found short. v. Duplicate keys of safe vault c ontaining RTC, will be placed in a sealed envelope and kept in branch “Safe custody”. An entry will also be made in the Key Register, duly authenticated by Branch Manager/Officer Incharge, with date. vi. RTC will be delivered to Branches in Blocks of 100 leave s. The Stock will be handled with care, to ensure that RTC’s are not soiled and remain crisp/clean and new, at all times. vii. RTC Stock sold during the day will be noted in the Stock Register, on daily basis. 4.14 COMPLIANCE / REGULAT ORY / OPERATIONAL INSTRUCTIONS i. Branch official responsible for issuance of RTC shall ensure that before handing over Rupee Travelers Cheques to any purchaser, his/her signatures must be obtained on the RTC. ii. Branches will report, without fail, RTC sold amounting to PKR 500,0 00 and above in sequential order to one customers on the prescribed format to RTC Division, PO, Karachi. The report will cover the name of customers, address, CNIC number and sold RTC numbers and amount for operational control. iii. RTCs presented in clearing, transfer or for Cash Payment will be examined carefully using instant verification techniques and tools provided to ascertain genuineness of the RTCs iv. Soon after making payment, branches will deface paid RTCs, affix paid stamp on the face of the RTCs, B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 231 punch holes, arranged in sequential order and stitched together properly v. Existing SBP instructions with regard to retention of record must be adhered to in letter and spirit vi. Record of sold/paid RTCs should not be displayed or kept in an open place. 4.15 FLOAT I NCOME DISBURSEMENT T O BRANCHES Since 1st April 2010 RTC processing has been successfully migrated to Symbols. As part of the migration process whereby the liability is booked at the issuing branch and remains intact there from instrument sale to encashment . RTC division in collaboration with ITG and OPS stakeholders has devised this process through which the income will now be transferred to RTC Division at the end of the month and distributed to branches as per their share. The breakup of the RTC income en d of month process is as follows: i. RTC Division will forward request for extraction of data file on prescribed format to Centralized Operations Division for conversion of data into symbols GL upload format. ii. Float income will be transferred to RTC division b y Centralized Ops as of the end of the month. iii. Commission Income Report will be provided by KM Team on the last day of the every month. iv. RTC division will review the commission Income report, validate the commission file and forward to KM team and Centrali zed Ops to process the income file on the same day to distribute compensation to branches. v. Centralized Ops will forward the file to ITG for processing the income file on same day. vi. After acknowledgement from ITD, RTC division will intimate to All MCB Bran ches that RTC compensation has been paid (via email). vii. Following Auto entries will be generated: 100% Income Transferred from Branches to RTC Division Branch End: Debit: Markup paid to P.O . (4050101010) Credit: Head Office A/c (1110101010) RTC Division End Debit: Head Office A/c (1110101010) Credit: Markup Received from P.O. (3070101010) Float Income/Compensation Disbursement to Branches RTC Division End: Debit: Compensation Paid to Branches on RTC (4060101080) Credit: H.O Account (11101 01010) Branch End: Debit: Head Office Account (1110101010) Transaction Code: 2246 Credit: Compensation Received on RTC (3080101060) B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 232 Chapter 5 HOME REMITTANCE 5.1 MCB HOME REMITTANCE Under Home Remittance branch makes payment to customer in following ways. i. Download payment instructions from MCB Payment System (Cash Payout ) ii. Download payment instructions from MCB Payment System ( Online Transfer) iii. Through responding Demand Draft or iv. Responding H.O advice 5.1.1 Process for MCB Home Remittance A. Download payment instructions from MCB Payment System - (Cash Payout) Customer will provides digit code/ Pin to DAO Designated authorized Officer i. Entered digit code/ Pin provided by the customer in MCB Payment System web based application and extract detail of the message/ transaction. ii. Match beneficiary detail with message from original CNIC and takes copy of CNIC and stamp it as “Original Seen” and sign off. iii. KYC is being conducted as per KYC and AML hand book iv. Incase customer KYC is not proof genuine, then further queries will be made or the transaction will be rejected. In case of any system issue GTB has performed supervisory function and resolve the paying branch issue. v. Designated authorized Officer after being satisfied with the credential of customer, confirm t he transaction on web portal and takes print of detail and prepares cash debit voucher and sign off. vi. Voucher and supporting documents forwarded to BOM / Forex Manager for approval. BOM/ Forex Manager Checks and verifies the particulars of voucher with supporting documents and after being verified counter sign off. Cash debit voucher forward to Cash department/ teller for cash payment to customer. Note: If remittance is in favor of company/ Firm than R -Form must obtained from each and every company/ firm regardless remittance amount. In case of huge amount of remittance in favor of individual related to other bank financial instrument to be issued and ‘R’ form must be obtained. Paying Branch obtained signed R -form from customer, verify customer signature with branch stamp and forwarded to GTB Branch. GTB Branch submits onward to SBP on monthly basis . Teller i. Takes customer’s signature on back side of voucher and matches the same with the original CNIC and copy of CNIC attached with voucher. Teller makes c ash payment to customer. ii. Teller posts the voucher in system through batch creation and affixed the “Posted” stamp with date. And forward to TSS/ BOM for supervision. TSS or B OM authorized the transaction after being satisfied with the supporting documents and counter sign voucher. Financial Impact: Debit: 1060101130 -REMIT EXPRESS - DD PAYABLE Credit: 2010101010 - CASH IN VAULT Note: Branch did not require sending any intimation regarding payment to GTB Branch. GTB Branch extract at day end report from MCB Payment System and NIL branches GL head (1060101130 -REMIT EXPRESS - DD PAYABLE) through GL B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 233 5.1.1 Process for MCB Home Remittance upload B. Download payment instruction s from MCB Payment System - (Online Transfer) i. GTB Branch concern In charge, receive payment instruction file through SWIFT, email or fax. ii. Before processing transaction in MCB Payment System test and authorized signatures are being verified. iii. Processor pass es the necessary accounting entries in NR System and in Symbol system and process payment instructions. iv. In case any transaction rejected due to dormant account or due to Islamic Banking accounts demand draft or advice being issued. If any payment rela ted to other banks than settled through RTGS process . C. Through responding Demand Draft BOM / Forex Manager i. Designated authorized Officer receives Demand Draft for customer with dully filled and signed deposit slip stated complete 16 -digit account numbe r. ii. If amount is more than RS. 100,000/ - than confirmation is taken from GTB branch before payment through email/ fax. Email will be forwarded by BOM/ Forex manager with particulars of instrument. Designated authorized Officer (GTB Branch) checks the DD detail with record, after satisfying from the credential or particulars of DD reply the email and give intimation/ confirmation to branch through fax Designated authorized Officer (Branch) Checks Authorize Signature (Test and signature on advice will verify by two designated officers) on demand draft and after being satisfied with genuineness of demand draft counter sign Note: If remittance is in favor of company/ Firm than R -Form must obtained from each and every company/ firm regardless remittance amount. In case of huge amount of remittance in favor of individual related to other bank financial instrument to be issued and ‘R’ form must be obtained. Paying Branch obtained signed R -form from customer, verify customer signature with branch stamp and forwarded to GTB Branch. GTB Branch submits onward to SBP on monthly basis. Designated authorized Officer gives credit to customer account by using transaction type: “REDD” and prepares transfer voucher and signs it and forward for counter sign to BOM/ Forex manager and create Batch. Financial Impact : Debit: 1060101130 -REMIT EXPRESS - DD PAYABLE A/C Credit: Customer’s Account Note: If transaction amount exceeds the DAO, limit screen pop -ups “Authorization Required” message. DAO forward vouche r to next supervision level for system authorization BOM/ Forex manager i. BOM/ Forex manager checks and verifies particulars of advice with supporting documents and after being satisfied with transaction authorizes in system and sign off. ii. Designated authori zed Officer apply test and sign advice with AS/ IBS #. Signed advice copy A and copy of Demand Draft courier to GTB Branch for responding at their end Financial Impact : Debit: HO Accou nt - GTB Branch (1110101010) Credit: 1060101130 -REMIT EXPRESS - DD PAYABLE A/C If DD is presented through Clearing: Clearing officer after proper verification of Demand Draft prepare advice sign it and forward to authorizer for approval and counter sign off. Clearing officer create batch B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 234 5.1.1 Process for MCB Home Remittance Authorizer i. Checks and verifies particulars of advice with supporting documents and after being satisfied with transaction authorizes in system and sign off. ii. Designated authorized Officer apply test and sign advice with AS/ IBS #. Signed advice copy A and copy of Demand Draft courier to GTB Branch for responding at their end Financial Impact Debit: HO Account - GTB Branch (1110101010) Credit: Clearing control A/c (1150101140 ) D. Responding H.O advice GBO receives advice from GTB Branch and forwarded to Designated authorized Officer for signature/ test verification. Designated authorized Officer checks Authorize Signature (AS) and test on advice and after being satisfied with genuineness of advice counter sign Note : If remittance is in favor of company / Firm than R -Form must obtained from each and every company/ firm regardless remittance amount. In case of huge amount of remittance in favor of individual related to other bank financial instrument to be issued and ‘R’ form must be obtained. Paying Branch obtained signed R -form from customer, verify customer signature with branch stamp and forwarded to GTB Branch. GTB Branch submits onward to SBP on monthly basis. GBO gives credit to customer account by u sing transaction type: “THRC” and prepares transfer voucher and sign off and for system authorization and counter sign forward to BOM. Financial Impact : Debit: 115010115 0-FUNDS TRANSFER CONTROL A/C Credit: Customer’s Account Note: If transaction amount exceeds the General Banking officer, limit screen pop -ups “Authorization Required” message. General Banking officer forward voucher to next supervision level for system authorization. And financial impact only showed in GL after authorization. i. Authorizer checks and verifies particulars of advice with supporting documents and after being satisfied with transaction authorizes in system and sign off. ii. Designated authorized Officer apply test and sign advice with AS/ IBS #. Signed advice copy A and c opy of Demand Draft courier to GTB Branch for responding at their end Financial Impact : Debit: HO Account - GTB Branch (1110101010) Credit: 1150101150 -FUNDS TRANSFER CONTROL A/C Day end report generation: Designated authorized Officer generates Day end report and validates the source documents/ Vouchers and arranges filing of the same and sign off. i. BOM / TSS counter signs Designated authorized Officer activity ii. BOM/ TSS reviews vouchers and reconciles with report and counter sign off. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 235 5.2 EXPRESS MONEY Customer will provides 16 digit code/ Pin to Designated authorized Officer Designated authorized Officer i. Entered 16 digit code provided by the customer in Express Money web base application and extract detail of the message/ transaction. ii. Designated autho rized Officer match the beneficiary detail with message from original CNIC / Passport /Driving License and also take a copy of CNIC / Passport / Driving License and stamp it as “Original Seen” and sign it. And conduct KYC of customer as per KYC and AML han dbook. iii. Incase customer KYC is not proof genuine, then further queries will be made or the transaction will be rejected. In case of any system GTB follow the supervising function and resolving the issue of the paying branch. iv. Designated authorized Officer a fter being satisfied with the credential of customer, confirm the transaction on web portal and take print of instructions, prepares internal voucher and forwarded to BOM/ Forex Manager for approval. Note : Cut of Timing: As per Circular # PO/CMD/HR/10 dat ed: August 11, 2009, branches will not pull out/ confirm any transaction in the system after cut of time i.e. from Monday to Friday 9:00AM to 5:00PM and Saturday 9:00AM to 1:30PM. BOM/ Forex Manager/ BM i. Checks and verify the particulars of voucher with supporting documents and also verify KYC & AML formality. After being verified counter sign the voucher. Voucher forward to teller for cash payment to customer. Note: If any, inward Home Remittance is of m ore than USD $10,000/ equivalent amount, than R -Form is required, clearly stated purpose of remittance. However, if remittance is in favor of company/ Firm than R -Form must obtained from each and every company/ firm regardless remittance amount. Branch obt ained signed R -form from customer, verify customer signature with branch stamp and forwarded to GTB Branch. GTB Branch submits onward to SBP on monthly basis . Teller i. Takes customer’s signature on back side of voucher and matches the same with the origina l CNIC and copy of CNIC attached with voucher. Teller makes cash payment to customer. ii. Teller posts the voucher in system and affixed the “Posted” stamp with date. And forward to BOM/ TSS BOM/ TSS authorize the transaction after being satisfied with the su pporting documents. Financial Impact: Debit: 1060101150 -EXPRESS MONEY PAYABLE ACCOUNT Credit: 2010101010 - CASH IN VAULT Day end report generation: Teller generates Day end report and Validates the source documents/ Vouchers and arranges filing of the same and sign off. BOM / TSS counter signs Designated authorized Officer activity after reviewing vouchers and reconciles with report and counter sign off. Note: Branch did not require sending any intimation regarding payment of Express Money to GTB Branch. GTB Branch extract at day end report from Express money website and NIL branches GL head (1060101150 -EXPRESS MONEY PAYABLE ACCOUNT) through GL upload B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 236 5.3 MONEY GRAM Customer will provides digit code/ Pin to Designated authorized Officer Designated authorized Officer i. Entered digit code provided by the customer in Money gram web based application and extract detail of the message/ transaction. ii. Match beneficiary detail with message from original CNIC and takes copy of CNIC and stamp it as “Original Seen” and sign off. iii. KYC is being conducted as per KYC and AML hand book iv. Incase customer KYC is not proof genuine, then further queries will be made o r the transaction will be rejected. In case of any system issue GTB has performed supervisory function and resolve the paying branch issue. v. Designated authorized Officer after being satisfied with the credential of customer, confirm the transaction on web portal and takes print of detail and prepares cash debit voucher and sign off. vi. Voucher and supporting documents forwarded to BOM/ Forex Manager for approval. BOM/ Forex Manager Checks and verifies the particulars of voucher with supporting documents an d after being verified counter sign off. Cash debit voucher forward to Cash department/ teller for cash payment to customer. Note: If any, inward Home Remittance is of more than USD $10,000/ equivalent amount, than R -Form is required, clearly stated purpose of remittance. However, if remittance is in favor of company/ Firm than R -Form must obtained from each and every company/ firm regardless remittance amount. Branch obtained signed R -form from customer, verify customer signature with branch stamp an d forwarded to GTB Branch. GTB Branch submits onward to SBP on monthly basis . Teller i. Takes customer’s signature on back side of voucher and matches the same with the original CNIC and copy of CNIC attached with voucher. Teller makes cash payment to custom er. ii. Teller posts the voucher in system through batch creation and affixed the “Posted” stamp with date. And forward to TSS/ BOM for supervision. BOM/ TSS authorized the transaction after being satisfied with the supporting documents and counter sign off. Financial Impact: Debit: 11501012 20-MONEYGRAM CONTROL ACCOUNT Credit: 2010101010 - CASH IN VAULT Note : Branch did not require sending any intimation regarding payment of Money gram to GTB Branch. GTB Branch extract at day end report from money gram utility and NIL branches GL head (1150101220 -MONEYGRAM CONTROL ACCOUNT) through GL upload Day end report gen eration: Designated authorized Officer generates Day end report and validates the source documents/ Vouchers and arranges filing of the same and sign off. i. BOM/ TSS counter signs Designated authorized Officer activity ii. BOM/ TSS reviews vouchers and reconciles with report and counter sign off. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 237 5.4 SPEED CASH NOW Customer will provides digit code/ Pin to Designated authorized Officer Designated authorized Officer i. Entered digit code/ Pin provided by the customer in Samba web based application and extract detail of the message/ transaction. ii. Match beneficiary detail with message from original CNIC and takes copy of CNIC and stamp it as “Original Seen” and sign off. iii. KYC is being conducted as per KYC and AML hand book iv. Incase customer KYC is not proof genuine, then further queries will be made or the transaction will be rejected. In case of any system issue GTB has performed supervisory function and resolve the paying branch issue. v. Designated authorized Officer after being satisfied with the credential of customer, confirm the transaction on web portal and takes print of detail and prepares cash debit voucher and sign off. vi. Voucher and supporting documents forwarded to BOM/ Forex Manager for approval. BOM/ Forex Manager checks and verifies the particul ars of voucher with supporting documents and after being verified counter sign off. Cash debit voucher forward to Cash department/ teller for cash payment to customer. Note : If any, inward Home Remittance is of more than USD $10,000/ equivalent amount, th an R -Form is required, clearly stated purpose of remittance. However, if remittance is in favor of company/ Firm than R - Form must obtained from each and every company/ firm regardless remittance amount. Branch obtained signed R -form from customer, verify c ustomer signature with branch stamp and forwarded to GTB Branch. GTB Branch submits onward to SBP on monthly basis. i. Teller takes customer’s signature on back side of voucher and matches the same with the original CNIC and copy of CNIC attached with vouche r. Teller makes cash payment to customer. ii. Teller posts the voucher in system through batch creation and affixed the “Posted” stamp with date. And forward to TSS/ BOM for supervision. BOM/ TSS authorized the transaction after being satisfied with the supp orting documents and counter sign off. Financial Impact: Debit: 1060101120 -SPEED CASH -DRAFT ISSUANCE A/C Credit: 2010101010 - CASH IN VAULT Note: Branch did not require sending any intimation regarding payment of speed cash to GTB Branch. GTB Branch extract at day end report from Samba utility and NIL branches GL head (1060101120 -SPEED CASH - DRAFT ISSUANCE A/C) through GL upload Day end report gene ration: Designated authorized Officer generates Day end report and validates the source documents/ Vouchers and arranges filing of the same and sign off. i. BOM/ TSS counter signs Designated authorized Officer activity ii. BOM/ TSS reviews vouchers and reconcile s with report and counter sign off. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 238 5.5 PAYMENT THROUGH RAM Designated authorized Officer Extract report from “RAM Report” server (Information is uploaded by GTB Branch), take print and instructions forwarded to BOM/ Forex manager for approval . Note: In case the payment does not pertain to the branch or the account is untraceable, the funds will be refunded to GTB branch (0069) via HO advice. BOM / Forex Manager reviews instructions and match amount of instructions with GL H ead: 1060101040 - HOME REMITTANC E PAYABLE (GTB branch had given credit to branches GL head: 1060101040 -HOME REMITTANCE PAYABLE with total amount of instructions uploaded on “RAM report” server). After being satisfied with credential or particulars of transaction, counter sign and forwar d to DAO for further processing Note: If any, inward Home Remittance is of more than USD $10,000/ equivalent amount, than R -Form is required, clearly stated purpose of remittance. However, if remittance is in favor of company/ Firm than R - Form must obtain ed from each and every company/ firm regardless remittance amount. Branch obtained signed R -form from customer, verify customer signature with branch stamp and forwarded to GTB Branch. GTB Branch submits onward to SBP on monthly basis. Designated authoriz ed Officer gives credit to customer account through Symbol -EOC interface by using transaction code: “ HRCC ” Financial Impact: Debit: 1060101040 -HOME REMITTANCE PAYABLE Credit: Customer’s Account Note: If transaction amount exceeds the DAO credit limit, screen pop -ups “Authorization Required” message. DAO forward voucher to next supervision level for system authorization. And financial impact only shown after authorization Day end report generation: Designated authorized Officer generates Day end report and validates the source documents/ Vouchers and arranges filing of the same and sign off. i. BOM/ TSS counter signs Designated authorized Officer activity ii. BOM/ TSS reviews vouchers and reconciles with report and counter sign off. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 239 REMOTE CHANNELS SECTION 5 REMOTE CHANNELS Section Summary: This section cover s Guidelines, Instructions and Processes of all Remote Banking Produc ts/ Channels pertaining to Branches Operations only detailing ATM Operations/ Reconciliation, Smart Card, Pre-paid Visa Card, Call Center, Virtual Banking and Mobile Banking. SECTION 5 B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 240 Chapter 1 AUTO TELLER MACHINE ATMs self -service multi -functional system not only provides convenience and flexibility to customers but also helps the Bank to reduce the work load and cash handling cost at the branches counters. 1.1 FUNDS TRANSFER VIA ATM This facility is provided to MCB ATM/Smart Card holders to transfer funds instantly between Accounts within a Branch or maintained at any other Online Branch. MCB Account holder can avail this facility on registration through MCB ATM or Internet Banking – MCB Virtual. For registration t hrough MCB ATM for Funds Transfer: i. Total 4 Accounts can be registered for availing funds transfer credit facility by debiting one Account. ii. Customer is allowed 10 transacti ons for total transfer up to PKR 20,000/ - per day. iii. Dormant, In -operative or Ceased Accounts shall not be linked for the Funds Transfer facility. 1.2 MNET - MCB NETWORK FOR ELEC TRONIC TRANSACTIONS MCB has established electronic platform known as MNET for enhancing network accessibility and to secure Online financial transactions. It enables member banks customers to have instant access to Cash through largest combined Network of ATMs located across the country. 1.3 INTER -SWITCH CONNECTIVITY Inter -switch connectivity between MNET Switch and 1 Link Switch has been activated so customers of member banks can share ATM facilities of each of the other member banks. 1.4 ACQUIRER TRANSACTION S Master Card holders visiting Pakistan and using cards with Cirrus/Maestro logo can withdraw Cash from any MCB ATM which represents an acquirer transaction. This tra nsaction goes to issuer Bank after conversion of the transaction amount in US $ by applying Inter Bank Rate via Master Card International. Further, when Card holders of other Banks use MCB ATMs linked under M-Net or 1-Link switch, such transactions are also called acquirer transactions. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 241 1.5 ISSUER TRANSACTIONS When MCB Card holders withdraw Cash from ATMs of other banks (Locally or globally) they are considered as issuer transaction. In case of Visa or MC transactions our s ettlement currency with IPM is US Dollars. During the authorization process these transactions are routed to MCB in US $ for approval. MCB host system converts the Dollar amount into local currency as per the exchange rate updated in the host system. If su fficient balance is available in the Card Holder’s Account this transaction is authorized and MCB Card holder gets the amount in the currency of the country where the ATM has been used. 1.6 DISABLED, RETAINED & CAPTURED CARDS ON AT MS For security reasons the related programs are modified to Disable, Retain or Capture a Card on ATMs as follows: 1.6.1 Disabled Cards due to Excessive Wrong PIN Tries: In case the card holder enters wrong PIN at the ATM thrice, then after three wrong attempts , the card will be ‘DISABLED’ and the card holder will not be allowed to perform any activity (financial or non -financial) anymore. To activate the card customer has to call ‘Call Center’. In such instances a message on following lines will be displayed on th e ATM for customer guidance. SORRY YOUR CARD HAS BEEN DISABLED PLEASE CONTACT CALL CENTER/BRANCH FOR ACTIVATION IF YOU ARE MCB CARDHOLDER - CALL 111 -000-mcb (622) 1.6.2 Retained Cards on ATM: ATMs may retain cards on certain occasions due to technical reasons s uch as malfunction of ATM or jerk on electricity failure etc or if the Card is not taken from ATM slot within time. In such instances a message on following lines will be displayed on the ATM for customer guidance. SORRY - YOUR CARD HAS BEEN CAPTURED . CARD CAN BE COLLECTED FROM ATM BANK/BRANCH (WHERE CARD WAS CAPTURED) WITHIN 2 WORKING DAYS CARD CAN BE COLLECTED FROM CUSTOMER’S OWN BRANCH WITHIN NEXT 8 WORKING DAYS THEREAFTER, A REPLACEMENT CARD WILL BE ISSUED FOR WHICH BANK MAY CHARGE. 1.6.3 Lost / Stolen / Hot Cards: If the status of a card being used by the card holder is marked as Lost, Stolen or Hot in bank’s record it will be captured by the ATM. In such instances a message on following lines will be displayed on the ATM for customer guidance. SORRY YOUR C ARD HAS BEEN CAPTURED DUE TO SECURITY REASONS PLEASE CONTACT YOUR BRANCH/BANK FOR DETAILS IF YOU ARE A MCB CARD HOLDER PLEASE DIAL 111 -000-622 (MCB) Note : As per SBP guidelines acquiring bank will not incur any liability for fraudulent or unauthorized transactions initiated with a card which was returned to the cardholder following its retention at ATM, provided that B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 242 Acquiring Bank acted in accordance with the guidelines of SBP. Acquiring Bank however, will be liable for the losses sustained by the Issuing Bank for any fraudulent or unauthorized transactions made subsequent to card retention, if Acquiring bank failed to comply with SBP mandated guidelines. 1.7 CARD F ACILITATION CENTER ( CFC) 1.7.1 CFC Set -up To facilitate the cardholders and to respond MNET, 1 -Link switch member bank’s queries pertaining to settlement of customers’ claims and handling/exchange of captured cards at ATMs of member banks MCB, has established “Card Facilitation Center (CFC)” at MCB Tower under Operations Group Note: The self branch transaction claims are handled by Parent Branches. As per SBP mandate following two staff members are designated to handle and respond queries: Staff Na me: Mr. Talha Shafi Mr. Kashif N Qureshi Area: Manager - DRU & CFC Supervisor – CFC Tel Number: 021-32641435 021-3111000111 Ext 3514 021-3111000111 Ext 3914 FAX Number: 021-32270126 021-32270126 E-Mail Address: Talha.shafi@mcb.com.pk Kashif.nazeer@mcb.com.pk Postal Address: 14th Floor MCB Tower I.I. Chundrigar Road , Karachi 14th Floor MCB Tower I.I. Chundrigar Road , Karachi Disposition of Retained/Captured Cards: i. Cards of ‘Other Banks’ received from MCB Branches:  On receipt of cards from MCB branches pertaining to ‘other banks’ that were captured at MCB ATMs will be acknowledged and logged/entered in a register on the day o f receipt. RETAINED / CAPTURED CARDS - ‘OTHER BANKS’ (Received from MCB Branches) Sr. No Date of Receipt Cards Received From (Branch Name) Card Number Card pertains to (Name of Issuing Bank) Date Delivered to CFC of Bank Custodian Initials C-1 C-2 1 2 3 4 5 6 7 8  Cards will be sorted ‘by bank’ and will be forwarded to ‘CFC’ of respective banks under a cover letter mentioning the number and details of the cards through courier latest by next working day.  Update the register with delivery status of cards sent to banks. ii. Cards of ‘MCB’ received from Other Banks: RETAINED/CAPTURED CARDS - ‘MCB’ (Received from Other Banks) Sr. Date of Cards Received From Card Number Card pertains to (Name Date delivered to Custodian Initials B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 243 No Receipt (Bank Name) of Issuing Branch) MCB Branch C-1 C-2 1 2 3 4 5 6 7 8  On receipt of cards from CFC of Other Banks pertaining to ‘MCB Branches’ that were captured at their ATMs will be acknowledged and logged/entered in a register on the day of receipt.  Cards will be sorted ‘by branch’ and will be forwarded to respective branches under a cover letter mentioning the number and details of the cards through courier latest by next working day.  Update the register with delivery status of cards sent to branches. Note : All Retained/captured cards must be kept under dual custody. 1.8 ATM CUSTODIANS RESPONSIBILITIES All ATM equipped branches are required to formally designate TWO officials of the branch as ATM Custodians to handle Cash Replenishment, balancing of ATM Cash and Reconciliation of ATM Cash with related Cash -in-ATM GL of the branch on a daily basis The ATM Custodians in addition to other assigned duties (core responsibilities/functions) in the branch are responsible for the following tasks. i. As per Institutional and Regulatory requirements it is a MUST to perform the following functions on each working day: ii. Daily Balancing of ATM cash . (For detailed process refer to Section 4: 1.11 Daily Balancing of ATM Cash iii. Daily Reconciliation of ATM Cash with ‘Cash -in-ATM GL’ of the branch. (For detailed process refer Section 4: 1.14 Reconciliation of ATM Cash with Cash -in-ATM GL iv. Cleanliness and up -keep of the ATM booth and manage the maintenance as per the Daily Health Checklist (refer to Annexure XI ) v. Customer issues resolution and coordination with Customer Facilitation Center (CFC) for settlement of claims. vi. Maintain check on ATM consumable items (journal roll, consumer receipts and ribbons) and replace them on timely basis. vii. Maintain/check ATM regulatory compliance item (CCTV, Hotline, Complain box & ATM Room Door lock) viii. Maintain ATM U P time and other networking equipments to be in order. ix. Arrange and maintain a backup contingency in case of long disruption in the network link. x. Maintain liaison with ATM Operations (ITD) and the Vendor. 1.8.1 Precautionary Measures/Check -list: i. Daily Cash Replenishment process should be according to the replenishment guidelines provided by ATM Team. (Please refer to the procedural manual on ATM Operation). ii. Make sure that good quality currency notes are used in the ATM Cash Dispenser. (Notes with staple/tape , punch hole, cut marks and soggy notes are not fed into the cassettes). iii. Make sure that only good quality of ribbons and paper for scroll /receipts is used. iv. Regularly monitor the ‘paper out’ status indicated through the sensors to ensure smooth running of the machine (Please note that the ATM becomes inoperative when journal printer goes out of paper). v. Each day before leaving the branch, make sure that adequate cash is fed to the ATM machine according to the overnight requirement. vi. Ensure that ATM is connected with GENSET & sufficient fuel is available for GENSET operation during power outage. Special arrangement to be made for GENSET operation during off -hours/off -days vii. Check ATM machine physically on daily basis for any unauthorized/suspicious attache d devices and B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 244 immediately update ATM Monitoring cell 1.8.2 General: i. Daily cleaning of ATM screen from inside and outside and regular trash -bin cleaning. ii. Ensure that ATMs are serviced by the vendor as per the agreed time frame established in the agreement. (as p er arrangement ATM vendor to perform complete preemptive maintenance activity once every Quarter) iii. Maintain a complaint log register and record all repair/maintenance activities on the machine by the vender/engineers. The movement of ATM parts either for re pairs/replacement should also be entered in the register. iv. Make sure to keep an updated record of names and contact numbers of the related vendors and the Centralized ATM Monitoring Cell personnel for quick reference. v. Do not allow unauthorized personnel to perform any maintenance/ repair work on the machines. Incase please contact the centralized ATM monitoring cell immediately 1.9 ATM CASH REPLENISHME NT ATM Custodians are required to visit the ATM for Cash Replenishment purpose at 15:00 Hrs on a daily basis and shift the ATM status from “Active” to “Supervisory Mode” and will: i. Remove the remaining cash from all cassettes including Divert Cassette. ii. Clear Cash Counter before replenishment the new cash in ATM. iii. Physically count and load the cassettes with fresh cash. iv. Start the ATM for next cycle. v. While performing the Cash Replenishment, obtain the following information:  Cassette Notes by Denomination.  Divert Cassette Cash Position.  Total amount Disbursed during the cycle.  Total Cash Remaining in ATM and; vi. Remove t he Scroll along with summaries printed by the machine. (For detailed process please refer to the IT Division procedural manual on ATM Operation). Physically count the ‘Remaining Cash’ amount found in the ATM and post the following vouchers in GL: Dr: Cash in Vault - (2010101010) Cr: Cash in ATM - (2010301010) For the fresh cash being loaded in the ATM prepare the following General Ledger Vouchers (GL) and post the same in General Ledger Module >> Transactions >> Batch Maintenance >> Entry (Screen # GL-21). Dr: Cash in ATM (2010301010) Cr: Cash in Vault (2010101010) Report of the above mentioned Batch can be retrieved from General Ledger Module >> Reports >> Daily Activities >> Batch Listing (Screen # GLA - 11). B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 245 1.10 CASH VAULT OPENING / CLOSING ON AN OFF-DAY / HOLIDAY ATM Custodian pro -actively checks cash position of ATMs and identify replenishment requirements. In case of outage, he/she gets a call from ATM Unit Karachi intimating cash outage in the branch ATM ATM Custodian calls the branch cash vault key holder(s). As a precautionary measure, ROM should be intimated about the same. Before opening cash vault, the vault ‘cash position’ is verified with the cash book and ATM Cash is checked (fact sheet). Security code for the vault door is disarm ed (if applicable). The code should only be known to the custodian(s). The key holders must ensure that all entrances leading to the vault are secured and no unauthorized persons are present. Both key holders jointly open the cash vault. Take out required cash from cash vault. Vault opening time is noted in the vault register and both custodians sign -off on the register. Cash debit voucher (non post able) is prepared and signed by both key holders and placed in the cash vault. In case both bins are not em pty, copy of the scroll with remaining cash recording should be annexed to voucher (non post able) and kept in cash vault. Cash safe(s) are securely locked and checked by both custodians to that effect. The vault closing time is noted on the vault registe r along with signatures of both custodians. The security code is activated (if applicable). Cash is replenished in the ATM as per the normal ATM cash replenishment process Cash debit voucher is posted in the system on next working day Note: i. Offsite ATM will not be replenished on a off -day ii. Branch Operations Manager should ensure Branch security Protocols are strictly adhered while visiting the Branch on a off -day/ holiday for ATM Cash replenishment 1.11 DAILY BALANCING OF A TM CASH As per the institutional and regulatory requirement it is mandatory for the ATM custodian to physically count and balance the ATM Cash on a daily basis. (Annexure XII) i. Individual transactions should be identified wherein customer account has been debited without cash disbursement. On the basis of verified transactions, branches should immediately complete process of ‘Automatic Credit’ which should not exceed the agreed t imeframe . However, for exceptional transactions such as partial retract and where primary evidence is not available, timeframe applicable from the date of claim by the customer. ii. Immediately after crediting customer account, the branches/Card Facilitation Centre must inform the customer in writing accordingly. iii. Customers whose account has been debited without cash disbursement should not be charged for minimum balance to the extent of the undisbursed amount and time for which it remained payable. Guidelines to prepare ‘Fact Sheet’ for balancing of ATM Cash: To balance the ATM cash custodians are required to prepare ‘Fact Sheet’ for each working day and ensure that the ATM cash is balanced. (Annexure XII ). Fact Sheet has four secti ons: B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 246 1.11.1 Cash Status This section contains the details of ATM Cash related data: i. Cash added in ATM ‘previous’ day: (Marked ‘A’ in the last column on Fact Sheet under category – Cash Status) This is the amount of cash that was replenished in the ATM at 15:00 Hrs the previous day. Ensure that:  The amount of cash that was replenished previous day is in agreement with the value of cash as per ‘ATM counters’ that were updated by the custodians at the time of cash replenishment. Custodian should print the cash repl enishment summary totals and keep it as a record.  The amount of cash that was replenished is in agreement with the value of ‘voucher’ used for updating the ‘Cash -in-ATM GL’ for the day. Copy of voucher should be kept with Cash Replenishment Summary. ii. Expect ed Remaining Cash: (Marked ‘O’ in the last column on Fact Sheet under Category –I ‘Cash Status’) This is the amount of remaining cash that is calculated by the ATM based on its counters (total cash in the ATM – Cash dispensed). This information is provided on ATM Scroll in the form of number of remaining notes for each category. Custodian should print the ‘cash replenishment summary totals’ at the time of cash replenishment to get this information and calculate the amount. iii. Actual Cash Found in ATM: (Marked ‘ P’ in the last column on Fact Sheet under Category –I ‘Cash Status’) This is the remaining cash amount found in the ATM at the time of cash replenishment and MUST be physically counted by the custodian. 1.11.2 Suspect Transactions : There are instances when the ac tual cash does not get dispensed to the customer from the ATM against suspect/un -authorized transactions due to malfunctioning of the ATM or due to communication issue, this situation may demand further investigation. This section contains the details (num ber of transactions and related amount) of Suspect Transactions for the day: i. Presenter error and Cash Retracted (Error Code 66 & 67): (Marked ‘R’ in the last column on Fact Sheet under Category -II ‘Suspect Transactions’) These are the transactions where ATM did present the cash but the customer failed to collect the cash within the specified time or ATM could not dispense the cash due to dispenser failure. As a result, the cash is with held or retracted by the ATM. These t ransactions are shown on the scroll as ‘authorized’ with a message “PRESENTOR ERROR” whereas, on the ATM Transaction Details & Summary Report the status of these transaction are marked as Response code 66 and under the dispensed amount column the amount is shown as ‘zero’. (These instances will result in ‘cash excess’). ii. Account debited against Response Code ‘99’ for MCB: (Marked ‘S -1’ in the last column on Fact Sheet under Category -II ‘Suspect Transactions’) The status of these transactions on ATM Transacti on Details & Summary Report is shown as ‘Suspect (Response code 99)’. There can be two scenarios as under: B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 247 Scenario Status On ATM Activity Report Status of Customer Account Transaction Status on GLA -29 Report Status Of Transaction on ATM Scroll Cash Dispen se Status 1 99 A/c Debited Included on GLA -29 “Transaction Authorized” Dispensed 2 99 A/c Debited Included on GLA -29 Missing on Scroll No Dispense For ATM Cash balancing purpose custodian is required to include only those transactions which meet the conditions given in scenarios # 1 i.e. Transaction is authorized on the scroll. Transactions falling under scenario # 2 will not impact ATM Cash but will create a difference in GL. To resolve this difference please refer the ‘Guidelines to Rec oncile Cash -in-ATM -GL. Note : While checking the status of suspect transactions ATM custodian MUST print customer account statement to evidence the DEBIT in customer account and should be kept as a record with Fact Sheet. iii. Funds received against Response Code ‘99’ for 1-Link: (Marked ‘S -2’ in the last column on Fact Sheet under Category -II ‘Suspect Transactions’) Similar to category (ii) above these are the 1 -Link suspect transactions for which funds are received from the ‘s witch’ and ATM has dispensed cash to the customer. iv. Funds received against Response Code ‘99’ for MNET : (Marked ‘S -3’ in the last column on Fact Sheet under Category -II ‘Suspect Transactions’) Similar to category (ii) above these are the MNET suspect tran sactions for which funds are received from the ‘switch’ and ATM has dispensed cash to the customer. v. Funds received against Response Code ‘99’ for MDS : Marked ‘S -4’ in the last column on Fact Sheet under Category -II ‘Suspect Transactions’) Similar to cat egory (ii) above these are the MDS suspect transactions for which funds are received from the ‘switch’ and ATM has dispensed cash to the customer. 1.11.3 Cash Balancing Summary : This is the section where above amounts given in Category I & II are considered for balancing the ATM Cash: i. Cash Fed in ATM previous day: (Marked ‘A’ in the last column on Fact Sheet under Category –III ‘Cash Balancing Summary’) This amount is taken from last column ( marked ‘A’ ) under Category –I ‘Cash Status’ on Fact Sheet. ii. Cash Dispensed to MCB Customers – (Response Code ‘00’): (Marked ‘B’ in the last column on Fact Sheet under Category –III ‘Cash Balancing Summary’) This is the amount of successful transactions of MCB customers for which ATM has dispensed cash during the day. However, to make this task easier for the ATM custodians a ‘NEW’ report is developed titled ‘ ATM Transaction Detail & Summary Report ’ (Annexure XIII). This new report is a replacement of old RAMS report and is ‘Transaction Sequence Range’ based. It pr ovides flexibility to the user to extract & print the complete activity of an ATM from ‘ Cash Replenishment Time ’ of day 01 to ‘Cash Replenishment Time ’ of day 02 which is the key fact or for balancing the ATM cash. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 248 To capture the complete activity for the day for which cash is being balanced the custodian is required to:  Note down the ‘1st sequence’ number immediately after first Cash Replenishment of day 01 and the ‘last sequence’ number before the last Cash Replenishment of day 02 from AT M Scroll.  Print the new ‘ATM Transaction Detail & Summary Report’ for the range of above sequence numbers that were noted from ATM Scroll. Note down the total amount of cash dispensed given in the summary at the end of the report under the column (1) “Res = 00” for MCB customers for input in this field. Note: The old RAMS report being used for this purpose is ‘inadequate’ and should NOT be used anymore. iii. Cash Dispensed to 1 -Link Customers – (Response Code ‘00’): (Marked ‘C’ in the last column on Fact Sheet u nder Category –III ‘Cash Balancing Summary’) This is the amount of ‘successful transactions’ of 1 -Link customers for which ATM has successfully dispensed the cash during the day. (Follow the above process to get this amount from ‘ATM Transaction Detail & Su mmary Report’ ). iv. Cash Dispensed to MDS Customers – (Response Code ‘00’): (Marked ‘D’ in the last column on Fact Sheet under Category –III ‘Cash Balancing Summary’) This is the amount of ‘successful transactions’ of MDS customers for which ATM has successful ly dispensed cash during the day. (Follow the above process to get this amount from ‘ATM Transaction Detail & Summary Report’ ). v. Cash Dispensed to MNET Customers – (Response Code ‘00’): (Marked ‘E’ in the last column on Fact Sheet under Category –III ‘Cash B alancing Summary’) This is the amount of ‘successful transactions’ of MNET customers for which ATM has successfully dispensed cash during the day. (Follow the above process to get this amount from ‘ATM Transaction Detail & Summary Report’ ). vi. Suspect amount debited against Error code ‘99’: (Marked ‘S’ in the last column on Fact Sheet under Category –III ‘Cash Balancing Summary’) Input the total of ‘Response Code ‘99’ transactions noted in last column marked ‘S’ on Fact Sheet under the Category -II ‘Suspect Transactions’. vii. Cash found (counted physically) from all cassettes: (Marked ‘P’ in the last column on Fact Sheet under Category –III ‘Cash Balancing Summary’) Input the ‘Remaining Cash’ that was found in the ATM and given in last column marked (P) on Fact Sheet under Category -I ‘Cash Status’. viii. Cash Fed in ATM if any, after flag time (15:00 M): (Marked ‘Q’ in the last column on Fact Sheet under Category –III ‘Cash Balancing Summary’) Input the amount of ‘additional’ Cash Replenishment if any made during the day from ATM Scroll Replenishment Summary. ix. Difference: (Marked ‘W’ in the last column on Fact Sheet under Category –III ‘Cash Balancing Summary’) Make totals of two the c olumns (Debits & Credits) Debits : Cash fed in ATM previous day + Cash fed in ATM after flag time 15:00 PM, if any. Credits: Total cash dispensed + Suspect amount debited against error code 99 + Remaining Cash found in ATM). B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 249 Compar e the Debit and Credit totals:  If the ‘Total Debits’ a gree with ‘Total Credits’ then there is no difference and ATM Cash is balanced.  If the ‘Total Debits’ do not agree with ‘Total Credits’ then ATM Cash has a difference. Custodian is required to investigate this difference. 1.11.4 Itemized Details of Difference: Difference if any, MUST be investigated to identify the transaction(s) creating that difference and it is mandatory for the custodian to individually list the details of these transaction(s) in this section. Resolution of Difference: For resolution of dif ference it is mandatory for the ATM custodian to: i. Check that the transaction(s) creating the difference are listed in ‘Proactive Module’. ii. Post Cash with ATM GL balancing carried out of the same date. iii. Check from statement of account (MCB customers) that cu stomer account was debited. iv. Check the status of ‘receipt of funds’ for MNET, 1 -LINK & MDS related transactions from Switch Settlement Unit. 1.12 STEPS TO FOLLOW FOR CASH BALANCING IN CA SE RAMS REPORT IS NO T AVAILABLE 1.12.1 ATM Cash Balancing (From Scroll) i. Take physical scroll of ATM & manually calculate cash dispense totals for MCB & Non MCB transactions. ii. MCB C ards bin # (5893887 & 5893882). Rest of the card numbers will be for other banks using on MCB ATM. iii. Cash withdrawal entries totals of ATM transaction s for cash balancing to be considered from 1st sequence number after last cash replenishment ( 15:00 hrs ) to last sequence number of current date before cash replenishment at (15:00 hrs.) iv. Combined totals for MCB & Other banks cards & consider it as cash dispensed. v. ATM Scroll also need be checked for problem transactions e.g. response codes 99 / 66 / 28 etc to validate cash dispense status to ensure proper cash balancing. vi. Now compare cash replenished previously against the cash dispensed plus remaining cas h as per existing process requirement to find any difference and then identify relevant transaction creating the differences as detailed in the process guidelines for preparing the Fact Sheet. vii. An ATM with no problem transactions would ideally be balanced for cash. viii. Follow steps mentioned above to carry out Cash balancing (without RAMS report support) exercise daily till RAMS is available. Upon RAMS report availability all the workings for Cash balancing must be reconciled by generating required RAMS reports of the said dates to ensure error free process continuation in this regard. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 250 1.13 SBP MANDATED TIMELIN ES FOR ”AUTOMATIC CREDIT” OF SUSPENSE ATM CASH Following is the summary of the SBP TATs mandated for Proactive resolution of failed to cash dispensed ATM transactions by the acquiring banks. Exec. of trx. by a card holder of: Procedures & Max. No. of Business Days Max No. of Days Same Bank at Same Branch  Branch to re credit the customer’s account Next Business Day Same Bank at Different Branch, Intra -City (Within Same City).  Acquiring Branch, after clarification, to issue credit instructions to its card issuing branch to inform its CFC.  Card issuing branch to re -credit the customer’s account 3 Business Days Same Bank at Different Branch, Inter -City (Diffe rent cities)  Acquiring Branch, after clarification, to issue credit instructions to its card issuing branch and inform its CFC.  Card issuing branch to re -credit the customer account. 4 Business Days Different Banks within same city -member of same switch (M-NET or 1 - Link).  Acquiring branch, after verification, to issue credit instructions to its CFC (within 3 Business Days)  Acquiring bank CFC to issue credit instructions to its respective switch. (Same day )  Respective switch -(M-NET or 1 -Link) to issue cred it instructions to its issuing bank CFC. (Within 1 Business day)  Issuing bank CFC to issue credit instructions to its card issuing branch. (Within 1 Business day)  Card issuing branch to re credit the customer’s account. (Within 1 Business day) 6 Business Days Different Banks in different cities -member of same switch (M -NET or 1 - Link).  Acquiring branch, after verification, to issue credit instructions to its CFC . (within 3 Business Days)  Acquiring bank CFC to issue credit instructions to its respective switch -(M-NET or 1 -Link) . (Same day )  Respective switch -(M-NET or 1 -Link) to issue credit instructions to its issuing branch. (Within 1 Business day)  Issuing bank CFC to issue credit instructions to its card issuing branch. (Within 1 Business day)  Card issu ing branch to re credit the customer’s account. (Within 1 Business day) 6 Business Days Different Banks within same city -member of different switch (M -NET & 1-Link)  Acquiring branch, after verification, to issue credit instructions to its CFC . (within 3 Business Days)  Acquiring bank CFC to issue credit instructions to its respective switch -(M-NET or 1 -Link) . (Same day )  Respective switch -(M-NET or 1 -Link) to issue credit instructions to the other switch -(M-NET or 1 -Link or Vice Versa) . (Within 1 Business d ay)  Other switch to issue credit instructions to its issuing bank CFC-(M-NET to 1 -Link or Vice Verse) . (Within 1 Business day)  Issuing bank CFC to issue credit instructions to its card issuing branch. (Within 1 Business day)  Card issuing branch to re credi t the customer’s account. (Within 1 Business day) 7 Business Days B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 251 Different Banks in different cities -member of different Switch (M -NET & 1-Link).  Acquiring branch, after verification, to issue credit instructions to its CFC . (within 3 Business Days)  Acquiring bank CFC to issue credit instructions to its respective switch -(M-NET or 1 -Link) . (Same day )  Respective switch -(M-NET or 1 -Link) to issue credit instructions to the other switch -(M-NET or 1 -Link or Vice Versa) . (Within 1 Business day)  Other switc h to issue credit instructions to its issuing bank CFC-(M-NET to 1 -Link or Vice Verse) . (Within 1 Business day)  Issuing bank CFC to issue credit instructions to its card issuing branch. (Within 1 Business day)  Card issuing branch to re credit the customer’ s account. (Within 1 Business day) 7 Business Day Serial No. 1 -3 is relevant where an account holder executes a transaction at an ATM installed at branch of card issuing bank. Serial No. 4 -5 is relevant where an account holder executes a transaction at an ATM installed at branch other than the card issuing bank’s branch. However, both banks i.e. card issuing and ATM on which transaction was executed, are member / connected with the same switch; either M -NET or 1 -Link. Timelines given in this annexure are a lso applicable on off -site ATM’s with 2 additional business days in each scenario 2 business days are added for tier -2 cities i.e. remote cities which are other than Karachi, Lahore, Islamabad and Rawalpindi and will be applicable on both same city and dif ferent cities cases Note i. TAT starts from next business day of transaction date ii. For Off -Site ATM’s 2 additional business days are provided iii. 2 More Business days are added for Tier 2 cities (i.e. Cities other than Karachi, Lahore, Islamabad, & Rawalpindi) for both same city and different cities cases. Terminology used in above table: i. Issuer: Card Issuing Bank ii. Acquirer: ATM branch of the bank iii. CFC: Card Facilitation Centre iv. DRU: Dispute Resolution Unit 1.14 RECONCILIATION OF AT M CASH WITH CASH -IN-ATM GL As per the institutional and regulatory requirement it is mandatory for the ATM custodian to Reconcile ATM Cash with “Cash -in-ATM GL” of the branch on a daily basis (Annexure XIV). Difference if any, must be investigated to fin d out the transaction(s) creating the difference and corrective entries should be passed the same day. 1.14.1 Guidelines to Reconcile ATM Cash with Cash -in-ATM GL: The branch GL for Cash -in-ATM reports the status of ATM Cash as of end -of-day (00:00 Hrs) when SYMBOLS end of day is executed. To reconcile the physical cash in the ATM with the corresponding balance on the GL it is required to get to know the ATM Cash pos ition at the end of day at 00:00 Hrs. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 252 SECTION “A” : ATM Cash Position at the end of previous day (24:00 Hrs) To find out the cash position at the end -of-previous day ATM custodians are required to perform the following steps: i. Remaining Cash in the ATM: Count the physical ‘remaining cash’ found in the ATM at the time of cash replenishment at 15:00 Hrs (it should be the same amount that is used for balancing ATM cash for the day). ii. Additional Cash Replenished, If any Any additional cash replenishments durin g the day except to standard time of 15:00 to be subtracted iii. Cash dispensed after end -of-previous day till Cash Replenishment time: Calculate the cash that was dispensed after ‘end -of-day’ (00:00 Hrs) until Cash Replenishment time (15:00 Hrs). This is the a mount of cash that was available in the ATM at end -of-day (00:00 Hrs) and was dispensed after end -of-day until cash replenishment time (15:00 Hrs) and as such, should be considered as ‘physical cash’ on hand for GL reconciliation purpose. To get this amou nt follow the step given below: Note down the 1st transaction sequence after Symbols EOD (00:00 Hrs) for previous day and the last transaction sequence number before the cash replenishment for the day from ATM Scroll. Then print the “ATM Transaction Detail s & Summary Report” for the noted sequence range. (For this purpose, week -ends & holidays should be treated as one Business day). This amount can also be calculated manually from ATM Scroll by adding up the total successful cash withdrawals for the given t ransaction sequence numbers . iv. Cash dispensed on previous Business day for MNET, 1Link, MDS transactions: This is the amount of cash that was dispensed for ‘Others’ (MNET, 1Link & MDS) customers on previous day but not posted/updated on the GL for the day du e to system limitations and as such, should be considered as cash on hand for GL reconciliation purpose. To get this amount follow the step given below: Note down the 1st transaction sequence number after midnight of day before previous day and the last t ransaction sequence number before the midnight of previous day . Print the 'activity report' from new RAMS report for the noted transaction sequence range. v. Total Cash in ATM at the end -of-day (00:00 Hrs): Calculate the amount of physical cash that was available in the ATM at the end of previous day (00:00 Hrs) by adding up the amount of point Nos. 1, 2 and 3 above. SECTION “B” : GL Balance of Cash -in-ATM for the day: Note down the GL balance for Cash -in-ATM of the branch for the day from GLA -91 report o f the branch. SECTION “C” : Difference between ATM Cash vs. Cash -in-ATM GL: Compare the ‘total cash in ATM’ given under point # 4 above which should agree with Cash -in-ATM GL balance given under point # 5. The difference, if any must be investigated and corrective entries must be passed the same day. However for differences relate d to response code 99 and 66 must be validated through ‘Proactive module’ and marked for required action taken. Possible scenarios of difference: i. Ensure that MNET/1LINK/MDS/MIBS offline entries of the day before previous day are B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 253 posted/updated on the GL. For all response code 99 transactions of MNET & 1Link funds are exchanged by the switch & credit for the same amount is due in Cash with ATM GL of the branch. ii. Cash dispensed but NO accounting entry is passed by the system (i.e. Debit customer & Credit cash). In this scenario GL will be more than the physical cash. For such instances custodian should: Dr= Customer Account Cr= Cash in ATM GL iii. Cash retract instances where ‘cash excess’ was highlighted during balancing of ‘ATM Cash’. In these instances physi cal cash will be more than the GL. For such instances custodian should: Dr= Cash in ATM GL Cr= Customer Account iv. Suspect transactions (code=99) where customer account is debited, cash is NOT dispensed but the transaction is included in “Cash in ATM Accounting Entries Report” for GL update. In these instances though the physical cash on Fact Sheet will be balanced but will create difference while reconciling the GL (Physical cash will be more). For such instances custodian should: Dr= Cash in ATM GL Cr= Customer Account Note : Do not reverse the transaction using manual entry through vouchers EXCEPT for ‘Partial Dispense’ instances SECTION “D” : Itemized Details of Difference: Difference if any, MUST be investigated to identify the transaction(s) creating that difference and it is mandatory for the custodian to individually list the details of these transaction(s) in this section. 1.15 STEPS TO FOLLOW FOR GL BALANCING IN CASE RAMS REPORT IS NOT AVAILA BLE 1.15.1 ATM GL Balancing (From Scroll) i. Take remaining physical cash position till 15:00 hrs. ii. Any additional cash replenishments during the day except to standard time of 15:00 to be subtracted. iii. Take physical scroll of ATM & manually calcul ate cash dispense totals for MCB & Non MCB transactions from 1st sequence number after 00:00 hrs till 15:00 hrs last sequence # before cash replenishment of the current day. iv. MCB Ca rds bin # (5893887 & 5893882). Rest of the card numbers will be for other banks using MCB ATM. v. Take other banks transactions (MNET / 1Link / MDS) from physical scroll of night before previous sequence # between 00:00 to 00:00 hrs last night for e.g. if today is August 04, 2010 then sequence # to be considered for this step woul d be of following timing August 03, 2010, 1st sequence of this date after 00:00 hrs till last sequence # 00:00 hrs of the same date. (August 03, 2010 24hrs). vi. Add all above three figures to work out cash in ATM at 00:00 hrs last night. vii. Take Cash with ATM GL balance from the GLA 91. viii. Compare both figures to work out the difference if any. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 254 ix. In case of differences, it need be resolved and said differences noted in section – D, however due to any unforeseen situation if difference could not be resolved the same day and its impact need be accounted for and carried forward to next day balancing exercise to have proper GL balancing be done onward & keep the required process continuity. x. Follow steps mentioned above to carry out GL balancing (without RAMS report supp ort) exercise daily till RAMS is available. Upon RAMS report availability all the workings for GL balancing must be reconciled by generating required RAMS reports of the said dates to ensure error free process continuation in this regard. 1.16 MCB ATM / SMART CARD PROACTIVE TRANS ACTION SETTLEMENT MCB ATM/Smart Card Proactive Transaction settlement Module is an intranet -based module that runs in all MCB branches & Dispute Resolution Unit (DRU). Branches can view all the suspect transactions of last working day pertaining to their ATM/s. The list of suspect transaction is uploaded in the system on daily basis. These suspect transactions are of Response Code ‘99’ and ‘66’ only. 1.16.1 Suspect Transaction Categories: The suspect Transactions are divided in three main categories: i. Self Branch Suspect – (Where Card and ATM machine pertains to same MCB Branch) ii. Cross Branch Suspect – (Where Card and ATM machine pertains to different MCB Branches) iii. M-Net & 1 Link Suspect – (Where M -Net & 1 Link MCB ATM/Smart Cards are used o n MCB ATM machine) 1.16.2 Main Features: i. User can view suspect transactions, which are grouped according to their respective Branch ATM ID’s. ii. Search option is available. User can look for the suspect transactions on the basis of Date or Sequence number. iii. It prov ides reports to the branches for record keeping. iv. TAT can be monitored through these reports 1.16.3 Process to view and mark suspect transactions: The input user needs to follow the following steps in order to mark Cash Position, ‘Scroll Status’ and ‘Account Debited or Not’ against Suspect Transactions in the ATM Proactive Transaction Settlement System. i. Authorized User (By Manager) has to Login by using User ID & Password. ii. Click View Suspects Tab on the top menu bar on Main Screen. The self -branch suspect tran saction list will be displayed on the screen. For viewing Cross Branch or M -Net & 1 Link suspects, click the respective link at the top of the page. iii. Click the STAN No link to view the complete details of each suspect transaction. iv. Screen will show the deta ils such as: Sequence No, ATM ID, Response Code, Customer Name, card, account number etc. User will check the Account Debited (For MCB customer transactions) or Funds Received field (For MNET/ 1 Link transactions). Select appropriate Radio Button “Yes” or “No”. v. Select the appropriate Status on scroll (list of which is given below: Table Scroll Status) from the Dropdown list by comparing the transaction details against the ATM scroll. NOTE: It is mandatory to mark the Cash Position (list of which is given be low: Table Scroll Status) against Suspect Transaction in the said module on daily basis in order to enable the system to auto reconcile the transactions. Failure to do so will increase the number of suspect transactions in the system . B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 255 Response Code Defini tion: Code by which transaction status is verified for completion or rejection. Table: Scroll Status Code Status TA Transaction Authorized PE Transaction Authorized Cash Retracted PE Presenter Error NA Transaction Not Authorized EM Missing from Scroll Select appropriate Cash position from the drop down list. Table: Cash Position Status Description CB Cash Dispensed to Customer Pls. Delete NP Does not pertain to suspect CE Cash not dispensed Pls. Credit Customer Account DE Account Credited by branch Pls. delete DL Claim Settled by Branch Pls. delete vi. If the suspect transaction pertain to ‘Self Branch’ (Local ATM, Local A/C), then home branch is required to settle the claim and mark cash position in the ATM Proactive Claim Transaction Settlement Module as DL. vii. If the suspect transaction pertain Cross Branch (Local ATM, Other branch A/C) or MNET/1Link (MNET Member Bank /1 Link Card) then the transaction on ATM branch is required to mark appropriate cash position status & submit. viii. Input re marks, if any and click submit button ix. Cross Branch & MNET & 1 Link Claims will be settled by DRU based as per SBP given timeframe for transaction settlement timelines. 1.17 ATM CLAIM MANUAL SET TLEMENTS 1.17.1 ATM Transaction Dispute Form - SF-259R has the following features: i. Bank’s Acknowledgment/ Customer’s Copy portion attached. ii. Carbonized copy attached with the SF -259R for branch record. iii. There is option available for Reference or Serial number in order to m onitor the resolution and Turnaround Time of the dispute. iv. ATM Transaction Dispute Form can also be submitted to transaction originating branch in case of other MCB’s Branch customer. 1.17.2 Branches are required to follow the below mentioned process for Handling ATM Transaction Dispute Forms: i. Branches are required to maintain a separate folder for the ATM Transaction Dispute Forms (Carbonized Copy), clearly mention Claim Received Date in the columns “For Bank Use Only & Customer’s Copy”. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 256 ii. It is mandatory for the branches to maintain a log for all the ATM Claims received in a day from MCB customers and Branches by allocating Reference/Serial Number on the form for easy retrieval of information and accurate track of the claims submitted by the customers. iii. Arrange the application Date wise & segregate the folder into two parts “Resolved” and “Unresolved” cases. iv. Acknowledgement portion given in the form must be duly filled and signed by the Designated Authorized Officer (DAO) and same will be delivered to the customer for his/her record and necessary follow -up. 1.17.3 In case customer has performed ATM Cash Withdrawal transaction from other MCB branches: i. In this scenario transaction originating branch is encouraged to facilitate the customers in providing and accepting the ATM Transaction Dispute Form. After reviewing the ATM Scroll, Designated Authorized Officer (DAO) will mark Cash Position on Proactive Claim Settlement Module as per the status given in ATM Scroll. ii. If the said module is not installed in the branch, DAO will h ighlight the transaction details in the Scroll, select or note down the appropriate remarks & attach the copy of Scroll with SF -259 and forward the same to Dispute Resolution Unit for further action. Transaction sequence number is the base for identifying the status of ATM suspect transactions. Therefore among SYMBOLS Branches, Sequence number can be obtained for the suspect transaction by viewing customer Account Statement through system (EOC or MCB Report). Note: The self branch transaction claims are ha ndled by Parent Branches. 1.18 DISPUTE RESOLUTION U NIT To facilitate the branches and customers for resolution of their ‘ON -US’ ATM failed transactions and claims in timely manner, bank has established a “Dispute Resolution Unit (DRU) at MCB Tower under Opera tions Group. DRU also coordinate with Dispute Resolution Unit of MNET to resolve/settle Issuer and Acquirer ATM failed transactions and claims that are performed through MNET Switch. Note: The self branch transaction claims are handled by Parent Branches. Contact details of Dispute Resolution Unit: Tel # : 021 – 2641514 E-Mail : dru.team@mcb.com.pk Address : MCB Towers 14th Floor I. I. Chundrigar Road Karachi 1.19 ESCALATION MATRIX – ATM CASH & GL BALANC ING In ad dition to daily ATM cash and GL balancing, following matrix will be applied to highlight and resolve the remaining difference with proper follow up to ensure continuation of the process in its true spirit and avoid penalties levied by regulator due to non compliance of the required mandate by the ATM branches. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 257 1.19.1 Escalation Matrix for CBBG 1.19.2 Escalation Matrix for WBG 1.19.3 Escalation Matrix for IBG Information being escalated Escalation by Escalation to Daily ATM Balancing Report All Branch Operations Managers All Regional ATM Coordinators Summary of daily ATM Balancing Report All Regional ATM Coordinators Coordinator IBG All Regional Operations Managers Transactions > 7days with aging on a daily basis All Regional Operations Managers Head IBG Operations Summary of key issues identified Head – IBG Operations Group Head 1.19.4 Escalation Matrix for CBG – Privilege Banking 1.19.5 Definition o f Acronyms Used: Issuer: Card Holder bank / branch Acquirer: ATM branch of the bank / branch Mnet Member Bank: Bank affiliated with M -Net Switch 1-Link Member Bank: Bank affiliated with 1 -Link Switch PSD: Payment System Department (SBP) Fact Sheet: Prescribed Format being used for ATM Cash balancing GL Sheet: Prescribed Format being used for Cash with ATM GL balancing ‘00:00’ : 24 hour’s cycle of a particular calendar date (from start of a day till end of the day) Self branch: where MCB Cards and MCB ATM branch to be the same Cross Branch: where MCB Cards and MCB ATM branch are different Information being escalated Escalation by Escalation to Daily ATM Balancing Report All Branch Operation Managers All Regional ATM Coordinators - CBBG Summary of daily ATM Balancing Report All Regional ATM Coordinators Coordinator - CBBG All Regional Operation Managers Transactions > 7days with aging on a daily basis All Regional Managers General Manager / Area Operations Head Summary of key issues identified All General Managers Operations Head /All Business Heads Group Head Information being escalated Escalation by Escalation to Daily ATM Balancing Report All Branch Operations Managers All Branch Managers Summary of daily ATM Balancing Report All Branch Managers All Regional Operations Managers Transactions > 7days with aging on a daily basis All Regional Operations Managers Unit Head, Internal Control Transactions > 7days with aging on a daily basis Unit Head, Internal Control Division Head Summary of key issues identified Division Head Group Head Ops Information being escalated Escalation by Escalation to Daily ATM Balancing Report All Branch Operation Managers CBG All Regional ATM Coordinators CBG Summary of daily ATM Balancing Report All Regional ATM Coordinators CBG - Privilege Banking Coordinator CBG -Privilege Banking All Regional Operation Managers CBG Transactions > 7days with aging on a daily basis All Regional Operation Managers CBG Business Head CBG Summary of key issues identified Business Head CBG - Privilege Banking only Group Head CBG B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 258 Chapter 2 SMART CARD Smart Card is a secure and convenient deposit access instrument for payments. It allows customer 24 hour access for bill payments, cash withdrawals, fund transfers and account enquires through MCB remote banking channels. 2.1 SMART CARD – LIFE CYCLE TAT Steps 2 Business days Card Request Order Taking i. From Branch ii. From Call Center iii. Issuance of Supplementary Card 4 Business days Production & Delivery i. Card & PIN Production and Delivery ii. Custody of Card & PIN iii. Handover of Card & PIN iv. Daily Balancing of Card & PIN v. Handling of un -delivered Card & PIN Real time Activation Real time Blocking (Lost/Stolen – Hot) 1 Business day Deletion 2.2 SMART CARD REQUEST ORDER T AKING 2.2.1 From Branch: Customer: duly fills out the ATM Application ( SF-1C for “Classic Card” and SF -1(H) for “Gold Card” ) along with page two, copy of CNIC and submits the same to Customer Services Officer (CSO). CSO: Reviews the form and forwards the same to the Designated authorized officer for signature verification. Designated authorized officer: i. Verifies the details of the customer and signature from the Branch Teller Module by using BT> Transactions > Non -Financial Transactions > Customer Signatory (Screen # BT44). ii. Checks that sufficient funds are available in the customer’s account. iii. Verifies signature and account balance . Customer: leaves the branch after the signature verification. Designated authorized officer : Performs the following tasks i. Click on Smart Card Registration Icon. ii. Smart Card Registration screen access requires Login ID and Pas sword. iii. Inserts Login ID and Password. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 259 2.2.1 From Branch: iv. Screen displays four (4) different options.  Add Application  View Application  Change Password  Logout v. Clicks on ‘Add Application’ option, enters customer’s account number and clicks on submit button given. vi. Screen displays customer account details retrieved from Symbols. vii. Clicks on “Proceed” button and manually inputs the following details: viii. Card Embossing Name, Card Member Name, Card Holder CNIC #, Card Holder Cell #, Product Group, Language & Nature of the card:  Original  Re-Issuance  Supplementary  Replacement ix. After inputting the above -mentioned information, clicks on the “Submit” button. The request is automatically forwarded to the designated approver’s SCGM ID for request validation and approval. Designated Autho rized Officer (Approver): Reviews the application received and approves if the information inputted is in accordance with customer’s application form submitted. Note: After approving the applications, system automatically generates a unique Reference ID for every application. Notes down the Reference ID on the application and files it for reference. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 260 2.2.2 From Call Center: Call Center Agent: Call Center makes an outbound call to the customer to take request for debit card issuance. (All conversation with the customer will be done over a recorded line). OR Customer ’s call is received at the call center requesting for debit card issuance. ( All conversation with the customer will be done over a recorded line). Call Center Agent: Customer is verified on the basis of information in the call center CRM. Information used for verification is (4 Static + 1 Dynamic): S=Static i. CNIC number. ii. Account Number. iii. Mother’s Maiden Name. iv. Date of Birth. v. Address / Contact No. (Alternate question to be asked in case any of incorrect response to the above). D=Dynamic i. Approximate account balance. (In case of negative verification, agent will not proceed further and would request customer to visit parent branch for data correction in symbols and its updation at the call center). Agent logs the card issuance request via a E -form in the CRM by filling up the following fields based on customer’s request: i. Card embossing name. ii. Card holder’s mobile number. iii. Card Category. iv. Card Nature (New/Replaceme nt /Re -Issuance). E -form is automatically forwarded to the Call Center Internal Control unit. Call Center Internal Control: i. E-form is validated to be in accordance with the call recording. To avoid multiple card issuances, it is also ensured from the Smart Card Generation Module (SCGM) that no active debit card request for the same customer is in process. ii. (CCIC will not process the request if it is not in accordance with customer’s request recorded. On approval, E -form is automatically routed to Card O perations bucket) iii. All E -forms launched by the call center will be processed by card operations on the next day. TAT of request processing at card operations (receiving of call center request till dispatch of produced card) will be 2 working days. Card Operations (Inputer): Card issuance request is initiated from SCGM on basis of the E -form logged by the call center. Card Operations Initiating Officer initiate this request in SCGM. The initiated request is forwarded to the SCGM approver’s bucket. Card O perations (Approver): Card Operations approving Officer review the initiated request on SCGM and verify the contents against E -Form raised by the call center. Approve the request upon satisfaction & close the E-Form. (Card issuance request is logged) 2.2.3 Supplementary Cards: Bank allows issuance of Supplementary cards. Copy of CNICs of the primary card holder & applicant of the supplementary card holder should be attached against a supplementary card request. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 261 2.3 SMART CARD & PIN PRODUCTION & DELIVER Y i. Card Issuance request can be initiated by branches (via SCGM) or Call Center (via e -Form) and subsequently smart card plastics and their PINs are produced. ii. Smart cards and PINs are packaged branch wise in sealed envelopes and dispatched at the respective branch address. iii. Card PIN mailers are dispatched on the following day via separate courier to ensure security. 2.4 CUSTODY OF SMART CAR D & PIN i. All Smart Cards received are logged in the physical card log register. The card receiving date and card number is al so updated on the ATM issuance Application submitted by customer. Same process for logging is followed by the PIN custodian. ii. Cards and PINs are maintained with separate custodians. 2.5 HANDOVER OF SMART CA RD & PIN i. Custodian of smart card after viewing custo mer’s original CNIC hands over card to customer and takes receipt on the log register. Signatures of the customer should be verified from SSC. Same process is followed for delivery of PIN by its respective custodian. ii. After handing over card to customer, br anch using SCGM submits smart card activation request which is automatically routed to the call center. Customer is asked to contact call center for activation. Note: Smart Card & PIN is to be delivered/ handed -over personally to the account holder and not to any representative or attorney 2.6 DAILY BALANCING OF SMART CARDS & PIN MA ILERS At day end, Operations Manager validates the total number of Smart Cards in custody of the authorized officer against the PIN Mailers in the custody of the respective authoriz ed officer. 2.7 HANDLING OF UNDELIVE RED SMART CARDS If the Customer does not collect Smart Card within 90 days, the same is destroyed by the branch by punching holes on the card’s magnetic strip along with its PIN Code. Intimation of the same is sent to CPDU through e -mail at cpdu@mcb.com.pk with a copy to Smart Card Support Group at scard.support@mcb.com.pk . The following format is used: Customer Name Account Number Card Number B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 262 2.8 SMART CARD ACTIVATIO N Customer contacts call center and requests activation. Call center agent checks in SCGM if the activation request has been forwarded by branch. If the request has been received, agent verifies customer in accordance with call center verification standards. On positive customer’s smart card is activated. 2.9 SMART CARD BLOCKING (LOST/ STOLEN) Customer is required to contact call center to request blocking of card. Call center agent after v erifying customer in accordance with call center verification standards will block card by marking it as ‘HOT’ in the system and will provide confirmation of the same. Card once marked ‘HOT’ cannot be re -activated. 2.10 SMART CARD DELETION Customer is require d to submit written request for card deletion at the respective branch. Branch on basis of the request received will forward request for deletion via email at cpdu@mcb.com.pk with the following details: Customer Name Account Number Card Number Authorized officer at CPDU will mark the card as ‘Deleted’ in the system and provide confirmation on email. 2.11 SMART CARD PIN CHANG E PIN change option is available at all MCB ATMs using which customer can change his/her smart card PIN. The PIN is not re -issuable and therefore if a customer has forgotten smart card PIN, he/she should be advised to get the card replaced. 2.12 ACTIVA TION OF WARM (DISABL ED) SMART CARD Smart Card should disable if a card holder makes three attempts with invalid PIN. As per MCB practice, MCB Smart Card also marked Warm (disabled) after end of day cycle due to excessive wrong PIN attempts. Please note that PIN got exhausted upon 3rd wrong PIN attempt and refresh after end of day cycle. For activation of ATM/Smart Card which is marked Warm (Disabled) due to excessive wrong PIN tries following process should be followed: i. Customer will contact his/her parent branch and request for his/ her card activation. ii. Branch after validating the customer will send a card activation request to Call Center through e -mail at mcb.atmca@mcb.com.pk immediately. The card activation request (e -mail) will be initiate d by the BM or BOM. The e -mail must have the following information: B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 263 Customer Name CNIC N o. Card No. Account No. Date of Request iii. At the same time the BM or BOM will intimate the customer to contact MCB Call Center @ 111 -000- 622(MCB) after end of day cycle to reactivate his/her card. iv. On receipt of call from customer, Call Center will validate customer and check if his/her card re - activation request has been received from the branch. The card will be re -activated once both the requirements are met i.e. cust omer validation at Call Center and re -activation request from the branch. In case of negative validation, customer will be requested to visit the parent branch to update his/her demographic(s) and then contact Call Center again. IMPORTANT NOTE : Call Cente r will not re -activate the card if: i. Any of the mandatory details mentioned above in table is not provided by the branch in its re -activation request. ii. Customer does not contact the Call Center for re -activation or call same day of card disabled before 00:00AM . 2.13 ISSUANCE OF SMART CARDS TO NON -RESIDENT RUPEE ACCOU NT HOLDERS Bank can issue Smart Cards as well as supplementary cards to the individual non -resident rupee account holders. However, withdrawals through Smart cards should only be allowed in Pakistan. 2.14 HANDLING OF RETAINED / CAPTURED CARDS ON ATMS ATMs may retain cards on certain occasions due to technical reasons such as malfunction of ATM or jerk on electricity failure etc or if the Card is not taken from AT M slot within time. 2.15 COLLECTION & RECORD KEEPING OF RETAINED/ CAPTURED CARDS i. ATM custodians on a daily basis at the time of Cash Replenishment will also collect the retained/captured cards from the ATM. ii. Reset the Card Capture ‘counters’ on the ATM back to zero. iii. Check the number of retained/captured cards collected from the ATM against ATM Scroll and ensures that the number of physical cards tallies with the number of cards retained/captured reported on ATM Scroll. iv. Retained/captured cards must be kept under dual custody of the two custodians. v. Log the all retained/captured card collected from ATM for the day in ‘Retained/Captured Cards Register’ on the same day in below mentioned format. Sr. No. Date of Capture Card No. Reason of Capture Issuing Bank Name Custodians Initials Card delivered to Customer / Branch/CFC Date delivered / returned Customer Signature Custodian Initials C-1 C-2 C-1 C-2 1 2 3 4 5 6 7 8 9 10 11 12 B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 264 vi. Branches/ATM Custodians must maintain proper record/audit trail of retained, returned, cut and re - enabled cards for at least six months for the purpose of investigation of crimes related to cards. vii. ATM custodians on a daily basis must report to i ts CFC:  Details of number of cards retained, number of cards returned to cardholders and number of cards returned to Issuing Bank/Branch on daily basis.  Details of claims settled, outstanding claims and balance in suspense accounts. 2.16 DISPOSITION OF RETAI NED / CAPTURED CARDS i. ATM custodians on the request of customer may return a ‘Retained Card’ to the customer after proper identity check through the presentation of original CNIC. Signatures of the customer should be verified from SSC ii. For return of ‘Retained Cards’ to customers, custodians MUST retain photocopy of CNIC for its record and obtain customer’s signature on the Retained/Captured Cards Register as an acknowledgment for receipt of card iii. In case of doubt or as advised by the Issuing bank/branc h, the custodians may decline the return of the card to customer and forward the card to CFC of Issuing Bank through CFC of MCB along with the reasons of refusal of return to the customer. iv. Cards captured at the request of Issuing Bank must be returned to I ssuing Bank on the following working day of card capture. v. Any retained card that appears “Suspicious” (for example, plain white plastic card, cardboard card or any other card that is unusual in nature) should be preserved. (These cards may be handed over to Law Enforcement Agency when demanded, in consultation with its legal department/Fraud Management Unit and with proper documentation). Note: Retained/ Captured Smart Card is to be delivered/ handed -over personally to the account holder and not to any rep resentative or attorney 2.16.1 Time frame for disposition of Retained Cards: Pertain to customers of: Required Action by Custodians of “Acquiring Branch / ATM” Required Action by Custodians of “Card Issuing Branch” MCB Self Branch i. Hold the card at branch end under dual custody for customer’s collection. ii. If not collected by the customer within 10 Business days from the date of capture then the ATM custodians must destroy the card by cutting it into half vertically through the magnet ic stripe. iii. Maintain proper audit trail of the cards that are destroyed for record purpose. - MCB Cross Branch Hold the cards under dual custody for 02 Business days for customer’s collection. If not collected by the customer within 02 Business days, send the cards to ‘Issuing i. Hold the cards under joint custody for next 08 Business days for customer’s collection. ii. If not collected by the customer within next 08 Business days the n the custodians B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 265 Branch’ through courier and maintain proper audit trail of cards delivery. must destroy the card by cutting it into half vertically through the magnetic stripe. iii. Maintain proper audit trail of the cards that are cut/destroyed for record purpose. Other Banks (MNET, 1Link & MDS) i. Hold the retained cards under joint custody for 02 Business days from date of capture for customer’s collection. ii. If not collected by the customer within 02 Business days send the card to CFC (of MCB) & maintain proper audit trail of cards delivery. - 2.16.2 Cards of ‘Other Banks’ received from MCB Branches: i. On receipt of cards from MCB branches pertaining to ‘other banks’ that were captured at MCB ATMs will be acknowledged and logged/entered in a register on the day of receipt. ii. Cards will be sorted ‘by bank’ and will be forwarded to ‘CFC’ of respective banks under a cover letter mentioning the number and details of the cards through courier latest by next Business day. iii. Update the register with delivery status of cards sent to ban ks. RETAINED/CAPTURED CARDS - ‘OTHER BANKS’ (Received from MCB Branches) Sr. No. Date of Receipt Cards Received From (Br Name) Card Number Card Pertains to (Name of Issuing Bank) Date Delivered to CFC of Bank Custodian Initials C-1 C-2 1 2 3 4 5 6 7 8 2.16.3 Cards of ‘MCB’ received from Other Banks: i. On receipt of cards from CFC of Other Banks pertaining to ‘MCB Branches’ that were captured at their ATMs will be acknowledged and logged/entered in a register on the day of receipt. ii. Cards will be sorted ‘by branch’ and will be forwarded to respective branches under a cover letter mentioning the number and details of the cards through courier latest by next Business day. iii. Update the register with delivery status of cards sent to branche s. RETAINED/CAPTURED CARDS - ‘MCB’ (Received from Other Banks) Sr. No. Date of Receipt Cards Received from (Bank Name) Card Number Card Pertains to (Name of Issuing Branch) Date Delivered to MCB Branch Custodian Initials C-1 C-2 1 2 3 4 5 6 7 8 Note : All Retained/captured cards must be kept under dual custody. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 266 Chapter 3 PREPAID VISA CARD Plastic money is a well accepted mode of payment by virtue of aggressive credit card and debit card marketing in Pakistan. According to our focus group findings, people have deposit account relationship with mostly local banks. Moreover, a bank account pen etration is at a household level but not at individual level. Individuals especially the housewives prefer a separate card for themselves rather than a supplementary card from husband and are moving towards an individualistic outlook generally where they c an plan and control. Also, due to declining credit availability, it has become difficult to surpass the criterion made to be eligible for credit cards. This further initiates the requirement for a different solution. In addition to the above, the basic generator of revenue through prepaid is on its point -of-sale usage and in Pakistan the growth in acquiring network has increased from 20,000 in 2006 to 55,000 in 2009, identifying Prepaid as an opportunity to earn in the credit crunch persistent right now. MCB Visa Prepaid Card is pre -funded reload -able card that is easy to use and is safer than cash. The prepaid card provides a means to penetrate at an individual level by reaching new consumer and commercial segments that currently rely on cash and cheques for payment. Operating in a similar fashion to debit card accounts, but with greater flexibility and lesser risk for both the issuer and the cardholder, prepaid cards may be issued in many cases where the applicant would not qualify for a credit or debit card. Visa prepaid cards can be used to access previously deposited funds in a Prepaid account. The funds in the account may be spent by the cardholder through purchase transactions or cash withdrawals or reduced by the issuer applying fees. Initially, th is card will be launched with 5 design variants against three Prepaid packages which are subsequently differentiated with respect to the limit on maximum deposit, ATM withdrawal, POS usage and internet transaction. 3.1 BRANCH RESPONSIBILIT IES The Commercial Branch Banking Group will entertain the internal and external customers through its branches for card issuance and payment collection for load/reload. In addition to that will maintain the Inventory dispatched to the Branches for issuance. The detailed pr ocesses are given as under: i. Customer Service Officer: The CSO will be responsible for customer creation on AMS. ii. Inventory Officer: The inventory officer will be responsible for maintaining the inventory registers, monitoring the sales of cards from the bra nch and initiating card requisitions to Card Production and Dispatch Unit. iii. Tellers: The teller is responsible for crediting funds into the customer account into AMS and symbols in MCB Visa Prepaid Collection account. iv. Branch Manager/ Branch Operation Mana ger: The BM/ BOM will be jointly responsible for ensuring compliance to processes and will serve as an approving authority B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 267 3.2 PREPAID VISA – CARD ISSUANCE PROCES S The Branch process below is only for non -personalized cards only. For personalized cards the customer needs to have a non -personalized card relationship. The customer will visit the branch for the prepaid card and will be briefed out by the Branch Personnel about the product and product features. The personnel will guide the customer to perform t he following task for the issuance of Card. Customer Service Officer: i. CSO will request the customer for the Copy of CNIC and input the same on the AMS System to ensure that the customer is new to bank and is not already availing facility of Prepaid Card and also will ask for the Original CNIC of the customer and will mark “Original Seen” on the CNIC with initial. ii. In case of MCB Account holder, CSO will fill up the “VERIFICATION OF CNIC” form and will get it verified from BOM/BM and will not perform NADRA for the CNIC as the customer will already be verified at the time of MCB account opening. iii. After confirmation Back -end operational personnel/CSO will perform NADRA Verification on VeriSys for the new customer and the CSO will request the customer to fill up the application fo rm after positive verification. In case the CNIC does not get verified on VeriSys , the staff will politely refuse the customer. iv. CSO will request the Customer to fill u p the application form, read the terms and conditions and select the Card design and also sign the Application form and terms and conditions. v. CSO will ensure the completion of application form and will match the signatures on application form and on terms and conditions with the copy of CNIC provided by the Customer and will also fill up the information “For Official Use Section” and attach the NADRA verification details with the application form. vi. CSO will confirm the Card number from the Card inventory off icer for registration on AMS System. vii. CSO will input the CNIC on AMS System and input the following mandatory fields on the AMS and mark the check box provided for enrolment of value added services if opted by the Customer.  First Name / Last Name  CNIC/B -Form No  Date of Birth  Mother’s Maiden Name  Place of Birth / Gender  Marital Status  Contact Address Home or Office  City  Contact Number: Residential or Office & Mobile  Type of Package  Card Number  Monthly Income viii. CSO will save the information on AMS System and will select the Package requested by the customer as per Application Form and then will link the Card number provided by the Inventory Officer duly mentioned on the Application Form. Note: In case of any data entry mistake realized by the CSO after saving the information on AMS rectification can be done on the same day by the Branch for which BOM/BM authentication will be required for rectification if the customer did not get his activated by contacting at call center. CSO will provide the deposit slip to the c ustomer mentioning the Card Number to deposit the issuance fee in B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 268 ‘Visa Prepaid Collection Account. Teller Service Officer: Teller will collect the Fee and FED amount from the customer and credit on the AMS System (Prepaid Application Management system) an d also deposit in the Collection Account using Symbols system (Core Banking System) simultaneously. 3.3 PREPAID VISA – CARD & PIN ISSUANCE PROCESS The CSO will brief the card activation process to the customer and request the customer to collect the card and Pin Mailer from the Inventory Officer. Inventory Officers upon receipt of the deposit slip will issue the Card and Pin Mailer to the Customer and will ensure the following. Mandatory requirement for Card/PIN Mailer receiving from Inventory Officers  Customer Name  Card and PIN issued to the Customer.  Receiving Date  CNIC  Customer’s Signature  Deposit Slip Number  Issuing officer ID/Name  Issuing officer Signature At day end the Branch Operations Manager or the Branch Manager will ensure to compile all of the below mentioned documents and dispatch them to the Card Operations department so that the remaining fields of the application form can be updated on the CTL sy stem and archiving of customer information can be made at back office. i. Application form dully filled in and signed by the Customer. ii. Copy of CNIC attached with the application form. iii. Copy of Deposit slip is attached with the application form. 3.4 PREPAID VISA – LOAD / RE -LOAD PROCESS Customer will inquire the Teller or the CSO about the maximum/minimum amount that can be loaded/re - loaded on the Card. Teller Service Officer / Customer Service Officer: i. Teller/CSO will confirm that the load/reload amount on the AMS System should not exceed the card limit. The Staff/ CSO will communicate the exact reload/load amount that can be loaded on the card to the customer. ii. Customer will fill up the Deposit slip and mention the Prepaid Card Number and contact number on the deposit slip and submit it to the teller. iii. Branch teller will confirm the load/reload amount on the AMS System again and ensure that the amount should not exceed the card limit iv. In case of deposit amount exceeding the card limit teller will advise the custom er to fill up the new deposit slip with loadable amount on the Card. v. Branch teller after ensuring that the deposit amount does not exceed the card limit, deposit the funds in the Prepaid Collection Account.  Cash Payment: Teller will process the credit on A MS System so that the customer’s prepaid Card B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 269 account is credited on CTL and thereafter the teller will deposit it in Visa Prepaid Collection Account in the symbols system (Core Banking System)  MCB Cheque Payment: Teller will confirm the available balance in the symbols system (Core Banking System) prior to process the credit into AMS System and after confirmation will process the credit on AMS System so that the customer’s prepaid Card account is credited on CTL. vi. At the time of processing the payment, AMS System will request for reconfirmation of the amount that is being input by the teller. After teller confirmation, the funds will be credited in Prepaid Card Account on real time on CTL. vii. The teller will send the deposit slip copy to the CSO; the CSO will c onfirm the amount that was credited on the AMS System and sign the deposit slip after verif ication. In case, any mistake or incorrect amount is identified to have been credited on the AMS System, the CSO will inform the BOM/BM and the following will be sce narios and remedial action. Note: Payment greater than equal to PKR 10,000 require BOM authentication to post the credit into AMS. In case, Excess / Less Amount Credited on AMS (CTL) i. In case, excess or less amount is being credited on the AMS System, the transaction will immediately be reversed by selecting the card and the associated transaction in the reversal module. ii. The reversal module for every reversal will require the operations manager to enter the User ID and Password. iii. After the acceptance of the User ID and Password, the entry will be reversed . Branch will take responsibility for correctness of deposit amount transactions into the customers’ prepaid card account and the collection account for Prep aid Card Product. In case there is any discrepancy, the concerned branch will make effort to timely identify and correct the same and any related financial loss (if occurred) will be borne by that branch. However the following efforts will be put in to re cover the loss and if recovered will be refunded to the branch . In case, the Customer Avails the Excess Credit: i. In case the customer avails the excess funds that were credited in his account due to negligence of any department, the card will be blocked im mediately after identification of the same, in daily reconciliation of Collection Account vs. CTL GL. ii. This case will be forwarded to Collection and Recovery Unit for recovery of the extra credit. iii. Collection and Recovery Unit will check if the Customer is an MCB account Holder as his MCB account can be debited as per terms and conditions. iv. Collection and Recovery unit can cater to the debiting of the MCB account through seeking information from CTL v. If the customer is MCB Account holder then the excess credit will be r ecovered from the MCB Account. In case, insufficient balance card will be blocked and case will be forwarded to Collection and Recovery Unit for recovery of extra credit. vi. The ‘operations copy’ of the deposit slips will be dispatched to the Card Operation division at day end by the branch. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 270 3.5 PREPAID VISA – BALANCE ENQUIRY i. Customer may visit the Branch for the balance inquiry. ii. The CSO will verify the customer through the physical presence of the card before providing the customer with the information for balance inquiry iii. The Branch staff will input the card number on AMS System and will confirm the available balance or last payment made on the card. 3.6 PREPAID VISA – STATEMENT REQUEST i. The Customer can request for the statement of account related to his prepaid account. ii. The CSO will verify the customer through the physical presence of the card iii. The customer will be provided with the statement that is generated on the system. However, the customer will be able to inquire about the current bal ance from the call centre as well as the branch. iv. The CSO will inform the customer about the statement charges and request the customer to confirm the period for which the statement is required. The statement will reflect transactions on month to month basi s and real time transaction can be inquired about at the call centre v. After confirmation, the CSO will take the statement print outs for the specified month from AMS System. vi. Customer will deposit the statement fee through the deposit slip at Teller’s count er vii. The teller will deposit the statement fee in the SYMBOLS Visa Prepaid Collection Account only and no entry will be passed in AMS module and sign the deposit slip. viii. The teller will provide the customer with the signed deposit slip. ix. The CSO upon receipt of signed deposit slip will furnished the print outs of the statement to the Customer. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 271 3.7 PREPAID VISA – INVENTORY MANAGEMENT Branch will receive prepaid design (Bangle, Scenery etc) Cards and Pin Mailers from Card Production Unit and will manage the physical inventory of cards and Pin Mailers in the fire proof vault. The issuance will be on FIFO method and the inventory officers will record the receipt and issuance of Card and Pin Mailer s in their inventory register. The registers will be maintained on the following fields which will be filled up by the custodians. 3.7.1 Record Keeping  Card and PIN Inventory Register: i. Card/PIN Bulk Receiving Date, ii. Number of Cards/PINs Received iii. Number of Cards/PINs issued to the customer iv. Cards/PINs Recalled v. Custodian’s Signature. vi. Custodian’s ID/Name vii. Custodian’s officer Signature 3.7.2 Inventory Ordering Process  Ordering Criteria will be design based i. Branch will calculate per day consumption by dividing the cards sold in 1 month by the number of days in the month ii. Branch will calculate the re -order point by multiplying the Cards sold per Day figure with 10 iii. The branch will maintain the resultant figure as the re -order point and as the cards stock level reaches that point, branch will place order for the month iv. For special cases – whereby more inventory is required by the branch due to the sales trend, the same will be provided to them *The figures may change as the learning curve may reach maturity. The inventory Officer of the Card will analyze the daily consumption of the Card s as per above standard, initiate the requisition for the required quantity of each design to the operations manager and the branch manager. REQUISITION SLIP FOR BLANK PLASTIC OF PREPAID CARD Branch ________ DATE :___________ Please dispatch the following quantity of cards along with PINs S. No Description Quantity 1 MCDONALD 2 BANGLE 3 FLOWER 4 SCENERY 5 AEROPLANE ______________ Branch Manager ________________ Operation's Manager 3.7.3 Approval Process: i. The Operation Manager and the Branch Manager, keeping in view the daily consumption and expected issuance in a month will approve the inventory request which will be forwarded to Card Production Unit by the CSO and the hard copy of the requisition request will be couriered to Card Production unit ii. After the inventory manager has gotten approval The CSO will initiate requisition request which will be duly approved by the Operation/Branch Manager and then log the same on to AMS system. iii. Card Production Unit will review the branch request received on AMS System as per the ordering B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 272 criteria on daily basis and produce the Card as per the branch request as mentioned above in card issuance process within 4 -5 Business days 3.7.4 Inventory Recall Process: In case of less issuance from the Branch the Consumer Operation can recall the inventory from the branch and will forward to the branch where it is required. i. The Card Production Unit will inform the specific branch through courier regarding the recall request. ii. The card production unit will send transmittal report (refer “Transmittal Report for Recalling of Inventory ” attached below ) which will contain the Card number and PINs that are to be dispatched back iii. The Transmittal report format, will serve as receiving p roof from the courier company and will be signed by branch manager, operations manager, CDPU officer, Courier official iv. Inventory Officer will dispatch the Card and PINs together to the Card Production Unit. v. Card Production Unit will follow the process of r e-distributing inventory to the other branch Transmittal Report for Recalling of Inventory Dispatch Date from CPDU Dispatch Date from Branch S# Branch Name and Branch Code Card and PIN # CITY 1 2 3 ______________ CPDU – Officer ______________ Branch Manager ______________ Courier official ______________ CPDU – Supervisor ______________ Branch Operations Manager ______________ Courier official 3.8 PREPAID VISA – PROCESS FOR CAPTURED CARDS IN ATM i. MCB CFC will receive captured/retained cards from MCB Branches and other Bank’s CFC ii. As per SBP directives (referen ce SBP PSD Circular No. 1 dated April 06, 2006) Acquiring branch can keep Captured/ retained card for 2 Business days so that customer my collect it from them afte r proper identification. After 2 Business , if the card is not collected by the customer Acquiring Branch has to forward the captured/retained card to MCB CFC iii. The branch personnel will identify the customer by verifying the customer through AMS system modul e. iv. The following field(s) will be used to identify the customer  Citing of CNIC – as linked on card  First Name  Last Name v. If customer’s Personal Identification is not confirmed or if acquiring branch finds any doubt while handing over the captured / retained card, the card is then forwarded to Card Operations: Card Production and Dispatch Unit vi. All Card received at CFC gets logged in to CFC Captured Card Database on daily basis & MIS is maintained to have it submitted to management at the end of month. vii. MCB C FC forwards the captured/retained cards to Card Production and Dispatch Unit on the same day it is received to CFC after logging the details into MCB CFC database . B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 273 Chapter 4 VIRTUAL BANKING 4.1 VB REGISTRATION PROC ESS FOR INDIVIDUAL C USTOMERS i. Customer clicks on the register link on the MCB Virtual banking page ( www.mcb.com.pk ) & completes the application form. ii. Customer visits any MCB ATM, selects the option “Service Requests” and on the next screen selects “Internet Banking Regist ration” waits a while for the registration to complete and the appropriate message displays on the screen. iii. Reminder email is sent to the customer on the next day if he/she fails to visit ATM for ATM ACTIVATION. iv. Email notification is sent to the customer’s registered email address containing the Customer number & Password. v. Customer calls the MCB Call Centre on (021) 111 -000-622 to obtain their User ID. After verification User ID is disclosed to the customer. vi. After receiving the User ID, customer enjoys 24 h rs Virtual banking facilities. 4.2 VB REGISTRATION PROC ESS FOR CUSTOMERS AB ROAD For users living abroad MCB Virtual Banking Registration is a three step process. i. Customer must fill out the registration form at MCB website. ii. Send in the duly signed AUTHORITY LETTER (available on the MCB website) at the following address: MCB Virtual Banking Department 9th Floor, Sheikh Sultan Trust Building, Beamount Road, Karachi -75530, Pakistan. iii. After receiving the authority letter the application will be processed by VB Ops. This will be done once they send the letter to the branch for signature verification. Upon positive signature verification the application will be processed. Once processed an email containing the password and customer number will be sent to the cust omer. iv. Customer must then call the MCB Call Centre at 111 000 622 (MCB) to get user -id after which he will be able to login to Virtual Banking. 4.3 VB REGISTRATION PROC ESS FOR CORPORATE CU STOMERS i. All corporate customers can register for Virtual Banking ii. Custom er fill s out VB corporate customer form from his home branch. iii. Branch duly verified customer’s relation and signature. iv. After branch verification, branch send request to mention below address. MCB Virtual Banking Department 9th Floor, Sheikh Sultan Trust Building, Beamount Road, Karachi -75530, Pakistan. v. Corporate customers can either have view only access of request for designated when submitting the form for Virtual Banking registration. vi. VB Ops receives application and sen d VB link and user id & password to VB corporate customer. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 274 Chapter 5 CALL CENTER MCB Bank Ltd officially introduced Call Center in the month of August 2006. MCB Call Center is 24/7 unit which deals in suite of transaction to the customers. MCB Call Center has 2 4/7 operation and have setup in Karachi & Lahore. Both the Centers are connected with state of the art connectivity between both the units. Call Center is performing a vital role for consumer and commercial banking and providing the efficient services to th e valuable customers. 5.1 CALL CENTER REGISTRA TION PROCESS FOR NTB CUSTOMERS Customer just needs to fill in account opening form and it includes the customer consent to register him to the MCB Call Center. 5.2 CALL CENTER REGISTRA TION PROCESS FOR OLD CUSTOMERS (PRIOR 01 -JAN-09) i. Customer Fills Call Center Registration form at any MCB Branch ii. CSO/ Officer Checks the application for completeness and accuracy, Affixes the sign and bank stamp on it. iii. BOM Verifies Customer information (Customer signature & Account validation) Affix the sign and bank’s stamp on application. iv. CSO will maintain an MIS bearing A/c #, Form # and Customer contact info. v. Branch Couriers the application to COD for further processing 5.3 CONTROL GUIDELINES All the customers are verified through t hree different ways of verification: i. ATM PIN Validation ii. TPIN Verification iii. Manual Verification (Through Static and Dynamic Questions) B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 275 Chapter 6 MOBILE BANKING 6.1 REGISTRATION P ROCES S i. Visit : Any MCB ATM & select “Services Request” option from Main Menu ii. Register : Choose “MCB Mobile Registration” from the menu & enter your mobile phone number iii. Activate : Call MCB Call Centre for activation OR Simply call 111 -000-(622) MCB if you are already registered at the Call Center (All new account holders who are issued new smart cards are preregistered at the call center and can register for MCB mobile when they make a call in to the call center to activate their smart cards) i. Visit any MCB ATM ii. Select Service Request iii. GO to Mobile Banking tab iv. Select MCB Mobile Registratio n v. Enter Mobile Number vi. Re-Enter Mobile Number vii. Call 111 -000-622 for activation viii. Customer should be registered at the call center 6.1.1 Call Center Registration Process : i. Customer can also register by calling the call center at 111 -000-622 ii. Call center executive wil l verify customer details iii. Customer will be requested Mobile Number from mobile registration iv. E-form will be logged with PAN and Mobile number v. Customer will receive registration and activation SMS within 48 working hours vi. Customer should be registered at the call center 6.1.2 Change Mobile Number : i. If customer wants to update/change his/her mobile number registered with MCB Mobile, it can be done by calling Call Center at 111 -000-622 ii. Call center executive will verify customer details and request for new mobile numbe r iii. Call center executive will log e -form with PAN, existing mobile number and new mobile number iv. Customer will receive a Mobile PIN on the new mobile number in 48 working hrs v. Customer will also receive an SMS on old number stating that service is disable on that number B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 276 6.1.3 Smart card update : i. If customer wants to update/change his/her Smart Card that is registered with MCB Mobile, it can be done by calling Call Center at 111 -000-622 ii. Call center executive will verify customer details and request confirm new ATM card number from customer iii. Call center executive will log e -form with existing PAN, Mobile number and new PAN number iv. Customer will receive a registration message followed by Mobile PIN on the his mobile in 48 working hrs v. Please note that MCB Mobile will be charged separately for updated ATM Customer can de-activate the service by calling the call center at 111 -000-622 6.2 MCB MOBILE REGISTRAT IONS POS TERMINAL M ANAGEMENT 6.2.1 Receiving : i. Once the POS is received at the branch receiving form (sent along with the terminal) is to be filled / signed by Ops manager and mailed back to MCB Mobile Team on the address mentioned below. MCB Mobile Team 2nd Floor MCB Building, Khyaban -e-Iqbal, Schon circle Clifton Block 5, Karachi. 111-000-456 Ext 132 ii. POS whose receiving forms will not be received to product team in 3 Business days will be called back. 6.2.2 Installation : POS machines have to be installed at the CSO desk inside the branch. Installation of POS requires a fixed line in the branch which has to be dedicated to the POS machine. In the absence of fixed line POS will not be delivered to the branch. 6.2.3 POS operation manual: i. Insert adapter in the power port to switch the POS on. ii. Insert a fixed line free of distortion in the port, mentioned on the back of the POS (this is not valid for GPRS POS machines) iii. Check ‘Main Menu’ on the initial POS screen (first option) iv. Check transaction ‘ (TRAN)’ once inside the main menu (first option) v. Check ‘ ENROLL’ once inside the transaction menu (last option) vi. Swipe smart c ard holding the card upside down and the magnetic strip facing towards the POS. vii. Once card number displayed on the POS screen check ‘ Yes’ viii. Enter ‘ATM PIN’ ix. Enter ‘Mobile Number’ x. Wait for the registration slip xi. Registration through POS is complete B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 277 6.2.4 POS recall procedure: i. MCB Mobile product team has the rights to call the POS machines back from the branch at their own discretion. ii. As soon as the branch is intimated by the product team for POS recall the branch has to return the POS machine back within 48 hours of notification. The POS has to be returned on the following address: MCB Mobile Team 2nd Floor MCB Building, Khyaban -e-Iqbal, Schon circle Clifton Block 5, Karachi. 111-000-456 Ext 132 B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 278 CENTRALIZED & AUTOMATED OPS SECTION 6 CENTRALIZATION & AUTOMATED OPERATIONS Section Summary: This Section entails all processes which have been centralized under “Centralized Operations Division / Special project & Reconciliation ” which are part of the Operations Group of the Bank. Though these processes are centralized however there are a few activities/ functions which are to be performed by various stakeholders including Branches as well . The Section also spells out roles & responsibilitie s of the concerned stakeholders. SECTION 6 B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 279 Chapter 1 CENTRALIZATION & AUTOMATION OF BRANCH BACK -END PROCESS To relieve the branches of the burden of manual work various back -end processes that were being performed manually by the branches across the count ry have been automated and centralized Centralization & automation of these processes in addition to the productivity gains will minimize the operational errors and ensure compliance of institutional & regulatory requirements within the mandated time frame. i. Collection of Federal Excise Duty – (FED) from branches and its onward payment to the government. ii. Collection of Withholding Tax – (WHT) from branches and its onward payment to government. iii. Recovery of ‘Service Charges’ from Customer Accounts where th e balance in the account is less than the established amount of Service Charge defined in schedule of bank charges. iv. Recovery of applicable charges from customers maintaining Basic Banking Accounts (BBA) with the bank. v. Recovery of ‘ IT Account Section’ relat es expenditure from Branches. vi. Compilation and Settlement of ‘HO Pool Mark -up’ between Branches and H.O. vii. Bulk Salary Processing viii. Settlement of Treasury (TROPS) Advices. ix. Allocation of semi -annual statement rendition expenses (Stationery, Postage & Processing Cost) of SP&R to branches for rendering customers account statements. x. Allocation of COD expenses (Postage) to branches related to Centralized Clearing and Account Opening. xi. Allocation of NIFT expenses to branches for processing of Clearing and Cheque Books . xii. Allocation of ‘Cash -in-Transit’ & ‘Cash House’ Charges to Branches directly dealing with Cash House. xiii. Centralization of ‘Cash -in-Transit (CIT)’ Charges at Cash F eeding Branches xiv. Allocation of ‘Swift Processing Charges’ to Branches. xv. Allocation of Stationery Charges of MCB Employees Foundation to branches. xvi. Processing and allocation of HRMG cost (salaries) of Contractual Staff to Branches/Units. xvii. Processing of ‘Account Sweep’ Ins tructions for Utility Companies and TPD Corporate Customers . xviii. Extraction and submiss ion of data to circles for ‘un -claimed deposits/ instruments’ with an option to generate ‘Three Months Notice Period Letter’ from system for onward mailing to Customers. xix. Rendition of Semi -Annual Accounts B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 280 1.1 ROLE & RESPONSIBILIT IES OF STAKEHOLDERS Though the above processes have been automated and centralized mainly at Centralized Operations (COD) / Special Projects & Reconciliation (SP&R) under Operations Group but still require some involvement of other stakeholders (IT-Ops, CAD, TROPs, Branches) a s the process owners who are required to ensure execution and accuracy of the process and retain the output/end results of the processes performed as branch re cord in the form of hard copies. The broad responsibilities are spelled out in the form of proces s steps. 1.2 COLLE CTION OF FED FROM BR ANCHES & ONWARD PAYMENT TO GO VERNMENT Frequency: Monthly COD on 1st or 2nd Business day of each month retrieve outstanding balances under FED GL code 1090802370 and transfer the file to IT Ops through FTP utility for upload. IT Ops execute the upload process and confirm back to COD of successful execution of the upload. COD validates the results of upload and extracts the data from Symbols for onward in timation to respective Branches along with Summary of FBR Payments up to previous cycle for their record and issuance of Tax Certificate purpose Branches on receipt of data from COD, validates the impact on GL & retains the MIS with day’s voucher for record. (In case of difference or mi smatch refer to COD for corrective action). COD also forwards the data to CAD to take the impact in HO books & Recon Utility System. CAD takes the impact on HO books to park the FED liability of all branches. CAD prepares Pay Order in favor of Government Treasury for the total sum of FED liability and deposit the Pay Order at SBP / NBP. Intimate COD via email. COD retains all chain of email along with upload files for audit trail and record purpose . B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 281 1.3 COLLECTION OF WHT FR OM BRANCHES & ITS ONWARD PAYMENT TO THE GOVERNMENT Frequency: Weekly COD as per FBR given frequency, retrieves the outstanding balances under following liability GL Heads from KM module: i. 1090 601070 – WHT on Cash Withdrawal section 231 A ii. 1090601020 – WHT on Markup Paid Section 151 iii. 1090601060 – With -Holding Income tax deduct iv. 1090601080 – WHT under instruments U/S -231-AA COD transfer the data in defined folder to IT Ops through FTP utility and request IT Ops for execution of the process. IT Ops executes the upload process through interface utility & confirm back to COD. COD on receipt of confirmation validates the results and extracts the uploaded data from symbols for onward intimation to branches. Branches upon receipt of information from COD validates the impacted entries from COD provided MIS and keep the same with the day’s voucher for records & compliance purpose. (In case of any mismatch or difference refers the matter to COD for its corrective action) . COD forwards the final summary under each section (151 , 231 -A & 231 -AA) to Main Civic Center Branch (0613) Islamabad for issuance of Pay Order category -wise. Main Civic Center Branch (0613) obtains the CPR (Computerized Payment Receipt) Number through FBR provided website. Prepares the Pay Order as per the information provided by COD and deposits it to SBP/NBP along with Challan copies. Main Civic Center Branch (0613) intimate to COD & Fin Con through email regarding completion of the process and submission of Pay Order along with complete details (FBR provided CPR number & copy of Pay Order). COD retains the confirmation and copy of PO with other work papers as audit trail and record purpose. Note : The above centralized process of collection & surrendering of tax liabilities DO NOT include the following GL Heads and will continue to be handled as per the old process till further instructions: i. 1090601030 – Withholding Tax on Supplies/Services. ii. 1090601050 – Withholding Tax on Export Proceeds. iii. Any Other Tax Liability GL except listed above under point # 1 are exempted from the Centralized Process iv. FATA /PATA/Azad Kashmir/ Gilgit Baltistan Region is exempted from the mentioned centralized process. Separate instructions are issued for these regions B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 282 1.4 PAYMENT OF WHT TO TH E GOVT BY BRANCHES U NDER JURISDICTION OF AZAD JAMMU KASHMIR Branches are require to maintain a Collection account as a “TAX SETTLEMENT A/C.” to transfer the outstanding tax liability amount into collection account Surrender the WHT tax as per existing frequency. Perform the credit transaction with outstanding amount lying in following tax liability heads separately with below mentioned transaction types: i. TX01 - WHT on Profit/Interest (1090601020) ii. TX02 - WHT on Cash Withdrawal (1090601070) System will debit the said liabi lities heads and credit the funds into collection account automatically. WHT which recover manually, require to be parked in GL head 1090601060 (withholding income tax collected), as this code as post able, therefore branches are require to debit the head manually and surrender the same into Govt. Treasury as per existing practice. 1.5 RECOVERY OF SERVICE CHARGES FROM CUSTOMERS Frequency: Semi Annually COD before execution of half -yearly profit cycle retrieves the list of accounts that meet the criteria for recovery of ‘Service Charges’ but have the restraint on account that prohibits financial posting in the account. The list is sent to concerned branches. Branches review the status of restraints and correct/update the system wherever required before the half - yearly profit cycle. COD after the disbursement of half -yearly profit retrieve the information of those accounts where the outstanding balance in cu stomer account is less than the established amount of service charge given in the schedule of bank charges. COD execute the a utility on Symbols whereby the system first calculates the applicable FED amount on the outstanding balance in the account and then debit the account with the outstanding balance in the account and credit Service Charges & FED Accounts accordingly. COD after execution of the utility extract the data of these accounts from Symbols with pertinent details and forward it to concerned branches via e -mail for their record. Branches print the details of these accounts and keep it along with days voucher as record. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 283 1.6 RECOVERY OF APPLICABLE CHARGES F ROM CUSTOMERS MAINTA INING BBA ACCOUNT Frequency: Monthly COD on 1st Business day of each month retrieve the information of accounts which meets the defined criteria for deduction of BBA Service Charges from customer accounts for previous month. COD executes the process for debiting customer accounts through Symbols interface utili ty. COD informs the concerned branches about successful & rejected transactions for further action at their end. Branches are required to review the rejections and ensure recovery of applicable Service Charges from customers, if required. Branches keep t he Service Charges recovery details/reports along with the day’s vouchers for record. 1.7 COMPILATION & SETTLE MENT OF HO. POOL MAR K-UP BETWEEN BRANCHES & HO Frequency: Monthly COD on last Business day of each month retrieves the required information of HO balances for the month from KM as per the defined criteria. COD transfers these files to IT Ops in the defined folder through FTP utility for upload. COD request IT Ops to execute the GL upload pr ocess. IT Ops execute the GL upload process through symbols interface utility. IT Ops intimate COD of the successful completion of the upload process. COD validate the results and compile MIS for onward submission to branches. COD forward the calculation of mark -up based on ‘HO account balance product’ to branches for their review and confirmation. Branches validate the accounting entries and impact on their GL against COD provided details. Branches keep the reports of mark -up calculation along with the day’s vouchers for record. 1.8 BULK SALARY PROCESSI NG Frequency: Monthly i. COD receive request from employer for disbursement of salary to its staff in the form of ‘soft file’ as per prescribed format and authority letter to debit its account with the bank. ii. COD request parent branch to verify the Customer’s signatures . iii. COD execute the RB -upload process through symbols interface utility. iv. COD after execution of the upload process forward the results along -with rejections to employer and parent branch for valid ation/ rectification . v. Parent branch will responsible for rectification of rejected transactions on same day vi. Customer validates the output . In case of any exceptions customer confirms to COD through e -mail . vii. COD keeps the employer’s request (debit authority & Credit MIS) as record. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 284 1.9 SETTLEMENT OF TREASU RY (TROPS) ADVICES Frequency: Monthly Treasury Operations (TROPS) transfer the upload files for the following in defined folder through Tr easury System and request IT Ops to execute th e upload process via auto email keeping COD into loop . i. Cash reserve requirement cost ii. Exchange Diff on FCY deposit iii. FC Deposit equalization Fees iv. FX Income Sharing v. Compensation on Foreign Bill Purchase IT Ops execute the upload process and confirms the succe ssful completion of the process to COD through e - mail. COD extract the details of upload from symbols and prepare MIS for onward submission to branches. COD extract the details of upload from symbols after all executions and prepare MIS for onward submission to branches Branches validate the accounting entries and impact on their GL against COD provided MIS. Branches keep the record of trail for audit/compliance. 1.10 ALLOCATION OF COD POSTAGE EXPENSES TO BRANCHES RELATED TO CENTRALIZ ED CLEARING & ACCOUNT OPENING Frequency: Monthly Central Processing Unit, Karachi (CPU) forwards the invoice copy to CAD for issuing PO to vendor. CAD validates the invoices and forward the request to COD for allocation of Postages Charges to branches COD request IT Ops to execute the GL upload process. IT Ops confirm COD of successful execution of the upload process through e -mail. COD after confirmation from IT Ops extract the uploaded data from Symbols for onward intimation to branches and CPUK for validation. Branches validate the accounting entries and impact on their GL against COD provided details. In case of any exceptions CPUK informs to COD for corrective action COD after getting confirmation keep the complete trail of the process and output for record. Simultaneously, COD forward the request to CAD for making of Pay Orders in favor of courier companies by debiting respective branches. COD also provides the data fil e to CAD through e -mail to take the impact in HO books and Recon Utility System CAD takes the impact in HO books by crediting Pay Order issuance head. CAD up load the file in Recon Utility System to incorporate the HO entries for auto reconciliation. CAD issues the Pay Order in favor of Courier Company and delivers to COD . CPUK deliver the same to Courier Company and take the acknowledgement for records. COD keep the complete trail of upload process cycle. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 285 1.11 ALLOCATION OF NIFT E XPENSES TO BRANCHES FOR PROC ESSING OF CLEARING & CHEQUE BOOKS Frequency: Monthly COD receives invoice along with complete branch wise MIS from Apex Printer and NIFT against Cheque book and Clearing respectively. COD forward the invoice and detail to CAD COD crea te the data as per Symbols GL upload format and transfer the same to IT Ops in defined folder through FTP utility and request to execute the GL upload process. IT Ops confirm COD of successful execution of the upload process through e -mail. COD after confirmation from IT Ops extract the uploaded data from Symbols for onward submission to branches along with APEX / NIFT provided invoices for validation. Branches validate the accounting entries and impact on their GL against COD provided details & APEX / NIFT invoice. COD simultaneously forward the request to CAD for making of Pay Order in favor of APEX / NIFT by debiting respective branches. COD also provides the data file to CAD through e -mail to take the impact in HO books and Recon Utility System. CAD takes the impact in ho books by crediting PO issuance head. CAD up load the file in Recon Utility System to incorporate the HO entries for auto reconciliation. CAD Scrutinize the authenticity of invoices and ensure deduction of applicable taxe s /advance loan CAD issues the Pay Order in favor of printer and delivers to COD. COD deliver the same to APEX printer / NIFT and take the acknowledgement for records. COD keep the complete trail of the upload process cycle. 1.12 ALLOCATION OF CASH –IN–TRANSIT & CASH HOUSE CHARGES TO BRANCHES DIRECTLY DEALING WITH CASH H OUSE Frequency: Monthly Cash House request COD through email to allocate ‘cash -in-transit’ charges & cash house charges amongst branches as per detail s provided. COD arrange to convert the soft data as per Symbols GL upload format and transfer the same into defined folder through FTP utility. COD request I.T -Ops to execute the GL upload process. IT-Ops confirm COD of successful execution of the upload process through e -mail. COD after confirmation from I.T -Ops, extract the uploaded data from Symbols for onward submission to branches and Cash House s for validation. Simultaneously forward debit advices to respective Cash Houses for onward forwarding to Islamic branches for taking the imp act of allocations at their end. Branches validate the accounting entries and impact on their GL against COD provided details. COD keep the complete trail of the upload process cycle. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 286 1.13 CENTRALIZATION OF CASH IN TRANSIT CHAR GES AT CASH FEEDING BRANCHES Frequency: Monthly Service Provider: The Security companies providing cash in transit services at Cash Feeding Branches shall provide invoices, for the previous month, by 15th of following month. Cash Feeding Branch i. Periodically maintain the branch wise MIS as per prescribed Annexure -XV ii. On receipt carefully examine the accuracy and authenticity of the invoice by cross checking the same with their retained records (as specified in Annexure -XV); iii. In case of any discrepancy, immediately contact the respective service provider for correction of invoice; iv. After ensuring accuracy, forward the original invoice along with Annexure -XVI to respect ive regional office (copy of invoice should be retained with branch for their record purpose) . Regional Office: Regional Operations Managers/Regional Heads, upon receipt of all original invoices along with Annexure -XVI should conduct due verification of received information i.e. tally Annexure -XVI against original invoices and forward the same to respective BH Office in consolidated format (Please use Annexure -XVI by marking respective regional office head) ; Business Head Office: Respective BH office will ensure the same control measures as specified above and forward the documents to Group Head’s office (Please use Annexure -XVI by marking respective business head office head) ; i. GH-office will consolidate, prepare and provide the branch wise expenses in the specified COD upload format maximum by 20th of the month along with the following breakup to Centralized Operations Division: ii. Invoice amount to be booked as expense with corresponding credit to security companies maintained account or pay order/demand draft released upon instructions of Central Accounts Division (please clearly specify beneficiary details) ; iii. Branch wise breakup of amounts to be debited in lieu of cash in transit services as per attached Annexure XVII. iv. GH-office will consolidate and forward all approved bill/invoice for payments to CAD on monthly basis. v. GH-Office should maintain separate record of Islamic Banking branches related allocation for onward submission to CAD. Centralized Operations Division On receipt of the request on specified format i.e. Annexure XVII Centralized Operations Division sh all perform the following functions: i. Upload the entries in respective branches general ledger by 23rd of the month; ii. After successful execution will intimate respective branches/stake holders. Centralized Accounts Division On receipt of the approved bill/i nvoice, CAD shall perform the following functions if data is provided in specified time (maximum by 20th of the month) i. Scrutinize the authenticity of approved bills and ensure deduction of applicable taxes; ii. Subsequently on same day/next day pass on necessary instructions to relevant branch to release payments in securities companies maintained account or issue pay order/demand draft; iii. Islamic Banking branches related expense allocation debit advices should be originated manually. General Notes: Branc hes are also advised to ensure following general notes at their end: i. No pool cost/remittance charges shall be recovered from branches by Cash Feeding Branches on cash transfers in line with the instructions given earlier; B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 287 1.14 ALLOCATION OF SWIFT PROCESSING CHARGES TO BRANCHES Frequency: Monthly Swift Operations request COD through e -mail for recovery of “swift processing charges” from branches as per detail provided. COD create the soft data as per Symbols GL upload format and transfer the same into defined folder through FTP utility. COD request IT Ops to execute the GL upload process. IT Ops confirm COD of successful execution of the upload process through e -mail. COD after confirmation from IT Ops extract the uploaded data from Symbols for onward submission to branches and Swift Operations for validation. Branches validate the accounting entries and impact on their GL against COD provided details. Swift Operations validates the uploaded data and in case of any exception informs COD . COD simultaneously also provides the data file to CAD through e -mail to take the impact in HO books and Recon Utility System. CAD takes the impact in HO books by crediting payable liability head. CAD load the file in Recon Utility System to incorporate the HO entries for auto reconciliation. COD after getting confirmation from Swift Operations, keep the complete trail of the upload process cycle. ii. Few branches have engaged independ ent sorters (foundation/outsourced) to perform cash sorting function; such branches shall use the following General Ledger Codes (these account heads should always contain petty amounts, therefore incase of abnormal rise may be called for justification) : 4040122040 - Cash Sorting Charges Paid to Foundation 4040122020 - Cash sorting charges paid to independent sorters (ROM’s shall be responsible to confirm the accuracy and completeness of aforementioned expenses) iii. Notional income/expense transfers should immediately be discontinued at concerned branches as expense would be centrally debited to the respective branches; iv. In case, cash handling services are rendered at any non cash feeding branch, the duly verified invoice by the respective branch shall be rou ted through nearest cash feeding branch. (Guidelines remain the same, please use specified annexure by clearly marking as “Non Cash Feeding Branch” for separate disclosure) v. The same specified guideline/procedure shall be followed for foreign currency trans fers and no entry for recording of cash handling charges shall be recorded on transfer of foreign currencies. The CIT related expenses incurred shall be processed centrally through the mechanism specified above. Soft copies of the annexure should also reac h respective stakeholders within the time specified B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 288 1.15 ALLOCATION OF STATIONERY CHARGES O F MCB EF TO BRANCHES Frequency: Fortnightly MCBEF forward the invoices to CAD f or issuing PO. CAD validates the invoices and forward the request to COD for allocation of Stationary Charges to branches COD arrange to convert the soft data as per Symbols GL upload format and transfer the same into defined folder through FTP utility. COD request IT Ops to execute the GL upload process. COD simultaneously also provides the data file to CAD through e -mail to take the impact in HO books and Recon Utility System IT Ops confirm COD of successful execution of the upload process through e -mail. COD after confirmation from IT Ops extract the uploaded data from Symbols for onward submission to branches and depar tments for validation. Branches validate the amount of invoice of MCBEF with COD provided details. COD keep the complete trail of the upload process cycle 1.16 PROCESSING & ALLOCAT ION OF HRMG COST (SA LARIES) OF CONTRACTUAL STAFF TO BRANCHES Frequency: Monthly HRMG forward the invoices to CAD for Crediting the cost of contractual staff to Third party Contractual Companies CAD validates the invoices and originates the credit advices in favor of respective party’s and forward to HRMG for onward submission to respective branches where accounts are maintained. CAD also intimate to COD through email for allocation of expense related to “Contractual Staff” assigned at branches as per details provided by the vendor." CAD generates and forwards the credit advices to vendor’s account maintaining branches for crediting the vendors account." COD arranges to convert the soft data as per Symbols GL upload format and transfers it into defined folder through FTP utility. COD re quests IT Ops to execute the GL upload process. IT Ops confirm COD of successful execution of the upload process through e -mail. COD after confirmation from IT Ops extract the uploaded data from Symbols for onward intimation to branches and HRMG for validation. Branches validate the accounting entries and impact on their GL against COD provided details. COD keep the complete trail of the upload process cycle. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 289 1.17 PROCESSIN G OF ACCOUNT SWEEP I NSTRUCTIONS FOR UTILITY COMPANIE S & TPD CUSTOMERS Frequency: On -Demand i. COD receives Account Sweep request from business via e -mail. ii. COD apply the sweep facility on accounts provided by business. iii. COD validate the results in onc e. iv. COD after completing the process forwards confirmation to the business. v. COD keep the complete trail of the sweep tagging process 1.18 SUBMI SSION OF DATA TO CIR CLES FOR UN CLAIMED DEPOSITS/ IN STRUMENTS FOR GEN ERATION OF NOTICE PERIOD LET TERS Frequency: Annually FCG (KM) forward data of un -claimed accounts / instruments to SBP Reporting Unit which qualify under un - claimed category as at process cycle year end. SBP Reporting Unit send excel based information to respective circle offices. Circle Office forwards this data to the respective branches in their region. Branches validate the information and add the data which is available on ‘manual register’, if any. Branches after validation forward the soft data to respective circle office. Circle Office consolidates the data and forwards it to SBP Reporting Unit for onward reporting to central bank. SBP Reporting Unit compile the data of all Circles / Business and forward to KM for issuing notice letter on soft copy and for further intimation to branche s via email. Based on provided data FCG (KM) generates Notice letter on soft copy and forward the same to respective branches / business via email, also intimate to dispatch it to customer after proper validation at their end. Branches dispatch to customers after proper validation 1.19 ALLOCATION OF SEMI -ANN UAL STATEMENT RENDIT ION CHARGES TO BRANCHES Frequency: Semi -Annually Special Projects & Reconciliation Division (SP&R) request CAD for payment to Venders. Details are provided in a covering schedule. SP&R request COD through e -mail to allocate “statement rendition expenses” (Postage, Stationery & Processing Charges) incurred for rendering semi -annual rendition of customers accoun t statements amongst branches as per details provided along with copy of senior management approval. COD arranges to convert the soft data as per Symbols GL upload format and transfers it into defined folder through FTP utility IT Ops confirm COD of succ essful execution of upload process through e -mail. COD after confirmation from IT Ops extract the uploaded data from symbols for onward intimation to branches and SP&R for validation. Branches validate the accounting entries and impact on their GL against COD provided details. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 290 SP&R validate the uploaded data and confirm to COD. COD simultaneously provides the data file to CAD through e -mail to take the impact in HO books and Recon Utility System . CAD takes the impact in HO books by crediting payabl e liability head. CAD up load the file in recon utility system to incorporate the HO entries which originated on CAD - HO for auto reconciliation. COD keep the complete trail of the process and output for r ecord. 1.20 RENDITION OF SEMI -ANNUAL ACCOUNT STATE MENT To improve the quality of service we provide to our customers, reduce turn -a-round time with added controls and to comply with regulatory requirement of dispatching customers’ account statements within the SBP mandated time frame the process of printing, packaging and mailing of customers’ semi -annual account statements for ALL branches across the country that was being handled by the business at Circle level has been centralized at SP&R Division under Operations Group. 1.20.1 Printing and Dispatch Process (Centralized): After completion of SYMBOLS ‘end -of-month’ cycle of June & December each year state ment print data for all branches across the country is extracted by IT and handed over to the Project Manager of statement rendition team (SP&R Division) latest by 3rd of July & January for onward delivery to vendor – (Currently TCS) The entire process of printing & packa ging at vendor’s print shops is performed under the direct supervision of bank’s representative from statement rendition team. The Project Manager of statement rendition team ensures that the process is being performed in controlled environment. The daily production is as per plan and made ready in the form of ‘sealed envelope s’ for onward delivery to the courier company. The Project Manager keeps a track of daily production and keeps close coordination with the vendor to ensure that the task is completed within the mandated time frame. 1.20.2 Handling / Processing of Return Mail Centralized Statement Rendition Team: i. Get the return mail sorted by branch / circle ii. Prepare annexure (SF -Return Mail 01) for each branch listing down the account numbers of the statements which are returned undelivered iii. Forward the physical statements of accounts under a cover memo along with annexure ‘SF -Return Mail 01’ to each circle for the branches under their jurisdiction for taking necessary action iv. Keep proper record of the return mail forwarded to circles along with related acknowledgments submitted by the courier company for delivery of same to the circles Circle / Branch: Mark restraint ‘Whereabouts Unknown’ on the system for all accounts that are returned undelivered and listed in annexure “SF -Return Mail -01”. After marking the restraint take app ropriate corrective action as follows: i. Refer account opening documentation or contact the customer on the contact numbers provided at the time of account opening. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 291 ii. Obtain ‘current mailing address’ of the customer (customer request for any change in the addr ess must be in writing). iii. Perform required maintenance on the system to update current mailing address of the customer. iv. Prepare a new envelope with current mailing address and mail the account statement to the customer . v. Circles are required to ensure that t he branches take corrective action on return mails and confirm the same to SP&R through email . Update the annexure “SF -Return Mail -01” of the corrective action taken against each account. Retain the updated annexure in file as a record for review by inspe ction team during annual audit of branch by SBP. "SF-Return Mail 01" Returned Mail - Customer Account Statement Statement Cycle ( ------------ ) Br Code:_____ Branch Name:________________ S No Account Number Br Records/Systems Updated with Current Mailing Address as: Statement Mailed on Remarks Circle / Branch: Remove the restraint ‘Whereabouts Unknown’ from customer’s account only for those cases where the branch has obtained the current mailing addresses of the customers, account statement is mailed and the system is updated with current mailing address 1.20.3 Procedure of Marking of Restraint for Whereabouts Unknown: At Branches , Following steps are required to be performed to mark “ Whereabouts Unknown ” restraint: i. Go to Enterprise Operation Center – (EOC) ii. Select Deposits Module - Transactions >>>> Account Faci lity >>>> Restraint Setup. iii. System will display >> Screen # RB 51. iv. Insert complete A/c number (15/16 digits) of the customer & press F8. v. Account details will be displayed on the screen. vi. Go to the field ‘Restraint Type’ & Press F9 to display LOV (list of va lues). vii. Pop-up Box will appear on the screen showing LOV (list of values). Select WAU - IN- Whereabouts Unknown. System will ask for: Start Date: Input today’s date OR default End Date: Do not input any date. Just default. System will take Jan 01, 2999 as end date). viii. Press F10 or click the ‘Save’ icon to save the information. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 292 GENERAL BANKING OPERATIONS SECTION 7 GENERAL BANKING OPERATIONS/ MISCELLANEOUS Section Summary: This Section encompass es processes , inst ructions and guidelines for General Ledger functions, Branch R eports, Branch IT security Guidelines, Start & End o f Day Processes, Locker Management, Inter -branch R econciliation Application CORONA , Government Securities, Branch’ related Operational Risks & Control, Investment services, SBP Guidelines for Sub -Branches and very importantly Branch Transactional Authorities & Threshold Limits. SECTION 7 B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 293 Chapter 1 GENERAL LEDGER 1.1 OVERVIEW In Symbols there are transactions that are not completely catered by any si ngle relevant module. The General Ledger Module (GL) translates banking transactions into accounting journal entries, posts them into the respective accounts and constructs an accounting database serving as a source of various Enquiries and Reports. GL Module records two types of transactions i. Transactions that originate in Deposits or Branch Teller Module where settlement of control account will be done in General Ledger Module. ii. Completely General Ledger related Transactions. (No involvement of other Symbols Modules) There are certain types of transactions that takes place in a branch; processing of which is executed through GL Module of Symbols. These processes have adequately been explained in relevant sections of the manual. Procedural and system related instructions for such processes are explained in detail under Section 7: 1.4 Transaction processing In GL Module 1.2 GENERAL LEDGER CONTR OL ACCOUNT S Listed as follows are important and critical control accounts in the General Ledger Module. They are used to facilitate th e transactions processed between Retail Banking (RB)/Branch Teller (BT) module to General Ledger (GL), and RB to RB. At end of day, the balances of these accounts should be equal to zero. All debits and credits transactions in the following control accoun ts should have the reversal/corresponding entries in order to keep the balances nil or have a verifiable balance that the Operation Manager should monitor and signoff on daily basis until the outstanding amount /balance in Nil. A format of self assessment check list for both local currency and foreign currency control heads is attached. Operation Manager should fill and signoff the checklist on daily basis in a separate file for review and validation. 1.2.1 Local Currency Critical Control Heads Sr. No GL Code Description 1 1091101010 Intra -branch Settlement Account 2 1150101110 Express Money Control Account 3 1150101120 Utility Bills Control Account 4 1150101130 Salary / Bonus Control Account 5 1150101150 Fund Transfer Control Account 6 1150101140 Clearing Control Account B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 294 1.2.2 Foreign Currency Critical Control Heads Sr. No GL Code Description 1 1090801250 Foreign currency in transit 2 2010201030 Foreign currency cash in transit 3 2010201040 Foreign currency in transit 4 2010201050 FCY in Transit – US$ 5 2010201060 FCY in Transit – GBP 6 2010201070 FCY in Transit – EUR Annexure XVIII & Annexure X IX are required to be signed off daily after end of day by Branch Operations Manager to ensure that proper monitoring of these heads is being done on daily basis. These checklists should be kept separately for review and validation 1.3 CENTRALIZED POSTING IN GENERA L LEDGER In order to eliminate redundancy, reduce the turnaround time, create process efficiency and control environment, with the consent of higher management, certain processes and postings into related General Ledger heads have been centralized by Cent ralized Operations Division, Operations Group. Section 6 : CENTRALIZATION & AUTOMATED OPERATIONS explains the key processes that have been centralized. Branches are strictly advised to monitor these GL heads on timely basis as per their run frequency and reconcile the impact of these transactions with the source information for record/audit trail. Currently, following GL heads have been centralized and transactions can be posted through centralized location following an approved mechanism/process. S No PROCESS Frequency DESCRIPTION GL CODES GL-DESCRIPTION 1 FED COLLECTION PROCESS Monthly FEDERAL EXCISE DUTY PAYABLE 1090802370 Federal excise duty payable 2 WHT COLLECTION PROCESS Weekly DEDUCTION ON ACCOUNT OF INCOME TAX 1090601070 WHT on cash withdrawal 1090601020 WHT on profit/interest 1090601080 WHT on instruments u/s -231aa 1090601060 With -holding income tax deduct 3 MCBEF STATIONERY PROCESS Fortnightly MCB EMPLOYEES FOUNDATION STATIONARY EXPENSES 4040115040 ATM stationary -foundation 4040115050 Computer stat. Exp -foundation 4040115060 Security stat. Exp -foundation 4040115070 General stat. Exp -foundation 4040115150 Printed stationary -foundation 4 CLEARING CHGS PAID TO NIFT Monthly CHEQUE PROCESS EXPENSES 4040121010 Clearing house exp paid to NIFT 5 CHEQUE BOOK PRINTING CHARGES Monthly STATIONERY 4040121020 Cheque process exp paid to NIFT 6 PDHS POSTAGES CHARGES Monthly MISC EXPENSES 4040111160 Centralized clearing & postages charges 7 SWIFT CHARGES Monthly FOR.EXCHANGE SWIFT CHARGES 4040111060 Swift charges 8 STATEMENT RENDITION Half Yearly STATEMENT RENDITION 4040111170 Postages statement rendition 4040115100 Stationery statement rendition B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 295 CHARGES 4040115090 Proc.cost statement rendition 9 TREASURY SETTLEMENT Monthly FOR.REMM INWARD OUTWARD / CASH RESERVE REQ / FOR.CCY TRANSACTION 4060101090 Rebate on cash reserve paid 3080101080 Compensation received on fbp 3050101440 Exchange account foreign (fx sharing income) 4060101120 FC equalization fee paid 3050101090 GL currency revaluation gain 4040124250 GL currency revaluation loss 10 OUTSOURCE CONTRACTUAL STAFF EXPENSES Monthly / Fortnightly Outsourced staff salaries/ commissions and other miscellaneous expenses 4010401050 Collection commission - consumer 4010401060 Sales commission - consumer products 4040124680 OSE - others 4040124700 OSE - tea services 4040124710 OSE - cash operations servic e 4040124720 OSE -custome r facilitations s 4040124730 OSE -data proc & off support ser 4040124740 OSE -consumer banking service 4040124910 OSE -sale services, DSCs/PBAs 11 HO POOL MARKUP Monthly Interest On Branches Account 3070101010 Mark -up received f rom PO 4050101010 Mark -up paid to PO 12 CASH HOUSE CHARGES Monthly CIT & CASH HOUSE CHARGES 3080101270 Central cash house chgs recov. 4040124150 Cit serv chgs to security com 4060101290 Central cash house charge paid 13 CONTRACTED SECURITY GUARDS Monthly CONTRACTUAL SECURITY GUARDS 4040124240 Contracted security guard services 14 FIXED ASSETS COST ALLOCATION Monthly DEPRECIATION EXPENSE 4040117050 Computer & its accessories 4040117010 Furniture fittings - offices 4040117040 Premises 4040117030 Vehicles 4040117120 Dep exp -office & othr equipment 4040117090 ATMs 4040117170 Depr expense -lease hold asset INSURANCE EXPENSE 4040108170 Insurance charges -bankers policy 4040108190 Insurance charges - computer policy 4040108210 Insurance charges - property 4040108080 Insurance charges - others 4040108100 Insurance charges – ATM 4040108090 Insurance charges - vehicles 4040108180 Insurance charges -lockers policy 4040108200 Insurance charges – furniture &fixture POOL COST ALLOCATION 4060101410 Pool cost on property paid 15 REBATE ON WHEAT PROCUREMENT Quarterly REBATE ON WHEAT PROCUREMENT 3080101360 Rebate rec. Ho -wheat pro. Fin. 4060101380 Rebate paid br -wheat pro. Fin. 16 BRANCH PROFIT & LOSS TRANSFER Yearly P & L TRANSFER 1010301010 Un-appropriated profit 17 RTC FLOAT INCOME & COMPENSATION PAID TO BRANCHES Monthly RTC FLOAT INCOME & COMPENSATION 4050101010 Mark -up paid to PO 3070101010 Mark -up received from PO 4060101080 Compensation paid to br on RTC 3080101060 Compensation received on RTC B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 296 1.4 TRANSACTION PROCESSI NG IN GL MODULE Posting of transactions in GL is categorized into three categories, i. A normal transaction (related to recording of transaction in same branch), ii. An originating entry (through which a branch originates an entry to contra branch) and send advice iii. Responding entry where contra branch accepts the batches on basis of advices received. In case of ii and iii above, inter branch account (Head O ffice Debit or Credit) is used, reconciliation process of head office account of branches is explained in detail in Section 7: Chapter 6 Inter -branch Reconciliation Application CORONA 1.4.1 Transaction originates in Deposits or BT Module and settled through control accounts in GL Module. Some general ledger control accounts that are used by branches in case of local currency transactions while transacting between two modules is listed as follows  Intra -branch Settlement Account  Express Money Control Account  Utility Bills Control Account  Salary / Bonus Control Account  Fund Transfer Control Account  Clearing Control Account i. Processor selects General Ledger Module >> Trans action >> Batch Maintenance >> Entry (Screen # GL 21). ii. Input number of items, input Batch Date, input Value Date, input or Select appropriate Transaction Nature.  Normal Transaction  Originating Transaction  Responding Entry iii. Input or select Contra Branch Code in case of Original or Responding Entries iv. Select appropriate Transaction codes like “0400” for Telegraphic Transfer. v. Input Hash Total (Total of Debit and Credit Vouchers) vi. Input Original Entry date in case of responding entry. vii. System will automatically put the transaction in lower portion of screen in case of PO transaction. Other parts of the batch can be entered in lower part of screen i. Input or select appropriate Currency e.g. “PKR” Pakistani Rupee. ii. Input or select 10 Digit appropriate GL Code. iii. Input Debit or Credit Amount. iv. Input Narration. v. Input Reference Number (Advice Control Number) vi. Press F10 or click on save icon in order to save the transaction. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 297 Batch Editing: Processor selects General Ledger Module >> Transaction >> Batch Maintenance >> E ntry (Screen # GL 21), press F7, enter Batch number and press F8. Batch Authorization by BOM : Operations Manager accepts the batch after v alidating the details from advic e by using General Ledger. Select the option Transaction >> Batch Maintenance >> Acce ptance (GL -22) EXAMPLE of Accounting Entry Mechanism in SYMBOLS where both RB and GL modules are used i. Issuance Of Payment Order Against Advice : Accounting entry in Deposit Module: Branch will book the Pay order liability using transaction type POSI in RB module. Pay order liability will be booked resulting in a balance outstanding in fund transfer control account Debit Fund Transfer Control Account Credit Payment Order Issued Accounting entry in GL module: Branch will settle the Fund Transfer Con trol Account (debited above) by creating a GL batch in GL module on t he advice issuing branch/unit. Following entry will be made in GL module. Debit Head Office Account Credit Fund Transfer Control Account ii. Purchase of P rize Bond By Debit To Account : Accounting entry in Deposit Module: In RB module, branch will debit the customer account by using transaction type CASD and following entry will be made. Debit Customer Account Credit Intra Branch Settlement Account Accounting entry in GL module: The head “Prize Bond” will manually be debited with a credit in Intra Branch Settlement Account. This entry will be made in GL module. Debit Intra Branch Settlement Account Credit Prize Bonds B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 298 1.4.2 Transactions where both account heads are posted in GL module directly in Symbols : There are certain transactions (such as recording of expense related to branch, transfer/receipt of cash from cash house or cash feeding branches, sale or purchase of prize bonds) where posting is done at branch end. In case of such heads, both entries are made in GL module of symbols. 1.4.3 General Ledger Batches among SYMBOLS Branches: General Ledger (GL) Batches amongst SYMBOLS branches should not be created for the Inter branch transactions. (e.g. Utility funds transfer, Express Money Account, Individual & / or Company account funds transfer against cash/ cheque/ advice etc).The above transactions should be performed via Branch Teller Module (BT) in order to avoid the creation of GL batches on the system amongst Symbolized branches. i. Processor selects Transac tions> Financial Transactions > Single Transactions > Current /Savings > Transfer (BT Screen # 3215) ii. Branches selects customer’s branch & account number on BT and inter branch transaction will be generated automatically. 1.4.4 Creation & Acceptance of General Ledger Batches among SYMBOLS Branches: For the settlement of Inter branch Transactions, Originating branch draws GL Batch on the Responding Branch and simultaneously prepares and forwards Original Advice (Debit - SF180 or Credit - SF179) to the responding b ranch in order to authenticate the batch details. i. Process of Batch Creation (Originating Branch)  After the above entry in the Deposits Module, General Ledger Maintenance Officer prepares Debit Advice SF -180.  On the basis of Debit Advice - SF-180, GL Officer creates the following GL Batch through GL Module >> Transaction >> Batch Maintenance >> Entry by inputting the following details: 1st Section of GL 21 2nd Section of GL 21 i. Number of Items ii. Batch & Value Date iii. Transaction Nature (0800, 0860 & 1000) iv. Contra Branch Code v. Hash Total i. Currency ii. GL Code iii. Debit & Credit Amount iv. Reference Number (Control Number) v. Press F10 or click on save icon. System generates a new Batch Number. Note down Batch Number on all the respective vouchers and Advices. Batch Authorization by BOM : Operations Manager accepts the batch after validating the details from advic e by using General Ledger >> Transaction >> Batch Maintenance >> Batch Acceptance - GL. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 299 Other Instructions: After accepting GL batch, GL Maintenance Officer jointly signs -off the Advice with the Operations Manager. Dispatch original Advice to the Responding Branch on the same day and retain one copy for record. Please ensure that the advice is dispatched on daily basis. ii. Process of Batch Acceptance – (Responding Branch ):  On receipt of Original Advice (Debit - SF180 or Credit - SF179), Responding Branch validates the Advice (Check Control Number, Transaction Code, Amount & Date) and accept the Batch on the system.  Original Advices will be used as the so urce document of the transaction (inter -branch Batches can be referred to as ‘End of Day Batches’).  End of Day Batches will not be accepted without the scrutiny of original Advices. If details available in the Advices do not match with the End of Day Batch es, Operations Manager will immediately inform the Batch Originating branch and will hold the batch in a pending file for daily follow -up for rectification. Such open batches should be resolved on priority basis.  If there is any unaccepted EOD batch appea ring in branch GL for more than 01 Business day, Branch Operations Manager should instantly contact the batch originating branch and take the necessary action i n order to reconcile the entry.  After batch acceptance, GL Maintenance Officer prepares Debit Vo ucher and creates batch for offsetting the Fund Transfer Control Account and booking the relevant expense account B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 300 Chapter 2 BRANCH REPORTS Reports are provided to the Branches for better management of their branch affairs. Source of which is KM/ EOC/ RAM & MCB R eports. There are ‘Financial Reports’ which show any financial transaction of the Branch and there are ‘Non -Financial Reports’ which show the Non -monetary transactions performed by the user. (e.g. Account open/Close Listings, Stop Cheque Listing etc). Reports are classified into two sections:  Mandatory Reports  Miscellaneous Reports 2.1 MANDATORY BRANCH REP ORTS Reports classified as ‘Mandatory Reports’ are all essential branch reports which are required for multiple functions/processes e.g. monitoring transactions, balancing & reconciliation. Following are the ‘mandatory branch reports’ which are to be extracted/ received & reviewed by the branch officer as per the frequency/ responsibility defined as under: Sr. # Report ID Retrieve from Report Title Responsibility Frequency Description 1 KM_RAM_0001 KM GLA 91 EMAIL FORM BOM / BM Daily To monitor daily working on GL with opening & closing balance. 2 KM_RAM_0006 KM GLA11 - BATCH REPORT EMAIL FORM BOM Daily To track status of all batches originated, responded & normal entries recorded by branch end user. 3 KM_CRC_0001 KM Running Finance BM / RM Assets Daily To monitor the Running Finance accounts and their current status on utilization of overdraft. 4 KM_KM_0007 KM High Value Transaction BM Daily Shows list of accounts where credit or debit transactions of PKR 1Mn or over have taken place. 5 KM_MCB_0018 KM Day Journals BOM / TSS Daily Shows all financial transactions under various GL heads and the channel used for this purpose. Also provides a deposit product wise summary showing movement of funds. 6 KM_MCB_0001 KM Branch Deposit Summary BM Daily Shows the branch deposit position with currency wise breakup as per the RB - Deposit Module. 7 KM_MCB_0011 KM Stop Cheque Listing BOM / TSS Daily Shows the list of those accounts marked with stop cheque. 8 KM_MCB_0023 KM Cheque Book Issuance BOM / TSS Daily Shows the list of those accounts where cheque book was issued. 9 KM_KM_0143 KM PO Outstanding Report GBO -Remittances / BOM Daily To monitor outstanding pay orders of the branch and to eliminate any differences in subsidiary and ledger records. 10 KM_KM_0139 KM DD Outstanding Report GBO -Remittances / BOM Daily To monitor outstanding demand drafts of the branch and to eliminate any differences in subsidiary and ledger records. 11 KM_KM_0145 KM PO Unclaimed Report GBO -Remittances / BOM Daily To monitor unclaimed pay orders of the branch and to eliminate any differences in subsidiary and ledger records. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 301 Sr. # Report ID Retrieve from Report Title Responsibility Frequency Description 12 KM_KM_0140 KM DD Unclaimed Report GBO -Remittances / BOM Daily To monitor unclaimed demand drafts of the branch and to eliminate any differences in subsidiary and ledger records. 13 KM_KM_0099 KM Change in Account Status Report BOM Daily Shows all those accounts whose account status has changed. 14 KM_RAM_0008 KM Client Status - RBA 14 PBA / BM Daily Shows the client profile of newly opened accounts. 15 KM_RTC_0009 KM RTC Outstanding BOM Daily Shows all outstanding Rupee Travelers Cheques and any differences in their subsidiary and ledger records. 16 RBA-11 EOC User wise printing TSO / TSS / BOM Daily 17 GL-90 EOC User wise batch listing TSO / TSS / BOM Daily 18 N/A MCB Reports GL Balances TSO / TSS / BOM Daily 19 N/A MCB Reports Cash/Clearing Summary TSO / TSS / BOM Daily 20 N/A RAMs ATM RAMS report ATM Custodian / BOM Daily 21 KM_MCB_0060 KM HO STATEMENT Incharge Reconciliation Fortnightly Shows list of inter branch reconciliation transactions of branch. 22 RAM_0001_EOY KM GLA 91 Before Closing BM / BOM Half Yearly / Yearly To monitor yearly working on GL with before closing balance. 23 RAM_0001_EOY KM GLA 91 After Closing BM / BOM Half Yearly / Yearly To monitor yearly working on GL with after closing balance. 24 RBA-145 EOC Salary Exception Turn Over BM Monthly 25 KM_KM_0012 KM Statement of Income Expense/ Monthly Affair BM / BOM Monthly Shows GL codes wise list of income and expenses of branch. 26 KM_KM_0146 KM Turnover Exception Report BM Monthly Shows list of accounts on monthly actual Debit (Dr) and Credit (Cr) turnover is exceed from expected turn over provided by the accountholder at the time of account opening in Symbols. 27 KM_RAM_0005 KM Closed Accounts List BM / BOM Monthly / Yearly Shows list of closed accounts in certain duration in branch. 28 BR_Issue_0025 KM Negative Balance Report BM / RM Assets Weekly Shows list of accounts having negative balances in saving accounts and those current accounts with no overdraft facility. 29 KM_FCD_0058 KM Administrative Expense Report BM Weekly To monitor administrative expenses accounts on standard benchmarked periods 30 Monthly Affairs Complete extracts of Branch’s General Ledger i.e. Statement of Affairs with break -up of Sundry Debtors/Creditors, Margin, Bank’s Liabilities, Statistical figures of Remittances and head -wise details of Income / Expenses. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 302 2.2 MANDATORY REPORTS – BRANCH RESPONSIBILIT IES 2.2.1 User Responsibility: User retrieves the report and attaches the source documents such as Vouchers/ Batches/ Customer requests/ application forms) with his/her Daily Transaction (Financial & Non -Financial). 2.2.2 Supervisor Responsibility: Supervisor must ensure that entire source documents are duly scrutinized and attached with the respective User’s reports. It is mandatory that Supervisor and Operations Manager sign -off all the Reports. In case of any discrepancy, transactions will be thoroughly reviewed by the Supervisor and/or Operations Manager and appropriate corrective action will be taken to rectify the error(s). 2.2.3 Branch Operations Manager’s Respons ibility: Operations Managers have to ensure before closing the branch that the entire source documents are duly scrutinized, signed -off & attached with the respective reports before final binding. All the ‘Mandatory Reports’ must be maintained date wise i n separate folders. All Operations Managers are advised to review and sign -off the reports jointly with the respective supervisors. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 303 2.3 MISCELLANEOUS BRANCH REPORTS Reports classified as ‘Miscellaneous’ are all essential branch reports helping them comply with various bank level circulars, financial principles, KYC matters, reconciliations and performance management. These reports bear importance with respect to opera tional compliance expected from the branches. The following can be retrieved from KM. Sr. # KM-ID Report Title Distribution Frequency Report Description Reports Devised on request of 1 KM_KM_0035 Cr/Dr Online Transactions External Customer Daily Shows all the online transactions carried out by the customers of home branch at other branches. Compliance 2 KM_KM_0036 Cr/Dr Online Transactions Internal Customer Daily Shows all the online transactions carried out by customers of other branches at the home branch. Compliance 3 KM_MCB_0054 Account Closure Charges Report Daily Shows all closed account and their status of recovery of accounts closure charges as per Schedule of Bank Charges. CMIS / FCG 4 KM_KM_0061 Suspense Account Report Daily Identifies Suspense Account (GL Code : 2140101010 ) appearing to be non -zero. CMIS / FCG 5 KM_KM_0062 GL Control Account Report Daily Reflects control accounts appearing with balances which needs to be nullified every day. CMIS / FCG 6 KM_KM_0060 Unappropriated Profit Daily Identifies Un -appropriated Profit (GL Code : 1010301010 ) appearing to be non - zero. CMIS / FCG 7 KM_KM_0106 Contra Liability and Asset Imbalance Summary Daily Reflects imbalances in Contra Liability and Assets. CMIS / FCG 8 KM_MCB_0058 Accounts incorrectly marked as STF Daily Shows all accounts that are incorrectly marked as Staff CMIS / FCG 9 KM_MCB_0057 MCB EMPLOYEES NOT MARKED AS STF Daily Shows MCB Employee accounts not Marked as Staff. CMIS / FCG 10 KM_FCD_0049 Incorrect Service Charges Daily Shows list of those account which are tagged with wrong service charges or where service charges are found missing. CMIS / FCG 11 KM_FCD_0006 Summary of Deposit & Variances Daily To monitor GL wise deposit performance at standardized benchmarks of last year, last month, last week and previous day. CMIS / FCG 12 KM_FCD_0004 Summary of Advances & Variances Daily To monitor GL wise advances performance at standardized benchmarks of last year, last month, last week and previous day. CMIS / FCG 13 KM_KM_0149 Cash in ATM Accounting Entries Daily Shows list of ATM reconciliation transactions of branch. ATM Reconciliation 14 KM_FCD_0001 Summary of No. of Accounts Report Daily To monitor product wise deposit accounts open / close activity with respect to standardized benchmarks of last year, last month, last week and previous day. CMIS / FCG 15 KM_RTC_0011 RTC Clearing Transaction Report Daily Shows RTC Clearing Transactions. CBG 16 KM_KM_175 Zero Balance Report Daily Shows all zero balance accounts which should be closed CMIS / FCG 17 KM_KM_0204 Clearing Control Report Daily Shows list of accounts where clearing control account (1150101140) not zero CMIS / FCG 18 KM_TRY_0002 TT Discounted Report Daily Shows GL balance of TT Discounted (GL Code: 1090801010) Treasury & Capital Market Ops 19 KM_TRY_0003 Remittance in Transit Report Daily Shows GL balance of Remittance in Transits (GL Code: 2010201010) Treasury & Capital Market Ops 20 KM_TRY_0001 GL Data Report Daily Shows Balances of Interest Payable GL codes and Interest Receivable GL codes. Treasury & Capital Market Ops B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 304 Sr. # KM-ID Report Title Distribution Frequency Report Description Reports Devised on request of 21 KM_KM_0108 Base Control Account Balance Summary Daily / Weekly Shows branches where sum of base control accounts is not equal to sum of position control accounts CMIS / FCG 22 KM_KM_0109 Base and Position Control Imbalance Daily / Weekly Shows branches where position control account balances appear in “PKR CMIS / FCG 23 KM_KM_0108 Position Control Account Balance Summary Daily / Weekly Shows branches where position control account balances appear in “PKR CMIS / FCG 24 KM_KM_0172 Tolerance Value Marked to Accounts Daily / Weekly Shows list of those accounts on Tolerance Value check marked. CMIS / FCG 25 KM_KM_0024 Clearing Control Accounts Not Zero (1150101140) Daily / Weekly Shows list of branches where clearing control account (1150101140) not zero CMIS / FCG 26 KM_KM_0010 Statement of Affairs in Base PKR Monthly Shows GL codes wise list of income & expenses and assets & liabilities of branch. Compliance 27 KM_RAM_0007 Open A/C List (Salary Dr / Cr Turnover) Monthly/ Yearly Shows list of accounts opened in certain period with salary Dr & Cr turnover. Compliance 28 KM_RAM_0003 New A/C Open List Monthly/ Yearly Shows list of new accounts opened in certain period. Compliance 29 KM_KM_0126 VALID / INVALID SBP CODE REPORT Weekly Shows accounts are tagged with correct or incorrect SBP Classified codes CMIS / FCG 30 KM_KM_0009 Invalid ID Detail Weekly Shows list of accounts having invalid IDs. CMIS / FCG 31 KM_MCB_0016 Missing CSW Detail Weekly Shows list of accounts on CSW check in not marked. CMIS / FCG 32 KM_MCB_0031 Missing Account Signature Detail Weekly Shows list of accounts on signature cards of customers not attached. CMIS / FCG 33 KM_KM_0042 Invalid ID Summary Weekly Shows list of branches having accounts with invalid IDs. CMIS / FCG 34 KM_KM_0043 Missing CSW Summary Weekly Shows list of branches having accounts on CSW check is not marked. CMIS / FCG 35 BR_Issue_0013 BBA Accounts with Service Charges Weekly Shows list of BBA accounts on which service charge check has been applied in violation to Branch Operations Manual CMIS / FCG 36 KM_KM_0173 FCY Accounts Opened with incorrect currency Weekly Shows branch wise list of Local Currency Accounts that have been opened in incorrect currencies. CMIS / FCG 37 KM_KM_0174 LCY Accounts Opened with incorrect currency Weekly Shows branch wise list of Foreign Currency Accounts that have been opened in incorrect currencies. CMIS / FCG 38 KM_MCB_0042 Missing Account Signature Summary Weekly Shows list of branches having accounts with signature cards of customers not attached. CMIS / FCG 39 KM_KM_0064 UN-APPROPRIATED PROFIT SUMMARY REPORT Weekly Identifies Un-appropriated Profit (GL Code: 1010301010) appearing to be non - zero for Symbol Branches in a particular region. CMIS / FCG 40 KM_KM_0065 SUSPENSE ACCOUNT SUMMARY Weekly Identifies Suspense Account (GL Code: 2140101010) appearing to be non -zero for Symbol Branches in a particular region. CMIS / FCG 41 KM_KM_0066 CONTROL ACCOUNT SUMMARY Weekly Identifies region wise no of branches, those are not complying with the instructions laid down in circulars related to Control Accounts. CMIS / FCG 42 KM_KM_0073 INVALID GL CODE SUMMARY Weekly Identifies those invalid codes most frequently used by the branches. CMIS / FCG 43 KM_KM_0106 Contra Liability and Asset Imbalance Summary Weekly Reflects imbalances in Contra Liability and Assets. CMIS / FCG 44 KM_KM_0158 CSW & EWT Marked Weekly Shows list of CSW exempted accounts having check of CSW with EWT restraint Compliance B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 305 Sr. # KM-ID Report Title Distribution Frequency Report Description Reports Devised on request of simultaneously in branches. 45 KM_KM_0114 Where About Unknown Weekly Shows accounts where Whereabouts Unknown Restraint has been marked. Compliance 46 KM_FCD_0057 Fee Based Income Report Weekly To monitor fee -based income accounts on standard benchmarked periods CMIS / FCG 47 KM_FCD_0046 Customer's Channel Report Weekly Shows status of product ( availed or not availed) by customers with account numbers and addresses. CMIS / FCG 48 KM_FCD_0062 Markup Expense Report Weekly To monitor mark -up expense accounts on standard benchmarked periods CMIS / FCG 49 KM_FCD_0061 Markup Income Report Weekly To monitor mark -up income accounts on standard benchmarked periods CMIS / FCG 50 KM_FCD_0063 Position for Fixed Assets Weekly Shows category wise position of fixed assets with date of placement, depreciation and net book value to update the fixed assets position CMIS / FCG 51 KM_MCB_0066 Correct Marking of Client Type Weekly Shows list of those accounts on which client type is incorrectly CMIS / FCG 52 KM_MCB_0063 MCB Employees not marked as STF Weekly Shows MCB Employee accounts not Marked as Staff. CMIS / FCG 53 KM_MCB_0064 Accounts incorrectly marked as STF Weekly Shows all accounts that are incorrectly marked as Staff CMIS / FCG 54 KM_ICD_0010 DD Outstanding Vs GL (1060101010) Weekly Shows list of branches where DD Outstanding balances are not yet balanced with GL. CMIS / FCG 55 KM_ICD_0009 PO Outstanding Vs GL (1060101050) Weekly Shows list of branches where PO Outstanding balances are not yet balanced with GL. CMIS / FCG 56 KM_KM_0125 DD Unclaimed Vs GL (1090802620) Weekly Shows list of branches where DD Unclaimed balances are not yet balanced with GL. CMIS / FCG 57 KM_KM_0124 PO Unclaimed Vs GL (1090801230) Weekly Shows list of branches where PO Unclaimed balances are not yet balanced with GL. CMIS / FCG 58 KM_RTC_0012 RTC Outstanding Vs GL (1060101070) Weekly Shows list of branches where RTC Outstanding balances are not yet balanced with GL. RTC / CBG 59 KM_MCB_0025 Zakat Deduction Transaction report Yearly Shows list of those accounts on which Zakat deducted on 1st of every Ramadan with Zakat amount. CMIS / FCG 60 KM_AUD -01 Amendment in Customer Account On-Request Shows the change in various attributes of customer account Audit 2.4 MISCELLANEOUS REPORT S – BRANCH RESPONSIBILIT IES User retrieves the report and performs the needed action in the light of subject circulars / instructions mentioned within the report. This action can be augmented either by keeping a track through electronic files or hard copies. Frequency of review may vary as per discretion of Area Head Operations. How ever, user’s will have access to reports as per given distribution frequency. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 306 Chapter 3 IT SECURITY GUIDELIN ES IT Security is everyone’s responsibility. Following basic guidelines must be adhered by end users to ensure minimum level of security in the day to day IT operations. 3.1 PASSWORD PROTECTION Protecting your computer with a password is a common method of ensuring that only authorized users (those with Permission) can access it. However, passwords are effective only as long as they are selected and used appro priately. Following are some guidelines based on MCB password policy that must be ensured: i. Password sharing is prohibited. Users must not share their passwords. If done will be considered as serious violation ii. System users must configure their password as p er MCB password policy as described below; iii. Minimum password length should be 8 character iv. Password must be alphanumeric and must contain at least one special character e.g .!,@,#,$ , %,^,&,*,(,) etc. v. All user -level passwords (e.g., applic ation user, email, we b, desktop computer, etc.) must be changed at once every 30 days and minimum password age should not be zero vi. Passwords must be checked to ensure that they are not identical to any of the previous 12 passwords for the same account vii. Passwords must not be writ ten down, stored on any information system or storage device viii. It is recommended not to type passwords when someone is viewing users hands, keyboard (Shoulder Surfing) ix. Passwords must not be revealed in conversations, inserted into email messages or other fo rms of electronic communication Transactions that require override by a next level of authority, each individual/user should him/herself insert the password in the system. Under no circumstances should the user disclose the password to other users. 3.2 EMAIL USAGE i. Personal or non -business use of the email systems must be avoided ii. MCB information resources should not be used to transmit or receive statements that contain any material that is offensive, defamatory, or threatening to others iii. The Systems should not be used to communicate statements, messages, or images consisting of pornographic material, ethnic slurs, racial epithets, or anything that may be construed as harassing, offensive, or insulting to others based on race, religion, national origin, color, m arital status, citizenship status, age, disability, or physical appearance iv. To maintain the security of MCB E -Mail system, it is important to control access to the system. Users should not provide other unauthorized persons with their E -Mail ID and personal password v. Users must not publish or distribute internal mailing lists to non -staff members. vi. Attachments from unknown or un -trusted sources must not be opened. All E -Mail attachments, regardless of the source or content, must be scanned for viruses and oth er destructive programs before being opened or stored on any MCB computer system. Personnel must perform a virus scan on all material that is transmitted to other users via E -Mail prior to sending it. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 307 3.3 REMOVABLE STORAGE PR OTECTION i. Unauthorized use of removable storage i.e. USB storage, portable hard disk is prohibited ii. Removable storage must be scanned for viruses before authorized usage 3.4 VIRUS AND MALICIOUS PROGRAMS PROTECTION i. Users should run a complete system virus scan weekly ii. Antivirus should be up dated and users should inform IT coordinators about outdated virus scan definitions. iii. If users feel virus attack at their system, they must inform the helpdesk 3.5 SYSTEM ACCEPTABLE US E i. Remote desktop, telnet and other remote management utilities are prohib ited ii. System must be used for MCB business purpose only iii. Games are not permitted and must be removed from all systems iv. It is strongly recommended that users should lock the system on leaving seat v. Unauthorized software and freeware must not be installed at sys tems B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 308 Chapter 4 START & END OF DAY Overview: In SYMBOLS Start of Day is use to run the Branch’s Start of Day. An authorizer officer who has an authorize password to perform Start of Day will only be able to perform this function on System. Failure to do so, the users will not be able to login to perform the financial as well as non -financial transactions. 4.1 START OF DAY i. Switch on the server and login through Administrator (User Id & Password) ii. Click JTP Icon available on Desktop iii. System shows the status of JTP as follows: [JTP MAIN] Wait for connection on port 1510 In case system shows any other message while running JTP, follow below mentioned procedure to check network availability. i. Press start button available on windows desktop ii. Click on Run button. iii. Pop-up message will be appeared on screen. iv. Insert necessary command in the pop -up box. v. Click Ok In case system shows message “Request Time Out ” then log a complaint with Call Center. i. Click the Branch Teller Icon available on Desktop ii. Login to BT and insert USER ID and Password, pop -up message will be appeared 4.2 END OF DAY In SYMBOLS End of Day is use to run the department’s end of day process. This process is a pre -requisite for the branch end of day process, which in turn is a pre -requisite for the Bank’s end of day process. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 309 Chapter 5 LOCKER MANAGEMENT Overview: Branches all over the country offer Safe Deposit Lockers facility to their customers. The lockers are invariably to be installed in the Strong Room of the Branch to ensure maximum security against burglary, theft and riots. Each locker irrespective of its size has a separate number and is fitted with a double key lock which cannot be opened except with the two keys, one being Master Ke y under the custody of Manager/Authorized Officer and the other possessed by the customer. The relationship subsisting between Bank and Person to whom locker is rented out will be that of a Licensee and a Licensor and not that of a customer and banker. 5.1 RIGHTS & OBLIGATIONS O F LICENSEE The ownership in the locker will vest in the Bank and the licensee will have only the right to use, subject to the fulfillment of the terms and conditions described hereinafter. The licensee will not be entitled to assign or sublet the locker or any part thereof. The License will terminate on death or insolvency of the Licensee. 5.2 ISSUE OF LICENSE Before issuing a License for the use of locker, make it sure that the licensee maintains an account in any branch of our Bank in the same City preferably in the branch where locker facility is available. A License for this purpose can be issued in single or joint names. The following process is to be followed: Procedure for Issuance of Locker Customer Request for a Locker facility General Banking Officer or Designated Locker Custodian: Makes sure that the customer maintains an account in any online Branch within the city preferably the same branch. In case the customer maintains account in other branch, a confirmation is obtained from parent branch about the account being active, KYC is complete and the risk level assigned to the account holder. Either the customer maintains account in same branch or other branch, KYC needs to be updated. If the customer is assigned high risk, a fresh KYC needs to be conducted and approval needs to be obtained from Senior Management ,before assigning locker facility in compliance with Prudential Regulation IX to conduct enhanced due diligence for high risk customers. GBO: Completes the following forms / formalities from the customer: i. Locker Application Form MF – 19R ii. Specimen Signature Card MF - 19AR iii. A Valid copy of CNIC The locker can be opened singly or jointly and the authority to operate can be singly, jointly or either or survivor. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 310 If locker is opened in name of joint account holders, particulars of all are filled in the locker application form, Specimen Signature C ard is filled by only those authorized to operate the locker facility. GBO checks the original CNIC and collects the copy of CNIC from the customer and affixes the stamp of “Original Seen” and signs the copy. The copy is then attached with the Locker appl ication form. GBO checks the accuracy and completeness of the application form and specimen signature card. The documents are then forwarded to Branch Operation Manager (BOM). BOM receives the documents from GBO and after further verification and scrutiny, signs off the Locker Application form. NADRA VeriSys is also conducted. The documents are then forwarded back to GBO. GBO enters the following information of customer in EOC -Sym bols Safety Deposit Box Assignment: i. Client ID ii. Locker No. iii. Key No. iv. Branch Size Start Date v. End Date (Expected when the locker facility is expected to end) vi. Key Deposit GBO marks the status A -Active and clicks Debit Account from Tools Bar for deduction of Key Deposit and Locker Rent. GBO deducts charges as mentioned in Schedule of Bank Charges. GBO allots the locker number and hands over the key and takes acknowledgement on the Locker Application form having thoroughly read and understood the terms and condit ions. 5.3 TERMINATION OF LICEN SE The agreement of License may be terminated by either party giving “7” days notice in writing and licensee will deliver key and vacant possession of the locker to the Bank during office hours. 5.4 RIGHTS OF THE BANK ( LICENSOR) IN CASE OF NON -PAYMENT OF RENT In the event of the rent of the locker falling in arrears, the Bank reserves the following rights: - i. To refuse access to the locker. ii. To exercise a general lien over the property deposited or about to be deposited in the locker until such time as the dues / arrears are paid by the licensee. iii. To sell the property described in Para (b) above or part thereof in satisfaction of Bank's dues with the permission of the Court. A Declaratory Suit against licensee of the inoperative / above said locker shall be filed with the Court of Competent Jurisdiction to “Break Open” the said locker in presence of “Nazir of the Court”. However, permission for filing of any such suit and clearance of draft plaint should invariably be obtained fr om Legal Affairs Div . The articles so recovered from the said locker shall be kept with the permission of the Court with the Bank in safe custody. A list of the said articles prepared by the Court Nazir shall be kept on Bank’s as well Court’s record. Moreo ver, any banned article / item if recovered from the said locker, the Bank shall not be responsible for the same, which shall be handed -over to the “Nazir” for taking appropriate legal action against the licensee as per law. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 311 5.5 LIABILITIES OF THE B ANK (LICE NSOR) The Bank ’s liability or responsibility in the event of partial or complete loss or destruction of or damage to any article, documents, securities valuables in the locker due to any reason whatsoever, incl uding theft, fire, accident etc, is up to the insurance ceiling of the locker ONLY . Branches should properly convey the terms & conditions (including size, rent per annum, insurance ceiling etc) to the existing locker holders/new locker holders. Further, consent of all existing/new locker holders sha ll be obtained for the applicable insurance ceiling. (SBP BPRD Circular No 5 dated Jun 05, 2007). 5.6 USE OF LOCKER The locker will not be used or permitted to be used for any purpose other than the deposit of documents, jewelry or other valuables etc. No pro perty of an explosive or harmful nature and any contraband items etc. will be deposited therein. 5.7 RENEWAL / EXPIRY In the absence of any notice of termination of the agreement of License by either party in writing before the expiry of the License, the Lice nse will be considered renewed for a further period of one year on due date without prejudice to the rights of the Bank to recover the accrued rental in the meantime at the stipulated rates as explained under Section 7: 5.4 Rights of the Bank (Licensor) in case of Non -Payment of Rent 5.8 KEY DEPOSIT Apart from rent/License fee presently in force, a 'Certain' amount as per schedule of Bank Charges will be payable as key deposit. This amount will be refunded to the licensee on the surrender of locker and key and clearan ce of dues, if any 5.9 PAYMENT OF RENT The rent / License fee as per schedule of Bank Charges will be payable in advance on yearly basis and will not be refundable in the event of the locker being surrendered earlier than the expiry of the term of the License . 5.10 RECOVERY OF RENT IN CASE OF DEFAULT Before one month of the due date of the License fee / rent Bank should issue notice to the licensee on MF -19D pointing out the date of expiry. In case of default the periodical reminders at his registered address will continue to be sent through registered mail. The Bank may postpone the recovery of the overdue License fee / rent of the locker to a maximum period of “2” years. If even after expiry of the said period the licensee fails to deposit the rent of the locker, the Bank may at its discretion exercise anyone or all its rights as a licensor described herein above in Section 7: 5.4 Rights of the Bank (Licensor) in case of Non -Payment of Rent for the recovery of the overdue rent. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 312 5.11 BREAK OPENING OF LOC KERS Under the terms and conditions governing the use of Lockers, the Bank is entitled to revoke the License and “Break Open” the same with the permission of the Court, in the event of default in payment of License Fee. Whenever default is committed in payment of License Fee and in spite of all efforts made by the Branch, it is continued for a period of two years, the License be revoked and on fulfillment of the terms and conditions, as per procedure laid -down hereunder, the Locker(s) be broken -open with the pe rmission of the Court and the articles, if any lying, be retained and subsequently disposed of to recover the amount of the License Fee, as well as cost of breaking -open as prescribed in schedule of Bank Charges, cost of making inventory, its repairs and cost of legal / court expenses etc., with the permission of the Court. The procedure to be adopted is as follows: - i. A notice, as per draft marked Annexure VI, should be sent by Registered A/D Post to the Licensee at his / her addr ess on record of the Bank revoking the License and giving him / her Seven Days time to pay the dues and remove the contents/articles, if any, lying in the Locker. ii. If the notice is delivered but no response is received from the Licensee or the same could no t be delivered for what so ever reason, the Bank will send another notice marked as “Final Notice” as per Annexure VII under Registered A/D post. Even if thereafter, there is no response then the Bank may adopt the procedure for breaking open the said locker with the permission of the court as per procedure laid down here under. iii. In case the Final Notice is returned undel ivered by the Postal Authority or there is any doubt as to the delivery thereof, such notice or notices, as an abundant precaution, may be published in the newspaper and thereafter the Bank may precede with the action of breaking -open the Locker(s) with th e permission of the Court. iv. After the locker is broken -open with the permission of the court, an inventory shall be prepared by the “Nazir” of the Court of the articles, if any, found in the locker. A copy of said inventory shall be kept in Bank’s record a nd another on the record of the Court with the said “Nazir”. The said articles so recovered shall be kept in Bank’s custody with the permission of the court. However, if any banned item is found in the said locker, the same shall be handed -over to the “Naz ir” of the Court against proper receipt for disposal of the said banned item as per law. v. If any articles are found in the Locker, a notice should be sent by Registered A/D Post to the Licensee as per draft marked Annexure VIII, requiring the Licensee to collect the items / articles to be disclosed / specified at the place provided therefore; on payment of the amount due and payable to the Bank . On expiry of the period given in the said notice, the Bank should sell the contents / articles found in the Locker, with the permission of the Court and appropriate the net proceeds thereof towards the cost of making inventory, breaking -open the Locker, its repairs, payment of arrears of License Fee and Cost of Legal / Court Expenses. If the proceeds fall short, demand be made upon the Licensee for payment of such amount, as per draft marked Annexure IX vi. Upon breaking -open the Locker, with the permission of the Court if the same is found empty, a demand notice, a s per draft marked Annexure X, should be sent to the Licensee(s) calling upon him / her to pay the amount representing the arrears of License Fee, cost of making inventory, the cost of breaking -open the Locker, its repair and Cos t of Legal / Court Expenses. If the License Fee of Locker is found in arrears for a period of two years or more in any branch, the Branch Manager will render himself liable for disciplinary action. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 313 5.12 GENERAL INSTRUCTIONS FOR THE LICENSEE/ LI CENSOR i. The licensee will keep the key in a place of security and not to divulge the number of his/her locker and his / her secret password. The key will not be delivered by the licensee to any person other than his/her duly authorized agent. ii. In the event of the key o f the locker being lost, the licensee will notify the Bank in writing immediately. All charges incurred in connection with the reopening of the locker and replacement of lock and key will be borne by the licensee. All such repairs and replacements will be carried out by a workman appointed by the Bank. iii. The opening / closing hours of Safe Deposit Vault are subject to office hours in force except gazetted holidays and will be changed without individual notice to the licensees. iv. Normally the operation of a lock er by the licensee is restricted to twice a day, however, this condition may be relaxed by the Licensor in very rare / special cases. v. In the event of mechanical failure or for any other unavoidable reasons, the Bank reserve the right to close the safe depo sit vault for such time as it may in its discretion consider expedient. vi. In the event of breach of any of the conditions by the licensee, the Bank reserves the right to take action on the lines set out under Section 7: 5.4 Rights of the Bank (Licensor) in case of Non -Payment of Rent vii. Any notice or c ommunication sent by post at the registered address of the licensee shall be deemed to have been duly served on the address in due course. viii. Any change of address of the licensee should be immediately brought to the notice of Bank. ix. The rules, regulations and procedures are subject to amendment from time to time without any notice to the Licensee and the licensee is legally bound to comply with them. 5.13 LOCKER INSURANCE POL ICY As per the SBP guidelines on the Lockers Security Standards, it is mandatory that all the existing and new locker holders are aware of the deposit box/locker insurance policy and the salient features including the amount of coverage and the limit from time to time. Branches are required to display the precise Locker Insurance Policy in the Locker Room at a conspicuous place in order to make the customers know the said policy of the Bank 5.14 CONTROL GUIDELINES In order to avoid any unpleasant incident, all BMs/ BOMs are instructed to check the following on regular intervals: i. Check that locker a pplication forms and specimen signature cards are complete and intact ii. Check that Master key and Master Chart indicating Key Nos. and Locker Nos. is handled carefully and remains with the authorized person only iii. Check that the keys of Un -leased Lockers are k ept in sealed envelopes and in safe custody under the charge of an authorized person iv. Check that proper request in writing (in case the key is lost by Licensee) is obtained and all formalities are observed before getting the locker broken -open. In case of d eceased locker holders, proper and laid - down procedure and legal formalities are observed in respect of delivery of contents to the legal heirs B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 314 Chapter 6 INTER -BRANCH RECONCILIATION APPLI CATION CORONA In line with the Bank’s strategic objective of enhancing contr ols, a key initiative has been taken up for implementation of a new state of the art application for Inter branch reconciliation, ‘CORONA’. CORONA is live with effect from June 1st , 2010 and the legacy system is discontinued from the same date. This would help in bringing better control on data completeness, place emphasis on transactions not being timely responded through identification of number of days outstanding and also providing branches/units more time to respond / to resolve transactions , which are outstanding at their end. This chapter narrates the new process of delivery to the branches / units and elaborates layout of the new Inter branch transaction summary along with the underlying transactions. Inter branch reconciliation will be performed on a weekly basis in CORONA and reports will be sent to the respective Branch Managers (BM) /Branch Operations Managers (BOM) and respective units’ representatives through Bank’s current email set up. In addition the format of the report has been completely r evamped with respect to its layout and provision of information. Following are the key changes: i. The new format provides aging at summary and transaction level based on transaction date. The aging buckets are as follows :  up to 7 days  from 8 to 15 days  from 16 to 30 days  Total up to 30 days  More than 30 days ii. The new format categorizes the transactions under different currencies being used currently in transaction processing. iii. The new format provides currency wise Head Office General Ledger Account movement (HO GL). iv. The new format provides information on transactions to be responded by other branches. v. The new layout will be referred as “Inter -branch Transaction Reconciliation Summary” . Summary will be supported by underlying transactions report. The report would be branch wise and defining the period for which data has been processed for matching. Inter branch transaction reconciliation summary is mainly divided in Five (5) s ections: 6.1 OUTSTANDING TRANSACT IONS AT BRANCH END A GING ANALYSIS These are transactions, which the branch needs to resolve/respond. The sum of section (1) is represented as “Total Outstanding / Unresolved transactions at Branch end” i. Transactions not res ponded as yet (Formerly REK 235) : In this sub -section outstanding debit and credit transactions are reflected, which are still to be responded by the branch (receiving this transaction report). ii. Responded but with error (outstanding) (Formerly REK 236) : In this sub -section outstanding debit & credit transactions are reflected, which have already been responded by the branch but due to some error the transactions are still not resolved / unmatched. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 315 6.2 OUTSTANDING /UNRESOL VED AMOUNT AT BRANCH END This sec tion narrates the outstanding amount in respective currencies for the transactions (debit & credit) mentioned in section 1 Part (a&b). 6.3 TRANSACTIONS TO BE R ESPONDED BY OTHER BR ANCHES This section narrates the outstanding debit & credit transactions, which are originated by the branch receiving this Transaction Summary but are not responded by other branches. This is only for information purposes and will help branches to coordinate with each other in resolution of all unresolved / outstanding transactions. 6.4 TRANSACTIONS AMOUNT (VALUE) TO BE RESPONDED BY OTHER BRANCHES This section narrates the outstanding amount in respective currencies for the transactions (debit & credit) mentioned in section 3. 6.5 HEAD OFFICE GENERAL LEDGE R ACCOUNT M OVEMENT This section defines currency wise HO GL account movement for the particular branch for the period mentioned on the schedule. It is important to notify that the movement is the period, whereas, outstanding transacti ons status is as of date i.e. it reflect all the transactions, which have not been resolved / responded as of date. Definition of the fields in this section is as follows: i. Opening balance defines the date and opening balance as of date for branch HO GL ii. Debit row reflects the debit movement in branch HO GL for the recon cycle period iii. Credit row reflects the credit movement in the branch HO GL for the recon cycle period iv. Missing statement data will reflect amount where any transaction is not loaded in Cor ona for the period v. Closing balance defines the date and closing balance in amount as of date for branch HO GL It is important to notify that normally there should not be any missing statement. In case there is any amount populated in this field, the branc h should immediately contact and coordinate with the Reconciliation Department for identification and resolution of such missing information. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 316 6.6 SUMMARY SCHEDULE It w ill be accompanied by underlying trans actions which will be used by bran ches to resolve all outstanding / unmatched transactions. Detailed Transaction Schedule comprises following areas: i. Part (1) Transactions not responded as yet (Formerly REK -235) represents transactions, which are not responded by the branch e.g. (receiving the schedule) and in this portion branch column represents the codes of the originating branches. ii. Part (2) Transactions responded but with error (Formerly REK -236) represents t ransactions which have been responded by the branch but due to some error the transactions are still not resolved / unmatched. In this part contra branch column represents branch codes who have originated the transaction. iii. Part (3) Transactions to be respo nded by other branches represents transactions which are originated by branch (receiving the schedule) and contra branch column represents branch codes that have not responded these transactions. This is only for information purposes and will help branches to coordinate with each other in resolution of all unresolved / outstanding transactions. Note: The ‘Remarks’ column given in the detailed transaction report is for branch /units own usage and is not intended to be sent to the Reconciliation department. Only those transactions, which needs to be resolved at the Reconciliation department level needs to be communicated through email. For any clarification on this chapter please contact the following staff members: Asma Hanif, e -mail ID: Asma.Hanif@mcb.com.pk Saira Javed, e -mail ID: Saira.Javed@mcb.com.pk Contact no. 042 -36041245 Faisal Waheed -mail ID: Faisal.Waheed@mcb.com.pk Contact no.042 -36041241 Note: Any addition / change in the process and contents would be circularized / communicated accordingly. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 317 B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 318 B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 319 Chapter 7 INVESTMENT SERVICES - MUTUAL FUNDS 7.1 SALES OF MUTUAL FUND S i. Sales staff will assess the customer's risk profile through Risk Profile Questionnaire and customer signs on the same to ensure that they were informed of the products most suited for their category. ( Not required for Institutions ) ii. If the customer agrees to invest in a particular fund, the sales staff requests the customer to comprehend and fill out the Fund Term Sheet to relieve the Bank and AMC of performance liability and secure its reputational risk. iii. Staff explain Front end Fees and Processing Charges that will be charged on the Investment, so that the customer is aware of the deduction. iv. Customers are requested to first open an MCB Bank Account. v. Minimum amount of transaction is PKR 5,000/ - for MCB Asset Management Company Limited and PKR 10,000/ - for JS Investments Limited. vi. The following documents are filled / at tached by the customer:  Printout of filled Risk Profile Questionnaire – signed by Applicant – stamped and signed by IS Relationship Associate  Fund Term Sheet – signed by Applicant – stamped and signed by IS Relationship Associate  Asset Management Company’s Registration Form (for first -time investors only) vii. Customer to mention his existing MCB Account Number, so that at the time of redemption, the funds are credited directly into their accounts. viii. Asset Management Company’s Unit Purch ase Form (if Customer is already investing in AMC, they should mention their AMC Account Number on the Form). ix. In case of a new to Bank customer, the Branch staff first opens the customer’s MCB Bank Account and waits until the funds have cleared into the ne w account. x. In case of Individuals copy of Valid CNIC – signed and stamped “Original Seen” by an Authorized Branch Officer - Branches to check that CNIC / Passport are not expired xi. In case CNIC is expired, copy of NADRA Token will be accepted, provided copy of CNIC is submitted as soon as it is issued. xii. Copy of Zakat Declaration Form (if applicable) – signed and stamped “Original Seen” by an Authorized Branch Officer xiii. Internal Fund Transfer Form (SF -100R) – signed, signature verified by an Authorized Branch Offic er In case of Institutions: i. Copies of Valid CNIC / Passport of all authorized signatories – signed and stamped “Original Seen” by an Authorized Branch Officer ii. List and sample signatures of all authorized signatories – signed and stamped “Original Seen” by an Authorized Branch Officer iii. Trust Deed – signed and stamped by Company Secretary iv. Articles of Association – signed and stamped by Company Secretary v. Board Resolution permitting the specified investment – signed and stamped by Company Secretary vi. Internal Fund T ransfer Form – signed, signature verified by an Authorized Branch Officer Note: Risk Profile not required in case of Institutional clients B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 320 Once the customer documentation (detailed above) is complete, the forms are approved by the Branch manager/ Investm ent Relationship Associate. Branch Manager/Authorized Officer should also affix their stamp under their sign. Branch Operations to verify Customer’s signature on Fund Transfer Request Form (SF -100R) Branch Operations Staff debit the Customer’s account and Credit the relevant Trustee Collection Account through Inter -Branch Transfer on SYMBOLS: Fund: Br. Code Investment Trans. Type Processing Fee Trans. Type A/C to Credit: CDC Trustee MCB Dynamic Cash Fund 1578 TFRD / TFRC TFRD / TFRC 0407468881000077 CDC Trustee MCB Dynamic Stock Fund 1578 TFRD / TFRC TFRD / TFRC 0407469811000078 CDC Trustee MCB Dynamic Allocation Fund 1578 TFRD / TFRC TFRD / TFRC 0407469381000076 MCFSL Trustee JS Income Fund 1578 TFRD / TFRC TFRD / TFRC 0415355941000119 CDC Trustee Unit Trust of Pakistan 1578 TFRD / TFRC TFRD / TFRC 0390116971000121 The Internal Fund Transfer is made through 3 Accounting entries: Amo unt being invested in the Fund i. Narration to be passed: “Investment In [Fund Name] – [Customer Name] –[Customer Account No.] – *Branch+” Example : Investment In MCB DAF –Shakir Khwaja –12345678 -0020 Non -Refundable Processing Charges of PKR 150/-. ii. Narration to be passed: “Processing Fees on Investment In [Fund Name] –[Customer Name] –*Account No.+” Example : Processing fees on Investment In MCB DAF – Shakir Khwaja -12345678 Federal Excise Duty on Processing Charges PKR 15/-: iii. Narration to be passed: “FED processing on investment *Fund Name+ – [Customer Nam e] – *Account No.+” Example : FED processing on investment MCB DAF – Shakir Khwaja -12345678 i. Branch Operations to confirm transfer of amount into Trustee Collection Account the same day ii. Branch Operations to provide Investments Associate with a photocopy o f the Fund Transfer Request Form. iii. Investment RA checks and attaches the Sales Checklist to the documentation pack and signs and stamps the same. All forms are sent to: Haris Naeem – IS Operations, 2nd floor, World Business Center B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 321 DHA Phase 1, Main National Highway KARACHI iv. Documents Mailed:  Original Investment Checklist  Original Risk Profile Questionnaire  All Original AMC Forms  Fund Term Sheet  Supporting Documents (CNIC, Zakat, Trust Deed for Institutional investors etc.)  Copy of Internal Fund Transfer Form v. For all upcountry transactions the documents need to be scanned and sent by email or fax (in case of faxed documents the Branch Manager / Authorized Officer to sign on the application forms) The original set of documents should be dispatched the same day via courier so that they reach latest by next Business day. All forms are sent to: Haris Naeem – IS Operations Officer Haris.naeem@mcb.com.pk FAX: 021 -531 7168 vi. Big-ticket transactions of PKR 25 Million and above will be confirmed over e -mail by the respective branches to the Product Manager / respective Sales Head to bring it to their notice. vii. AMC will issue Units directly in the name of the customer, in accordan ce with the original application forms received from branches and cleared funds received from Investment Operations. viii. AMC will send a Statement of account to the customers within 6 Business days to confirm the purchase of units, and assign a folio number fo r all first time sales. MCB Sales staff to ensure that on subsequent sales the customer mentions this folio number on the purchase / redemption forms to enable the AMC to maintain a consistent/complete record of the customer. ix. All AMCs issue Electronic uni ts and no certificates will be issued; only a statement of account will be provided. However, a certificate can be issued on request with a nominal payment (generally PKR 50 per certificate – the denomination of the certificate is at the discretion of the investor) and filling in a request for physical certificates form. x. Investment Services will e -mail a daily Sales Summary MIS to all branches for their knowledge. 7.2 DISCREPANCIES AND RE VERSALS i. Once a customer’s account has been debited for the investment amo unt, the transaction cannot be reversed. Only upon written request of the Customer and the approval of the relevant Group Head, will the transaction be reversed and the funds returned to the Customer. ii. If, after receipt of the application by Investment Oper ations, the application is found to be incomplete or incorrect in any manner, Investment Operations will advise the Branch staff and Investments RA to remove the discrepancy within 2 business days. In the event the discrepancy is not removed in that time, the relative IS Relationship Associate will be held accountable, and the sale will not reflect in either their targets or the branch targets. iii. However, in the event Units have been issued and a discrepancy is discovered after that, the AMC will advise the a pplicant in writing to remove the discrepancy within fifteen days. If the investor fails to remove the discrepancy, the Units shall be redeemed at the Redemption Price on the date as decided by the AMC. The Unit Holder shall not be entitled to any payment beyond the redemption value. The same will be highlighted to the relevant Group Head for their knowledge. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 322 7.3 AFTER -SALES SERVICES 7.3.1 Redemption Requests: i. In the event that the customer wishes to redeem their investment, they may request for a Redemption of Units, which can be partial or in full. ii. In case the Fund has a Back -end Load attached to it, staff to explain to customer that redemption will incur a penalty on the investment and will result in a loss for the customer. iii. Customer to fill out the AMC redemp tion form clearly mentioning the folio number assigned by the AMC. iv. The customer needs to either provide a copy of their Statement of Account as evidence of his holding (Optional) or a physical certificate (as the case maybe), along with the redemption application. v. Investments RA to verify the customer’s details and ensure that all redemption transactions are reported to Investment Operations AND MCB Asset Management Company latest by 4:30pm so that Investment Operations will report these transactions to AM C on the same day by 6:30pm. Upcountry branches to scan & send the complete set by 4:30pm and originals should be dispatched by overnight courier, so that they are received next Business day. vi. AMC will directly credit the amount to the customer’s MCB accoun t mentioned on the redemption form and inform Investment Operations. vii. Customer's funds will be credited within 6 Business days by AMC along with a statement of account. 7.3.2 Conversion of Units Requests: i. In the event that the customer wishes to convert their i nvestment to another Fund managed by the same AMC, they may wish to request for Conversion of Units. ii. In case the Fund has a Front -end Load or a Back -end Load attached to it, staff to explain to customer that transfer will incur a charge on the investment a nd will result in a loss for the customer. iii. Customer to fill out the Term Sheet for the New Fund & the AMC Conversion of Units form clearly mentioning the folio number assigned by the AMC. iv. The customer needs to either provide a copy of their Statement of A ccount as evidence of his holding (Optional) or a physical certificate (as the case maybe), along with the transfer application. v. Investments RA to verify the customer’s details and ensure that all redemption transactions are reported to Investment Operatio ns AND MCB Asset Management Company latest by 4:30pm so that Investment Operations will report these transactions to AMC on the same day by 6:30pm. Upcountry branches to scan & send the complete set by 4:30pm and originals should be dispatched by overnight courier, so that they are received next Business day. vi. AMC will execute the transfer request and confirm the same to Investment Operations. vii. Customer will receive a revised statement of account. 7.3.3 Account Statement Requests: In case the customer is not receiving their statement, branches to fill out a Change of Address Form, signed by the customer and scan and fax the same to Investment Operations and the AMC. Similarly, the IS RA will courier the originals to IS Ops and AMC r espectively. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 323 7.3.4 Investment Value Enquiries: In case the customer wants to enquire the current value of their investment, branches to note down their CNIC and AMC Account No. and forward the same to Investment Operations and the Business Team. Alternatively, the Customer may directly contact the AMC Toll -free number. 7.3.5 Submission of Zakat Exemption Certificate: Under the Zakat and Ushr Ordinance of 1980, units held by resident Pakistanis who are declared Muslims are liable to pay 2.5% of the value of their inv estment as Zakat. Zakat is deducted on Mutual Funds, unless the customer provides an Exemption Certificate (CZ -50) at least one month before the 1st of Ramadan. It is the responsibility of the Investment RAs as well as the Branch staff to follow up with cu stomers and ensure that their investment has a valid Exemption Certificate attached to it so that Zakat is not deducted from their investment. i. For Joint Account Holders, Zakat Exemption is necessary for both account holders. ii. For Non -Muslims, Branch to rece ive instructions in writing from the customer that since they are not eligible for Zakat, they may be exempted from the same. iii. Change of Account Information Requests: iv. In the event that the customer wishes to change any particulars of their Account Informati on (address, nominee details, Bank Account Number etc.), they may do so by submitting the AMC Special Request Form clearly mentioning the folio number assigned by the AMC. v. The customer needs to provide a copy of their Statement of Account as evidence of hi s holding vi. Investments RA to verify the customer’s details and ensure that all redemption transactions are reported to Investment Operations AND MCB Asset Management Company latest by 4:30pm so that Investment Operations will report these transactions to A MC on the same day by 6:30pm. Upcountry branches to scan & send the complete set by 4:30pm and originals should be dispatched by overnight courier, so that they are received next Business day. vii. Upcountry branches to scan & send the complete set by 4:30pm an d originals should be dispatched by overnight courier, so that they are received by Investment Operations by next Business day. viii. AMC will execute the changes and issue a notification to the customer. 7.3.6 General Enquiries: All General Enquires must be forwarde d to either the Investments RAs, the Unit Head Sales – Investment Services or the Investments Business Team. They will ensure that these queries are responded to within 24 hours. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 324 Chapter 8 GOVERNMENT SECURITIE S (DSC/ SSC) 8.1 ABOUT DEFENCE SAVING CERTI FICATES (DSC) The Government of Pakistan introduced Defence Savings Certificate scheme in the year 1966. The scheme has specifically been designed to meet the future requirements of the depositors. This is 10 years' maturity scheme with built in feature of automatic rei nvestment after the maturity. These certificates are available in the denominations of PKR 500, PKR 1000, PKR 5,000, PKR 10,000, PKR 50,000, PKR 100,000, PKR 500,000 and PKR 1,000,000/=. 8.1.1 Eligibility These certificates can be purchased by a single adult, a minor, two adults in their joint names with the options of payable to the holders jointly (Joint -A ) or payable to either (Joint -B). An adult can also purchase these certificates on behalf of a single minor, two minors jointly or himself/herself and a mi nor jointly. In addition to above individual investors, the following institutions are also allowed to invest in the scheme, subject to their registration under the relevant law for the time being in force:  Registered Charities (Non -profit bodies).  Public Sector Enterprises excluding Banks.  Private Educational & Health Institutions.  Employees Old Age Benefit Institutions (EOBIs).  Private Corporate Sector registered with the SECP excluding Banks.  Non -Bank Financial Institutions (NBFIs) excluding Insurance Co mpanies. 8.1.2 General Guidelines The customer must have a local currency account, as these certificates cannot be issued from a foreign currency account. These certificates are encashable at par any time after the date of purchase. However, no profit is payable if encashment is made before completion of one year. The DSCs are registered certificates; the name of the person is mentioned on the certificates and only that person can encash the certificates. But the holder can nominate an individual as nominee of th e certificates and these nominees can operate the certificates on holder’s death (subject to the prevailing laws applicable in Pakistan at the time of encashment). Therefore it is prudent to obtain Legal Opinion in such circumstances before processing the transaction. Guidelines are subject to change in Defence Saving Certificates rules 1996 and any other relevant rules and regulations issued by the Government of Pakistan from time to time. DSCs can only be encashed from the bank where these certificates we re issued. The DSCs are issued to account holders only, walk –in customers are to be avoided. However, DSCs can be issued against cash to the account holders or against remittance received from abroad only if it is specified to issue DSCs against that remi ttance. Bank’s approved KYC & AML policy should be strictly complied for walk -in customers; in addition, verification of computerized CNIC should be done through NADRA VERYSIS. DSC has no profit coupons and is a single certificate. On the reverse, the profit schedule is printed which denotes the value of the certificate after completion of each year. In case of premature encashment profit is entitled only for completed year for e xample, if a customer wants to encash the certificate between B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 325 eighteen months after the date of issuance, he will receive the profit of the first year only and no profit would be given to him for the remaining eight months. Stamp of latest approved rates should be affixed on reverse of the DSC. At the time of encashment, 2.50% (of Zakat) to be collected at source as per rules . However, non –Muslim and followers of different sects as described by the Zakat and Ushr Ordinance 1980 are exempted from Zakat, bu t followers of certain sects e.g. Shias, Quadians etc. have to submit an indemnity on a Bond paper attested by the Oath Commissioner for such exemptions. The minimum amount of DSCs that a customer is to be issued is PKR. 500 and there is no maximum limit f or its issuance. 8.2 ISSUANCE OF DSC 8.2.1 Procedure for Issuance of DSC by Main Branch : Printed forms are available from the government securities desk if a person wants to buy DSCs. These forms are issued and approved by the State Bank of Pakistan. The custom er fills out the form giving the following details.  Full name  Address  Computerized NIC number (photocopy attached)  Account number (if being issued against his account)  Required denomination.  Total Amount  Signature  Nominee (if any)  Zakat declaration stating if Zakat is to be deducted or not except the Non -Muslim customer. If there are joint applicants, the other person also has to provide the same information as mentioned above. The government securities officer takes out the required denomination and types the name, bank’s stamp, and date of issue and registration number. In case the amount of issuance of DSC is more than Rupees one million per application, then the certificates has to be signed by the Branc h Manager of the Main Branch as one of the tw o signatories. The DSCs serial numbers are logged in the DSC issuing register along with the beneficiary’s name and date of issuance. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 326 In case of joint applicants there is a section on the DSCs mentioning whether the DSCs are to be operated singly or join tly i.e. if singly, any of the two applicants can sign & operate the DSCs but if joint, both the applicants have to sign the DSCs. The DSCs are delivered to the customer who has to sign on the application as an acknowledgement of receipt. Original Zakat d eclaration shall be returned to the customer after retaining copy of the same and recording with relevant register should be done. 8.2.2 Procedure fo r Issuance of DSC by Cross Branch : If the customer comes to any other SYMBOLS branch for issuance of DSC then the receiving branch will follow following procedure: i. Customer will fill out printed application form for issuance of DSC/SSC along with a crossed cheque of “Payees Account Only” in favor of MCB Bank Ltd duly attached with application form. ii. The authorized branch person will verify customer’s account signature and forward the request along with cross cheque to its respective Main Branch with branch covering letter. iii. Upon receipt of application received from branch, the authorized officer will scrutinize appl ication form and will complete all formalities as mentioned above. iv. It is important to follow banks approved KYC & AML policy for walk in customer before issuance of DSC/SSC. Transaction posting in SYMBOLS : DSC can be issued in following three ways: a) By Cash b) Direct Debit (for self branch and other branch customer) c) Clearing a) By Cash : If a walk -in customer (non account holder ) comes for issuance of DSC via cash, then all prerequisite formalities will be completed at branch end and customer will deposi t the cash at counter. It is important to comply with bank’s approved KYC & AML policy related with walk -in customers before issuance of DSC. Following entries will be passed in SYMBOL S: Go to EOC>>General Ledger>>Transaction>> Batch Maintenance. Pass following manual entry in GL: CCY GL CODE NARRATION DEBIT CREDIT PKR 2010101010 CASH IN VAULT XXXX B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 327 PKR 1090801160 DSC SALE PAYABLE TO SBP XXXX b) Direct Debit (for self branch or other branch customer)  Go to EOC>>Deposit>> Transaction>>Value Transaction>>Withdrawal.  Insert customer’s complete account number and press F8 to execute query.  Debit customer’s account using transaction code DSDR with required amount and cheque number and press F10. System will pass following entry in GL: CCY GL CODE NARRATION DEBIT CREDIT PKR CUSTOMER’S ACCOUNT XXXX PKR 1090801160 DSC SALE PAYABLE TO SBP XXXX Note: No manual inter branch advice will be entertained to/from branches. c) By Clearing If a walk -in customer or self branch customer has given cheque of a bank other then MCB, then the cheque will lodged in clearing and DSC will be issued after proceeds of the cheque have been realized. It is important to comply with bank’s approved KYC & AM L policy for walk in customers. Go to EOC>>General Ledger>>Transaction>>Batch Maintenance. Following entry will be passed in GL: CCY GL CODE NARRATION DEBIT CREDIT PKR 1150101140 CLEARING CONTROL ACCOUNT XXXX PKR 1090801160 DSC SALE PAYABLE TO SBP XXXX Note: Details of DSC sold against negotiable instruments should be clearly mentioned in daily MIS prepared by branch. 8.2.3 Daily MIS for Sale of DSC : Statement of Sale is prepared by the government securities desk for submission to the State Bank of Pakistan at the end of each day and the same is to be jointly signed by the preparing officer and the officer in charge. Note: Total amount of sale shown in the Claim Statement must be equal to the Credit Balance appearing in the DSC Sale Payable to SBP Account (1090801160) which also includes amount of cheques sent for collection. Main Branch will maintain and submit MIS of daily sale of DSC to State Ban k of Pakistan for recovery of claim against sale of DSC. The MIS for the day must always be submitted on the next working day. Following information will be available on the MIS: B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 328 S.NO DATE NAME OF APPLICANT CERTIFICATE NO. REGISTRATION NO. DENOMINATION QTY TOTAL SALE The daily MIS for sale of DSC will be concluded with following summary: S.NO DENOMINATION QUANTITY VALUE CERTIFICATE NO. Main branch will inform MCB Treasury for issuance of SBP cheque against total sale amount. The cheque will be deposited in SBP along with Statement of Sale of DSC sale. Upon confirmation from SBP, following entry will be passed in the books of Main Branch Go to EOC>>General Ledger>>Transaction>>Batch Maintenance CCY GL CODE NARRATION DEBIT CREDIT PKR 1090801160 DSC SALE PAYABLE TO SBP XXXX PKR 1110101010 HEAD OFFICE ACCOUNT XXXX 8.3 ENCASHMENT OF DSC 8.3.1 Procedure for E ncashment of DSC by Main Branch : i. The customer brings in the matured DSCs for encashment. ii. The person at the government securities desk verifies that the Bank issues the DSCs. As per the SBP the DSCs are encashed from the same Bank & branch from which Bank the DSCs are purchased. iii. The beneficiary customer has to sign on the back of the DSCs in front of the person encashing the same. iv. If joint applicants, authorized signature as per mandate of application must be taken on the reverse. v. The signatures are verified by the government securities desk after pulling -out the original application form the record. vi. The government securities desk pro vides the customer with the encashment form, which the customer has to fill out or give application for encashment of the certificates. vii. The certificates are marked “PAID”. “PAID” stamp must always be kept under dual control of BOM and officer in charge of the desk. viii. Zakat (if applic able) is to be collected at source as per rules ix. It is upon customer’s discretion if he wants to take cash or wants his account (LCY) to be credited. x. If the customer requests for cash payment against the certificates, the governmen t securities desk prepares a cash withdrawal slip. But this should always be avoided and credit to the account should be encouraged at all times . xi. The calculated amount is to be checked by an officer in charge of securities desk and the slip is to be signed off by both i.e. the person who has prepared the slip and the officer who has verified it. xii. The particulars of DSC should be verified from with “DSC Issuance Register” at the time of encashment. The register should be updated for all encashment in order to avoid duplicate payment . B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 329 Payment Options and transactions postings in SYMBOLS : There are two payment options available for encashment of DSC: a) Via Cash b) Direct Credit to customer’s account (self or other branch customer) a) Via Cash Where cash is being paid out, a withdrawal slip is handed -over to the customer who presents the slip to the cash counter where the teller should obtain a signature of the customer on the reverse and must also ensure that two signatures (i.e. the processor’s and the offi cer) are made there in. After the cash payment to customer, “CASH PAID” stamp will be affixed on cash withdrawal slip (cash payment voucher) by authorized teller and following entry will be passed in GL: Go to EOC>>General Ledger>>Transaction>>Batch Main tenance>>Batch Entry and pass following manual entry: CCY GL CODE NARRATION DEBIT CREDIT PKR 2090701020 DSC ENCASHMENT ACCOUNT XXXX PKR 2010101010 CASH IN VAULT XXXX b) Direct credit to customer’s account (self or cross branch) If the proceeds of encashment of DSC are being made directly to customers’ account (self or cross) then following option in SYMBOLS will be used for encashment of DSC:  Go to EOC>>Deposit>>Transaction>>Value Transaction>>Deposit.  Insert complete account number of beneficia ry and press F8 to execute the query.  Credit customer’s account using transaction code DSCR by inserting encashment amount and date. If the transaction is greater than user limit then system will ask for supervisor’s override after which transaction will be completed successfully. Following auto accounting entries will be generated: For self branch customer CCY GL CODE NARRATION DEBIT CREDIT PKR 2090701020 DSC ENCASHMENT ACCOUNT XXXX PKR CUSTOMER’S ACCOUNT XXXX For cross branch customer CCY GL CODE NARRATION DEBIT CREDIT PKR 2090701020 DSC ENCASHMENT ACCOUNT XXXX PKR 1110101010 HEAD OFFICE ACCOUNT (respective branch) XXXX CCY GL CODE NARRATION DEBIT CREDIT PKR 1110101010 HEAD OFFICE ACCOUNT (respective main branch) XXXX PKR CUSTOMER’S ACCOUNT XXXX B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 330 8.3.2 Procedure for encashment of DSC at cross branch :  Receive application for encashment of DSC from customer and make sure that all required information and documents are enclosed.  Customer’s application will be sent to respective Main Branch with a covering letter by branch mentioning details of customer (Name, valid CNIC etc .)  Main branch upon receiving of application from branch will complete all formalities as mentioned above. 8.3.3 Deduction of withholding tax : Normally the rate applicable is mentioned on the back of the securities and the amount payable is calculated. This rate is subject to change by State Bank without notice therefore it is prudent to keep an update rate list issued by SBP at all times for ready reference and the same should be referred at the time of encashment of certificates. At present, the profit earn ed is exempt from withholding tax, if the total investment in the scheme by the investor(s) does not exceed PKR 150,000/ -. However, withholding tax @ 10% is deductible at source on the profit(s) earned if the total investment exceeds PKR 150,000/ - by the investor(s) at the time of encashment of certificates. The Zakat is collected at source as per rules. If the encashment of DSC is made via cash then tax will be recovered manually from customer and proceeds will be recorded in the books of branch via manua l GL batch. Incase if the encashment is done via direct credit to customer’s account then following steps will be followed:  Profit amount will be credited to customer’s account along with principal amount via transaction code DSCR which will directly hit DSC Encashment Account (2090701020).  10% withholding tax will be deducted from customer’s account using transaction code WHDS (Withholding Tax on Encashment of DSC). Following auto entry will be passed: CCY GL CODE NARRATION DEBIT CREDIT PKR CUSTOMER’S ACCOUNT/Cash in vault XXXX PKR 1090601030 WITHHOLDING TAX ON SUPPLIES & SERVICES XXXX 8.3.4 Daily MIS for encashment of DSC : A statement of encashment is prepared by the government securities desk for submission to the State Bank of Pakistan at the end of each day and the same is to be jointly signed by the preparing officer and the officer in charge. Note: Total amount of encas hment shown in the Claim Statement must be equal to the Debit Balance appearing in the DSC Encashment Account (2090701020). This statement provides following information: B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 331  Serial Number  Register Number  Name of Applicant  Certificate Number  Denomination  Total certificates (quantity)  Face Value of certificate  Interest Amount  Total Amount paid  Commission (recoverable from SBP)  Zakat deduction (if applicable)  Date of issue (certificate)  Date of payment (certificate)  Withholding tax deducted Main branch is r equired to submit this MIS on daily basis to SBP to recover the claim against encashment of DSC. Upon confirmation from SBP, following entry will be passed in the books of Main Branch: CCY GL CODE NARRATION DEBIT CREDIT PKR 1110101010 HEAD OFFICE ACCOUNT XXXX PKR 2090701020 DSC ENCASHMENT ACCOUNT XXXX 8.3.5 Recording of C ommission on issuance and encashment of DSC : Main branch recovers commission from SBP against sale of DSC. The commission is charged on rates prescribed by the government from time to time. The branch is responsible to submit claims preferably at the end of each month to SBP and keep track of all sal e for the recoverable commission for transactions where claims have been submitted but not realized and where claims are yet to be submitted. Following entry will be passed in the books of branch: CCY GL CODE NARRATION DEBIT CREDIT PKR 1110101010 HEAD OFFICE ACCOUNT XXXX PKR 3030401590 COMMISSION ON SSC/DSC XXXX B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 332 8.4 ABOUT SPECIAL SAVING CERTI FICATES (SSC) Keeping in view the periodic needs of depositors, this three years' maturity scheme was introduced in February, 1990. These certificates are available in the denomination of PKR 500, PKR 1000, PKR 5,000, PKR 10,000, PKR 50,000, PKR 100,000, PKR 500,000 and PKR 1,000,000/=. Profit is paid on the completion of each period of six months. 8.4.1 Eligibility: These certificates can be purchased by a single adult, a minor, two adults in their joint names with the options of payable to the holders jointly (Joint -A ) or payable to either (Joint -B). An adult can also purchase these certificates on behalf of a single minor, two minors jointly or himself/herself and a minor jointly. In addition to the above individual investors, the following institutions can also invest in the scheme, subject to their registration under the relevant law for the time being in force:  Registered Charities (Non -profit bodies)  Public Sector Enterprises excluding Banks  Private Educational & Health Institutions  Employees Old Age Benefit Institutio ns (EOBIs)  Private Corporate Sector registered with the SECP excluding Banks  Non -Bank Financial Institutions (NBFIs) excluding Insurance Companies 8.4.2 Mode of deposit These certificates can be purchased by depositing cash at the issuing office or by presenting a cheque. The certificate shall immediately be issued on receipt of cash. However, in case of deposit through cheque the certificates shall be issued from the date of realization of the cheque after receipt of the clearance advice. 8.4.3 The investme nt limit The minimum investment limit is PKR 500/ -, however, there is no maximum limit of investment in the scheme. 8.4.4 Encashment/ Redemption These certificates are encashable at par any time after the date of purchase. However, no profit is payable if the encashment is made before completion of six months. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 333 8.5 ISSUANCE OF SSC 8.5.1 Procedure for issuance of Special Saving Certificate (SSC) i. Printed forms are available from the Government securities desk if a person wants to buy SSCs. These forms are issued and approved by the State Bank of Pakistan. ii. The customer fills out the form giving the following details:  Full name  Address  National I.D card number (photocopy attached)  Account number (if being issued against his account)  Required denomination.  Total Amount  Signatures.  Nominees (if any)  Zakat declaration stating if Zakat is to be deducted or not except the Non Muslim customers.  If there are joint applicants the other person also has to provide the same information as mentioned above. iii. Government securities de sk checks the data provided by the applicant and passes entry in the system. iv. The government securities desk takes out the required denomination and types the name, bank’s stamp, date of issue and the registration number. v. The SSCs serial numbers are logged in the SSCs issuing register along with the beneficiary’s name and date of issuance. vi. In case of joint applicants there is a section on the SSCs mentioning whether the SSCs are to be operated JOINT “A” or JOINT “B”. vii. If JOINT “B”, any of the two applicants can sign & operate the SSCs but in case of JOINT “A” both the application have to sign the SSCS. viii. The SSCs are delivered to the customer who has to sign on the application as an acknowledgement of receipt. 8.5.2 Procedure for issuance of SSC in cross branch If the customer comes to any other SYMBOLS branch for issuance of SSC then the receiving branch will follow following procedure: i. Customer will fill out printed application form for issuance of DSC/SSC along with a crossed cheque of “Payees Account Only” in favor of MCB Bank Ltd duly attached with application form. ii. The authorized branch person will verify customer’s account signature and forward the request along with cross cheque to Main Branch with covering letter. iii. Upon receipt of application received from b ranch, the authorized officer will scrutinize application form and will complete all formalities as mentioned above. iv. It is important to follow banks approved KYC & AML policy for walk in customer before issuance of DSC/SSC. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 334 8.5.3 Transaction postings in SYMBOL S SSC can be issued in following three ways: a) By cash b) Direct debit (for self branch or cross branch customer) c) By clearing a) By Cash If a walk -in customer comes for issuance of SSC via cash, then all prerequisite formalities will be completed at branch end and customer will deposit the cash at counter. Following entries will be passed in SYMBOSL: Go to EOC>>General Ledger>>Transaction>>Batch Maintenance. Pass following manual entry in GL: CCY GL CODE NARRATION DEBIT CREDIT PKR 2010101010 CASH IN VAULT XXXX PKR 1090801170 SSC SALE PAYABLE TO SBP XXXX b) Direct Debit (for self branch or other branch customer) Go to EOC>>Deposit>>Transaction>>Value Transaction>> Withdrawal. Insert customer’s complete account number and press F8 to execute query. Debit customer’s account using transaction code SSDR with required amount, cheque number and press F10. System will pass following entry in GL: CCY GL CODE NARRATION DEBI T CREDIT PKR CUSTOMER’S ACCOUNT XXXX PKR 1090801170 SSC SALE PAYABLE TO SBP XXXX c) By Clearing If a walking customer or self branch customer has given cheque of a bank other then MCB, then the cheque will lodged in clearing and SSC will be issued after proceeds of the cheque have been realized. Go to EOC>>General Ledger>>Transaction >>Batch Maintenance>>Batch E ntry. Following entry will be passed in GL: CCY GL CODE NARRATION DEBIT CREDIT PKR 1150101140 CLEARING CONTROL ACCOUNT XXXX PKR 1090801170 SSC SALE PAYABLE TO SBP XXXX B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 335 8.5.4 Daily MIS preparation (Statement of Sale of SSC) A statement of sale is prepared by the government securities desk for submission to State Bank of Pakistan (SBP) at the end of each day and same is to be jointly signed by the preparing officer and the officer in charge. Note: Total amount of sale shown in the SSC Sale Statement must be equal to the credit balance appearing in the SSC Sale Payable to SBP Account (1090801170). Following information will be available in the MIS submitted to SBP:  Serial number  Date  Name of applicant  Certificate number  Denom ination  Quantity  Total Amount  Cheque Book Number  Register Number Main branch is required to submit the statement of sale of SSC on daily basis to SBP to submit the proceeds against sale of SSC. Upon confirmation from SBP, following entry will be passed in the books of Main Branch: CCY GL CODE NARRATION DEBIT CREDIT PKR 1090801170 SSC SALE PAYABLE TO SBP XXXX PKR 1110101010 HEAD OFFICE ACCOUNT XXXX 8.6 ENCASHMENT OF SSC 8.6.1 Procedure for encashment of Special Saving Certificates (SSC) i. Customer comes to the government securities desk and fills out an encashment form. The customer can also present a detailed letter legibly stating his full name, certificate numbers, date of issue, certificates amount, signature of authorized person’s and indicating what is being encashed. ii. The government securities desk then checks the certificates, the customer’s signature is verified, and the identity of the customer is also verified by reviewing the issuing documents including the customer’s NIC photocopy filed by the Bank at the time of issuance. iii. The front of the certificates is stamped “PAID”. “PAID” stamp is always kept under dual control of BOM and officer in charge of the securities desk. iv. The government securities desk calculates the certificate amount. The amount of encashment can be given to the customer in cash or to be credited in customer’s account. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 336 v. At present, the profit earned is exempt from withholding tax, if the total investment in the scheme by the investor(s) does not exceed PKR 150,000/ -. However, withholding tax @ 10% is deductible at source on the profit(s) earned if the total investment exceeds PKR 150,000/ - by the investor(s). Zakat is collected at source as per rules. vi. If Zakat is applicable on customer, then amount of Zakat should be deducted before making encashment of SSC to customer and the liability should be recorded in proper Zakat Collection head in GL. vii. If the customer requires cash then a withdrawal slip is pre pared. The cash withdrawal slip is checked with the encashment form/certificates and authorized by the government securities unit head. viii. The customer presents the withdrawals slip to the cash teller for withdrawal of cash. ix. The encashed amount can also be credited into the customer’s account on the customer’s request. x. The government securities desk checks the date provided by the applicant and passes entry in the system. The particulars of SSC should be verified from “SSC Issuance Register” at the time of encashment. The register should be updated for all encashment in order to avoid duplicate payment. In case of SSC under lien, then the designated officer/ Incharge should verify that lien marking is properly discharged as per SOP. 8.6.2 Procedure for encashment of SSC in cross branch It is always prudent that the customer should take the certificates himself/herself to the main branch counter for encashment purpose. But if the customer has visited or requested for encashment of SSC from other MCB branc h in which he/she is maintaining his/her account, then the branch facing client will perform following tasks on the risk and responsibility of the customer: a) Receive application for encashment of SSC from customer and make sure that all required informati on and documents are enclosed herewith. b) Verify original book and serial number of the coupon(s). c) Customer’s application will be sent to Main Branch with a covering letter by branch mentioning details of customers. d) Main branch upon receiving of application from branch will complete all formalities as mentioned above. 8.6.3 Payment Options and transactions postings in SYMBOLS There are two payment options available for encashment of SSC: a) Via Cash b) Direct Credit to customer’s account (self or other branch customer) B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 337 a) Via Cash Where cash is being paid out, a withdrawal slip is handed -over to the customer who presents the slip to the cash counter where the teller should obtain a signature of the customer on the reverse and must also ensure that two signatures (i.e. the processor’s and processor and the officer) are there before passing the following entry in the system and giving cash to the customer Go to EOC>>General Ledger>>Transaction>>Batch Maintenance>>Batch Entry and pass following manual entry: CCY GL CODE NARRATION DEBIT CREDIT PKR 2090701030 SSC ENCASHMENT ACCOUNT XXXX PKR 2010101010 CASH IN VAULT XXXX b) Direct credit to customer’s account (self or cross branch) If the proceeds of encashment of SSC are being made directly to customers’ account (self or cross) then following option in SYMBOLS will be used for encashment of SSC:  Go to EOC>>Deposit>>Transaction>>Value Transaction>>Deposit.  Insert complete account number of beneficiary and press F8 to execute the query.  Credit customer’s account using transaction code SSCR by inserting encashment amount and date.  If the transaction is greater than user limit then system will ask for supervi sor’s override after which transaction will be completed successfully. Following auto accounting entries will be generated: For self branch customer CCY GL CODE NARRATION DEBIT CREDIT PKR 2090701030 SSC ENCASHMENT ACCOUNT XXXX PKR CUSTOMER’S ACCOUNT XXXX For cross branch customer CCY GL CODE NARRATION DEBIT CREDIT PKR 2090701030 SSC ENCASHMENT ACCOUNT XXXX PKR 1110101010 HEAD OFFICE ACCOUNT XXXX CCY GL CODE NARRATION DEBIT CREDIT PKR 1110101010 HEAD OFFICE ACCOUNT XXXX PKR CUSTOMER’S ACCOUNT XXXX B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 338 8.6.4 Deduction of withholding tax Normally the rate applicable is mentioned on the back of the securities and the amount payable is calculated. This rate is subject to change by State Bank without notice therefore it is prudent to keep an update rate list issued by SBP at all times for ready reference and the same should be referred at the time of encashment of certificates. At present, 10% withholding tax is applicable if the face value of SSC exceeds PKR 150,000/ - which will be recovered from customer at the time of encashment of SSC. If the encashment of SSC is made via cash then tax will be recovered manually from customer and proceeds will be recorded in the books of branch via manual GL batch. Incase if the encashment is done via direct credit to customer’s account then following steps will be followed:  Profit amount will be credited to customer’s account along with principal amount via transaction code SSCR which will directly hit SSC Encashment Account (2090701030) in GL.  10% withholding tax will be deducted from customer’s account using transaction code WHSC (Withholding Tax on Encashment of SSC). Following entry will be auto generated: CCY GL CODE NARRATION DEBIT CREDIT PKR CUSTOMER’S ACCOUNT XXXX PKR 1090601030 WITHHOLDING TAX ON SUPPLIES & SERVICES XXXX 8.6.5 Daily MIS preparation (Statement of SSC Encashment) Main branch is required to submit the statement of encashment of SSC to State Bank of Pakistan (SBP) only daily basis. The statement will be signed by preparing officer and counter signed by officer in charge. Statement of encashment of SSC will cover following information:  Register Number  Name of applicant  Certificate number  Denomination  Quantity  Date of issue  Date of payment  Total amount paid  Commission recovered  Zakat registration number B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 339 This statement is to be submitted to SBP for recovery of claim from SBP against encashment of SSC. Upon confirmation, branch will pass following entry in GL: CCY GL CODE NARRATION DEBIT CREDIT PKR 1110101010 HEAD OFFICE ACCOUNT XXXX PKR 2090701030 SSC ENCASHMENT ACCOUNT XXXX 8.6.6 Recording Commission on issuance and encashment of SSC Main branch recovers commission from SBP against sale and encashment of SSC. The commission is charged on following rates at every quarter end:  0.5% on issuance of SSC (on face value)  0.25% on encashment of SSC (on face value) Following entry is passed in the books of branch: CCY GL CODE NARRATION DEBIT CREDIT PKR 1110101010 HEAD OFFICE ACCOUNT XXXX PKR 3030401590 COMMISSION ON SSC/DSC XXXX 8.7 ENCASHMENT OF SSC CO UPONS Profit paid on coupons Profit on SSCs are payable every six months. After the completion of six months from the date of issuance the first coupon attached to the certificate is due for payment. E.g. if a customer plans to encash a certificate eight months after the date of issue, he can receive the profit for only six months and nothing for the next two months. Interest Rate Interest rates are subject to change by the State Bank of Pakistan. Normally the rate applicable is mentioned on the coupons and the amount payable is calculated. This rate is subject to change by State Bank without notice therefore it is prudent to keep an update rate list issued by SBP at all times for ready re ference and the same should be referred at the time of encashment of certificates. Add the clause of re -investment if encashment is not done. 8.7.1 Procedure for encashment of SSC coupon Encashment of SSC coupon involves following: B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 340 i. Customer comes to the gove rnment securities desk for profit coupons to be encashed. ii. The government securities desk has to verify that these SSCs were issued from the Bank. iii. The government securities desk hands over an encashment form to the customer. iv. The customer fills the form. v. Government securities desk checks the details provided by the customer and the profit coupons are verified from original application form, which was filled out by the customer at the time of issuance. The customer’s signatures are also verified from the same form. vi. Government securities desk then prepares a withdrawal slip in case the customer requires cash. In case the profit amount needs to be credited to the account then this is not required. vii. The withdrawal slip is to be signed jointly by two authorized offi cers in charge, after verifying all the necessary calculations. viii. The withdrawal slip is handed over to the cash counter and the teller passes the encashment entry in system. ix. The government securities desk credits the customer’s if the customer instructs to credit to his account against the profit coupons. x. The person who handles government securities desk, which is verified by an officer, prepares statements of encashment of profit coupons. xi. The profit coupons are pasted on butter paper and are marked “PAID” a long with the signature of an officer. 8.7.2 Procedure for encashment of SSC coupons in cross branch If the customer has visited or requested for encashment of SSC coupons from other MCB branch in which he/she is maintaining his/her account, then the branch facing client will only perform following tasks: i. Receive application for encashment of SSC from customer and make sure that all required information and documents are enclosed herewith. ii. Customer’s application will be sent to Main Branch with a covering le tter by branch mentioning details of customers via registered mail/currier service. iii. Incase documents are lost in transit then branch (sending documents) should inform Main branch immediately to mark instruments (SSC coupons) lost in their record (registers ) and inform the customer accordingly. iv. Main branch upon receiving of application from branch will complete all formalities as mentioned above. 8.7.3 SSC Coupon Payment Options and transactions postings in SYMBOLS There are two payment options available for encashment of SSC coupons: a) Via Cash b) Direct Credit to customer’s account (self or other branch customer) a) Via Cash B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 341 Where cash is being paid out, a withdrawal slip is handed -over to the customer who presents the slip to the cash counter where the teller should obtain a signature of the customer on the reverse and must also ensure that cash withdrawal slip is signed by two authorized officers before passing the following entry in the system and giving cash to the customer Go to EOC>>General Ledger> >Transaction>>Batch Maintenance>>Batch Entry and pass following manual entry: CCY GL CODE NARRATION DEBIT CREDIT PKR 2090701080 SSC COUPON ENCASHMENT A/C XXXX PKR 2010101010 CASH IN VAULT XXXX b) Direct credit to customer’s account (self or cross branch) If the proceeds of encashment of SSC coupon are being made directly to customers’ account (self or cross) then following option in SYMBOLS will be used for encashment of SSC coupon: i. Go to EOC>>Deposit>>Transaction>>Value Transaction>>Deposit. ii. Insert complete account number of beneficiary and press F8 to execute the query. iii. Credit customer’s account using transaction code SECR by inserting encashment amount and date. iv. If the transaction is greater than user limit then system will ask for supervisor’s override after which transaction will be completed successfully. Following auto accounting entries will be generated: For self branch customer CCY GL CODE NARRATION DEBI T CREDIT PKR 2090701080 SSC COUPON ENCASHMENT A/C XXXX PKR CUSTOMER’S ACCOUNT XXXX For cross branch customer CCY GL CODE NARRATION DEBIT CREDIT PKR 2090701080 SSC COUPON ENCASHMENT A/C XXXX PKR 1110101010 HEAD OFFICE ACCOUNT XXXX CCY GL CODE NARRATION DEBIT CREDIT PKR 1110101010 HEAD OFFICE ACCOUNT XXXX PKR CUSTOMER’S ACCOUNT XXXX 8.7.4 Deduction of withholding tax Normally the rate applicable is mentioned on the back of the securities and the amount payable is calculated. This rate is subject to change by State Bank without notice therefore it is prudent to keep an update rate list issued by SBP at all times for ready reference and the same should be referred at the time of encashment of certificates. At present, 10% withholding tax is applicable if t he face value of SSC exceeds PKR 150,000/ - which will be recovered from customer at the time of encashment of SSC coupon. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 342 If the encashment of SSC coupons is made via cash then tax will be recovered manually from customer and proceeds will be recorded in the books of branch via manual GL batch. Incase if the encashment is done via direct credit to customer’s account then following steps will be followed:  Profit amount will be credited to customer’s account along with principal amount v ia transaction code SSCR which will directly hit SSC Encashment Account (2090701030).  10% withholding tax will be deducted from customer’s account using transaction code WHSC (Withholding Tax on Encashment of SSC). Following auto entry will be generated: CCY GL CODE NARRATION DEBIT CREDIT PKR CUSTOMER’S ACCOUNT XXXX PKR 1090601030 WITHHOLDING TAX ON SUPPLIES & SERVICES XXXX 8.7.5 Daily MIS Preparation Main branch will prepare statement of encashment of SSC coupon which will be submitted to State Bank of Pakistan for claim against coupon encashment. This statement (MIS) will be jointly singed by preparing officer and officer in charge. The MIS will provide following information:  Name of applicant (certificate holder)  Cheque number  Serial Number of cer tificate  Denomination  Certificate number  Number of coupons  Total value of certificate  Date of issue  Date of encashment  Rate of interest  Profit amount  Total profit paid  Withholding tax deducted  Register number After the claim from SBP is reimbursed, following entry will be passed in the books of Main Branch: CCY GL CODE NARRATION DEBIT CREDIT PKR 1110101010 HEAD OFFICE ACCOUNT XXXX PKR 2090701080 SSC COUPON ENCASHMENT A/C XXXX B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 343 8.8 DSC & SSC STOCK RECEIVIN G PROCEDURE All stock will be ordered by authorized Main Branches only. They will follow up with SBP/NSC for issuance of stock and will remain record keeping related to stock under dual control. The following procedure is carried out by Main Branch: i. Letter has to be made, addressed to the Nati onal Saving Centre Islamabad, requesting them for a new stock with complete unused stock and sale statement for the last three months. ii. The National Saving Centre verifies the stock and the sale statement. iii. If the National Saving Centre verifies the stock & sale statement correct they write a letter to SBP as a confirmation and the authority to issue a new stock. iv. State bank of Pakistan then informs the ordering bank the date the Bank can obtain a fresh stock from the SBP. After clearance of stock letter the S BP then stamps on the letter with the approval of issuance of securities. v. The bank collects the securities from SBP and hands it over to bank’s approved security providing vendor. (The shipment from & to Phoenix remains the same.) vi. After stock has been rece ived from NSC by Main branch, the same will be placed in safe locker under custody of two authorized officers and entry of stock receiving will be made in SSC Stock Register. 8.9 PROCEDURE FOR RE-ISSUANCE OF LOST SEC URITIES If any certificate is misplaced b y the customers the general guidelines that the bank should follow are as follows: i. Customer must inform the issuing Bank about the missing securities. ii. Customer has to write a letter to the bank giving details of the type of security missing, the date of issuance, amount, value and the serial number. iii. The bank has to mark stop payment on the missing numbers and value of the certificate/coupons that was issued by the bank of the dealer. iv. The issuing bank or dealer has to immediately inform the State Bank of Pa kistan for stop payment on the missing securities with the customer letter. v. Customer has to give a written indemnity on a bond paper attested from the notary public officer. For the customer’s facility, the bank can fill out the same. vi. The customer gives th e indemnity bond paper to the issuing authority with the complete details along with his letter of stop payment. vii. The bank or dealer from which these securities were issued has to surrender the documents and the letter to the State Bank of Pakistan. viii. After submission of indemnity and letter of stop payment, State Bank of Pakistan then allows the bank to reissue the lost securities to the customer. ix. If the missing securities have been found by the customer after being issued new ones, the customer must inform the issuing authority (branch) immediately. Main branch will surrender the found securities to State Bank of Pakistan through a covering letter. x. State Bank of Pakistan then cancels the missing securities by marking them CANCELLED B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 344 8.10 PROCEDURE F OR MAIN BRAN CHES NOT DEALING IN HO A/C FOR DSC/SSC CLAIM SETTLEMENT There are some main branches of MCB who are not dealing in HO account for settlement of claims related to DSC/SSC. They are using following two GL heads in their books for the same: a) Current Account With SBP – LCY (2020101010) b) Current Account with NBP – LCY (2020101020) Current Account with NBP – LCY (2020101020) is used where no branch of SBP is available and NBP is functioning on behalf of SBP. Branches who are maintaining above mentioned GL heads in their books use State Bank Cheques for their transaction with SBP. This cheque book is issued by SBP for that particular Main Branch and is kept under dual control of Branch Operations Manager and an authorized officer who will be aut horized to sign these cheques. As far as transactions postings are concerned all entries related to sale and encashment of DSC/SSC will remain the same as mentioned above. However following accounting entries will be used submission of encashment claims a nd sale liability: Entries for transfer of DSC sale amount to SBP The concerned branch will issue SBP cheque and same will be submitted to SBP along with MIS of daily sale of DSC. This cheque will be signed by two authorized officers. Following entry will be passed in the books of branch: CCY GL CODE NARRATION DEBIT CREDIT PKR 1090801160 DSC SALE PAYABLE TO SBP XXXX PKR 2020101010 / 2020201010 CURRENT A/C WITH SBP - LCY / CURRENT ACCOUNT WITH NBP - LCY XXXX Entries for encashment claim of DSC from SBP CCY GL CODE NARRATION DEBIT CREDIT PKR 2020101010 / 2020201010 CURRENT A/C WITH SBP - LCY / CURRENT ACCOUNT WITH NBP - LCY XXXX PKR 2090701020 DSC ENCASHMENT ACCOUNT XXXX Entries for transfer of SSC sale amount to SBP The concerned branch will issue SBP cheque and the same will be submitted to SBP along with MIS of daily sale of SSC. This cheque will be signed by two authorized officers. Following entry will be passed in the books of branch: CCY GL CODE NARRATION DEBIT CREDIT PKR 1090801170 SSC SALE PAYABLE TO SBP XXXX PKR 2020101010 / 2020201010 CURRENT A/C WITH SBP - LCY / CURRENT ACCOUNT WITH NBP - LCY XXXX B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 345 Entries for encashment of SSC claim from SBP CCY GL CODE NARRATION DEBIT CREDIT PKR 2020101010 / 2020201010 CURRENT A/C WITH SBP - LCY / CURRENT ACCOUNT WITH NBP - LCY XXXX PKR 2090701030 SSC ENCASHMENT ACCOUNT XXXX Entries for encashment of SSC coupons claim from SBP CCY GL CODE NARRATION DEBIT CREDIT PKR 2020101010 / 2020201010 CURRENT A/C WITH SBP - LCY / CURRENT ACCOUNT WITH NBP - LCY XXXX PKR 2090701080 SSC COUPON ENCASHMENT ACCOUNT XXXX 8.11 GENERAL CONTROLS a) Stock of DSC/SSC should be under dual control at all times. Stock register for issuance /receipt should be maintained. Checking of physical stock should be done on monthly basis, in addition to this, ROM during his/her visit to branch should also check the stock physically and the comments for same should be mentioned in branch Visitor’s Book. b) A reconciliation statement of net balanc e receivable/payable to/from SBP as per bank and as per SBP should be prepared on monthly basis both for SSC and DSC separately. c) Claim received from SBP should be marked in DSC/SSC issuance register. d) Branches authorized for issuance of SSC/DSC should ref er SBP circular number F.E No. 20 dated 16.12.2002 for issuance of DSC/SSC against home remittance. 8.12 MIS P REPARATION AT BRANCH END Following statements shall be prepared by branch on daily basis for onward submission to SBP as well as for their record: a) Statement of Sale of Defence Saving Certificate –DSC b) Statement of Sale of Special Saving C ertificate – SSC c) Statement of Encashment of Defence Sa ving Certificate d) Statement of Encashment of Special Sav ing Certificate e) Statement of Encashment of Special Saving Certificate Coupons Following statements will only be prepared for branch internal use and not be submitted to SBP : a) Statement of DSC encashmen t claim from SBP b) Statement of SSC encashmen t claim from SBP B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 346 Chapter 9 OPERATIONAL RISK AND CONTROLS Sr. Activity Potential Risk Control 1. Cash Transfer from Cash House to Branch & Vice Versa  Transit Risk of Cash Vulnerability.  Misappropriation of Cash.  Cash counting errors.  Adequate transit coverage (Insurance) and strict monitoring of cash carrying limits.  Maintain Cash Book to record Physical Cash in Hand of the branch.  Daily Balancing of Cash in Hand with Cash in Vault (GL Head)  Verify IBS/AS number and Test on Credit/ Debit Advice.  Dual control on Cash Vault  Review Cash in Vault system generated report. 1a Cash Deposit  Incorrect transaction capture, execution and settlement.  Incorrect Credit in the customer’s account, Accounting and Taxation errors.  Inadequate record keeping & review of books.  Unavailability of Vault Keys.  Violation of Customer’s instructions.  Dual control on transaction execution process by defining users limits.  Restraint setup option available to mark customer’s instructions  Daily Balancing of Cash in Hand with Cash in Vault (GL Head)  Review daily syste m generated Transaction Alert, High Value Transactions and Over the Counter Cash Transaction Reports  Restricting incorrect use of options (LOV available).  Use of Standard Forms and applications  Review System generated Reports (RB11) with Source Documents.  Maintenance of Key Register  Sign-off the instruments as per the assigned limits. 1b Cash Withdrawal  Incorrect transaction capture, execution and settlement  Incorrect Debit in the customer’s account, Accounting and Taxation errors  Inadequate record keeping  Outstanding balances in Control Accounts  Unavailability of Vault Keys  Violation of Customer’s instructions  Dual control over limit assigned to teller by the system.  Restraint setup option available to mark customer’s instructions  Cheque inventory is monitored by the system restricting use of fake instruments.  Auto recovery of Tax Deduction on Cash Withdrawals above PKR 25000 .  Review System generated Reports (RB11) with Source Documents.  Review daily system generated Transaction Alert, High Value Tr ansactions and Over the Counter Cash Transaction Reports  Restricting incorrect use of options (LOV available).  Sign-off the paid instruments as per the assigned limits. 1c Clearing  Payment against unclear funds.  Payment of Fake cheque/ instrument  Inadequate record.  Outstanding balances in Clearing Control Account.  Float marking on unclear funds.  Cheque inventory is monitored by the system restricting use of fake instruments.  IBS/AS number on PO/DD  System generated PO/DD and control numbers.  Centralized processing of inward clearing providing segregation of processing.  Review system generated reports (RB11 & Clearing Control) with the source document. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 347 Sr. Activity Potential Risk Control 2. Funds Transfer  Unauthorized Transfer of Funds  Insufficient record keeping  Selection of incorrect transaction type  Lack of training/ information  Money Laundering  Unauthorized issuance of PO/DD  Misappropriation of funds by transfer.  Dual control on Test Key  Auto Commission and postal charges recovery  Customer Signature verification on Cheque /Application.  Sign-off applications as per assigned limits.  Review system generated EOD Reports with Source Documents.  Dual control on security stationery.  Daily Balancing and monitoring of Fund Transfer Control Account.  Review Cheque Deals Report (RB87)  Maintain proper record of the applications/vouchers.  List of Values available in system (with description) for correct selection of transaction type.  Inter Branch and Authorized Signatory numbers  Centralized issuance of PO/DD series.  KYC Implementation, obtain CNIC.  Customer’s acknowledgement . 3. Cheque books Maintenance  Misuse of Customer’s Cheque books  Unauthorized Withdrawal  Unused/Blank cheque books store in a secure/locked area under Dual Control  Review and discard six months old cheque books and maintain proper record of the same.  Signature Verification  Delivered Cheque book series are attached with the account.  Proper record should be maintained (Delivered and uncollected)  Auto recovery of cheque book issuance charges and Excise Duty (If any)  Customer/Authorized person’s acknowledgement 4. ATM Maintenance  Fraudulent transactions via ATM  Loss of Client assets  Delivery of MCB ATM/Smart Card to the unauthorized individual  Discard 03 months uncollected MCB ATM/Smart Cards and PIN Mailers  Two indep endent officers handle ATM and PIN mailers separately.  Proper record should be maintained (Delivered and uncollected)  Auto recovery of ATM issuance charges.  Signature verification  Captured Cards record keeping and delivery/dispatch to concerned branches/ banks.  Customer’s acknowledgement. 5. Issuance of Bank Statement  Unauthorized access to customer’s information  Verify signature on applications for duplicate account statement.  Hold mail facility available.  Mark restraint for undelivered statements or for holding mail. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 348 Sr. Activity Potential Risk Control  Attach correct Contact Type with multiple accounts  Use of pre -printed format with restricted access in the branch. 6. Issuance of RTCs and Prize Bonds  Misuse of the instruments  Dual Control on instruments  Physical balancing of instruments with the GL balance. 7. Term Deposit  Money Laundering and fictitious transactions  Incorrect booking with wrong tenor or rate.  KYC implementation/ TDR facility is only for the existing account holders.  System defined parameters restricting incorrect input.  Use of Standard Forms  Auto profit accruals & profit capitalization.  Signature verification 8. Account Maintenance  Money Laundering and fictitious transactions  Fictitious account opening  Inadequate information/documents  Lack of information  Incorrect data input  Centralized backend processing & monitoring of input by branch.  Implementation of KYC.  Obtain required documents.  Clear Operational Instructions on Specimen Signature Card.  Cross check applications with inserted information.  Maintain record of system generated account information.  Timely circulation of regulator’s instructions.  Review Account Open List (RBA 11, 12,)13 & 14)  Marking of service charges restraint.  Cross checkin g of system generated account opening details list with Account opening application. 9. Job Description and responsibilities  Inadequate segregation of Duties:  Job descriptions are clearly delineated and system access is provided to the users as per their JD’s and Responsibilities.  No single person initiate approve, record, reconcile balances, & review reports. 10. Maintenance of Collection Accounts  Fraud in Collection Accounts  Balance should be zero at each end of day.  Daily independent monitoring & revi ew. 11. Locker Maintenance  Unauthorized access to the lockers  Record keeping  Signature verification  Customer account relationship mandatory prior to lockers facility.  Recovery of Charges/Rent on due dates.  Binding of locker applications.  Keep SS Cards in an organized way with clear Operational instructions. 12. ATM Cash Verification and Balancing  Misuse of excess cash in ATM (Not dispensed to customer)  Preparation of ATM Fact on daily basis.  Verification of GLA 29 with ATM Scroll.  Verification of Physical Cash with ATM Cash Controller Report B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 349 Sr. Activity Potential Risk Control  Daily marking of Cash Position in Proactive Claim Settlement Module in order to settle suspect transactions. 13. Off line Transactions on BT  Incorrect transaction capture, execution and settlement.  Cash withdrawal restricted to a maximum of PKR 50,000 .  Pop-up message appear for restraint.  Review Offline cheque exception report. (RBA84) 14. Hardware and Software Maintenance  Power Failure  Communication failure  System Break down  Computer hacking or virus  Unavailability of data  Adequate supply of UPS  Back -up communication system  Stand -by generators  Disaster Recovery Plan Document. 15. Branch Contingency Arrangement  Continuity of Business Impairment.  Contact number of Emergency services  Evacuation plan  Branch Map  Review Daily Security Checklist  Review monthly “Fire Prevention Checklist”  C.C.T.V is installed in the branch & it is functional.  Keep Branch Call Tree 15. Offsite location & Back up  Inadequate Record Keeping  Keep all security stationery and safe custody items in fire proof cabinets under dual control  Proper binding of the vouchers.  Proper and update filing B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 350 Chapter 10 HIGH PRIORITY DOCUME NTS & RETENTION PERI OD Sr. Items Description Priority Risk Location/ Floor/ Room/ Cabinet Retention Period Coverage/ Backup ACCOUNT OPENING 1 Account Opening Forms High Loss of Customer's information - Contact details Strong Room/ Fire Proof Cabinets Permanent Archiving/ Scanning of Forms 2 Client Profile form (KYC) High SBP Penalties/ Fines/ Compliance failure Strong Room/ Fire Proof Cabinets Permanent Archiving/ Scanning of Forms 3 Customer Specimen Signature Cards High Loss of Customer's signature Strong Room/ Fire Proof Cabinets Permanent System (BT & EOC) 4 Scanned Signature Backup High Loss of Customer's signature Hardware/ Software failure Fire Proof Cabinets Permanent Customer Signature Specimen Cards 5 Standing Instructions High  Incorrect/ Untimely execution of standing instructions of the customer  Non execution of instructions  Breach of mandate Fire Proof Cabinets Permanent System (BT & EOC) 6 Account Closed File Medium Fire Proof Cabinets 5 years after Closure System Report available on EOC for Closed Accounts 7 Term Deposit Application Medium Inadequate record maintenance Fire Proof Cabinets 2 Years after maturity / Premature encashment Archiving/ Scanning of Forms 8 Term Deposit Receipt Medium Encashment of deposit to unauthorized person. Attempt of fraudulent transaction Fire Proof Cabinets 15 Years System (BT/EOC) Sr. Items Description Priority Risk Location/ Floor/ Room/ Cabinet Retention Period Coverage/ Backup CHEQUE BOOK MAINTENANCE 1 Checkbooks High Initiation of Fraudulent Transaction Unauthorized Withdrawal Vault/ Fire Proof Cabinets in Strong Room 06 months 1.MICR encoding 2.Cheque series is inserted in system 3.Discard undelivered cheque books over 06 months 2 Cheque book Requisition Slip Medium  Misuse of undelivered Cheque -books  Issuance to unauthorized person Bind with Daily Voucher & keep them in Fire Proof Cabinets 10 Years 3 Cheque book Issuance Medium To loss the record of Customer's Fire Proof Cabinets 03 Years Cheque book Registration B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 351 Reports (Retrieve from CBR System) Acknowledgment System Sr. Items Description Priority Risk Location/ Floor/ Room/ Cabinet Retention Period Coverage/ Backup ATM MAINTENANCE 1 SMART CARD S High  Fraudulent transactions via ATM  Issuance to unauthorized person Vault (In Dual Control) 3 months Card and PIN Mailers should be equal in number and must be in dual control 2 ATM PIN MAILERS High  Initiation of Fraudulent Transaction  Unauthorized Withdrawal Vault (In Dual Control) 3 months Card Activation is mandatory requirement 3 ATM Issuance Report (Retrieve from ATM System) Medium To lose the record of Customer's Acknowledgment Fire Proof Cabinets 1 Year ATM Registration System & Centralized Card Production Unit 4 ATM Issuance Form High Loss of Customer's request for ATM / Debit Card Fire Proof Cabinets 8 Years ATM Registration System & Centralized Card Production Unit 5 ATM Scroll Registers High  Hindrance in settlement of ATM Claims & Cash balancing process  Loss of customer transaction details Fire Proof Cabinets 10 Years ITD- ATM Department 6 ATM Claim Forms High Delay in settlement of ATM Claims Fire Proof Cabinets 5 Years N/A 7 ATM Fact Sheet High unbalancing of Cash in Vault & ATM 10 Years N/A 8 ATM Capture Cards Register Medium Insufficient record of Captured Cards received and delivered/dispatched to customers &/or concerned Banks/ branches Fire Proof Cabinets 3 years N/A Sr. Items Description Priority Risk Location/ Floor/ Room/ Cabinet Retention Period Coverage/ Backup CASH MANAGEMENT 1 Cash, Foreign Currency, Prize Bonds High  Transit Risk of Cash Vulnerability  Misappropriation of Cash VAULT -  Insurance coverage available  Transfer excess cash to Cash House 2 Prize Bonds Register High  Inadequate record keeping Vault / Fire Proof Cabinets in Strong Room 10 Years N/A B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 352 3 Prize Bonds Shut Period Register High Inadequate record keeping & Execution of transactions during Shut Period Vault / Fire Proof Cabinets in Strong Room 08 Years N/A 4 Daily Cash Book High  Misappropriation of Cash  Inappropriate recording of Cash in the bank books Vault / Fire Proof Cabinets in Strong Room 05 Years System/ Relevant Credit Advices/ Deposit slips Sr. Items Description Priority Risk Location/ Floor/ Room/ Cabinet Retention Period Coverage/ Backup FUNDS TRANSFER 1 Funds Transfer Application High  Insufficient record of financial transactions  Misappropriation of funds by transfer. Fire Proof Cabinets 10 Years System has all the record of the transactions 2 Uncollected PO/DD from Branch by the customers High Initiation of fraudulent transaction Vault 10 years Funds Transfer Application 3 Blank Stationery of Pay Orders & Demand Drafts High Initiation of Fraudulent Transaction Vault/ Fire Proof Cabinets in Strong Room -  Pre printed Stationery Control number  Cheque inventory is monitored by the system restricting use of fake instruments 4 Inter Branch Test Key High Unauthorized execution of transactions Vault/ Fire Proof Cabinets in Strong Room Permanent Dual control on Test Key 5 Telegraphic Transfer Advices/Stationery High Misuse of Blank Stationery Fire Proof Cabinets N/A 6 Telegraphic Issuance Register (Outward TT Register) Medium  Insufficient record of financial transactions  Misappropriation of funds Fire Proof Cabinets 10 Years 7 TT Payable Register (Inward TT Register) Medium Insufficient record of financial transactions Fire Proof Cabinets 10 Years 8 Collection Register (Inward & Outward) Medium  Incorrect/insufficient record  Delay in transfer of Funds to customer's account Fire Proof Cabinets 10 Years B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 353 Sr. Items Description Priority Risk Location/ Floor/ Room/ Cabinet Retention Period Coverage/ Backup LOCKER MAINTENANCE 1 Locker Application High Loss of customer's information/ contact details Fire Proof Cabinets Permanent 2 Signature Specimen Cards of customers High Loss of customer's signature Vault/ Fire Proof Cabinets in Strong Room Permanent 3 Locker Issuance Register High Customer Data Loss Fire Proof Cabinets Permanent 4 Safe Deposits Lockers - Customer Visit Register High Unauthorized usage/ access to lockers Fire Proof Cabinets Permanent Sr. Items Description Priority Risk Location/ Floor/ Room/ Cabinet Retention Period Coverage/ Backup MISCELLANEOUS DOCUMENTS 1 Stop Payment File Medium 05 Years 2 Key Register Medium Non -identification of Responsibility Permanent 3 Video Cassettes Medium  Loss of data (Counter Activities)  Failure to cope up with emergency situations Vault 30 Days Centralized Location 4 SBP Circulars File Low Loss of procedural Instructions Cabinets Permanent SBP Website or Centralized Location 5 POK Circulars File Low Insufficient/ Incomplete procedural instructions Cabinets Permanent Intranet/ Centralized Location 6 Procedural Manuals Low Cabinets Permanent 7 Power of Attorney Low Misuse of powers Fire Proof Cabinets Permanent 8 Security Documents, Collaterals, Charge forms, Client's Credit Limit file High  Loss of Client's Assets documents  Loss legal rights Vault/ Fire Proof Cabinets in Strong Room Permanent 9 Unused Standard/ Miscellaneous Forms/ Standard Books Low Misuse of Blank forms/ stationery Fire Proof Cabinets B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 354 Chapter 11 BRANCH MANDATORY NOT ICES/ WALLBOARDS/ MA TERIAL S. No Category Item 1 License Branch License/ Temporary Permission 2 License Forex license [AD Letter]. (if applicable) 3 Notice Details of unclaimed deposits of PKR 5000 /- and above on notice board for the year. Along with instructions "complete list of unclaimed deposit available with the officer of the branch" 4 Notice Latest list of Prize Bonds Draw 5 Notice Daily FCY rate sheet (if applicable) 6 Notice Lending/ Deposit rates 7 Notice The list of accounts closed on the basis of Zero Balance 8 Notice List of Gazetted Holiday 9 Notice Information regarding lodgment of Complaints directly to State Bank concerning payment of utility bills at branch 10 Notice Schedule of Charges 11 Notice/ Wall Board "All currency notes are acceptable" 12 Notice/ Wall Board "Electric, Gas & Telephone Bills are accepted here" 13 Notice/ Wall Board Timing of Collection of Utility Bills (Urdu & English)to be displayed outside the branch premises 14 Notice/ Wall Board Emergency contact numbers 15 Notice/ Wall Board "Sale/Purchase of Prize Bonds is done here" 16 Notice/ Wall Board "Lockers are available here". Also mention Insurance Limits of different locker sizes. (if applicable) 17 Notice/ Wall Board "BBA accounts are opened here" 18 Notice/ Wall Board "Foreign currency accounts are opened here" (if applicable) 19 Notice/ Wall Board "Soiled & Defective notes are acceptable here". Also disclose contact number of CM SBP BSC 20 Notice/ Wall Board "Use of Mobile phones and Arms are prohibited" 21 Notice/ Wall Board "Agriculture Loans are available here" to be written in respective area local language (where applicable) 22 Wall Board Bank timings outside the branch premises 23 Wallboard New Currency Notes Features board 24 Material Complaint Box at a prominent location 25 Material Utility Bills Drop Box at a prominent location 26 Material Smoke detectors (activated) in the Branch/ ATM kiosk 27 Material Fire Extinguisher along with expiry date 28 Material Leaflet (both in English and Urdu) indicating the procedure for the lodgment/resolution of complaints 29 Material Complaint Forms 30 Material Whistle -blower/enforcement wing Form 31 Material Banking Mohtasib complaint lodgment procedure board 32 Material Availability of Drinking Water B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 355 Chapter 12 SBP GUIDELINES FOR S UB-BRANCHES Following is an extract of SBP circular # 15 of 2007 on Branch Lic ensing Policy dated 12 -Oct-2007 spelling out guidelines for Sub -Branches: Banks can open sub -branches, which will allow them another option for enhancing their outreach to underserved areas and population. The sub -branches will be a conduit of a branch to which it is affiliated. Banks will be required to apply to SBP for opening of sub -branches approved under ABEP on the prescribed format (Annexure - II & II - A). Banks will not be allowed to convert any of their existing branches into sub branches. However, they can convert a booth into a sub -branch & a sub -branch into a full -fledged branch only after approval under their ABEP and in terms of BLP. Banks will be allowed to open sub -branches subject to criteria mentioned at section -2.2 above, centralization of processing of all the transactions at sub -branches to a base branch, existence of a ppropriate systems & controls and adequate security arrangements. Further, all relevant record shall be maintained by the controlling branch. It would be preferable if banks resort to technology based solutions in sub -branches including on -line/real time links, kiosks, ATMs, Point of Sales etc as also use drop box facilities. The bank will ensure compliance with all the laws, rules regulations and SBP instructions issued from time to time, which may affect the existence/ operations of the sub -branch. The s ub branches can perform one or both of the following functions: - Limited general banking functions viz cash receipt and payment, issuance and encashment of DD, TT, MT, pay order, traveler cheques etc. However, account opening & issuance of account number and other formalities including Know Your Customer (KYC) and Customer Due Diligence (CDD) shall be performed by the controlling branch (not by sub -branch). The general banking functions may also include the functions performed a t permanent booths as stated in section ‘2.6.1’ . Disbursement & recovery of agri/rural financing, group based lending, lodgment & settlement of insurance claims of agri/rural loans and to create awareness amongst the rural consumer about agri/rural financ e products & services. A signboard stating the name of the bank at sub -branch should also state under the bank’s name in clear bold words that “This is a sub -branch/limited function branch of……..Bank” in English as well as in Urdu. Section ‘2.6.1’ (i) Receiv ing utility bills, Government dues/revenue/cash, collection of fees/dues of educational institutions, collection and disbursements of loans to farmers, receiving cash from patients of hospitals, visa application/visa fee or other related cash receipt funct ions on the recommendations of the concerned Government Departments, other institutions and for providing limited banking facilities (i.e. cash payment and receipt of cash and cheques/demand draft/pay order only) in the premises of Embassies, Consulates, F oreign Missions and International Financial Institutions in Pakistan, on their specific request. (ii) For exchange of foreign currency subject to normal exchange control regulations at the port of entry in Pakistan. (iii) National Bank of Pakistan will be allowed to open booths for receiving railway cash and other Government dues on the recommendations of the Department concerned. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 356 Chapter 13 BRANCH TRANSACTIONAL A UTHORITIES & THRESHOLD L IMIT S OVERVIEW : The Branch Transactional Authorities and Threshold Limits are devised after detailed analysis of branch transactional needs/ threshold limits that complement our guiding principles which are to promote prudent control environment/ minimize operational risk and enhance customer service. All Branches are required to follow the same without Fail . Deviation to the same will be considered as serious violation and can result into Audit Issues. DEVIATION : In some branches, according to the business/ operations ne eds, deviations to the pre -established Branch Transactional Authorities and Threshold Limits can be given. Concerned ROM will prepare a proposal clearly mentioning valid reason(s) for Change and Proposed Limits for the specific Branch(s) and forward to the Area Head Operations and Head of Operations for their Recommendations and Sign -off. Once signed by both, Head of Operations will furnish the same for final Approval from Group Head Operations. Sr. # Transactions/ Activities Teller Services Officer Teller Services Supervisor General Banking Officer Branch Operations Manager Branch Manager Personal Banking Advisor Customer Service Officer Credit Manager Credit Officer 1 Cash Withdrawals - Contractual Teller Upto PKR 25K Upto PKR 200K Not applicable Upto PKR 1M (applicable for authorization above PKR 1M in absence of BM). Regularization must be done by BM Unlimited for Authorization Not applicable Not applicable Not applicable Not applicable 2 Cash Withdrawals - Permanent Teller Upto PKR 25K (equivalent FCY) Upto PKR 200K (equivalent FCY) Not Applicable Upto PKR 1M (applicable for Authorization above PKR 1M in absence of BM). Regularization must be done by BM Unlimited for Authorization Not Applicable Not Applicable Not Applicable Not Applicable B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 357 Sr. # Transactions/ Activities Teller Services Officer Teller Services Supervisor General Banking Officer Branch Operations Manager Branch Manager Personal Banking Advisor Customer Service Officer Credit Manager Credit Officer 3 Cash Deposits - Contractual Teller Upto PKR 50K Upto PKR 500K Not Applicable Upto PKR 1M (applicable for Authorization above PKR 1M in absence of BM). Regularization must be done by BM Unlimited for Authorization Not Applicable Not Applicable Not Applicab le Not Applicable 4 Cash Deposits - Permanent Teller Upto PKR 100K (equivalent FCY) Upto PKR 500K (equivalent FCY) Not Applicable Upto PKR 1M (applicable for Authorization above PKR 1M in absence of BM). Regularization must be done by BM Unlimited for Authorization Not Applicable Not Applicable Not Applicable Not Applicable 5 Utility Bills Receipts Upto PKR 5K Upto PKR 50K Not Applicable Upto PKR 1M (applicable for Authorization above PKR 1M in absence of BM). Regularization must be done by BM Unlimited for Authorization Not Applicable Not Applicable Not Applicable Not Applicable 6 Outward Clearing Applicable (for accepting instrument over the counter) Upto PKR 250K Upto PKR 50K Upto PKR 1M (applicable for Authorization above PKR 1M in absence of BM). Regularization must be done by BM Unlimited for Authorization Not Applicable Not Applicable Not Applicable Not Applicable 7 Outward Collection (LCY) Applicable (for accepting instrument over the counter) Upto PKR 250K Upto PKR 50K Upto PKR 1M (applicable for Authorization above PKR 1M in absence of BM). Regularization must be done by BM Unlimited for Authorization Not Applicable Not Applicable Not Applicable Not Applicable B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 358 Sr. # Transactions/ Activities Teller Services Officer Teller Services Supervisor General Banking Officer Branch Operations Manager Branch Manager Personal Banking Advisor Customer Service Officer Credit Manager Credit Officer 8 Outward Collection (FCY) Applicable (for accepting instrument over the counter) Upto PKR 250K (equivalent FCY) Upto PKR 50K (equivalent FCY) Upto PKR 1M (applicable for Authorization above PKR 1M in absence of BM). Regularization must be done by BM Unlimited for Authorization Not Applicable Not Applicable Not Applicable Not Applicable 9 Pay Order Issuance Upto PKR 25K Upto PKR 250K Upto PKR 50K Upto PKR 1M (applicable for Authorization above PKR 1M in absence of BM). Regularization must be done by BM Unlimited for Authorization Not Applicable Not Applicable Not Applicable Not Applicable 10 Demand Draft Issuance (LCY) Upto PKR 25K Upto PKR 250K Upto PKR 50K Upto PKR 1M (applicable for Authorization above PKR 1M in absence of BM). Regularization must be done by BM Unlimited for Authorization Not Applicable Not Applicable Not Applicable Not Applicable 11 Demand Draft Issuance (FCY) Not Applicable Upto PKR 250K (equivalent FCY) Upto PKR 50K (equivalent FCY) Upto PKR 1M (applicable for Authorization above PKR 1M in absence of BM). Regularization must be done by BM Unlimited for Authorization Not Applicable Not Applicable Not Applicable Not Applicable 12 Rupee Travelers Cheques Issuance Not Applicable Upto PKR 250K Upto PKR 50K Upto PKR 1M (applicable for Authorization above PKR 1M in absence of BM). Regularization must be done by BM Unlimited for Authorization Not Applicable Not Applicable Not Applicable Not Applicable B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 359 Sr. # Transactions/ Activities Teller Services Officer Teller Services Supervisor General Banking Officer Branch Operations Manager Branch Manager Personal Banking Advisor Customer Service Officer Credit Manager Credit Officer 13 Rupee Travelers Cheques Encashment Not Applicable Upto PKR 250K Upto PKR 50K Upto PKR 1M (applicable for Authorization above PKR 1M in absence of BM). Regularization must be done by BM Unlimited for Authorization Not Applicable Not Applicable Not Applicable Not Applicable 14 FCY Travelers Cheques Deposit Not Applicable Not Applicable Applicable (for accepting Travelers Cheques in collection only ) Applicable Upto PKR 1M (Equivalent FCY) for checking and signing off on TCs Collection form and authorization upon realization of funds Applicable above PKR 1M (Equivalent FCY) for checking and signing off on TCs Collection form and authorization upon realization of funds Not Applicable Not Applicable Not Applicable Not Applicable 15 Online Funds Transfer / Internal Transfers Upto PKR 50K Upto PKR 250K Upto PKR 50K Upto PKR 1M (applicable for Authorization above PKR 1M in absence of BM). Regularization must be done by BM Unlimited for Authorization Not Applicable Not Applicable Not Applicable Not Applicable 16 FCY/ LCY Cheque Purchase / Payment against un-cleared effects No Authority No Authority No Authority No Authority No Authority No Authority No Authority No Authority No Authority B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 360 Sr. # Transactions/ Activities Teller Services Officer Teller Services Supervisor General Banking Officer Branch Operations Manager Branch Manager Personal Banking Advisor Customer Service Officer Credit Manager Credit Officer 17 Debit to Expense Account Not Applicable Not Applicable Applicable (for input only and as per the approved schedule of Revenue & Expenditure from CAD) Applicable for approval (as per the approved schedule of Revenue & Expenditure from CAD) Applicable (as per the approved schedule of Revenue & Expenditure from CAD) Not Applicab le Not Applicable Not Applicable Not Applicable 18 Debit to GL/ Suspense Account on EOC Applicable with Batch Acceptance from BOM or BM Applicable with Batch Acceptance from BOM or BM Applicable with Batch Acceptance from BOM or BM Applicable for Batch Acceptance except deletion of EOD batches Applicable for Batch Acceptance including deletion of EOD Batches Not Applicable Not Applicable Not Applicable Not Applicable 19 Bulk Salary Postings (Non -Centralized) Upto PKR 50K Upto PKR 100K Upto PKR 50K Upto PKR 1M (applicable for Authorization above PKR 1M in absence of BM). Regularization must be done by BM Unlimited for Authorization Not Applicable Not Applicable Not Applicable Not Applicable 20 Issuance of CDRs Not Applicable Upto PKR 250K Upto PKR 50K Upto PKR 1M (applicable for Authorization above PKR 1M in absence of BM). Regularization must be done by BM Unlimited for Authorization Not Applicable Not Applicable Not Applicable Not Applicable 21 Funds disbursal on deceased accounts Not Applicable Not Applicable Not Applicable Applicable (only after receipt of Approval from GM) Applicable (only after receipt of Approval from GM) Not Applicable Not Applicable Not Applicable Not Applicable B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 361 Sr. # Transactions/ Activities Teller Services Officer Teller Services Supervisor General Banking Officer Branch Operations Manager Branch Manager Personal Banking Advisor Customer Service Officer Credit Manager Credit Officer 22 ‘Cash Requisition ’ to Cash Feeding Branch/ Cash House Not Applicable Not Applicable Not Applicable Upto PKR 5M with joint approval of BM (Above PKR 5M will require approval from ROM/RH) Upto PKR 5M with joint approval of BOM (Above PKR 5M will require approval from ROM / R H) Not Applicable Not Applicable Not Applicable Not Applicable 23 Transfer of ‘Excess Cash’ to Cash Feeding Branch/ Cash House Not Applicable Not Applicable Not Applicable Upto PKR 10M with joint approval of BM (Above PKR 10M will require approval from ROM/RH) Upto PKR 10M with joint approval of BOM (Above PKR 10M will require approval from ROM / RH) Not Applicable Not Applicable Not Applicable Not Applicable 24 Credit Card Payments in Cash Upto PKR 50K Upto PKR 500K Not Applicable Upto PKR 1M (applicable for Authorization above PKR 1M in absence of BM). Regularization must be done by BM Unlimited for Authorization Not Applicable Not Applicable Not Applicable Not Applicable 25 Cash Advance through POS Upto PKR 25K Upto PKR 200K Not Applicable Upto PKR 1M (applicable for Authorization above PKR 1M in absence of BM). Regularization must be done by BM Unlimited for Authorization Not Applicable Not Applicable Not Applicable Not Applicable 26 Cheque Withdrawal Reversals Not Applicable Applicable Not Applicable Applicable Applicable Not Applicable Not Applicable Not Applicable Not Applicable 27 Inward Clearing - Cheque Debit Reversals Not Applicable Applicable Not Applicable Applicable Applicable Not Applicable Not Applicable Not Applicable Not Applicable B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 362 Sr. # Transactions/ Activities Teller Services Officer Teller Services Supervisor General Banking Officer Branch Operations Manager Branch Manager Personal Banking Advisor Customer Service Officer Credit Manager Credit Officer 28 Internal Fund Transfer - Reversals Not Applicable Applicable Not Applicable Applicable Applicable Not Applicable Not Applicable Not Applicable Not Applicable 29 Prize bond Sale (Cash/Account) Upto PKR 50K Upto PKR 500K Not Applicable Upto PKR 1M (applicable for Authorization above PKR 1M in absence of BM. Regularization must be done by BM Unlimited for Authorization Not Applicable Not Applicable Not Applicable Not Applicable 30 Prize bond Encashment (Cash/Account) Upto PKR 50K Upto PKR 500K Not Applicable Upto PKR 1M (applicable for Authorization above PKR 1M in absence of BM. Regularization must be done by BM Unlimited for Authorization Not Applicable Not Applicable Not Applicable Not Applicable 31 Outward Wire Transfer (FCY) Not Applicable Applicable (signature verifications) Applicable (scrutiny & recovery of handling charges) Applicable (signature verification & checking of KYC / Turn over info) Applicable (signature verification above USD 10K & checking of KYC / Turn over info) Not Applicable Not Applicable Not Applicable Not Applicable 32 Off-line Financial Transactions Not Applicable Not Applicable Not Applicable Applicable Applicable Not Applicable Not Applicable Not Applicable Not Applicable 33 ATM Cash Replenishment Applicable jointly with TSS / BOM Applicable jointly with TSO Not Applicable Applicable jointly with TSO Applicable jointly with TSO Not Applicable Not Applicable Not Applicable Not Applicable 34 Pre-paid Visa Cash load/ re -load Less than PKR 10k PKR 10k and above Not Applicable PKR 10k and above 10k and above Not Applicable Not Applicable Not Applicable Not Applicable B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 363 ANNEXURE ANNEXURES Annexure B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 364 ANNEXURE I FORM A -7 FOREIGN EXCHANGE REGULATION ACT, 1947 Application to Transfer Pakistan Rupees From/To a Private Non -Resident Account held in Pakistan. N.B. (1) This form should be used only when payment is made in Pakistan Rupees to or from an account in the name of a person or firm other than a bank resident outside Pakistan. (2) This form should be completed in duplicate when the transfer is from one non -resident account to another. I/We the undersigned apply for permission to transfer/pay Rs. __________ say _____________ _________ _____ (In figures) (In words) From / to the account of _______________________________________________________________________ ___________________________________________________________________________________ ________ (Name and address of transferor/transferee or full title of account debited / credited stating the country of residence and name of bank with whom account is kept.) To/from ___________________________________________________________________________________ ___________________________________________________________________________________________ (Name and address of transferee/transferor or full title of account credited / debited stating the country of residence and name of bank with whom account is kept.) For the purpose stated below : - ___________________________________________________________________________________________ ________________________________________________ __________________________________________ I/We declare that the statements on this form are true, that the transfer is solely for the pur pose specified above and that this purpose in no way contravenes the provisions of the Foreign Exchange Regulation Ac t, 1947. Name of Applicant ____________________________ ______________________________ Nationality ___________________________ Stamp & signature(s) of Applicant Address _______________________________________________ Date _______________________ We he reby certify that the statements overleaf are to the best of our knowledge correct and that we have seen documentary evidence in support thereof and allowed transfer in terms of Chapter VIII of the Foreign Exchange Manual/apply for permission of the State Bank to affect the transfer. Date ________________________________ Authorized Dealer ___________________________________________________________________________________________ Space for use by the State Bank of Pakistan State Bank of Pakistan, Exchange Policy Department, Date ______________________ Jr. Joint Director/Assistant Director B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 365 ANNEXUR E II FORM Q .A. 22 Form of undertaking to be furnished by foreign nationals resident in Pakistan and companies and firms whose head offices are outside Pakistan for maintaining Bank account To The Manager/Agent, MCB Bank Ltd Dear Sir, I/We hereby certify that the credits paid into my/our account with your bank relate normally to my/our trading business in Pakistan only and consist of the followi ng: - (Here state the principle sources from which rupee payments into the account are derived, e.g., payments received for goods sold, stating general nature of goods). In consideration of the State Bank of Pakistan agreeing to dispense with my/our completing Form A -7 in respect of every credit to my/our account, other than from non -resident account, I/We undertake that I/We will not make available to any persons or firms in Pakistan any foreign cur rency which may be at my/our disposal, against reimbursement in rupees, without first having obtained the permission of the State Bank of Pakistan, (through an Authorized Dealer) by com pleting Form A -7 in respect of the rupee payment to my/our account. I/We further agree to com plete Form A -7 in respect of any payments into the account which may not be directly connected with my/our trading activities in Pakistan, or which represent remittances received from overseas. Yours fa ithfully, (Signature of applicant) Date ____________ Full Name of applicant __________________________________________________________________ Nationality ______________ Passport No ______________ dated __________ issued by _______________ Occupation __________________________________________________________________________ Address _____________________________________________________________________________ Date of arrival in Pakistan ________________________________________________________________ We ce rtify that to the best of our knowledge and belief the information given above is correct. Date: ______________ Stamp and Signature of Authorized Dealer Date Note: -"This form should he completed in duplicate and submitted to the A.D. with whom th e account is desired to he opened. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 366 ANNEXURE III Revised Annexure “C” CERTIFICATE FOR REFUND OF UNCLAIMED ACCOUNT IN RESPECT OF____________________________ (Name of Customer / Claimant) This is to certify that we have received request from the above named customer / client, for refund of unclaimed account, which was reported in Form -XI for the year ended________________ as prescribed under Rule 17 of Banking Companies Rules, 1963 and sinc e transferred to the State Bank of Pakistan in terms of provision contained in Section 31 of Banking Companies Ordinance, 1962. It is further certified and confirmed that signatures of the customer/client have been verified and all the necessary documents have alto been obtained and verified from our record. Further, we fully understand that the proper identification of the claimant is sole responsibility of MCB Bank Ltd . 1. Name of the Customer__________________________________________________________ 2. Name of the Claimant__________________________________________________________ 3. CNIC Number__________________________________________________________________ 4. Residential Address, Telephone/ Mobile No, e -mail, (if any) of the Customer/ Claimant _______ ____________________________________________________________________________ ___________________________________________________________________________________ 5. Account Number__________________________________________________________________ 6. Amount C laimed________________________________________________________________ Signature of the Branch Manager_________________________________________ (Stamp with Name & Designation) Signature of Head of Internal Control (Audit) ______________________________ (Stamp with Name & Designation) B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 367 ANNEXURE I V MCB BANK LTD. DAILY CASH POSITION AS ON ______________ BRANCH CODE: ______________ Denomination Re-Issuable Soiled Defective Unsorted Net Position No. (Pieces) Amount No. (Pieces) Amount No. (Pieces) Amount No. (Pieces) Amount No. (Pieces) Amount PKR 5000 Notes PKR 1000 Notes PKR 500 Notes PKR 100 Notes PKR 50 Notes PKR 20 Notes PKR 10 Notes PKR 5 Notes PKR 5 Coins PKR 2 Coins PKR 1 Coins TOTAL Prepared BY Checked By B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 368 ANNEXURE V The Chief Manager State Bank of Pakistan ___________________ Dear Sir, We forward herewith the under noted prize bonds which have qualified for prize money in the Draw No. ________________ held on ________________ for the amount mentioned against each: Denomination Of Bond Series & No of Bond Date of Issue Place of Issue We shall be glad if you please credit the amount of prize money payable on the above bond/s into Government Account and its/their face value amounting to Rs. ______________ to our Account maintained by us with you. Please acknowledge receipt. Yours faithfully, B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 369 ANNEXURE VI Mr./Mrs./Miss . Registered A/D Dear Sir / Madam, LOCKER No: You are our Licensee in respect of the above Locker on the terms and conditions duly accepted by you. You have failed/neglected to pay the License Fee for the use of the above said Locker since ___ . Consequently an amount o f Rs ___ _ (Rupees ) is outstanding against you on account of License Fee for the period ending on . Under the terms and conditions governing the said Locker and even otherwise, we are entitled to revoke the License and break -open the said Loc ker. We have, therefore, decided to revoke and do hereby revoke the said License and call upon you to remove your articles, if any, deposited / kept in the said Locker within Seven Days from the receipt hereof, of course, against payment of the amount sho wn hereinabove and handover possession of the Locker along with the Key, to us. Please note that in the event of your failure to pay the aforesaid outstanding amount and to surrender the said Locker with its Key to us, within Seven Days from the date hereof, otherwise with the permission of the Court, we shall break -open the said Lock er and retain possession of the contents / articles if any found, at your risk as to costs and consequences. Further note that the Bank is entitled to dispose -off the said articles / contents or part thereof also with the permission of the Court to recover the outstanding amount against above said locker, which shall include but not limited to cost of breaking -open the said locker, cost of legal / court expenses and repairing cost of the said locker from the net sale proceeds, without being bound to give yo u any further notice or information. Yours faithfully, B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 370 ANNEXURE VII Mr./Mrs./Miss “FINAL NOTICE” ________________ Registered A/D Dear Sir / Madam, LOCKER No._________________ DEMAND NOTICE FOR RECOVERY OF RS. / NOTICE FOR FILING OF SUIT: Reference may please be made to our earlier Notice (No. _____________) Dated _______________ sent to you through courier / registered A/D at your address on our record, whereby you were requested to pay us an amount of Rs .______________ outstanding against your above said locker as License fee etc. for the period___________ to __________ and surrender the said locker with key to which you have failed to do so till date. You are therefo re, hereby called upon to pay the aforesaid amount immediately but not later than seven days from the date of this notice, failing which we shall file a declaratory suit for breaking open the said locker / Suit for recovery of our dues against you in the C ourt of Competent jurisdiction at your sole risk as to costs & consequences which may please be noted. Regards, Yours truly, B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 371 ANNEXURE VIII Mr./Mrs./Miss _______________________________ Registered A/D Dear Sir / Madam, LOCKER No: In spite of the Notice dated sent to you by Registered A/D Post at your address on our record / published in Daily “ ______ “ dated ______ , you failed/neglected to pay us the outstanding amount of License Fee and surrender the said Locker with Key to us. Consequently, with the permission of the Court, we had broken -open the said locker and found the following articles which have been kept in our custody also with the permission of the Court. An amount of Rs : (Rupee s _____________) is due to us by you as follows: 1) License Fee for the period from _______ to__ ____ Rs. 2) Cost of breaking -open & repairing the Locker Rs. __ 3) Cost of making Inventory Rs. __ 4) Cost of Legal / Court Expenses Rs. _ ________ We have decided to sell the aforesaid articles or so much thereof, as may necessary with the permission of the Court, to recover the aforesaid amount and shall do so unless you pay us the aforesaid sum within Seven Days from the receipt hereof. The sale shoul d be entirely at your risk as to costs and consequences, which please note. Yours faithfully Note: The name of the newspaper and its date will be inserted in case the notice is published otherwise reference of newspaper be deleted and after the word “record” appearing in second line, full stop (.) be inserted. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 372 ANNEXURE IX Mr./Mrs./Miss Registered A/D Dear Sir / Madam, LOCKER No : DEMAND NOTICE FOR RECOVERY OF RS. Further to our letter / notice dated __________ sent by Regis tered A/D Post, advising the contents found in the said Locker, this is to advise you that the articles found therein and listed in our letter / notice, referred to above, have been sold out with the permission of the Court and the net sale proceed has been appropriated for payment of the amount due and payable by you. After appropriating the net sale proceeds, a sum of Rs: _________ is still due and payable by you. You are, therefore, required to please pay the said sum of Rs. ______________ (Rupees ) within Seven Days from the receipt hereof failing which we shall have no option but to initiate necessary legal proceedings for recovery of the said sum, at your risk as to costs and consequences, which please note Yours faithfully, B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 373 ANNEXURE X Mr./Mrs./Miss Registered A/D Dear Sir / Madam, LOCKER No: DEMAND NOTICE FOR RECOVERY OF RS: In spite of our Notice dated ________ sent to you by Registered A/D Post at your address on our record / published in Daily “____________” dated __________ , you failed and neglected to pay us the outstanding amount of License Fee and surrender the Locker with Key to us. Consequently we had the said Locker broken -open with the permission of the Court and found the said Locker empty. You are, therefore, called upon to pay the aforesaid sum of Rs.______ _____ ____ (Rupees ____________________ ) within Seven Days from the receipt hereof, failing which we shall file suit for recovery of the said sum at your risk as to costs & consequences, which please note. Yours faithfully, Note: The name of the newspaper and its date will be inserted in case the notice is published. Otherwise reference of newspaper be deleted and after the word “record” appearing in second line, full stop (.) be inserted. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 374 ANNEXURE XI B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 375 ANNEXURE XII B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 376 ANNEXURE XIII B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 377 ANNEXURE XIV B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 378 ANNEXURE XV Attachment to CIRCULAR NO.PO/FC-North/GEN/251 dated October 20, 2010 MCB Bank Limited Daily branch MIS report For the month of: __________ Code: Cash Feeding Branch Name: No. of Seals No. of Trips No. of Seals No. of Trips No. of Seals No. of Trips No. of Seals No. of Trips - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - * Incase where CIT services are obtained from more then one service provider then separate Annexure-A should be maintained accordingly.Br. Name Br. Code Chief Cashier Signature with rubber stampNote: Overtime charges (with # of hours utilized), Over Night vaulting charges (with # of Days), Toll Tax/Parking Charges (if any), Off Days/Holidays Utilization (with # of Days), Special CIT Service, Surcharge Amount, Distance Charges or any other related charges should be separately maintained at branch end and crossed checked with original invoice. Branch Manager Signature with rubber stampGrand TotalSecurity Company Name:Date: ____________ Date: ____________ Security Company Name:Date: ____________ Security Company Name: Branch Operations Manager Signature with rubber stampANNEXURE-A Grand Total Security Company Name: B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 379 ANNEXURE XVI Attachment to CIRCULAR NO.PO/FC-North/GEN/251 dated October 20, 2010 MCB Bank Limited ANNEXURE-B Expense Allocation Summary For the month of: __________ Code: __________ Cash Feeding Branch/Region/BH Name:_____________ Security Company Name: (2)Security Company Name: (2)Grand Total CIT Expense (1)CIT Expense (1)CIT Expense - - - - - - - - - - - - - - - - - - - - - (1) Branches where dedicated vehicle services are applied should distribute the expense on agreed formula i.e. per trip/carried amount basis (2) Incase where CIT services are obtained from more then one service provider then separate column information should be maintained accordingly.Note: In addition to trips and seal charges grand total amount should always contain Overtime charges, Over Night vaulting charges, Toll Tax/Parking Charges, Off Days/Holidays Utilization, Special CIT Service, Surcharge Amount, Distance Charges or any other related charges identically to specific branch where services are rendered and should be duly crossed checked with original invoice. Further security company wise grand totals should be tallied with billed amount against each cash feeding branch.Br. Name Br. Code Grand Total Signature with rubber stamp Signature with rubber stampBranch Operations Manager / Branch Manager ROM / Regional Head / Business Head B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 380 ANNEXURE XVII Attachment to CIRCULAR NO.PO/FC-North/GEN/251 dated October 20, 2010 MCB Bank Limited ANNEXURE-C Central Upload Format - GH office use only Month: S# BR CON_BR GL_CODE(dr) GL_CODE(cr) CCY AMOUNT CONTROL_NO TRAN_CODE NARRATION TYPE 1 0000 4040124150 1110101010 PKR 800001 2255 03 2 0000 4040124150 1110101010 PKR 800002 2255 03 3 0000 4040124150 1110101010 PKR 800003 2255 03 4 0000 4040124150 1110101010 PKR 800004 2255 03 5 0000 4040124150 1110101010 PKR 800005 2255 03 6 0000 4040124150 1110101010 PKR 800006 2255 03 7 0000 4040124150 1110101010 PKR 800007 2255 03 8 0000 4040124150 1110101010 PKR 800008 2255 03 9 0000 4040124150 1110101010 PKR 800009 2255 03 10 0000 4040124150 1110101010 PKR 800010 2255 03 11 0000 4040124150 1110101010 PKR 800011 2255 03 12 0000 4040124150 1110101010 PKR 800012 2255 03 13 0000 4040124150 1110101010 PKR 800013 2255 03 14 0000 4040124150 1110101010 PKR 800014 2255 03 15 0000 4040124150 1110101010 PKR 800015 2255 03 16 0000 4040124150 1110101010 PKR 800016 2255 03 17 0000 4040124150 1110101010 PKR 800017 2255 03 18 0000 4040124150 1110101010 PKR 800018 2255 03 19 0000 4040124150 1110101010 PKR 800019 2255 03 20 0000 4040124150 1110101010 PKR 800020 2255 03 Note: Only shaded area column needs to be filled in by respective office remaining columns should be repeated as mentioned above against each entry. Signature with rubber stampBusiness Financial Controller Signature with rubber stampMIS /Consolidation Officer B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 381 ANNEXURE XVIII Local Currency Self Assessment Control Function Checklist SELF ASSESSMENT CONTROL FUNCTION CHECKLIST LCY Critical Control Accounts Balance Verification Function Br: __________ Code: ________ Ensure all following GL Heads have either NIL or justifiable balance at EOD 1 1091101010 Intra -branch Settlement Account 2 1150101110 Express Money Control Account 3 1150101120 Utility Bills Control Account 4 1150101130 Salary / Bonus Control Account For the month of: ____________ 5 1150101150 Fund Transfer Control Account 6 1150101140 Clearing Control Account Frequency: Daily Responsibility: Branch Operations Manager Date Initials Notes 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 Branch Operations Manager is required to initial the relevant check -box upon confirmation of verification. If the relevant Head is not NIL, the balance to be justified with supporting documents with explanatory notes documented here -in IMP Note: If a pending entry in any control head is cleared later -on on any subsequent day (other than same day) , proper reference (date/ voucher/ supporting documents) to the same should be made in the current day statu s/notes. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 382 ANNEXURE XIX Foreign Currency Self Assessment Control Function Checklist SELF ASSESSMENT CONTROL FUNCTION CHECKLIST FCY Critical Control Accounts Balance Verification Function Br: ________ Code: _______ Ensure all following GL Heads have either NIL or justifiable balance at EOD 1 1090801250 Foreign Currency in Transit 2 2010201030 Foreign Currency Cash in Transit 3 2010201040 Foreign Currency in Transit 4 2010201050 FCY in Transit – US$ For the month of: ____________ 5 2010201060 FCY in Transit – GBP 6 2010201070 FCY in Transit – EUR Frequency: Daily Responsibility: Branch Operations Manager Date Initials Notes 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 Branch Operations Manager is required to initial the relevant check -box upon confirmation of verification. If the relevant Head is not NIL, the balance to be justified with supporting documents with explanatory notes documented here -in IMP Note: If a pending entry in any control head is cleared later -on on any subsequent day (other than same day), proper reference (date/voucher/ supportin g documents) to the same should be made in the current day status/notes. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 383 ANNEXURE XX B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 384 ANNEXURE XXI B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 385 ANNEXURE XXII DIFFERENCE IN SIGNATURE FROM CNIC Date: _______________ The Manager, MCB Bank Limited, ________________ Branch, ________________. Dear Sir Re: Difference in Specimen of Signature I intend to open an account in your branch and would like to inform you that my current signature differs with the one’s appearing on my CNIC. I would ap preciate if you could please accept my current signatures on all account opening documents. I have authenticated my current signatures with my signatures on CNIC. Name: __________________________ Specimen of my current signature ________________________________ Specimen of my signature as per Latest CNIC ________________________________ B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 386 ANNEXURE XXIII “CTR FORM” Information of Person Conducting the Cash Transaction Exceeding CTR Limit of PKR 2.5M Transacting Branch Name: _________________ Br. Code: _________ Transaction Date: ______________ _____ Account No: _________________________ Title of Account: ___________________________________ ______ Name of the Person Conducting the Transaction: _________________________ DOB: ______________ ______ Permanent Address: ________________________________________________________________ _________ Present Address: _________________________ _____________________________ ______________________ Phone No Res/ Off: _________________________ ____ Mobile No: ________ ____ ________________ CNIC No: _____________________________________ Nationality: _________ ____________ ______ CNIC Verified through NADRA VeriSys: Yes No Currency of the Transaction: ______________ Amount of the Transactions: ____________________ _______ Transaction Type: Negotiable Instrument(s) Sold Negotiable Instrument(s) Purchased Currency Exchange( s) Cash Deposit/Withdrawal Relationship with MCB: Account Holder Agent Employee Walk -in Customer Other (please Specify) ________________________________ Relationship with Customer / Account Holder: __________________________ _________ __________________ Purpose of Transaction: _______________________________________ ___________ ______________ _______ _______________________________________________________________________________ ___________ _______________________________________________________________________________ _________ __ We are satisfied with the conduct of the transaction; it is in line with customer’s business/ personal needs and is in line with customer profile. Notes (if any): ______________________________________________ _______________________________ __ Authorized Signature Authorized Signature BM Name: ____________________ BOM/ TSS Name: _____________________ B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 387 PROCESS DEVIATION The content contained in this Manual is mandatory and apply to, and must be observed by, all relevant businesses and functions within the Bank , however , in case of any “Process Deviation”, relevant business will be required to present a “Process Deviation Request” along with rationale and alternate business process mitigating the associated risks. All Process Deviation Requests will be approve d by Group Head Operations. B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 388 GLOSSARY Abbreviation Full Form A/c Account A/D Acceptance against Delivery AAS Account Activity Seize ABEP Annual Branch Expansion Plan AMC Asset Management Company AML Anti Money Laundering AOF Account Opening Form AS Authorized Signatory ASM Area Sales Manager AT&C Application along with the Terms and Conditions ATM Automated Teller Machine BA Business Account BBA Basic Banking Account BCBR Bills for Collection Bills Receivable BCO Banking Company Ordinance BH Business Head BLP Branch Licensing Policy BM Branch Manager BOD Board of Directors BOE Bank of England BOM Branch Operation Manager BPD Banking Policy Department BPRD Banking Policy and Regulations Department BRBC Bills Receivable Bills for Collection BRPD Banking Regulations and Policy Department BT Branch Teller BUS Business Account CA Current Account CAD Central Accounts Division CASA Current Account Saving Account CBBG Commercial Branch Banking Group CBC Call Back Confirmation CBG Consumer Banking Group CBR Cheque Book Registration CBS Core Banking System CC Cheque Collection CCA Customer’s Collection Account CCH Central Cash House CCIC Call Center Internal Control CCTV Closed Circuit Television CD Call Deposit CDD Customer Due Diligence B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 389 CFC Card Facilitation Center CFT Combating Financing of terrorism CIH Cash -in-Hand CIT Cash in Transit CIU Centralized Insurance Unit CMD Cash Management Division CMIS Central Management Information System CNIC Computerized National Identity Card COD Centralized Operations Division CPDU Card Production and Delivery Unit CPR Computerized Receipt Number CPU Central Processing Unit CPUK Centralized Processing Unit Karachi Cr Credit CRC Credit Risk Control CSO Customer Service Officer CUR Current Account DAO Designated Authorized Officer DD Demand Draft DDCI Demand Draft Buy Clearing Internal DDCS Demand Draft Cash Sale DDTS Demand Draft Transfer Sale DHA Defense Housing Authority Dr Debit DRU Dispute Resolution Unit DSC Direct Sale Consultant DSF Direct Sales Force E.S.P Extra Small Print E2E End 2 End EBM Electronic Banding Machines EDD Enhanced Due Diligence E-filing Electronic filing E-Form Electronic Form EOC Enterprise Operation Center EOD End of Day EPZ Export Promotion Zone EU European Union EUN Exempted Unclaimed Accounts EWT Exempted Withholding Tax FBC Foreign Bills for Collection FBR Federal Board of Revenue FCG Financial Control Group FCY Foreign Currency FDA Flexi Deposit Account FDD Foreign Demand Draft FED Federal Excise Duty FIA Federal Investigation Agency FIDD Foreign Inward Demand Draft B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 390 FIR First Information Report FOH Funds on hold FSU Fund Settlement Unit FTA Funds Transfer Application FTP File Transfer Protocol FX Foreign Exchange GBO General Banking Officer GH Group Head GL General Ledger GM General Manager GTB Global Transaction Banking H.O Head Office HESCO Hyderabad Electric Supply Company HRMG Human Resource Management Group IBCA Inter Branch Credit Advice IBS Inter branch Signatory IBG Islamic Banking Group ID Identification IDP Internally Displaced Person IESCO Islamabad Electric Supply Company IPM Integrated Payment Mechanism IS Investment Service ITD Information Technology Division ITG Information Technology Group ITO Income Tax Officer IT Ops Information Technology Operations KBA Khushali Bachat Account KESC Karachi Electric Supply Company KM Kernel Module KYC Know your Customer LAD Legal Affairs Division LCY Local Currency LIBOR London Inter Bank Offer Rate LOT Letter of Thanks LOV List of Values LZC Local Zakat Committee LZF Local Zakat Fund MC Master Card MCBEF MCB Employee Foundation MDS Master Debit Switch MICR Magnetic Ink Character Recognition MPA Mahana Profit Account N/A Not Applicable NAB National Accountability Bureau NADRA National Database and Registration Authority NARA National Aliens Registration Authority NBP National Bank of Pakistan NCR No Carbon Required B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 391 NICOP National Identity Card for Overseas Pakistani NIFT National Institutional Facilitation Technologies NRP Non -Resident Pakistanis NTB New to Bank NTN National Tax Number OBC Outward Bill for Collection OD Overdraft OFAC Office of Foreign Assets Control OGL Oracle General Ledger OM Operations Manager PAN Personal Access Number PBA Personal Banking Advisor PEP Politically Exposed Person PIN Personal Identification Number PKR Pakistani Rupee PLS Profit & Loss Sharing PO Pay Order POC Pakistan Origin Card POCI Payment Order Buy Clearing Internal POCS Payment Order Cash Sell POR Proof of Registration POS Point of sale POTB Payment Order Transfer Buy POTS Payment Order Transfer Sale PPG Product Program Guide PR Prudential Regulations PRC Proceeds Realization Certificates PTCL Pakistan Telecommunication Company Limited PZA Provincial Zakat Administrator RA Relationship Associate RAMS Report Archival Managem ent System RB Retail Banking RCO Regional Compliance Officer RM Relationship Manager ROMs Regional Operations Manager RTC Rupee Travelers Cheque SBP State Bank of Pakistan SCGM Smart Card Generation Module SECP Securities and Exchange Commission of Pakistan SF Standard Form SFTD Smart Foreign Currency Term Deposits SLA Service Level Agreement SMA Savings Maximizer Account SMCs School Management Committees SND Special Notice Deposit SNGPL Sui Northern Gas Pipeline Limited SOBC Schedule of Bank Charges SOD Start of Day B r a n c h O p e r a t i o n s M a n u a l – V e r s i o n 2 . 0 - D e c e m b e r 2 0 1 0 P a g e | 392 SP&R Special Projects & Reconciliation Division SQA Service Quality assurance SRTD Special Rupee Term Deposit SS Card Specimen Signature Card SSA Smart Savings Account SSGC Sui Southern Gas Company SST Sheikh Sultan Trust STDR Special Term Deposits Receipt STDR Special Term Deposit Receipt SWIFT Society for Worldwide Interbank Financial Telecommunication T&C Terms & Conditions TAT Turnaround Time TBD Transaction Banking Division TD Term Deposit TDA Term Deposit Application TDR Term Deposit Receipt TPIN Telephone Personal Identification Number Tr codes Transaction codes TROPS Treasury Operations TSD Trade Services Division TSO Teller services Officer TSS Teller Services Supervisor TT Telegraphic Transfer TTDR Term Deposits Receipts UN United Nations UPS Uninterrupted Power Supply UVL Ultra Violet light VB Virtual Banking VERISYS Verification System WAU Whereabouts Unknown WBG Wholesale Banking Group WHT Withholding Tax WICIF Walk -in- Customer Information Form ~----------------------------------------- END OF DOCUMENT ----------------------------------------- ~
diff --git a/data/raw_text/Elite_Dynamics_Partners_Policies.txt b/data/raw_text/Elite_Dynamics_Partners_Policies.txt
new file mode 100644
index 0000000..70e44d0
--- /dev/null
+++ b/data/raw_text/Elite_Dynamics_Partners_Policies.txt
@@ -0,0 +1 @@
+Elite Dynamics Partners Comprehensive Organizational Policies Effective Date: January 1, 2024 Version: 3.6 Confidential Document - For Internal Use Only This document contains proprietary information and policies of the organization. Table of Contents 1. Company Overview 2. Human Resources Policies 3. Information Technology Policies 4. Code of Conduct 5. Data Protection & Privacy Policies 6. Appendices 1. Company Overview Elite Dynamics Partners was founded in 2010 and has grown to become a leading organization in the Retail & E-commerce sector. With approximately 4250 employees worldwide, we are committed to excellence, innovation, and ethical business practices. Our mission is to deliver exceptional value to our clients while maintaining the highest standards of integrity and professionalism. This document outlines the policies and procedures that guide our operations and define our organizational culture. Core Values: - Integrity and Ethical Conduct - Innovation and Continuous Improvement - Customer Focus and Satisfaction - Employee Development and Well-being - Social Responsibility and Sustainability Organizational Structure: The company operates with a matrix structure that promotes collaboration across departments while maintaining clear lines of authority and accountability. 2. Human Resources Policies 2.1 Employment Policies All employment decisions are based on merit, qualifications, and business needs. The organization prohibits discrimination based on race, color, religion, sex, national origin, age, disability, or any other protected status. Probation Period: New employees undergo a 90-day probation period with performance evaluations at 30, 60, and 90 days. Working Hours: Standard working hours are 9:00 AM to 5:00 PM, Monday through Friday, with flexibility arrangements available based on role requirements. 2.2 Compensation and Benefits The organization offers competitive compensation packages including: - Base salary reviewed annually - Performance-based bonuses - Comprehensive health insurance - Retirement savings plan with company matching - Paid time off and holidays - Professional development opportunities Salary bands are determined based on market research, role requirements, and individual qualifications. 2.3 Leave Policies Vacation Leave: Employees accrue 15 days annually, increasing with tenure. Sick Leave: 10 days per year with proper documentation. Parental Leave: 12 weeks paid leave for primary caregivers. Emergency Leave: Available for family emergencies with manager approval. All leave requests must be submitted through the HR portal with appropriate advance notice when possible. 3. Information Technology Policies 3.1 Acceptable Use Policy Company IT resources are provided for business purposes. Employees must: - Use strong, unique passwords and enable multi-factor authentication - Report any security incidents immediately - Avoid downloading unauthorized software - Refrain from accessing inappropriate content - Protect sensitive information when working remotely Monitoring: The organization reserves the right to monitor IT resource usage to ensure compliance with policies and protect company assets. 3.2 Data Classification and Handling Data is classified into four categories: 1. Public: Information approved for public release 2. Internal: General business information 3. Confidential: Sensitive business information 4. Restricted: Highly sensitive information requiring special handling Each classification level has specific handling, storage, and transmission requirements that employees must follow. 4. Code of Conduct All employees are expected to adhere to the highest ethical standards in their professional conduct. This includes: - Acting with integrity and honesty in all business dealings - Avoiding conflicts of interest and disclosing potential conflicts - Protecting company assets and using them responsibly - Maintaining confidentiality of proprietary information - Treating colleagues, clients, and partners with respect and dignity - Complying with all applicable laws and regulations Violations of the code of conduct may result in disciplinary action, up to and including termination of employment. Reporting Mechanisms: Employees can report concerns through their manager, HR department, or the anonymous ethics hotline. The organization prohibits retaliation against individuals who report concerns in good faith. 5. Data Protection & Privacy Policies Elite Dynamics Partners is committed to protecting the privacy and security of personal data in accordance with applicable data protection laws. Data Protection Principles: - Lawfulness, fairness, and transparency in data processing - Purpose limitation: Data collected for specified, legitimate purposes - Data minimization: Collecting only necessary data - Accuracy: Keeping data accurate and up-to-date - Storage limitation: Retaining data only as long as necessary - Integrity and confidentiality: Implementing appropriate security measures - Accountability: Demonstrating compliance with data protection principles Data Subject Rights: Individuals have rights regarding their personal data, including access, rectification, erasure, and data portability. Requests should be submitted to the Data Protection Officer. International Data Transfers: When transferring data internationally, the organization ensures adequate protection through appropriate safeguards such as Standard Contractual Clauses. 6. Appendices Appendix A: Emergency Contact Information Appendix B: Department-Specific Policies Appendix C: Forms and Templates Appendix D: Policy Acknowledgment Form Appendix E: Revision History This document is reviewed annually and updated as necessary to reflect changes in laws, regulations, and business practices. The latest version is always available on the company intranet.
diff --git a/data_cleaning_pipeline/__pycache__/__init__.cpython-313.pyc b/data_cleaning_pipeline/__pycache__/__init__.cpython-313.pyc
deleted file mode 100644
index baee36a..0000000
Binary files a/data_cleaning_pipeline/__pycache__/__init__.cpython-313.pyc and /dev/null differ
diff --git a/data_cleaning_pipeline/__pycache__/data_structures.cpython-313.pyc b/data_cleaning_pipeline/__pycache__/data_structures.cpython-313.pyc
deleted file mode 100644
index b75f9d0..0000000
Binary files a/data_cleaning_pipeline/__pycache__/data_structures.cpython-313.pyc and /dev/null differ
diff --git a/data_cleaning_pipeline/__pycache__/loader.cpython-313.pyc b/data_cleaning_pipeline/__pycache__/loader.cpython-313.pyc
deleted file mode 100644
index 89e1063..0000000
Binary files a/data_cleaning_pipeline/__pycache__/loader.cpython-313.pyc and /dev/null differ
diff --git a/data_cleaning_pipeline/__pycache__/main.cpython-313.pyc b/data_cleaning_pipeline/__pycache__/main.cpython-313.pyc
deleted file mode 100644
index ff367e1..0000000
Binary files a/data_cleaning_pipeline/__pycache__/main.cpython-313.pyc and /dev/null differ
diff --git a/data_cleaning_pipeline/__pycache__/preprocessing.cpython-313.pyc b/data_cleaning_pipeline/__pycache__/preprocessing.cpython-313.pyc
deleted file mode 100644
index 0162d51..0000000
Binary files a/data_cleaning_pipeline/__pycache__/preprocessing.cpython-313.pyc and /dev/null differ
diff --git a/data_cleaning_pipeline/__pycache__/qa_generation.cpython-313.pyc b/data_cleaning_pipeline/__pycache__/qa_generation.cpython-313.pyc
deleted file mode 100644
index 665375e..0000000
Binary files a/data_cleaning_pipeline/__pycache__/qa_generation.cpython-313.pyc and /dev/null differ
diff --git a/data_cleaning_pipeline/__pycache__/utils.cpython-313.pyc b/data_cleaning_pipeline/__pycache__/utils.cpython-313.pyc
deleted file mode 100644
index 3f1a6c9..0000000
Binary files a/data_cleaning_pipeline/__pycache__/utils.cpython-313.pyc and /dev/null differ
diff --git a/data_cleaning_pipeline/data_structures.py b/data_cleaning_pipeline/data_structures.py
deleted file mode 100644
index db528d2..0000000
--- a/data_cleaning_pipeline/data_structures.py
+++ /dev/null
@@ -1,8 +0,0 @@
-from dataclasses import dataclass
-from typing import List
-
-@dataclass
-class QAPair:
-    question: str
-    answer: str
-    supporting_passages: List[str]
diff --git a/data_cleaning_pipeline/loader.py b/data_cleaning_pipeline/loader.py
deleted file mode 100644
index f81e16f..0000000
--- a/data_cleaning_pipeline/loader.py
+++ /dev/null
@@ -1,23 +0,0 @@
-import os
-import docx
-import PyPDF2
-
-def load_documents(folder: str) -> str:
-    """Reads all txt, pdf, docx files from a folder and returns concatenated text."""
-    texts = []
-    for fname in os.listdir(folder):
-        fpath = os.path.join(folder, fname)
-        if fname.lower().endswith(".txt"):
-            with open(fpath, "r", encoding="utf-8", errors="ignore") as f:
-                texts.append(f.read())
-        elif fname.lower().endswith(".pdf"):
-            with open(fpath, "rb") as f:
-                reader = PyPDF2.PdfReader(f)
-                pages = [p.extract_text() or "" for p in reader.pages]
-                texts.append("\n".join(pages))
-        elif fname.lower().endswith(".docx"):
-            doc = docx.Document(fpath)
-            texts.append("\n".join([p.text for p in doc.paragraphs]))
-        else:
-            print(f"[WARN] Skipping unsupported file: {fname}")
-    return "\n".join(texts)
diff --git a/data_cleaning_pipeline/main.py b/data_cleaning_pipeline/main.py
deleted file mode 100644
index 222d167..0000000
--- a/data_cleaning_pipeline/main.py
+++ /dev/null
@@ -1,148 +0,0 @@
-# data_cleaning_pipeline/main.py
-import os, re, json, fitz, math
-from tqdm import tqdm
-from transformers import pipeline
-from difflib import SequenceMatcher
-from collections import Counter
-
-# ---------------- CONFIG ----------------
-RAW_DIR = "../data/raw"
-PROCESSED_DIR = "../data/processed"
-QA_DIR = "../data/qa"
-
-CORPUS_PATH = os.path.join(PROCESSED_DIR, "corpus.txt")
-QA_PATH = os.path.join(QA_DIR, "qa_clean.json")
-
-MODEL_NAME = "mistralai/Mistral-7B-Instruct-v0.3"  # change to flan-t5-large for 16 GB cards
-MAX_CHUNK_LEN = 900
-QAS_PER_CHUNK = 6
-AUGMENT_PER_QA = 2
-MIN_SCORE = 0.55      # minimum clarity/relevance threshold
-
-# ---------------- STEP 1: PDF EXTRACTION ----------------
-def extract_text_from_pdfs(raw_dir):
-    texts = []
-    for file in os.listdir(raw_dir):
-        if file.lower().endswith(".pdf"):
-            print(f"📄 Extracting from {file}")
-            try:
-                with fitz.open(os.path.join(raw_dir, file)) as doc:
-                    texts.append("\n".join(page.get_text("text") for page in doc))
-            except Exception as e:
-                print(f"⚠️ {file}: {e}")
-    return "\n".join(texts)
-
-# ---------------- STEP 2: CLEANING ----------------
-def clean_text(text):
-    text = re.sub(r"\s+", " ", text)
-    text = re.sub(r"([a-z])([A-Z])", r"\1. \2", text)
-    for b in ["•", "", "●"]:
-        text = text.replace(b, "-")
-    return text.strip()
-
-# ---------------- STEP 3: CHUNKING ----------------
-def chunk_text(text, max_len=MAX_CHUNK_LEN):
-    sents = re.split(r"(?<=[.!?]) +", text)
-    chunks, buf = [], ""
-    for s in sents:
-        if len(buf) + len(s) < max_len:
-            buf += " " + s
-        else:
-            chunks.append(buf.strip())
-            buf = s
-    if buf:
-        chunks.append(buf.strip())
-    return chunks
-
-# ---------------- STEP 4: PRIMARY QA GENERATION ----------------
-def generate_qa(chunks, model_name=MODEL_NAME, qas_per_chunk=QAS_PER_CHUNK):
-    gen = pipeline("text2text-generation", model=model_name, device_map="auto")
-    out = []
-    for chunk in tqdm(chunks, desc="Primary QA"):
-        prompt = f"""
-From the banking passage below, create {qas_per_chunk} realistic question–answer pairs in JSON array form.
-Each should contain:
-  "question", "answer", "supporting_passages"
-Add relevant topic tags like [aml kyc #99aa11], [customer support #22bb88].
-
-Passage:
-{chunk}
-"""
-        try:
-            txt = gen(prompt, max_new_tokens=1024, temperature=0.9, do_sample=True)[0]["generated_text"]
-            m = re.search(r"\[.*\]", txt, re.DOTALL)
-            if m:
-                out.extend(json.loads(m.group(0)))
-        except Exception as e:
-            print("skip", e)
-    return out
-
-# ---------------- STEP 5: AUGMENTATION ----------------
-def augment_dataset(data, model_name=MODEL_NAME, n=AUGMENT_PER_QA):
-    gen = pipeline("text2text-generation", model=model_name, device_map="auto")
-    aug = []
-    for d in tqdm(data, desc="Augmenting"):
-        q, a = d["question"], d["answer"]
-        ctx = d.get("supporting_passages", [""])[0]
-        for _ in range(n):
-            p = f'Paraphrase this banking QA as JSON (same keys): {{"question":"{q}","answer":"{a}","supporting_passages":["{ctx}"]}}'
-            try:
-                t = gen(p, max_new_tokens=256, do_sample=True, temperature=1.0)[0]["generated_text"]
-                m = re.search(r"\{.*\}", t, re.DOTALL)
-                if m:
-                    aug.append(json.loads(m.group(0)))
-            except Exception:
-                continue
-    return data + aug
-
-# ---------------- STEP 6: POST-PROCESSING ----------------
-BANK_TERMS = {"aml","kyc","account","loan","transaction","customer","policy",
-              "support","refund","compliance","security","risk","data","privacy"}
-
-def similarity(a,b): return SequenceMatcher(None,a,b).ratio()
-
-def score_entry(q,a):
-    # clarity: length balance, punctuation
-    lq, la = len(q.split()), len(a.split())
-    clarity = 1 - abs(lq-15)/40 - abs(la-25)/50
-    # relevance: keyword overlap
-    rel = sum(k in (q+a).lower() for k in BANK_TERMS)/len(BANK_TERMS)
-    return max(0,min(1, (clarity+rel)/2))
-
-def deduplicate_and_filter(data, min_score=MIN_SCORE):
-    print("🧹 Cleaning & scoring QAs ...")
-    seen, clean = [], []
-    for d in tqdm(data, desc="Filtering"):
-        q,a = d.get("question",""), d.get("answer","")
-        s = score_entry(q,a)
-        if s < min_score: continue
-        if any(similarity(q,x["question"])>0.85 for x in seen): continue
-        d["score"]=round(s,3)
-        seen.append(d)
-        clean.append(d)
-    print(f"✅ {len(clean)} clean entries kept of {len(data)} total.")
-    return clean
-
-# ---------------- STEP 7: SAVE ----------------
-def save_dataset(corpus,data):
-    os.makedirs(PROCESSED_DIR,exist_ok=True)
-    os.makedirs(QA_DIR,exist_ok=True)
-    with open(CORPUS_PATH,"w",encoding="utf-8") as f: f.write(corpus)
-    with open(QA_PATH,"w",encoding="utf-8") as f: json.dump(data,f,indent=2,ensure_ascii=False)
-    print(f"✅ Saved corpus → {CORPUS_PATH}")
-    print(f"✅ Saved filtered dataset → {QA_PATH} ({len(data)} items)")
-
-# ---------------- MAIN ----------------
-def main():
-    print("🏦 Running full data-generation pipeline ...")
-    raw = extract_text_from_pdfs(RAW_DIR)
-    corpus = clean_text(raw)
-    chunks = chunk_text(corpus)
-    base = generate_qa(chunks)
-    aug  = augment_dataset(base)
-    clean = deduplicate_and_filter(aug)
-    save_dataset(corpus, clean)
-    print("🎯 Finished — high-quality banking QA dataset ready!")
-
-if __name__ == "__main__":
-    main()
diff --git a/data_cleaning_pipeline/preprocessing.py b/data_cleaning_pipeline/preprocessing.py
deleted file mode 100644
index 0a56feb..0000000
--- a/data_cleaning_pipeline/preprocessing.py
+++ /dev/null
@@ -1,19 +0,0 @@
-import nltk
-from nltk.tokenize import sent_tokenize
-
-nltk.download("punkt", quiet=True)
-
-def split_into_passages(text: str, max_words: int = 200):
-    """Splits raw text into passages (by sentences)."""
-    sentences = sent_tokenize(text)
-    passages, current, count = [], [], 0
-    for sent in sentences:
-        words = sent.split()
-        if count + len(words) > max_words:
-            passages.append(" ".join(current))
-            current, count = [], 0
-        current.append(sent)
-        count += len(words)
-    if current:
-        passages.append(" ".join(current))
-    return passages
diff --git a/data_cleaning_pipeline/qa_generation.py b/data_cleaning_pipeline/qa_generation.py
deleted file mode 100644
index 15847c6..0000000
--- a/data_cleaning_pipeline/qa_generation.py
+++ /dev/null
@@ -1,32 +0,0 @@
-from typing import List, Tuple
-from transformers import pipeline as hf_pipeline
-from .data_structures import QAPair
-from .loader import load_documents
-from .preprocessing import split_into_passages
-
-# HuggingFace models
-qg_model = "valhalla/t5-base-qg-hl"
-qa_model = "deepset/roberta-base-squad2"
-
-qg = hf_pipeline("text2text-generation", model=qg_model)
-qa = hf_pipeline("question-answering", model=qa_model)
-
-def build_corpus_and_qa(folder: str, num_qs: int = 2) -> Tuple[List[str], List[QAPair]]:
-    """Build corpus + QA dataset from raw documents folder."""
-    raw_text = load_documents(folder)
-    passages = split_into_passages(raw_text)
-
-    qa_pairs: List[QAPair] = []
-    for passage in passages:
-        input_text = f"generate questions: {passage}"
-        outputs = qg(input_text, max_length=64, num_return_sequences=num_qs)
-
-        for out in outputs:
-            q = out["generated_text"].strip()
-            try:
-                ans = qa(question=q, context=passage)["answer"]
-            except Exception:
-                ans = "Answer not found"
-            qa_pairs.append(QAPair(q, ans, [passage]))
-
-    return passages, qa_pairs
diff --git a/data_cleaning_pipeline/utils.py b/data_cleaning_pipeline/utils.py
deleted file mode 100644
index 033df54..0000000
--- a/data_cleaning_pipeline/utils.py
+++ /dev/null
@@ -1,12 +0,0 @@
-import json
-from .data_structures import QAPair
-
-def save_corpus(passages, path="data/processed/corpus.txt"):
-    with open(path, "w", encoding="utf-8") as f:
-        for p in passages:
-            f.write(p + "\n\n")
-
-def save_qa(qa_pairs, path="data/qa/qa.json"):
-    qa_dicts = [qa.__dict__ for qa in qa_pairs]
-    with open(path, "w", encoding="utf-8") as f:
-        json.dump(qa_dicts, f, indent=2)
diff --git a/data_generation_pipeline/data-pipeline/.gitignore b/data_generation_pipeline/data-pipeline/.gitignore
new file mode 100644
index 0000000..498d102
--- /dev/null
+++ b/data_generation_pipeline/data-pipeline/.gitignore
@@ -0,0 +1,36 @@
+# Python cache
+__pycache__/
+*.pyc
+*.pyo
+*.pyd
+
+# Virtual environment
+.venv/
+venv/
+
+# OS files
+.DS_Store
+
+# Jupyter
+.ipynb_checkpoints/
+
+# Data pipeline outputs
+data/output/
+data/interim/
+
+# Logs
+logs/
+
+# Cache directories
+.cache/
+transformers_cache/
+hf_cache/
+
+# IDE settings
+.vscode/
+.idea/
+
+# Distribution / build artifacts
+dist/
+build/
+*.egg-info/
diff --git a/data_generation_pipeline/data-pipeline/README.md b/data_generation_pipeline/data-pipeline/README.md
new file mode 100644
index 0000000..6d8d696
--- /dev/null
+++ b/data_generation_pipeline/data-pipeline/README.md
@@ -0,0 +1,172 @@
+# data-pipeline
+```
+A modular, production-ready Question & Answer (Q/A) generation pipeline designed for bank policy documents.
+The project transforms large policy PDFs into validated Q/A pairs using LLMs (Qwen 7B), evidence extraction, and semantic deduplication.
+
+---
+```
+
+## 🚀 Features
+
+```
+- PDF/TXT text extraction
+- Advanced cleaning for policy documents
+- Configurable chunking with overlap
+- Qwen 7B (4-bit) model support via `bitsandbytes`
+- Deterministic + sampling generation retries
+- Strict question validation (section numbers, policy names, acronyms)
+- Q/A parsing with numbering pattern matching
+- Sentence-level evidence extraction using `sentence-transformers`
+- Exact + semantic deduplication (FAISS cosine similarity)
+- Fully modular source code
+- CLI interface for terminal execution
+
+---
+```
+
+## 📁 Project Structure
+
+```
+data-pipeline/
+├── README.md
+├── pyproject.toml
+├── requirements.txt
+├── .gitignore
+├── config/
+│   ├── pipeline_config.yaml
+│   └── model_config.yaml
+├── data/
+│   ├── input/
+│   │   └── (place input PDF/TXT here)
+│   ├── interim/
+│   └── output/
+├── src/
+│   ├── __init__.py
+│   ├── cli.py
+│   ├── pipeline_runner.py
+│   ├── file_loader.py
+│   ├── cleaner.py
+│   ├── chunker.py
+│   ├── prompts.py
+│   ├── model_loader.py
+│   ├── generator.py
+│   ├── qa_parser.py
+│   ├── validators.py
+│   ├── evidence.py
+│   └── dedupe.py
+├── notebooks/
+│   └── experiments.ipynb
+├── tests/
+│   ├── test_cleaner.py
+│   ├── test_chunker.py
+│   └── test_parser.py
+└── docs/
+    └── architecture.md
+
+
+````
+
+---
+```
+## 🛠 Installation
+
+### 1. Create virtual environment
+```bash
+python3 -m venv .venv
+source .venv/bin/activate       # macOS / Linux
+# or
+.venv\Scripts\activate          # Windows
+````
+
+### 2. Install dependencies
+
+```bash
+pip install -r requirements.txt
+```
+
+---
+
+## 🚨 Input File
+
+Place your input file (PDF or TXT) inside:
+
+```
+data/input/
+```
+
+Example:
+
+```
+data/input/amanah_bank_policy.pdf
+```
+
+---
+
+## ▶ Running the Pipeline
+
+Run via CLI:
+
+```bash
+python -m cli run \
+    --input data/input/amanah_bank_policy.pdf \
+    --output data/output/results.json
+```
+
+This command will:
+
+1. Extract document text
+2. Clean and normalize it
+3. Chunk it into overlapping windows
+4. Generate Q/A pairs per chunk
+5. Extract supporting evidence sentences
+6. Deduplicate similar questions
+7. Save results as JSON
+
+---
+
+## ⚙ Configuration
+
+Edit these files to customize the pipeline:
+
+```
+config/pipeline_config.yaml   # chunk size, Q/A limits, dedupe threshold
+config/model_config.yaml      # model name, embedding model, quantization options
+```
+
+---
+
+## 🧪 Running Tests
+
+```bash
+pytest -q
+```
+
+Tests cover:
+
+* Cleaner
+* Chunker
+* Q/A parser
+
+---
+
+## 🧠 Notebooks
+
+Use the `notebooks/` directory for:
+
+* debugging
+* exploring text chunks
+* visualizing embeddings
+* evaluating model output
+
+---
+
+## 🤝 Contributing
+
+Pull requests and improvements are welcome.
+Follow standard Git branching with PR review.
+
+---
+
+## 📜 License
+
+Open-source — free to use and modify.
diff --git a/data_generation_pipeline/data-pipeline/config/model_config.yaml b/data_generation_pipeline/data-pipeline/config/model_config.yaml
new file mode 100644
index 0000000..a245e99
--- /dev/null
+++ b/data_generation_pipeline/data-pipeline/config/model_config.yaml
@@ -0,0 +1,7 @@
+default_model: "microsoft/phi-2"
+embed_model: "sentence-transformers/all-MiniLM-L6-v2"
+quantization:
+  load_in_4bit: true
+  bnb_4bit_use_double_quant: true
+  bnb_4bit_quant_type: "nf4"
+  bnb_4bit_compute_dtype: "float16"
diff --git a/data_generation_pipeline/data-pipeline/config/pipeline_config.yaml b/data_generation_pipeline/data-pipeline/config/pipeline_config.yaml
new file mode 100644
index 0000000..7f49b2c
--- /dev/null
+++ b/data_generation_pipeline/data-pipeline/config/pipeline_config.yaml
@@ -0,0 +1,11 @@
+chunk_size_words: 120
+chunk_overlap_words: 30
+max_q_per_chunk: 3
+max_new_tokens: 512
+deterministic_temp: 0.0
+sampling_temp: 0.4
+semantic_dedupe_threshold: 0.88
+evidence_sent_top_k: 2
+sleep_between_chunks: 0.12
+input_path: "data/input/amanah_bank_policy.pdf"
+output_file: "data/output/results.json"
diff --git a/data_generation_pipeline/data-pipeline/docs/architecture.md b/data_generation_pipeline/data-pipeline/docs/architecture.md
new file mode 100644
index 0000000..8a426fa
--- /dev/null
+++ b/data_generation_pipeline/data-pipeline/docs/architecture.md
@@ -0,0 +1,14 @@
+# Architecture
+
+- file_loader: reads PDF/TXT
+- cleaner: document cleaning + regex heuristics
+- chunker: fixed-size chunking with overlap
+- prompts: prompt templates for LLM
+- model_loader: loads quantized LLM
+- generator: deterministic + sampling retry logic
+- qa_parser: extract Q/A pairs from model output
+- validators: question checks (policy refs)
+- evidence: sentence-level evidence using sentence-transformers
+- dedupe: exact + semantic dedupe
+
+The implementation mirrors the earlier single-file pipeline and is modularized for maintainability. :contentReference[oaicite:2]{index=2}
diff --git a/data_generation_pipeline/data-pipeline/notebooks/experiments.ipynb b/data_generation_pipeline/data-pipeline/notebooks/experiments.ipynb
new file mode 100644
index 0000000..65838a5
--- /dev/null
+++ b/data_generation_pipeline/data-pipeline/notebooks/experiments.ipynb
@@ -0,0 +1 @@
+(placeholder) Use this notebook for iteratively testing chunks, prompts, evidence extraction, and visualizing embeddings.
diff --git a/data_generation_pipeline/data-pipeline/pyproject.toml b/data_generation_pipeline/data-pipeline/pyproject.toml
new file mode 100644
index 0000000..00cc93f
--- /dev/null
+++ b/data_generation_pipeline/data-pipeline/pyproject.toml
@@ -0,0 +1,13 @@
+[build-system]
+requires = ["setuptools", "wheel"]
+build-backend = "setuptools.build_meta"
+
+[project]
+name = "data-pipeline"
+version = "0.1.0"
+description = "Q/A generation pipeline for policy documents"
+authors = [
+  {name = "Saad Maqsood", email = "saadmaqsood1818@gmail.com"}
+]
+readme = "README.md"
+requires-python = ">=3.9"
diff --git a/data_generation_pipeline/data-pipeline/requirements.txt b/data_generation_pipeline/data-pipeline/requirements.txt
new file mode 100644
index 0000000..417e600
--- /dev/null
+++ b/data_generation_pipeline/data-pipeline/requirements.txt
@@ -0,0 +1,30 @@
+# Core ML & NLP libraries
+transformers>=4.35.0
+accelerate>=0.26.0
+sentence-transformers>=2.2.2
+torch>=2.1.0
+
+# Quantization
+bitsandbytes>=0.42.0
+
+# Document processing
+PyPDF2>=3.0.0
+
+# Embeddings / similarity / vector ops
+faiss-cpu>=1.7.4
+scikit-learn>=1.3.0
+
+# Text utilities
+nltk>=3.8.1
+
+# Progress bars
+tqdm>=4.66.0
+
+# Quantized model loading (optional)
+autoawq>=0.1.8
+
+# Config parsing
+pyyaml>=6.0.1
+
+# Logging
+loguru>=0.7.0
diff --git a/data_generation_pipeline/data-pipeline/src/__init__.py b/data_generation_pipeline/data-pipeline/src/__init__.py
new file mode 100644
index 0000000..3dc1f76
--- /dev/null
+++ b/data_generation_pipeline/data-pipeline/src/__init__.py
@@ -0,0 +1 @@
+__version__ = "0.1.0"
diff --git a/data_generation_pipeline/data-pipeline/src/chunker.py b/data_generation_pipeline/data-pipeline/src/chunker.py
new file mode 100644
index 0000000..5a05642
--- /dev/null
+++ b/data_generation_pipeline/data-pipeline/src/chunker.py
@@ -0,0 +1,16 @@
+from typing import List
+
+
+def chunk_text(text: str, chunk_size: int = 120, overlap: int = 30) -> List[str]:
+    if not text:
+        return []
+    words = text.split()
+    if len(words) <= chunk_size:
+        return [" ".join(words)]
+    chunks = []
+    i = 0
+    while i < len(words):
+        chunk = words[i : i + chunk_size]
+        chunks.append(" ".join(chunk))
+        i += chunk_size - overlap
+    return chunks
diff --git a/data_generation_pipeline/data-pipeline/src/cleaner.py b/data_generation_pipeline/data-pipeline/src/cleaner.py
new file mode 100644
index 0000000..41067e4
--- /dev/null
+++ b/data_generation_pipeline/data-pipeline/src/cleaner.py
@@ -0,0 +1,64 @@
+import re
+
+
+def clean_text(t: str) -> str:
+    if not t:
+        return ""
+    t = re.sub(r"\r\n?", "\n", t)
+    t = re.sub(r"\n{2,}", "\n\n", t)
+    # remove non-ascii sequences to reduce tokenization surprises
+    t = re.sub(r"[^\x00-\x7F]+", " ", t)
+
+    # remove everything before TABLE OF CONTENTS if present
+    t = re.sub(
+        r"^[\s\S]*?TABLE OF CONTENTS", "TABLE OF CONTENTS", t, flags=re.IGNORECASE
+    )
+
+    # a safe try to remove TOC region (non-fatal)
+    try:
+        t = re.sub(r"TABLE OF CONTENTS[\s\S]*?GLOSSARY[\s\.]*388", "", t)
+    except Exception:
+        pass
+    # REMOVE MINI TABLE OF CONTENTS
+    t = re.sub(
+        r"(?:\n|^)(?:[A-Za-z][A-Za-z0-9\s\(\)/,&\-]+?\s+\d+(?:\.\d+)+\s*){6,}",
+        "\n",
+        t,
+        flags=re.MULTILINE,
+    )
+
+    # ---------- REMOVE ANY REMAINING MINI-TOC LINES INSIDE 1.1 ----------
+    m = re.search(
+        r"(1\.1\s+OVERVIEW[\s\S]*?)(\n1\.2\s+CURRENT\s+ACCOUNTS)",
+        t,
+        flags=re.IGNORECASE,
+    )
+    if m:
+        section_11 = m.group(1)
+        rest = t[m.end(1) :]
+        # remove lines ending with x.y.z inside 1.1
+        section_11 = re.sub(r"(?m)^[^\n]*\b\d+\.\d+\.\d+\s*$", "", section_11)
+        t = section_11.strip() + "\n\n" + rest.strip()
+
+    # remove PREFACE up to first SECTION / CHAPTER
+    t = re.sub(
+        r"PREFACE[\s\S]*?(SECTION\s+1|CHAPTER\s+1)", r"\1", t, flags=re.IGNORECASE
+    )
+
+    # remove OCR-styled spaced footers e.g., "A m a n a h"
+    t = re.sub(r"(?m)^(?:\s*(?:[A-Za-z]\s+){2,}[A-Za-z].*)$", "", t)
+
+    t = re.sub(r"(?m)^\s*$", "", t)  # remove blank lines
+    t = re.sub(r"\n{3,}", "\n\n", t)
+    t = re.sub(r"[ \t]{2,}", " ", t)
+    return t.strip()
+
+
+BAD_MARKERS = ["Human:", "You are generating", "<question>", "<answer>"]
+
+
+def clean_text_leakage(text: str) -> str:
+    for marker in BAD_MARKERS:
+        if marker in text:
+            return ""
+    return text.strip()
diff --git a/data_generation_pipeline/data-pipeline/src/cli.py b/data_generation_pipeline/data-pipeline/src/cli.py
new file mode 100644
index 0000000..9de4c22
--- /dev/null
+++ b/data_generation_pipeline/data-pipeline/src/cli.py
@@ -0,0 +1,41 @@
+import argparse
+
+from config_reader import load_config
+from pipeline_runner import run_pipeline
+
+
+def build_parser():
+    p = argparse.ArgumentParser("data-pipeline")
+    p.add_argument("command", choices=["run"], help="Command to run")
+    p.add_argument(
+        "--config", default="config/pipeline_config.yaml", help="Pipeline config YAML"
+    )
+    p.add_argument("--input", help="Input PDF/TXT file (overrides config)")
+    p.add_argument("--output", help="Output JSON file (overrides config)")
+    return p
+
+
+def main():
+    # parser = build_parser()
+    # args = parser.parse_args()
+    # with open(args.config, "r", encoding="utf-8") as f:
+    #     cfg = yaml.safe_load(f)
+
+    cfg1 = load_config("config/pipeline_config.yaml")
+    cfg2 = load_config("config/model_config.yaml")
+    cfg = cfg1 | cfg2
+
+    input_path = ""
+    out_file = ""
+    if cfg:
+        input_path = cfg["input_path"]
+        out_file = cfg["output_file"]
+
+    # input_path = args.input or cfg.get("file_path")
+    # out_file = args.output or cfg.get("output_file", "data/output/results.json")
+
+    run_pipeline(input_path, out_file, cfg)
+
+
+if __name__ == "__main__":
+    main()
diff --git a/data_generation_pipeline/data-pipeline/src/config_reader.py b/data_generation_pipeline/data-pipeline/src/config_reader.py
new file mode 100644
index 0000000..3f4b875
--- /dev/null
+++ b/data_generation_pipeline/data-pipeline/src/config_reader.py
@@ -0,0 +1,20 @@
+import yaml
+
+
+def load_config(config_path="config.yaml"):
+    """Loads configuration from a YAML file."""
+    # Construct the full path relative to the script location
+    # script_dir = os.path.dirname(os.path.abspath(file))
+    # file_path = os.path.join(script_dir, config_path)
+    file_path = config_path
+
+    try:
+        with open(file_path, "r") as file:
+            config_data = yaml.safe_load(file)
+        return config_data
+    except FileNotFoundError:
+        print(f"Error: The file {config_path} was not found at {file_path}")
+        return None
+    except yaml.YAMLError as exc:
+        print(f"Error parsing YAML file: {exc}")
+        return None
diff --git a/data_generation_pipeline/data-pipeline/src/dedupe.py b/data_generation_pipeline/data-pipeline/src/dedupe.py
new file mode 100644
index 0000000..b82009d
--- /dev/null
+++ b/data_generation_pipeline/data-pipeline/src/dedupe.py
@@ -0,0 +1,29 @@
+from sentence_transformers import SentenceTransformer, util
+
+_embed_model = None
+
+
+def ensure_embed_model(model_name="sentence-transformers/all-MiniLM-L6-v2"):
+    global _embed_model
+    if _embed_model is None:
+        _embed_model = SentenceTransformer(model_name)
+    return _embed_model
+
+
+def semantic_dedupe(qas: list, threshold: float = 0.88):
+    if not qas:
+        return []
+    model = ensure_embed_model()
+    questions = [entry["question"] for entry in qas]
+    q_embs = model.encode(questions, convert_to_tensor=True)
+    keep = []
+    used = [False] * len(questions)
+    for i in range(len(questions)):
+        if used[i]:
+            continue
+        keep.append(qas[i])
+        sims = util.cos_sim(q_embs[i], q_embs).cpu().numpy()[0]
+        for j in range(i + 1, len(questions)):
+            if sims[j] >= threshold:
+                used[j] = True
+    return keep
diff --git a/data_generation_pipeline/data-pipeline/src/document_reader.py b/data_generation_pipeline/data-pipeline/src/document_reader.py
new file mode 100644
index 0000000..14a9431
--- /dev/null
+++ b/data_generation_pipeline/data-pipeline/src/document_reader.py
@@ -0,0 +1,109 @@
+import re
+import time
+from pathlib import Path
+from typing import Dict, List, Tuple
+
+from chunker import chunk_text
+from cleaner import clean_text, clean_text_leakage
+from config_reader import load_config
+from evidence import extract_evidence_sentences
+from file_loader import extract_text, get_file_name_from_dir
+from generator import generate_with_retry
+from prompts import build_prompt
+from qa_parser import parse_qa_block
+from validators import valid_question
+
+cfg = load_config("config/pipeline_config.yaml")
+SLEEP_BETWEEN_CHUNKS = cfg.get("sleep_between_chunks", 0.12)
+
+
+VAGUE_PATTERNS = [
+    r"\bthis policy\b",
+    r"\bthis context\b",
+    r"\bthis document\b",
+    r"\bthis section\b",
+    r"\bthe above\b",
+    r"\bhere\b",
+]
+
+
+def process_document(file_path: Path, tokenizer, model) -> Tuple[List[Dict], Dict]:
+    doc_meta = {
+        "doc_id": f"doc_{hash(str(file_path)) & 0xffffffff}",
+        "file_name": file_path.name,
+        "file_path": str(file_path),
+        "file_type": file_path.suffix.lower().lstrip("."),
+    }
+
+    try:
+        print(f"[INFO] Loading text of {file_path}...")
+        raw = extract_text(str(file_path))
+        cleaned = clean_text(raw)
+
+        file_name = get_file_name_from_dir(str(file_path))
+
+        # Save cleaned corpus for audit
+        with open(f"cleaned_corpus_{file_name}.txt", "w", encoding="utf-8") as f:
+            f.write(cleaned)
+        print(f"[INFO] Saved cleaned_corpus_{file_name}.txt")
+
+        chunks = chunk_text(cleaned)
+
+        results = []
+        seen_exact = set()
+
+        for idx, chunk in enumerate(chunks[:30]):
+            prompt = build_prompt(chunk)
+            text = generate_with_retry(tokenizer, model, prompt)
+            print(f"Working on chunk {idx} out of {len(chunks)} of file {file_name}")
+            if not text:
+                print(f"[WARN] Empty model output for chunk {idx}")
+                continue
+            parsed = parse_qa_block(text)
+            if not parsed:
+                # no Q/A found — skip
+                time.sleep(SLEEP_BETWEEN_CHUNKS)
+                continue
+
+            for q, a in parsed:
+                q = clean_text_leakage(q)
+                a = clean_text_leakage(a)
+
+                if any(re.search(p, q.lower()) for p in VAGUE_PATTERNS):
+                    continue
+
+                if not q or not a:
+                    continue
+                if q.startswith("<") or a.startswith("<"):
+                    continue
+
+                if len(a.split()) > 60:
+                    continue
+
+                q_norm = q.strip().rstrip("?")
+                a_norm = a.strip()
+
+                if not valid_question(q_norm):
+                    continue
+
+                key = (q_norm.lower(), a_norm.lower())
+                if key in seen_exact:
+                    continue
+                seen_exact.add(key)
+
+                evidences = extract_evidence_sentences(a_norm, chunk)
+
+                results.append(
+                    {
+                        **doc_meta,
+                        "chunk_id": idx,
+                        "question": q_norm,
+                        "answer": a_norm,
+                        "supporting_passages": evidences or [chunk],
+                    }
+                )
+
+        return results, {"status": "success", "qas": len(results)}
+
+    except Exception as e:
+        return [], {"status": "failed", "error": str(e)}
diff --git a/data_generation_pipeline/data-pipeline/src/evidence.py b/data_generation_pipeline/data-pipeline/src/evidence.py
new file mode 100644
index 0000000..5e24a8c
--- /dev/null
+++ b/data_generation_pipeline/data-pipeline/src/evidence.py
@@ -0,0 +1,43 @@
+from typing import List
+
+import nltk
+from sentence_transformers import SentenceTransformer, util
+
+_embed_model = None
+
+
+def ensure_embed_model(model_name: str = "sentence-transformers/all-MiniLM-L6-v2"):
+    global _embed_model
+    if _embed_model is None:
+        _embed_model = SentenceTransformer(model_name)
+    return _embed_model
+
+
+def sentences_from_text(text: str):
+    try:
+        nltk.data.find("tokenizers/punkt")
+    except Exception:
+        nltk.download("punkt")
+    from nltk.tokenize import sent_tokenize
+
+    sents = sent_tokenize(text)
+    return [s.strip() for s in sents if s.strip()]
+
+
+def extract_evidence_sentences(
+    answer: str,
+    chunk: str,
+    k: int = 2,
+    model_name: str = "sentence-transformers/all-MiniLM-L6-v2",
+) -> List[str]:
+    sents = sentences_from_text(chunk)
+    if not sents:
+        return []
+    model = ensure_embed_model(model_name)
+    embeddings = model.encode([answer] + sents, convert_to_tensor=True)
+    ans_emb = embeddings[0]
+    sent_embs = embeddings[1:]
+    scores = util.cos_sim(ans_emb, sent_embs)[0].cpu().numpy()
+    idxs = scores.argsort()[::-1][:k]
+    chosen = [sents[i] for i in idxs if scores[i] > 0.1]
+    return chosen
diff --git a/data_generation_pipeline/data-pipeline/src/file_loader.py b/data_generation_pipeline/data-pipeline/src/file_loader.py
new file mode 100644
index 0000000..d715483
--- /dev/null
+++ b/data_generation_pipeline/data-pipeline/src/file_loader.py
@@ -0,0 +1,52 @@
+from pathlib import Path
+from typing import List
+
+import PyPDF2
+
+
+def is_pdf(path: str) -> bool:
+    return str(path).lower().endswith(".pdf")
+
+
+def is_txt(path: str) -> bool:
+    return str(path).lower().endswith(".txt")
+
+
+def extract_text_from_pdf(path: str) -> str:
+    pages = []
+    with open(path, "rb") as f:
+        reader = PyPDF2.PdfReader(f)
+        for p in reader.pages:
+            pages.append(p.extract_text() or "")
+    return "\n".join(pages)
+
+
+def extract_text(file_path: str) -> str:
+    p = Path(file_path)
+    if not p.exists():
+        raise FileNotFoundError(f"Input file not found: {file_path}")
+    if is_pdf(str(file_path)):
+        return extract_text_from_pdf(file_path)
+    elif is_txt(str(file_path)):
+        return p.read_text(encoding="utf-8")
+    else:
+        raise ValueError("Unsupported file type. Provide .pdf or .txt")
+
+
+def discover_files(input_path: str) -> List[Path]:
+    p = Path(input_path)
+    if not p.exists():
+        raise FileNotFoundError(f"Input path not found: {input_path}")
+
+    if p.is_file():
+        return [p]
+
+    files: List[Path] = []
+    for ext in ("*.pdf", "*.txt"):
+        files.extend(p.rglob(ext))
+
+    return sorted(files)
+
+
+def get_file_name_from_dir(input_path: str):
+    return Path(input_path).stem
diff --git a/data_generation_pipeline/data-pipeline/src/generator.py b/data_generation_pipeline/data-pipeline/src/generator.py
new file mode 100644
index 0000000..9446c36
--- /dev/null
+++ b/data_generation_pipeline/data-pipeline/src/generator.py
@@ -0,0 +1,54 @@
+import torch
+
+
+def generate_with_retry(
+    tokenizer,
+    model,
+    prompt: str,
+    max_new_tokens: int = 512,
+    deterministic_temp: float = 0.0,
+    sampling_temp: float = 0.4,
+):
+    inputs = tokenizer(
+        prompt,
+        return_tensors="pt",
+        truncation=True,
+        max_length=tokenizer.model_max_length,
+    ).to(model.device)
+    text = ""
+    try:
+        with torch.no_grad():
+            out = model.generate(
+                **inputs,
+                max_new_tokens=max_new_tokens,
+                min_new_tokens=50,
+                temperature=deterministic_temp,
+                top_p=0.95,
+                do_sample=False,
+                pad_token_id=tokenizer.eos_token_id,
+                eos_token_id=tokenizer.eos_token_id,
+            )
+        text = tokenizer.decode(
+            out[0][inputs["input_ids"].shape[1] :], skip_special_tokens=True
+        ).strip()
+    except Exception:
+        text = ""
+
+    if not text or len(text) < 10:
+        try:
+            with torch.no_grad():
+                out = model.generate(
+                    **inputs,
+                    max_new_tokens=max_new_tokens,
+                    temperature=sampling_temp,
+                    top_p=0.95,
+                    do_sample=True,
+                    pad_token_id=tokenizer.eos_token_id,
+                    eos_token_id=tokenizer.eos_token_id,
+                )
+            text = tokenizer.decode(
+                out[0][inputs["input_ids"].shape[1] :], skip_special_tokens=True
+            ).strip()
+        except Exception:
+            text = ""
+    return text
diff --git a/data_generation_pipeline/data-pipeline/src/model_loader.py b/data_generation_pipeline/data-pipeline/src/model_loader.py
new file mode 100644
index 0000000..79d979b
--- /dev/null
+++ b/data_generation_pipeline/data-pipeline/src/model_loader.py
@@ -0,0 +1,23 @@
+from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig
+
+
+def load_model_tokenizer(model_name: str, quant_config: dict):
+    bnb_config = BitsAndBytesConfig(
+        load_in_4bit=quant_config.get("load_in_4bit", True),
+        bnb_4bit_use_double_quant=quant_config.get("bnb_4bit_use_double_quant", True),
+        bnb_4bit_quant_type=quant_config.get("bnb_4bit_quant_type", "nf4"),
+        bnb_4bit_compute_dtype=quant_config.get("bnb_4bit_compute_dtype", "float16"),
+    )
+
+    tok = AutoTokenizer.from_pretrained(model_name, trust_remote_code=True)
+    if tok.pad_token is None:
+        tok.pad_token = tok.eos_token
+
+    model = AutoModelForCausalLM.from_pretrained(
+        model_name,
+        quantization_config=bnb_config,
+        device_map="auto",
+        trust_remote_code=True,
+    )
+    model.config.pad_token_id = tok.eos_token_id
+    return tok, model
diff --git a/data_generation_pipeline/data-pipeline/src/pipeline_runner.py b/data_generation_pipeline/data-pipeline/src/pipeline_runner.py
new file mode 100644
index 0000000..3cca94b
--- /dev/null
+++ b/data_generation_pipeline/data-pipeline/src/pipeline_runner.py
@@ -0,0 +1,96 @@
+import json
+from collections import defaultdict
+from typing import Any
+
+from config_reader import load_config
+from dedupe import semantic_dedupe
+from document_reader import process_document
+from file_loader import discover_files
+from model_loader import load_model_tokenizer
+
+cfg1 = load_config("config/pipeline_config.yaml")
+cfg2 = load_config("config/model_config.yaml")
+cfg = cfg1 | cfg2
+DEFAULT_MODEL = cfg.get("default_model", "meta-llama/Llama-3.2-1B")
+SEMANTIC_DEDUPE_THRESHOLD = cfg.get("semantic_dedupe_threshold", 0.88)
+
+
+def run_pipeline(input_path: str, out_file: str):
+    files = discover_files(input_path)
+    print(f"[INFO] Found {len(files)} files")
+
+    print(
+        "[INFO] Loading model and tokenizer (device_map='auto') — this may take a minute..."
+    )
+
+    tokenizer, model = load_model_tokenizer(DEFAULT_MODEL)
+    all_results = []
+    report: dict[str, Any] = {
+        "files_found": len(files),
+        "files_processed": 0,
+        "files_failed": 0,
+        "qas_per_document": {},
+    }
+
+    for f in files:
+        print(f"[INFO] Processing {f.name}")
+        results, status = process_document(f, tokenizer, model)
+
+        if status["status"] == "success":
+            report["files_processed"] += 1
+            report["qas_per_document"][f.name] = status["qas"]
+            all_results.extend(results)
+        else:
+            report["files_failed"] += 1
+            print(f"[WARN] Failed {f.name}: {status['error']}")
+
+    # print("[INFO] Running semantic dedupe per document...")
+    # # optional: semantic_dedupe here per doc_id
+
+    # print(f"[INFO] Raw generated Q/A count before semantic dedupe: {len(all_results)}")
+
+    # # Semantic dedupe (embedding-based) to remove near-duplicates
+    # results = semantic_dedupe(all_results, threshold=SEMANTIC_DEDUPE_THRESHOLD)
+    # print(f"[INFO] Q/A count after semantic dedupe: {len(all_results)}")
+
+    print("[INFO] Running semantic dedupe per document...")
+
+    docs = defaultdict(list)
+    for qa in all_results:
+        docs[qa["doc_id"]].append(qa)
+
+    deduped_results = []
+    for _, qas in docs.items():
+        deduped = semantic_dedupe(qas, threshold=SEMANTIC_DEDUPE_THRESHOLD)
+        deduped_results.extend(deduped)
+
+    print(
+        f"[INFO] Q/A count after per-document semantic dedupe: {len(deduped_results)}"
+    )
+
+    # Optional global exact dedupe
+    final_results = []
+    seen = set()
+    for qa in deduped_results:
+        key = (qa["question"].lower(), qa["answer"].lower())
+        if key in seen:
+            continue
+        seen.add(key)
+        final_results.append(qa)
+
+    print(f"[INFO] Final Q/A count after global exact dedupe: {len(final_results)}")
+
+    all_results = final_results
+
+    with open(out_file, "w", encoding="utf-8") as f:
+        json.dump(all_results, f, indent=2, ensure_ascii=False)
+    print(f"[INFO] Saved final dataset -> {out_file}")
+
+    report["total_qas"] = len(all_results)
+
+    report_name = "processing_report.json"
+    with open(report_name, "w") as f:
+        json.dump(report, f, indent=2)
+    print(f"[INFO] Saved final dataset report-> {report_name}")
+
+    print("[INFO] Pipeline complete.")
diff --git a/data_generation_pipeline/data-pipeline/src/prompts.py b/data_generation_pipeline/data-pipeline/src/prompts.py
new file mode 100644
index 0000000..12e43c3
--- /dev/null
+++ b/data_generation_pipeline/data-pipeline/src/prompts.py
@@ -0,0 +1,64 @@
+from config_reader import load_config
+
+cfg = load_config("config/pipeline_config.yaml")
+MAX_Q_PER_CHUNK = cfg.get("max_q_per_chunk", 3)
+
+
+def build_prompt(passage: str, max_q: int = MAX_Q_PER_CHUNK) -> str:
+    PROMPT_TEMPLATE = f"""
+  You are generating high-quality question–answer pairs for fine-tuning a language model to reduce hallucinations.
+
+  Follow these strict rules:
+
+  Question Guidelines
+  Questions must sound natural and realistic, as if asked by a bank customer, employee, or compliance officer.
+  Do NOT mention section numbers, clause numbers, or internal policy labels.
+  Questions must be specific and unambiguous.
+  Avoid generic phrases like “What does the policy say”.
+
+  Questions must be fully self-contained and standalone.
+  Do NOT use vague references such as:
+  - "this policy"
+  - "this context"
+  - "this document"
+  - "this section"
+  - "the above"
+  - "here"
+  Instead, explicitly name the policy, entity, or subject described in the text.
+  Canonical Subject Rule:
+  Each question MUST explicitly name the policy, process, or entity described in the passage (e.g., “Amanah Bank’s Account Opening and Maintenance Policy”).
+  Generic references such as “the policy” are NOT allowed.
+
+  Answer Guidelines
+  Answers must be fully supported by the provided text.
+  Answers must be complete, factual, and standalone.
+  Do NOT repeat the question wording.
+  Do NOT add assumptions or external knowledge.
+  Answers should be concise and limited to the facts explicitly stated in the passage.
+
+  Grounding Requirement
+  Each answer must be directly traceable to one or more exact sentences in the text.
+  Do not combine information from unrelated sections.
+  Generate up to {max_q} high-quality question–answer pairs from the text. Generating zero questions is acceptable.
+
+  Generation Preference
+  If the passage contains clear rules, responsibilities, timelines, or conditions, generate at least one question.
+
+  Negative instruction
+  If the text does not clearly answer a potential question, do NOT generate that question.
+
+  Output ONLY the Q&A pairs in the exact format shown. Do not include explanations or commentary.
+
+  Format:
+  Q1: <question>?
+  A1: <answer>
+
+  Q2: <question>?
+  A2: <answer>
+
+  ... up to Q{max_q}
+
+    Passage:
+    {passage}
+  """
+    return PROMPT_TEMPLATE.format(max_q=max_q, passage=passage)
diff --git a/data_generation_pipeline/data-pipeline/src/qa_parser.py b/data_generation_pipeline/data-pipeline/src/qa_parser.py
new file mode 100644
index 0000000..30c26ca
--- /dev/null
+++ b/data_generation_pipeline/data-pipeline/src/qa_parser.py
@@ -0,0 +1,22 @@
+import re
+
+Q_RE = re.compile(r"^\s*Q\s*(\d+)\s*[:.\-]\s*(.+?)(\?)?\s*$", re.IGNORECASE)
+A_RE = re.compile(r"^\s*A\s*(\d+)\s*[:.\-]\s*(.+)", re.IGNORECASE)
+
+
+def parse_qa_block(block: str):
+    lines = [ln.strip() for ln in block.splitlines() if ln.strip()]
+    pairs = []
+    i = 0
+    while i < len(lines) - 1:
+        q_match = Q_RE.match(lines[i])
+        a_match = A_RE.match(lines[i + 1])
+        if q_match and a_match and q_match.group(1) == a_match.group(1):
+            q = q_match.group(2).strip()
+            a = a_match.group(2).strip()
+            a = re.split(r"\nQ\d+[:\-]|Q\d+[:\-]", a)[0].strip()
+            pairs.append((q, a))
+            i += 2
+        else:
+            i += 1
+    return pairs
diff --git a/data_generation_pipeline/data-pipeline/src/validators.py b/data_generation_pipeline/data-pipeline/src/validators.py
new file mode 100644
index 0000000..1178fd0
--- /dev/null
+++ b/data_generation_pipeline/data-pipeline/src/validators.py
@@ -0,0 +1,44 @@
+import re
+
+POLICY_NUM_RE = re.compile(
+    r"\b(?:section|sec|clause|article|policy)\s*\d+(?:\.\d+)*\b", re.IGNORECASE
+)
+NAMED_POLICY_RE = re.compile(
+    r"\b([A-Z][A-Za-z&\-]{2,}(?:\s+[A-Z][A-Za-z&\-]{2,}){0,6}\s+(?:Policy|policy))\b"
+)
+ABBR_POLICY_RE = re.compile(r"\b(KYC|CDD|EDD|AML|CFT|FD|ATM|STR|CTR)\b", re.IGNORECASE)
+
+
+def question_has_valid_reference(q: str) -> bool:
+    if POLICY_NUM_RE.search(q):
+        return True
+    if NAMED_POLICY_RE.search(q):
+        return True
+    if ABBR_POLICY_RE.search(q):
+        return True
+    return False
+
+
+def is_vague_question(q: str) -> bool:
+    ql = q.lower()
+    vague_phrases = [
+        "purpose of this policy",
+        "what is this policy",
+        "what is the purpose of this policy",
+        "what does this policy say",
+    ]
+    return any(p in ql for p in vague_phrases)
+
+
+def valid_question(q: str) -> bool:
+    if len(q.strip()) < 8:
+        return False
+    # reject only truly vague questions
+    vague_phrases = [
+        "what is this policy",
+        "what does the policy say",
+        "what is the purpose of this policy",
+        "what does this policy say",
+    ]
+    ql = q.lower()
+    return not any(v in ql for v in vague_phrases)
diff --git a/data_generation_pipeline/data-pipeline/tests/test_chunker.py b/data_generation_pipeline/data-pipeline/tests/test_chunker.py
new file mode 100644
index 0000000..037aa6d
--- /dev/null
+++ b/data_generation_pipeline/data-pipeline/tests/test_chunker.py
@@ -0,0 +1,7 @@
+from chunker import chunk_text
+
+
+def test_chunk_small():
+    text = "one two three"
+    chunks = chunk_text(text, chunk_size=5, overlap=2)
+    assert len(chunks) == 1
diff --git a/data_generation_pipeline/data-pipeline/tests/test_cleaner.py b/data_generation_pipeline/data-pipeline/tests/test_cleaner.py
new file mode 100644
index 0000000..9807527
--- /dev/null
+++ b/data_generation_pipeline/data-pipeline/tests/test_cleaner.py
@@ -0,0 +1,8 @@
+from cleaner import clean_text
+
+
+def test_cleaner_basic():
+    raw = "PREFACE\nsomething\nSECTION 1\nThis is text.\n\n\nA m a n a h\n"
+    cleaned = clean_text(raw)
+    assert "PREFACE" not in cleaned or "SECTION 1" in cleaned
+    assert "A m a n a h" not in cleaned
diff --git a/data_generation_pipeline/data-pipeline/tests/test_parser.py b/data_generation_pipeline/data-pipeline/tests/test_parser.py
new file mode 100644
index 0000000..d6f46e4
--- /dev/null
+++ b/data_generation_pipeline/data-pipeline/tests/test_parser.py
@@ -0,0 +1,8 @@
+from qa_parser import parse_qa_block
+
+
+def test_parse_basic():
+    block = "Q1: What is Section 1?\nA1: It is the initial section.\nQ2: What is Section 2?\nA2: Another section."
+    pairs = parse_qa_block(block)
+    assert len(pairs) == 2
+    assert pairs[0][0].startswith("What is")
diff --git a/docs/api_reference.md b/docs/api_reference.md
new file mode 100644
index 0000000..eca8b2f
--- /dev/null
+++ b/docs/api_reference.md
@@ -0,0 +1,53 @@
+# API Reference
+
+This document provides a reference for the key classes and functions in the AI4Org codebase.
+
+## Hallucination Reduction
+
+### `hallucination_reduction.generator.Generator`
+
+Wrapper for the TinyLlama causal language model.
+
+#### `__init__(self, model_name: str, device: str)`
+Initializes the generator model.
+*   `model_name`: Hugging Face model identifier.
+*   `device`: 'cuda' or 'cpu'.
+
+#### `generate(self, prompt: str, max_new_tokens: int = 128) -> str`
+Generates text based on the prompt.
+
+### `hallucination_reduction.discriminator.Discriminator`
+
+Wrapper for the DistilBERT binary classifier.
+
+#### `__init__(self, model_name: str, device: str)`
+Initializes the discriminator model.
+
+#### `predict(self, text: str) -> float`
+Returns the probability (0.0 to 1.0) of the positive class.
+
+### `hallucination_reduction.retriever.Retriever`
+
+Handles semantic search.
+
+#### `retrieve(self, query: str, top_k: int = 3) -> List[str]`
+Retrieves the top-k most relevant document chunks for the query.
+
+## Data Pipeline
+
+### `data_pipeline.src.pipeline_runner.PipelineRunner`
+
+Orchestrates the data generation process.
+
+#### `run(self, input_path: str, output_path: str)`
+Executes the full pipeline on the input file.
+
+### `data_pipeline.src.cleaner.DocumentCleaner`
+
+#### `clean(self, text: str) -> str`
+Removes noise, headers, and footers from the text.
+
+### `data_pipeline.src.chunker.SmartChunker`
+
+#### `chunk(self, text: str) -> List[str]`
+Splits text into overlapping chunks while respecting sentence boundaries.
diff --git a/docs/architecture.md b/docs/architecture.md
new file mode 100644
index 0000000..ce775ed
--- /dev/null
+++ b/docs/architecture.md
@@ -0,0 +1,101 @@
+# System Architecture
+
+This document provides a detailed overview of the AI4Org system architecture, including its components, data flow, and design decisions.
+
+## High-Level Overview
+
+AI4Org is designed to reduce hallucinations in Large Language Models (LLMs) used for organizational policy Q&A. It employs a Retrieval-Augmented Generation (RAG) approach enhanced by a multi-discriminator system and Reinforcement Learning (RL).
+
+### Core Components
+
+1.  **Data Generation Pipeline**: Automates the creation of high-quality Q&A pairs from raw policy documents.
+2.  **Hallucination Reduction Module**: The core ML engine that trains the generator using SFT and RL.
+3.  **Frontend Application**: A cross-platform desktop interface for users to interact with the system.
+
+## Architecture Diagram
+
+```mermaid
+graph TB
+    subgraph "Data Ingestion & Processing"
+        Raw[Raw Documents<br/>(PDF/TXT)] --> Cleaner[Document Cleaner]
+        Cleaner --> Chunker[Smart Chunker]
+        Chunker --> QGen[Qwen 7B<br/>Q&A Generator]
+        QGen --> Evidence[Evidence Extractor]
+        Evidence --> Dedupe[Semantic Deduplication]
+        Dedupe --> QA_DB[(Validated Q&A Database)]
+    end
+
+    subgraph "Training Pipeline"
+        QA_DB --> SFT[Supervised Fine-Tuning]
+        SFT --> RL_Loop[RL Loop (REINFORCE)]
+
+        subgraph "Discriminator System"
+            Fact[Factuality Discriminator]
+            Style[Style Discriminator]
+            Safety[Safety Discriminator]
+        end
+
+        RL_Loop <--> Fact
+        RL_Loop <--> Style
+        RL_Loop <--> Safety
+
+        RL_Loop --> FinalModel[Final Generator Model]
+    end
+
+    subgraph "Inference System"
+        User[User Query] --> Retriever[Semantic Retriever]
+        Retriever --> Context[Context Retrieval]
+        Context --> FinalModel
+        FinalModel --> Response[Generated Response]
+    end
+
+    style Raw fill:#f9f,stroke:#333,stroke-width:2px
+    style QA_DB fill:#bbf,stroke:#333,stroke-width:2px
+    style FinalModel fill:#bfb,stroke:#333,stroke-width:2px
+```
+
+## Component Details
+
+### 1. Data Generation Pipeline (`data_generation_pipeline`)
+
+The data pipeline is critical for creating the "ground truth" needed for training.
+
+*   **Input**: Raw PDF or TXT files (e.g., bank policies).
+*   **Processing**:
+    *   **Cleaning**: Removes headers, footers, and page numbers.
+    *   **Chunking**: Splits text into overlapping windows (default 512 tokens) to preserve context.
+    *   **Generation**: Uses a quantized Qwen 7B model to generate question-answer pairs from each chunk.
+    *   **Validation**: Checks for hallucinated section numbers or acronyms not present in the text.
+*   **Output**: A JSON file containing Q&A pairs linked to their source evidence.
+
+### 2. Hallucination Reduction Module (`hallucination_reduction`)
+
+This module implements the novel training approach.
+
+*   **Generator**: Based on `TinyLlama-1.1B-Chat`. It is small enough for efficient training but capable enough for coherent text generation.
+*   **Discriminators**: Three separate `DistilBERT` models trained to classify:
+    *   **Factuality**: Is the answer supported by the provided context?
+    *   **Style**: Is the tone professional and appropriate?
+    *   **Safety**: Is the content safe and non-toxic?
+*   **Reinforcement Learning**: Uses the REINFORCE algorithm. The generator produces an answer, the discriminators score it, and these scores are used as rewards to update the generator's policy.
+
+### 3. Frontend (`frontend`)
+
+The user interface for the system.
+
+*   **Technology**: `pywebview` allows building a desktop app using web technologies (HTML/CSS/JS) while running a Python backend.
+*   **Features**:
+    *   **Chat Interface**: Similar to standard LLM chat UIs.
+    *   **Admin Dashboard**: For monitoring usage and managing users.
+    *   **Local Inference**: Runs the Python inference engine directly on the user's machine.
+
+## Design Decisions
+
+### Why TinyLlama?
+We chose TinyLlama-1.1B because it offers an excellent balance between performance and resource requirements. It can be fine-tuned on consumer hardware (like a single RTX 3090 or even lower with quantization), making the system accessible for smaller organizations.
+
+### Why Separate Discriminators?
+Using a single reward model can lead to "reward hacking" where the model optimizes for the score rather than the actual quality. By separating factuality, style, and safety, we can tune the weights of each reward component independently, ensuring a more balanced output.
+
+### Why Qwen 7B for Data Generation?
+Qwen 7B has shown superior performance in following complex instructions compared to other models in its size class. Its ability to generate structured Q&A pairs from unstructured text is key to our pipeline's success.
diff --git a/docs/data_generation_pipeline.md b/docs/data_generation_pipeline.md
new file mode 100644
index 0000000..03d5e92
--- /dev/null
+++ b/docs/data_generation_pipeline.md
@@ -0,0 +1,101 @@
+# Data Generation Pipeline
+
+The `data_generation_pipeline` is a standalone tool designed to transform raw policy documents into high-quality, validated Question-Answer pairs. These pairs serve as the training data for the Hallucination Reduction module.
+
+## 🌟 Features
+
+*   **PDF/TXT Support**: Extracts text from standard policy document formats.
+*   **Smart Chunking**: Splits documents into manageable chunks with overlap to ensure no context is lost at boundaries.
+*   **LLM-based Generation**: Uses **Qwen 7B** (quantized) to generate intelligent questions and answers.
+*   **Evidence Extraction**: Identifies the exact sentences in the source text that support the answer.
+*   **Strict Validation**: Automatically rejects Q&A pairs that contain hallucinations (e.g., referencing non-existent section numbers).
+*   **Deduplication**: Removes duplicate or highly similar questions using semantic similarity.
+
+## 🛠️ Setup & Installation
+
+The pipeline runs as a separate module.
+
+1.  Navigate to the directory:
+    ```bash
+    cd data_generation_pipeline/data-pipeline
+    ```
+
+2.  Install dependencies:
+    ```bash
+    pip install -r requirements.txt
+    ```
+
+## 📖 Usage
+
+### Command Line Interface (CLI)
+
+The primary way to use the pipeline is via the CLI.
+
+```bash
+python -m cli run --input <path_to_input_file> --output <path_to_output_json>
+```
+
+**Example:**
+```bash
+python -m cli run \
+    --input data/input/security_policy.pdf \
+    --output data/output/qa_dataset.json
+```
+
+### Input Data
+Place your raw documents in `data_generation_pipeline/data-pipeline/data/input/`.
+
+### Output Format
+The output is a JSON file containing a list of Q&A objects:
+
+```json
+[
+  {
+    "question": "What is the maximum data retention period?",
+    "answer": "The maximum data retention period is 7 years.",
+    "context": "...data shall be retained for 7 years...",
+    "evidence": ["data shall be retained for 7 years"],
+    "meta": {
+      "source": "security_policy.pdf",
+      "chunk_id": 12
+    }
+  }
+]
+```
+
+## ⚙️ Configuration
+
+Configuration files are located in `config/`.
+
+### `pipeline_config.yaml`
+Controls the processing logic.
+
+```yaml
+chunking:
+  chunk_size: 512       # Tokens per chunk
+  overlap: 128          # Overlap between chunks
+
+generation:
+  max_qa_per_chunk: 5   # Max questions to generate per chunk
+  temperature: 0.7      # Creativity of the model
+
+deduplication:
+  similarity_threshold: 0.85  # Threshold for considering questions duplicates
+```
+
+### `model_config.yaml`
+Controls the LLM settings.
+
+```yaml
+model_name: "Qwen/Qwen-7B-Chat"
+quantization: "4bit"    # Use 4-bit quantization for memory efficiency
+device: "cuda"          # Use GPU
+```
+
+## 🔍 Validation Logic
+
+The pipeline implements several validators in `src/validators.py`:
+
+1.  **Section Checker**: If the answer mentions "Section X.Y", it verifies that "Section X.Y" actually exists in the text chunk.
+2.  **Acronym Checker**: Ensures any acronyms used in the answer are defined or present in the context.
+3.  **Relevance Checker**: Uses a lightweight cross-encoder to verify the question is actually answered by the text.
diff --git a/docs/frontend.md b/docs/frontend.md
new file mode 100644
index 0000000..74a0439
--- /dev/null
+++ b/docs/frontend.md
@@ -0,0 +1,76 @@
+# Frontend Application
+
+The AI4Org frontend is a modern, cross-platform desktop application that allows users to interact with the trained hallucination reduction model. It is built using `pywebview`, which bridges Python logic with a web-based UI (HTML/CSS/JavaScript).
+
+## 🖥️ Features
+
+*   **Interactive Chat**: A familiar chat interface for asking questions and receiving RAG-enhanced answers.
+*   **Source Citations**: Answers include references to the specific policy documents and sections used.
+*   **User Management**: Secure login and registration system.
+*   **Admin Dashboard**: A restricted area for administrators to view usage statistics and manage users.
+*   **Document Upload**: Interface for uploading new policy documents to the system.
+
+## 📦 Installation & Setup
+
+1.  Navigate to the frontend directory:
+    ```bash
+    cd frontend
+    ```
+
+2.  Install dependencies:
+    ```bash
+    pip install -r requirements.txt
+    ```
+
+3.  Run the application:
+    ```bash
+    python main.py
+    ```
+
+## 📖 User Guide
+
+### Login / Register
+*   **New Users**: Click "Register" to create an account. Your data is stored locally in `user_history.json`.
+*   **Existing Users**: Enter your username and password to log in.
+
+### Chat Interface
+1.  Type your question in the input box at the bottom.
+2.  Press Enter or click the Send button.
+3.  The system will retrieve relevant context and generate an answer.
+4.  **Citations**: Click on the citation numbers (e.g., `[1]`) to see the source text.
+
+### Admin Dashboard
+*   **Access**: Click the "Admin" link in the navigation menu.
+*   **PIN Code**: The default admin PIN is `9999`.
+*   **Capabilities**:
+    *   View total number of users and queries.
+    *   See a list of recent queries and system responses.
+    *   Manage uploaded files.
+
+## 🔧 Technical Details
+
+### Architecture
+The frontend uses a Client-Server architecture, but running locally within a single process.
+
+*   **Python Backend (`main.py`)**:
+    *   Initializes the `pywebview` window.
+    *   Exposes a Python API class to the JavaScript frontend.
+    *   Handles calls to the `hallucination_reduction` inference engine.
+*   **Web Frontend (`html/`, `css/`, `script/`)**:
+    *   Standard web technologies.
+    *   Calls Python functions via `pywebview.api.function_name()`.
+
+### API Bridge
+The `Api` class in `main.py` defines the methods available to the frontend:
+
+*   `login(username, password)`
+*   `register(username, password)`
+*   `send_message(message)`: The core function that calls the ML model.
+*   `get_admin_stats()`
+*   `upload_file(file_content)`
+
+## 🎨 Customization
+
+*   **Styling**: Edit `css/style.css` to change the look and feel.
+*   **Layout**: Edit the HTML files in `html/`.
+*   **Logic**: Edit `script/app.js` for frontend logic or `main.py` for backend logic.
diff --git a/docs/hallucination_reduction.md b/docs/hallucination_reduction.md
new file mode 100644
index 0000000..fde8849
--- /dev/null
+++ b/docs/hallucination_reduction.md
@@ -0,0 +1,90 @@
+# Hallucination Reduction Module
+
+The `hallucination_reduction` module is the core machine learning component of AI4Org. It implements a sophisticated training pipeline designed to minimize hallucinations in Large Language Models.
+
+## 🧠 Model Architecture
+
+### Generator
+*   **Base Model**: `TinyLlama/TinyLlama-1.1B-Chat-v1.0`
+*   **Type**: Causal Language Model (CLM)
+*   **Role**: Generates answers based on the provided context and user question.
+
+### Discriminators
+The system uses three distinct binary classifiers based on `distilbert-base-uncased`:
+
+1.  **Factuality Discriminator**:
+    *   **Input**: `[CLS] context [SEP] answer [SEP]`
+    *   **Task**: Predicts if the answer is factually supported by the context.
+    *   **Label 1**: Factual / **Label 0**: Hallucinated
+
+2.  **Style Discriminator**:
+    *   **Input**: `[CLS] answer [SEP]`
+    *   **Task**: Predicts if the answer follows the desired professional style.
+    *   **Label 1**: Professional / **Label 0**: Unprofessional
+
+3.  **Safety Discriminator**:
+    *   **Input**: `[CLS] answer [SEP]`
+    *   **Task**: Predicts if the answer is safe and harmless.
+    *   **Label 1**: Safe / **Label 0**: Unsafe
+
+## 🔄 Training Pipeline
+
+The training process consists of three sequential stages:
+
+### 1. Discriminator Training
+Before we can use the discriminators to guide the generator, they must be trained themselves.
+*   **Data**: A labeled dataset of (context, answer, label) tuples.
+*   **Process**: Standard supervised classification training using Cross-Entropy Loss.
+
+### 2. Supervised Fine-Tuning (SFT)
+The generator is first fine-tuned on high-quality Q&A pairs to learn the basic task.
+*   **Data**: Validated Q&A pairs from the data generation pipeline.
+*   **Loss**: Standard Causal Language Modeling (CLM) loss (next-token prediction).
+
+### 3. Reinforcement Learning (RL)
+This is where the hallucination reduction happens.
+*   **Algorithm**: REINFORCE (Policy Gradient).
+*   **Process**:
+    1.  Generator produces an answer for a given prompt.
+    2.  Discriminators evaluate the answer and provide scores (0-1).
+    3.  **Reward Calculation**: $R = w_f \cdot S_{fact} + w_s \cdot S_{style} + w_{safe} \cdot S_{safe}$
+    4.  The generator's weights are updated to maximize this expected reward.
+
+## ⚙️ Configuration
+
+All hyperparameters are defined in `hallucination_reduction/config.py`.
+
+### Key Parameters
+
+| Parameter | Default | Description |
+|-----------|---------|-------------|
+| `SFT_EPOCHS` | 4 | Number of epochs for Supervised Fine-Tuning |
+| `DISC_EPOCHS` | 4 | Number of epochs for Discriminator training |
+| `RL_EPOCHS` | 4 | Number of epochs for RL training |
+| `MC_ROLLOUTS` | 6 | Monte Carlo rollouts for variance reduction in RL |
+| `FACT_WEIGHT` | 0.8 | Weight of the factuality reward (highest priority) |
+| `STYLE_WEIGHT` | 0.15 | Weight of the style reward |
+| `SAFETY_WEIGHT` | 0.05 | Weight of the safety reward |
+
+## 🚀 Usage
+
+### Training
+To run the full training pipeline:
+```bash
+python -m hallucination_reduction.main
+```
+
+### Inference
+To chat with the trained model:
+```bash
+python -m hallucination_reduction.inference
+```
+
+## 📂 File Structure
+
+*   `main.py`: Orchestrates the entire training workflow.
+*   `generator.py`: Wrapper class for the TinyLlama generator.
+*   `discriminator.py`: Wrapper class for the DistilBERT discriminators.
+*   `rl_utils.py`: Implementation of the REINFORCE algorithm and reward calculation.
+*   `retriever.py`: Handles semantic search and context retrieval.
+*   `data_utils.py`: Functions for loading and processing datasets.
diff --git a/frontend/CNAME b/frontend/CNAME
new file mode 100644
index 0000000..208536e
--- /dev/null
+++ b/frontend/CNAME
@@ -0,0 +1 @@
+www.aifororg.asd
diff --git a/frontend/README.md b/frontend/README.md
new file mode 100644
index 0000000..50ffc4d
--- /dev/null
+++ b/frontend/README.md
@@ -0,0 +1,26 @@
+# Reflect Clone Desktop (Python + HTML/CSS)
+
+A minimal Reflect-style hero page with a looping background video, wrapped as a desktop app using **pywebview** (Python).
+
+## Run
+
+1. Install Python 3.10+.
+2. Open terminal in this folder and run:
+   ```bash
+   pip install -r requirements.txt
+   python main.py
+   ```
+
+> Note: Put your looping video as `assets/bg.mp4`. A placeholder path is already referenced in `index.html`.
+
+## Build EXE (Windows)
+
+```bash
+pip install pyinstaller
+pyinstaller -F --add-data "index.html;." --add-data "styles.css;." --add-data "script.js;." --add-data "assets;assets" main.py
+```
+The built exe will be in `dist/main.exe`.
+
+## Customize
+- Edit text, links, and buttons in `index.html`.
+- Tweak colors and glow in `styles.css`.
diff --git a/data_cleaning_pipeline/__init__.py b/frontend/__init__.py
similarity index 100%
rename from data_cleaning_pipeline/__init__.py
rename to frontend/__init__.py
diff --git a/frontend/app.py b/frontend/app.py
new file mode 100644
index 0000000..eae705c
--- /dev/null
+++ b/frontend/app.py
@@ -0,0 +1,24 @@
+import os
+
+import webview
+
+
+def create_window():
+    current_dir = os.path.dirname(os.path.abspath(__file__))
+    html_path = os.path.join(current_dir, "index.html")
+
+    window = webview.create_window(
+        "Your Personal Intelligence Platform",
+        url=html_path,
+        width=900,
+        height=700,
+        resizable=True,
+        text_select=True,
+    )
+
+    return window
+
+
+if __name__ == "__main__":
+    window = create_window()
+    webview.start()
diff --git a/frontend/assets/images/bg.mp4 b/frontend/assets/images/bg.mp4
new file mode 100644
index 0000000..18cd8a9
Binary files /dev/null and b/frontend/assets/images/bg.mp4 differ
diff --git a/frontend/assets/images/bg2.mp4 b/frontend/assets/images/bg2.mp4
new file mode 100644
index 0000000..3d0e0e1
Binary files /dev/null and b/frontend/assets/images/bg2.mp4 differ
diff --git a/frontend/assets/images/bg3.mp4 b/frontend/assets/images/bg3.mp4
new file mode 100644
index 0000000..c9600e6
Binary files /dev/null and b/frontend/assets/images/bg3.mp4 differ
diff --git a/frontend/assets/images/data-cleaning.png b/frontend/assets/images/data-cleaning.png
new file mode 100644
index 0000000..d44af47
Binary files /dev/null and b/frontend/assets/images/data-cleaning.png differ
diff --git a/frontend/assets/images/data-collection.png b/frontend/assets/images/data-collection.png
new file mode 100644
index 0000000..2f4714c
Binary files /dev/null and b/frontend/assets/images/data-collection.png differ
diff --git a/frontend/assets/images/data-processing.png b/frontend/assets/images/data-processing.png
new file mode 100644
index 0000000..0d008a8
Binary files /dev/null and b/frontend/assets/images/data-processing.png differ
diff --git a/frontend/assets/images/deep-learning.png b/frontend/assets/images/deep-learning.png
new file mode 100644
index 0000000..4aeeb3b
Binary files /dev/null and b/frontend/assets/images/deep-learning.png differ
diff --git a/frontend/assets/images/evaluation.png b/frontend/assets/images/evaluation.png
new file mode 100644
index 0000000..54f615b
Binary files /dev/null and b/frontend/assets/images/evaluation.png differ
diff --git a/frontend/assets/images/feature.png b/frontend/assets/images/feature.png
new file mode 100644
index 0000000..9d61470
Binary files /dev/null and b/frontend/assets/images/feature.png differ
diff --git a/frontend/assets/images/file-upload.png b/frontend/assets/images/file-upload.png
new file mode 100644
index 0000000..3b52b72
Binary files /dev/null and b/frontend/assets/images/file-upload.png differ
diff --git a/frontend/assets/images/logo.jpeg b/frontend/assets/images/logo.jpeg
new file mode 100644
index 0000000..26a2bdc
Binary files /dev/null and b/frontend/assets/images/logo.jpeg differ
diff --git a/frontend/assets/images/logo.png b/frontend/assets/images/logo.png
new file mode 100644
index 0000000..f120f81
Binary files /dev/null and b/frontend/assets/images/logo.png differ
diff --git a/frontend/assets/images/monitoring.png b/frontend/assets/images/monitoring.png
new file mode 100644
index 0000000..e286214
Binary files /dev/null and b/frontend/assets/images/monitoring.png differ
diff --git a/frontend/assets/js/script.js b/frontend/assets/js/script.js
new file mode 100644
index 0000000..c210ca1
--- /dev/null
+++ b/frontend/assets/js/script.js
@@ -0,0 +1,67 @@
+// Optional: small UX niceties
+document.addEventListener('click', (e)=>{
+  const pill = document.querySelector('.ai-pill');
+  if(e.target === pill){
+    pill.classList.add('pulse');
+    setTimeout(()=>pill.classList.remove('pulse'), 700);
+  }
+});
+
+// Arrays of headings and slogans
+const headings = [
+  "TRUST IN PRIVACY",
+  "YOUR DATA, YOUR POWER",
+  "PRIVACY REDEFINED",
+  "SECURE BY DESIGN",
+  "OWN YOUR INFORMATION"
+];
+
+const slogans = [
+  "Your data, your control — never stored on cloud.",
+  "No servers. No risks. Your data lives only with you.",
+  "Privacy first. We don’t keep your data, you do.",
+  "Your data is safe — offline, secure, and only yours.",
+  "No tracking. No storing. 100% yours.",
+  "Your digital life, protected. Nothing leaves your device.",
+  "We never see your data — and never will.",
+  "Trust in privacy: your information stays with you.",
+  "Zero cloud. Zero compromise. Full privacy.",
+  "Your data is safe, forever in your hands."
+];
+
+// Get the heading, slogan text, and video elements
+// const securityHeading = document.getElementById('security-heading');
+const securityHeading = document.getElementById('security-flow');
+
+const sloganText = document.getElementById('slogan-text');
+const securityVideo = document.getElementById('security-video');
+
+// Set video playback speed (1.0 is normal, 1.5 is 50% faster, 0.5 is 50% slower, etc.)
+securityVideo.playbackRate = 2; // Adjust this value as needed
+
+// Function to change heading and slogan
+function changeContent() {
+  let headingIndex = 0;
+  let sloganIndex = 0;
+
+  setInterval(() => {
+    // Fade out both heading and slogan
+    securityHeading.style.opacity = 0;
+    sloganText.style.opacity = 0;
+
+    setTimeout(() => {
+      // Update heading and slogan
+      headingIndex = (headingIndex + 1) % headings.length;
+      sloganIndex = (sloganIndex + 1) % slogans.length;
+      securityHeading.textContent = headings[headingIndex];
+      sloganText.textContent = slogans[sloganIndex];
+
+      // Fade in both heading and slogan
+      securityHeading.style.opacity = 1;
+      sloganText.style.opacity = 1;
+    }, 100); // Wait for fade out before changing text
+  }, 800); // Change every 3 seconds
+}
+
+// Start the content cycle
+changeContent();
diff --git a/frontend/assets/style/styles.css b/frontend/assets/style/styles.css
new file mode 100644
index 0000000..d7a787d
--- /dev/null
+++ b/frontend/assets/style/styles.css
@@ -0,0 +1,608 @@
+*{box-sizing:border-box}
+:root{
+  --bg:#0b0a14;
+  --text:#e8e6ff;
+  --muted:#b7b5d3;
+  --glass:rgba(255,255,255,0.06);
+  --accent:#6c53ff;
+  --accent-2:#b388ff;
+}
+*{
+  font-family: Georgia, 'Times New Roman', Times, serif ;
+}
+html,body{height:100%; margin:0; padding:0;}
+body{
+  font-family: ui-sans-serif, system-ui, -apple-system, Segoe UI, Roboto, Helvetica, Arial, Apple Color Emoji, Segoe UI Emoji;
+  color:var(--text);
+  background:var(--bg);
+  overflow-x:hidden;
+}
+
+/* Background video */
+#bgVideo{
+  position:fixed;
+  inset:0;
+  width:100vw;height:100%;
+  object-fit:cover;
+  /* filter:brightness(0.55) saturate(1.1) contrast(1.05); */
+  z-index:-2;
+}
+
+/* Overlay glow + stars */
+.overlay{
+  position:fixed; inset:0; z-index:-1;
+  background:
+    radial-gradient(60rem 25rem at 50% 80%, rgba(150, 97, 255, 0.55), rgba(108,83,255,0.15) 35%, rgba(0,0,0,0) 65%),
+    radial-gradient(1400px 600px at 50% 110%, rgba(255,255,255,0.22), rgba(255,255,255,0.0) 60%);
+  pointer-events:none;
+}
+.overlay::after{
+  content:''; position:absolute; inset:0;
+  background-image: radial-gradient(rgba(255,255,255,0.55) 1px, transparent 1px);
+  background-size: 3px 3px;
+  opacity:0.08;
+  mask-image: radial-gradient(60rem 30rem at 50% 70%, black, transparent 70%);
+}
+
+/* Navbar */
+.nav{
+  position:fixed; top:0; left:0; right:0;
+  display:flex; align-items:center; justify-content:space-between;
+  padding:20px 32px;
+  backdrop-filter: blur(10px);
+  background: linear-gradient(to bottom, rgba(0,0,0,0.35), rgba(0,0,0,0.0));
+  z-index: 100;
+
+}
+.brand{display:flex; align-items:center; gap:.6rem; font-weight:700; color:#fff}
+.brand-logo{
+  width:28px; height:28px; border-radius:10px;
+  display:grid; place-items:center;
+  background: linear-gradient(135deg, var(--accent), var(--accent-2));
+  color:white; font-size:14px;
+}
+.links{display:flex; gap:36px; font-size:1.35rem;}
+.links a{color:#fff; text-decoration:none; font-weight:700}
+.links a:hover{color:var(--accent-2);}
+.auth{display:flex; gap:10px}
+.btn{
+  border:none; border-radius:999px;
+  padding:12px 18px; font-weight:700; cursor:pointer;
+}
+.auth .btn.ghost{background: linear-gradient(135deg, var(--accent), var(--accent-2)); color:#fff; border:none;}
+.auth .btn.ghost:hover{filter:brightness(1.06); box-shadow:0 10px 26px rgba(108,83,255,.45)}
+.btn.solid{
+  position: relative;
+  background: linear-gradient(135deg, var(--accent), var(--accent-2));
+  color:white; box-shadow: 0 10px 26px rgba(108,83,255,.45);
+  padding:14px 22px;
+}
+.btn.solid::before{
+  content:''; position:absolute; inset:-2px; border-radius:999px;
+  padding:2px; background:linear-gradient(135deg, rgba(255,255,255,.25), rgba(108,83,255,.35));
+  -webkit-mask:linear-gradient(#000 0 0) content-box, linear-gradient(#000 0 0);
+  -webkit-mask-composite:xor; mask-composite:exclude;
+}
+.btn.solid:hover{filter:brightness(1.06); transform: translateY(-1px)}
+
+/* Hero */
+.hero{
+  min-height:80vh;
+  display:flex; flex-direction:column; align-items:center; justify-content:center;
+  text-align:center; gap:18px; padding:0 18px;
+}
+.hero h1{
+  font-size: clamp(3rem, 9vw, 7rem);
+  line-height: 1.02;
+  letter-spacing: .5px;
+  text-shadow: 0 12px 50px rgba(108,83,255,.55);
+}
+.ai-pill{
+  border-radius:999px; padding:8px 14px; border:1px solid rgba(255,255,255,.15);
+  background: rgba(0,0,0,.35); color:#ebe9ff; font-weight:600; letter-spacing:.1px;
+  backdrop-filter: blur(6px);
+}
+h1{
+  margin:0; font-size: clamp(2.2rem, 5vw, 4.2rem); line-height:1.05;
+  text-shadow: 0 8px 40px rgba(108,83,255,.45);
+}
+.sub{color:var(--muted); font-size:1.1rem}
+
+/* Cards Section */
+.cards {
+  position: relative;
+  /* margin-top: 100px; */
+  /* min-height: 250vh;  */
+  display: flex;
+  flex-direction: column;
+  align-items: center;
+  justify-content: center;
+}
+.card {
+  height:500px;
+  position: sticky;
+  top: 100px;
+  width: min(700px, 90vw);
+  padding: 40px;
+  margin-bottom: 80px;
+  border-radius: 20px;
+  background: rgba(255, 255, 255, 0.08);
+  backdrop-filter: blur(12px);
+  border: 1px solid rgba(255, 255, 255, 0.15);
+  font-size: 1.4rem;
+ /* font-weight: 600; */
+  color: white;
+  text-align: justify;
+  box-shadow: 0 12px 30px rgba(0,0,0,0.35);
+  display: flex;
+  flex-direction: column;
+  align-items: center;
+  justify-content: center;
+}
+
+/* Responsive */
+@media (max-width: 820px){
+  .links{display:none}
+}
+/* Features Section */
+.features {
+  display: grid;
+  grid-template-columns: repeat(4, 1fr);
+  gap: 24px;
+  padding: 40px 20px;
+  /* max-width: 1200px; */
+  width:100%;
+  background-color: black;
+
+  margin: 0 auto;
+  /* margin-top: 100px; */
+}
+
+/* Responsive columns for How It Works */
+@media (max-width: 1024px){
+  .features{ grid-template-columns: repeat(2, 1fr); }
+}
+@media (max-width: 640px){
+  .features{ grid-template-columns: 1fr; }
+}
+
+.feature-card {
+  height: 220px;
+  padding: 20px;
+  border-radius: 15px;
+  background: rgba(255, 255, 255, 0.08);
+  backdrop-filter: blur(12px);
+  border: 1px solid rgba(255, 255, 255, 0.15);
+  text-align: center;
+  display: flex;
+  flex-direction: column;
+  align-items: center;
+  justify-content: center;
+  color: var(--text);
+  transition: transform 0.2s;
+}
+
+
+    /*  */
+
+    #github-link:hover {
+      background: #0366d6;
+    }
+
+    #linkedin-link {
+      text-decoration: none;
+      padding: 6px 12px;
+      border-radius: 6px;
+      font-size: 14px;
+      color: white;
+      background: #0A66C2;
+      transition: background 0.3s;
+    }
+
+    #linkedin-link:hover {
+      background: #004182;
+    }
+
+    @keyframes scroll {
+      0%   { transform: translateX(0); }
+      100% { transform: translateX(-50%); }
+    }
+
+.feature-card:hover {
+  box-shadow: 1px 1px 10px #40269F;
+  transform: translateY(-5px);
+}
+
+.feature-card .icon {
+  font-size: 2rem;
+  margin-bottom: 10px;
+}
+
+.feature-card h3 {
+  margin: 10px 0;
+  font-size: 1.2rem;
+  color: var(--text);
+}
+
+.feature-card p {
+  margin: 0;
+  font-size: 0.9rem;
+  color: var(--muted);
+}
+/* Security Section */
+.security {
+  min-height: 80vh;
+  display: flex;
+  align-items: center;
+  justify-content: center;
+  text-align: center;
+  position: relative;
+  overflow: hidden;
+}
+.contact-video{
+   position: absolute;
+  top: 0;
+  left: 0;
+  width: 100%;
+  height: 100%;
+  object-fit: cover;
+  z-index: -2;
+}
+.security-video {
+  position: absolute;
+  top: 0;
+  left: 0;
+  width: 100%;
+  height: 100%;
+  object-fit: cover;
+  z-index: -2;
+}
+
+.security-content {
+  padding: 20px;
+  position: relative;
+  z-index: 1;
+}
+
+.lock-icon {
+  width: 100px; /* Adjust size as needed */
+  height: auto;
+  margin-bottom: 10px;
+}
+
+.security-label {
+  display: block;
+  font-size: 0.9rem;
+  color: #b7b5d3;
+  margin-bottom: 10px;
+  text-transform: uppercase;
+  letter-spacing: 1px;
+}
+
+.security h2 {
+  font-size: clamp(2.2rem, 5vw, 4.2rem);
+  line-height: 1.05;
+  color: #e8e6ff;
+  margin: 0 0 15px;
+  text-shadow: 0 8px 40px rgba(108, 83, 255, 0.45);
+}
+
+.security-text {
+  font-size: 1.1rem;
+  color: #b7b5d3;
+  max-width: 600px;
+  margin: 0 auto 20px;
+}
+
+/* Overlay for pattern effect */
+.security::before {
+  content: '';
+  position: absolute;
+  top: 0;
+  left: 0;
+  width: 100%;
+  height: 100%;
+  background: url('assets/security-pattern.png') repeat; /* Replace with actual pattern image URL */
+  opacity: 0.5; /* Adjust opacity to match the design */
+  z-index: -1;
+}
+
+
+/* Contact Us Section */
+.contact {
+  min-height: 100vh;
+  /* background-color: #000; */
+  display: flex;
+  align-items: center;
+  justify-content: center;
+  text-align: center;
+  position: relative;
+  padding: 40px 20px;
+  color: #e8e6ff;
+}
+
+.contact-content {
+  max-width: 600px;
+  width: 100%;
+  padding: 30px;
+  background: linear-gradient(135deg, rgba(0, 0, 0, 0.9), rgba(20, 20, 20, 0.9));
+  border-radius: 15px;
+  box-shadow: 1px 1px 30px #6d53ff74;
+}
+
+.contact-title {
+  font-size: clamp(2.2rem, 5vw, 4.2rem);
+  line-height: 1.05;
+  margin: 0 0 20px;
+  text-shadow: 0 8px 40px rgba(108, 83, 255, 0.45);
+  position: relative;
+}
+
+.contact-title::after {
+  content: '';
+  position: absolute;
+  bottom: -5px;
+  left: 50%;
+  transform: translateX(-50%);
+  width: 50px;
+  height: 3px;
+  background: linear-gradient(90deg, #6c53ff, #b388ff);
+  border-radius: 2px;
+}
+
+.contact-text {
+  font-size: 1.1rem;
+  color: #b7b5d3;
+  margin-bottom: 30px;
+  padding: 0 20px;
+}
+
+.contact-form {
+  display: flex;
+  flex-direction: column;
+  gap: 15px;
+  padding: 0 20px;
+}
+
+.input-field {
+  padding: 12px 15px;
+  border: 1px solid rgba(255, 255, 255, 0.15);
+  border-radius: 8px;
+  background: rgba(255, 255, 255, 0.05);
+  color: #e8e6ff;
+  font-size: 1rem;
+  transition: border-color 0.3s, background 0.3s;
+}
+
+.input-field:focus {
+  border-color: #6c53ff;
+  background: rgba(255, 255, 255, 0.1);
+  outline: none;
+}
+
+.textarea {
+  min-height: 120px;
+  resize: vertical;
+}
+
+.btn-animated {
+  position: relative;
+  overflow: hidden;
+  z-index: 1;
+}
+
+.btn-animated::after {
+  content: '';
+  position: absolute;
+  top: 0;
+  left: -100%;
+  width: 100%;
+  height: 100%;
+  background: linear-gradient(120deg, transparent, rgba(255, 255, 255, 0.2), transparent);
+  animation: shine 2s infinite;
+  z-index: -1;
+}
+
+@keyframes shine {
+  0% { left: -100%; }
+  20% { left: 100%; }
+  100% { left: 100%; }
+}
+
+.contact-info {
+  font-size: 0.9rem;
+  color: #b7b5d3;
+  margin-top: 20px;
+  letter-spacing: 1px;
+}
+
+/* Footer */
+.footer {
+  background: linear-gradient(135deg, #0b0a14, #1a1a2e);
+  color: #e8e6ff;
+  padding: 40px 20px;
+  position: relative;
+  z-index: 1;
+}
+
+.footer-content {
+  display: flex;
+  justify-content: space-around;
+  flex-wrap: wrap;
+  gap: 30px;
+  max-width: 1200px;
+  margin: 0 auto;
+}
+
+.footer-section {
+  flex: 1;
+  min-width: 200px;
+}
+
+.footer-section h3 {
+  font-size: 1.2rem;
+  margin-bottom: 15px;
+  color: #b7b5d3;
+  text-transform: uppercase;
+  letter-spacing: 1px;
+}
+
+.footer-section ul {
+  list-style: none;
+  padding: 0;
+}
+
+.footer-section ul li {
+  margin-bottom: 10px;
+}
+
+.footer-section ul li a {
+  color: #b7b5d3;
+  text-decoration: none;
+  transition: color 0.3s;
+}
+
+.footer-section ul li a:hover {
+  color: #6c53ff;
+}
+
+.footer-section p {
+  font-size: 0.9rem;
+  color: #b7b5d3;
+  margin: 5px 0;
+}
+
+.social-links {
+  display: flex;
+  gap: 15px;
+}
+
+.social-links a {
+  color: #b7b5d3;
+  text-decoration: none;
+  font-size: 0.9rem;
+  transition: color 0.3s;
+}
+
+.social-links a:hover {
+  color: #6c53ff;
+}
+
+.footer-bottom {
+  text-align: center;
+  margin-top: 20px;
+  padding-top: 20px;
+  border-top: 1px solid rgba(255, 255, 255, 0.1);
+}
+
+.footer-bottom p {
+  font-size: 0.8rem;
+  color: #b7b5d3;
+}
+/* .p1{
+  font-size: 18px;
+  font-weight: 300;
+} */
+
+.how_it_work{
+  background-color: black;
+  display: flex;
+  justify-content: center;
+  align-items: center;
+  padding: 20px;
+}
+.img_icon{
+    filter: invert(100%);
+    height: 50px;
+    width: 50px;
+}
+
+
+
+    /* Team Section */
+    .team-section {
+      width: 100%;
+      padding: 80px 0;
+      display: flex;
+      justify-content: center;
+      align-items: center;
+      flex-direction: column;
+      overflow: hidden;
+      position: relative;
+      background: rgba(0, 0, 0, 0.7);
+    }
+
+    .team-title {
+      text-align: center;
+      margin-bottom: 40px;
+      font-size: 2.5rem;
+    }
+
+    .team-container {
+      width: 100%;
+      overflow: hidden;
+      position: relative;
+    }
+
+    .team-scroll {
+      display: flex;
+      animation: scroll 30s linear infinite;
+      width: max-content;
+    }
+
+    .team-member {
+      min-width: 300px;
+      height: 350px;
+      background: rgba(255, 255, 255, 0.08);
+      backdrop-filter: blur(12px);
+      border: 1px solid rgba(255, 255, 255, 0.15);
+      margin: 0 20px;
+      border-radius: 12px;
+      display: flex;
+      flex-direction: column;
+      justify-content: center;
+      align-items: center;
+      text-align: center;
+      transition: transform 0.3s;
+      padding: 20px;
+    }
+
+    .team-member:hover {
+      /* transform: scale(1.05); */
+      box-shadow: 0 0 20px rgba(108, 83, 255, 0.5);
+    }
+
+    .member-name {
+      margin: 15px 0;
+      font-size: 1.5rem;
+      font-weight: bold;
+    }
+
+    .member-links {
+      margin-top: 20px;
+      display: flex;
+      gap: 15px;
+    }
+
+    .member-link {
+      display: inline-flex;
+      align-items: center;
+      justify-content: center;
+      width: 40px;
+      height: 40px;
+      border-radius: 50%;
+      background: var(--accent);
+      color: white;
+      text-decoration: none;
+      transition: all 0.3s;
+    }
+
+    .member-link:hover {
+      background: var(--accent-2);
+      /* transform: translateY(-3px); */
+    }
+
+    @keyframes scroll {
+      0% { transform: translateX(0); }
+      100% { transform: translateX(-50%); }
+    }
diff --git a/frontend/css/chat.css b/frontend/css/chat.css
new file mode 100644
index 0000000..e2be874
--- /dev/null
+++ b/frontend/css/chat.css
@@ -0,0 +1,945 @@
+/* Modal Styles */
+.modal {
+    position: fixed;
+    z-index: 1000;
+    left: 0;
+    top: 0;
+    width: 100%;
+    height: 100%;
+    background-color: rgba(0, 0, 0, 0.8);
+    display: flex;
+    align-items: center;
+    justify-content: center;
+    backdrop-filter: blur(5px);
+}
+
+.modal-content {
+    background: linear-gradient(135deg, var(--gradient-start), var(--gradient-mid));
+    border-radius: 15px;
+    width: 80%;
+    max-width: 800px;
+    max-height: 80vh;
+    overflow: hidden;
+    box-shadow: 0 20px 40px rgba(0, 0, 0, 0.5);
+    border: 1px solid rgba(255, 255, 255, 0.1);
+}
+
+.modal-header {
+    padding: 20px;
+    background: rgba(155, 89, 182, 0.1);
+    border-bottom: 1px solid rgba(255, 255, 255, 0.1);
+    display: flex;
+    justify-content: space-between;
+    align-items: center;
+}
+
+.modal-header h2 {
+    color: #fff;
+    margin: 0;
+    font-size: 24px;
+    font-weight: 600;
+}
+
+.close {
+    color: #fff;
+    font-size: 28px;
+    font-weight: bold;
+    cursor: pointer;
+    transition: color 0.3s ease;
+    width: 30px;
+    height: 30px;
+    display: flex;
+    align-items: center;
+    justify-content: center;
+}
+
+.close:hover {
+    color: #e74c3c;
+}
+
+.modal-body {
+    padding: 20px;
+    max-height: 60vh;
+    overflow-y: auto;
+}
+
+/* History Message Styles */
+.history-message {
+    margin-bottom: 15px;
+    padding: 12px 16px;
+    border-radius: 10px;
+    background: rgba(255, 255, 255, 0.05);
+    border-left: 3px solid var(--primary-color);
+    transition: all 0.3s ease;
+}
+
+.history-message:hover {
+    background: rgba(255, 255, 255, 0.08);
+    transform: translateX(5px);
+}
+
+.history-message.user {
+    background: rgba(0, 0, 0, 0.3);
+    border-left-color: #bb8fce;
+}
+
+.history-message.ai {
+    background: rgba(155, 89, 182, 0.1);
+    border-left-color: var(--primary-color);
+}
+
+.history-timestamp {
+    font-size: 12px;
+    color: rgba(255, 255, 255, 0.5);
+    margin-top: 5px;
+    display: flex;
+    align-items: center;
+    gap: 5px;
+}
+
+.history-timestamp svg {
+    width: 12px;
+    height: 12px;
+    fill: rgba(255, 255, 255, 0.5);
+}
+
+.no-history {
+    text-align: center;
+    color: rgba(255, 255, 255, 0.7);
+    font-style: italic;
+    padding: 40px;
+    display: flex;
+    flex-direction: column;
+    align-items: center;
+    gap: 10px;
+}
+
+.no-history svg {
+    width: 48px;
+    height: 48px;
+    fill: rgba(255, 255, 255, 0.3);
+}
+
+/* Settings Modal Styles */
+.settings-section {
+    margin-bottom: 30px;
+    padding: 20px;
+    background: rgba(255, 255, 255, 0.05);
+    border-radius: 10px;
+    border: 1px solid rgba(255, 255, 255, 0.1);
+}
+
+.settings-section h3 {
+    color: #fff;
+    margin-bottom: 15px;
+    font-size: 18px;
+    display: flex;
+    align-items: center;
+    gap: 10px;
+}
+
+.settings-section h3 svg {
+    width: 20px;
+    height: 20px;
+    fill: var(--primary-color);
+}
+
+.theme-options {
+    display: flex;
+    gap: 20px;
+    justify-content: center;
+    flex-wrap: wrap;
+}
+
+.theme-option {
+    display: flex;
+    align-items: center;
+    cursor: pointer;
+    padding: 10px;
+    border-radius: 8px;
+    transition: all 0.3s ease;
+}
+
+.theme-option:hover {
+    background: rgba(255, 255, 255, 0.1);
+}
+
+.theme-option input[type="radio"] {
+    margin-right: 10px;
+    accent-color: var(--primary-color);
+}
+
+.theme-preview {
+    padding: 12px 20px;
+    border-radius: 6px;
+    font-weight: 500;
+    color: white;
+    text-align: center;
+    min-width: 100px;
+    transition: all 0.3s ease;
+    border: 2px solid transparent;
+}
+
+.theme-option input:checked + .theme-preview {
+    border-color: var(--primary-color);
+    box-shadow: 0 0 15px rgba(155, 89, 182, 0.3);
+}
+
+.dark-theme {
+    background: linear-gradient(135deg, var(--gradient-start), var(--gradient-mid), var(--gradient-end));
+}
+
+.light-theme {
+    background: linear-gradient(135deg, #f8f9fa, #e9ecef, #dee2e6);
+    color: #333;
+}
+
+.font-size-controls {
+    display: flex;
+    flex-direction: column;
+    gap: 15px;
+}
+
+.font-size-controls label {
+    color: #fff;
+    font-weight: 500;
+    display: flex;
+    align-items: center;
+    gap: 10px;
+}
+
+.font-size-controls label svg {
+    width: 18px;
+    height: 18px;
+    fill: var(--primary-color);
+}
+
+#fontSizeSlider {
+    width: 100%;
+    height: 6px;
+    border-radius: 3px;
+    background: rgba(255, 255, 255, 0.2);
+    outline: none;
+    -webkit-appearance: none;
+}
+
+#fontSizeSlider::-webkit-slider-thumb {
+    -webkit-appearance: none;
+    appearance: none;
+    width: 20px;
+    height: 20px;
+    border-radius: 50%;
+    background: var(--primary-color);
+    cursor: pointer;
+    box-shadow: 0 2px 6px rgba(0, 0, 0, 0.3);
+    border: 2px solid white;
+}
+
+#fontSizeSlider::-moz-range-thumb {
+    width: 20px;
+    height: 20px;
+    border-radius: 50%;
+    background: var(--primary-color);
+    cursor: pointer;
+    box-shadow: 0 2px 6px rgba(0, 0, 0, 0.3);
+    border: 2px solid white;
+}
+
+.save-btn, .reset-btn {
+    padding: 12px 24px;
+    border: none;
+    border-radius: 8px;
+    cursor: pointer;
+    font-weight: 600;
+    margin-right: 10px;
+    transition: all 0.3s ease;
+    display: flex;
+    align-items: center;
+    gap: 8px;
+}
+
+.save-btn {
+    background: linear-gradient(45deg, var(--primary-color), #bb8fce);
+    color: white;
+}
+
+.save-btn:hover {
+    transform: translateY(-2px);
+    box-shadow: 0 4px 12px rgba(155, 89, 182, 0.4);
+}
+
+.save-btn svg {
+    width: 16px;
+    height: 16px;
+    fill: white;
+}
+
+.reset-btn {
+    background: rgba(231, 76, 60, 0.2);
+    color: #e74c3c;
+    border: 1px solid #e74c3c;
+}
+
+.reset-btn:hover {
+    background: rgba(231, 76, 60, 0.3);
+    transform: translateY(-2px);
+}
+
+.reset-btn svg {
+    width: 16px;
+    height: 16px;
+    fill: #e74c3c;
+}
+
+/* Theme Classes */
+.theme-light {
+    background: linear-gradient(135deg, #ffffff, #f8f9fa, #e9ecef) !important;
+    color: #2c3e50 !important;
+}
+
+.theme-light .sidebar {
+    background: rgba(255, 255, 255, 0.98) !important;
+    color: #2c3e50 !important;
+    box-shadow: 3px 0 15px rgba(0, 0, 0, 0.1) !important;
+}
+
+.theme-light .chat-container {
+    background: rgba(255, 255, 255, 0.9) !important;
+    color: #2c3e50 !important;
+    box-shadow: inset 0 0 15px rgba(0, 0, 0, 0.1) !important;
+}
+
+.theme-light .message {
+    color: #2c3e50 !important;
+}
+
+.theme-light .user-message {
+    background: rgba(155, 89, 182, 0.1) !important;
+    color: #2c3e50 !important;
+}
+
+.theme-light .ai-message {
+    background: rgba(155, 89, 182, 0.15) !important;
+    color: #2c3e50 !important;
+}
+
+.theme-light .nav-item {
+    color: #2c3e50 !important;
+}
+
+.theme-light .nav-item:hover {
+    background: rgba(155, 89, 182, 0.1) !important;
+}
+
+.theme-light .nav-item.active {
+    background: rgba(155, 89, 182, 0.2) !important;
+}
+
+.theme-light .input-field {
+    background: rgba(255, 255, 255, 0.8) !important;
+    color: #2c3e50 !important;
+    border: 1px solid rgba(0, 0, 0, 0.1) !important;
+}
+
+.theme-light .input-field::placeholder {
+    color: rgba(44, 62, 80, 0.6) !important;
+}
+
+.theme-light .user-name {
+    color: #2c3e50 !important;
+}
+
+.theme-light .user-email {
+    color: rgba(44, 62, 80, 0.7) !important;
+}
+
+/* History Modal Header Actions */
+.header-actions {
+    display: flex;
+    align-items: center;
+    gap: 15px;
+}
+
+.clear-history-btn {
+    background: rgba(231, 76, 60, 0.2);
+    color: #e74c3c;
+    border: 1px solid #e74c3c;
+    padding: 8px 16px;
+    border-radius: 6px;
+    cursor: pointer;
+    font-size: 14px;
+    transition: all 0.3s ease;
+    display: flex;
+    align-items: center;
+    gap: 8px;
+}
+
+.clear-history-btn:hover {
+    background: rgba(231, 76, 60, 0.3);
+    transform: translateY(-2px);
+}
+
+.clear-history-btn svg {
+    width: 16px;
+    height: 16px;
+    fill: currentColor;
+}
+
+/* Help Center Styles */
+.help-section {
+    margin-bottom: 30px;
+    padding: 20px;
+    background: rgba(255, 255, 255, 0.05);
+    border-radius: 10px;
+    border: 1px solid rgba(255, 255, 255, 0.1);
+}
+
+.help-section h3 {
+    color: #fff;
+    margin-bottom: 15px;
+    font-size: 18px;
+    display: flex;
+    align-items: center;
+    gap: 10px;
+}
+
+.help-section h3 svg {
+    width: 20px;
+    height: 20px;
+    fill: var(--primary-color);
+}
+
+.help-items {
+    display: flex;
+    flex-direction: column;
+    gap: 15px;
+}
+
+.help-item {
+    display: flex;
+    align-items: flex-start;
+    gap: 15px;
+    padding: 15px;
+    background: rgba(255, 255, 255, 0.03);
+    border-radius: 8px;
+    border-left: 3px solid var(--primary-color);
+    transition: all 0.3s ease;
+}
+
+.help-item:hover {
+    background: rgba(255, 255, 255, 0.08);
+    transform: translateX(5px);
+}
+
+.help-item svg {
+    width: 24px;
+    height: 24px;
+    fill: var(--primary-color);
+    margin-top: 2px;
+    flex-shrink: 0;
+}
+
+.help-item strong {
+    color: #fff;
+    display: block;
+    margin-bottom: 5px;
+    font-size: 16px;
+}
+
+.help-item p {
+    color: rgba(255, 255, 255, 0.8);
+    margin: 0;
+    line-height: 1.5;
+    font-size: 14px;
+}
+
+/* Feedback Form Styles */
+.feedback-form {
+    display: flex;
+    flex-direction: column;
+    gap: 15px;
+}
+
+#feedbackText {
+    width: 100%;
+    padding: 15px;
+    border: 1px solid rgba(255, 255, 255, 0.2);
+    border-radius: 8px;
+    background: rgba(255, 255, 255, 0.05);
+    color: #fff;
+    font-size: 14px;
+    resize: vertical;
+    min-height: 100px;
+    font-family: inherit;
+    transition: all 0.3s ease;
+}
+
+#feedbackText::placeholder {
+    color: rgba(255, 255, 255, 0.5);
+}
+
+#feedbackText:focus {
+    outline: none;
+    border-color: var(--primary-color);
+    box-shadow: 0 0 0 2px rgba(155, 89, 182, 0.2);
+    background: rgba(255, 255, 255, 0.08);
+}
+
+.feedback-actions {
+    display: flex;
+    align-items: center;
+    justify-content: space-between;
+    flex-wrap: wrap;
+    gap: 10px;
+}
+
+.submit-feedback-btn {
+    background: linear-gradient(45deg, var(--primary-color), #bb8fce);
+    color: white;
+    border: none;
+    padding: 12px 24px;
+    border-radius: 8px;
+    cursor: pointer;
+    font-weight: 600;
+    transition: all 0.3s ease;
+    display: flex;
+    align-items: center;
+    gap: 8px;
+}
+
+.submit-feedback-btn:hover {
+    transform: translateY(-2px);
+    box-shadow: 0 4px 12px rgba(155, 89, 182, 0.4);
+}
+
+.submit-feedback-btn svg {
+    width: 16px;
+    height: 16px;
+    fill: white;
+}
+
+.feedback-note {
+    color: rgba(255, 255, 255, 0.6);
+    font-size: 12px;
+    font-style: italic;
+}
+
+/* Notification System */
+.notification {
+    position: fixed;
+    top: 20px;
+    right: 20px;
+    z-index: 10000;
+    max-width: 400px;
+    background: linear-gradient(135deg, #2c3e50, #34495e);
+    color: white;
+    padding: 16px 20px;
+    border-radius: 10px;
+    box-shadow: 0 10px 30px rgba(0, 0, 0, 0.3);
+    border-left: 4px solid var(--primary-color);
+    transform: translateX(100%);
+    transition: all 0.3s ease;
+}
+
+.notification.show {
+    transform: translateX(0);
+}
+
+.notification.success {
+    border-left-color: #27ae60;
+    background: linear-gradient(135deg, #27ae60, #2ecc71);
+}
+
+.notification.error {
+    border-left-color: #e74c3c;
+    background: linear-gradient(135deg, #e74c3c, #c0392b);
+}
+
+.notification.warning {
+    border-left-color: #f39c12;
+    background: linear-gradient(135deg, #f39c12, #e67e22);
+}
+
+.notification-content {
+    display: flex;
+    align-items: center;
+    gap: 12px;
+}
+
+.notification-icon {
+    width: 20px;
+    height: 20px;
+    fill: currentColor;
+    flex-shrink: 0;
+}
+
+.notification-message {
+    font-weight: 500;
+    line-height: 1.4;
+}
+
+/* Base Styles */
+* {
+    margin: 0;
+    padding: 0;
+    box-sizing: border-box;
+    font-family: 'Segoe UI', Tahoma, Geneva, Verdana, sans-serif;
+}
+
+:root {
+    --primary-color: #9b59b6;      /* Brighter Purple */
+    --dark-color: #000000;         /* Black */
+    --light-color: #f0f0f0;        /* Soft White */
+    --gray-color: #bbbbbb;         /* Mid Gray */
+    --gradient-start: #000000;     /* Black start */
+    --gradient-mid: #64278e;       /* Rich Purple mid */
+    --gradient-end: #7f8c8d;       /* Gray end */
+}
+
+body {
+    background: linear-gradient(135deg, var(--gradient-start), var(--gradient-mid), var(--gradient-end));
+    color: var(--light-color);
+    display: flex;
+    height: 100vh;
+    overflow: hidden;
+}
+
+/* Sidebar */
+.sidebar {
+    width: 280px;
+    background: rgba(0, 0, 0, 0.95);
+    padding: 20px;
+    display: flex;
+    flex-direction: column;
+    box-shadow: 3px 0 15px rgba(0, 0, 0, 0.6);
+    position: relative;
+    z-index: 10;
+}
+
+.logo {
+    display: flex;
+    align-items: center;
+    margin-bottom: 30px;
+    padding-bottom: 20px;
+    border-bottom: 1px solid rgba(255, 255, 255, 0.08);
+}
+
+.logo-icon {
+    width: 28px;
+    height: 28px;
+    margin-right: 12px;
+    fill: var(--primary-color);
+}
+
+.logo-text {
+    font-size: 22px;
+    font-weight: 700;
+    background: linear-gradient(45deg, var(--primary-color), #bb8fce);
+    -webkit-background-clip: text;
+    -webkit-text-fill-color: transparent;
+}
+
+.nav-section {
+    margin-bottom: 25px;
+}
+
+.section-title {
+    font-size: 12px;
+    text-transform: uppercase;
+    color: rgba(255, 255, 255, 0.5);
+    letter-spacing: 1px;
+    margin-bottom: 15px;
+}
+
+/* Sidebar Nav Items - Compact Style */
+.nav-item {
+    display: flex;
+    align-items: center;
+    padding: 8px 12px;
+    border-radius: 6px;
+    margin-bottom: 3px;
+    cursor: pointer;
+    font-size: 14px;
+    transition: all 0.3s ease;
+}
+
+.nav-item:hover {
+    background: rgba(155, 89, 182, 0.15);
+}
+
+.nav-item.active {
+    background: rgba(155, 89, 182, 0.25);
+    box-shadow: 0 0 8px rgba(155, 89, 182, 0.3);
+}
+
+/* Sidebar Icons */
+.nav-icon {
+    width: 18px;
+    height: 18px;
+    margin-right: 10px;
+    fill: var(--primary-color);
+    flex-shrink: 0;
+}
+
+/* Sidebar Text */
+.nav-text {
+    font-size: 14px;
+    font-weight: 500;
+}
+
+.user-profile {
+    margin-top: auto;
+    padding: 15px;
+    background: rgba(255, 255, 255, 0.05);
+    border-radius: 12px;
+    display: flex;
+    align-items: center;
+    transition: all 0.3s ease;
+}
+
+.user-profile:hover {
+    background: rgba(155, 89, 182, 0.15);
+    transform: translateY(-2px);
+}
+
+.user-avatar {
+    width: 45px;
+    height: 45px;
+    border-radius: 50%;
+    background: linear-gradient(135deg, var(--primary-color), #bb8fce);
+    display: flex;
+    align-items: center;
+    justify-content: center;
+    margin-right: 15px;
+    box-shadow: 0 4px 10px rgba(0,0,0,0.3);
+}
+
+.user-avatar svg {
+    width: 20px;
+    height: 20px;
+    fill: white;
+}
+
+.user-info {
+    flex: 1;
+}
+
+.user-name {
+    font-weight: 600;
+    font-size: 15px;
+    margin-bottom: 3px;
+    color: #fff;
+}
+
+.user-email {
+    font-size: 12px;
+    color: rgba(255, 255, 255, 0.7);
+}
+
+/* Main Content */
+.main-content {
+    flex: 1;
+    display: flex;
+    flex-direction: column;
+    padding: 20px;
+    height: 100vh;
+}
+
+.header {
+    padding: 10px 0 30px 0;
+}
+
+.header h1 {
+    font-size: 32px;
+    font-weight: 700;
+    background: linear-gradient(45deg, var(--primary-color), #bb8fce);
+    -webkit-background-clip: text;
+    -webkit-text-fill-color: transparent;
+    text-align: center;
+}
+
+/* Chat */
+.chat-container {
+    flex: 1;
+    overflow-y: auto;
+    padding: 20px;
+    background: rgba(255, 255, 255, 0.02);
+    border-radius: 15px;
+    margin-bottom: 20px;
+    box-shadow: inset 0 0 15px rgba(0, 0, 0, 0.5);
+}
+
+.message {
+    margin-bottom: 25px;
+    max-width: 80%;
+    animation: fadeIn 0.5s ease;
+}
+
+.ai-message {
+    background: rgba(155, 89, 182, 0.15);
+    padding: 15px 20px;
+    border-radius: 18px 18px 18px 5px;
+    align-self: flex-start;
+}
+
+.user-message {
+    background: rgba(0, 0, 0, 0.5);
+    padding: 15px 20px;
+    border-radius: 18px 18px 5px 18px;
+    margin-left: auto;
+}
+
+.feedback-buttons {
+    display: flex;
+    margin-top: 10px;
+    gap: 8px;
+}
+
+.feedback-button {
+    background: rgba(255, 255, 255, 0.08);
+    border: none;
+    border-radius: 50%;
+    width: 36px;
+    height: 36px;
+    display: flex;
+    align-items: center;
+    justify-content: center;
+    cursor: pointer;
+    transition: all 0.3s ease;
+    font-size: 16px;
+}
+
+.feedback-button:hover {
+    background: rgba(255, 255, 255, 0.2);
+    transform: scale(1.1);
+}
+
+.typing-indicator {
+    padding: 15px 0;
+    display: none;
+}
+
+.typing-dots {
+    display: flex;
+    align-items: center;
+}
+
+.typing-dot {
+    width: 10px;
+    height: 10px;
+    background: var(--primary-color);
+    border-radius: 50%;
+    margin: 0 3px;
+    animation: typingAnimation 1.4s infinite ease-in-out;
+}
+
+.typing-dot:nth-child(1) { animation-delay: 0s; }
+.typing-dot:nth-child(2) { animation-delay: 0.2s; }
+.typing-dot:nth-child(3) { animation-delay: 0.4s; }
+
+/* Input */
+.input-area {
+    padding: 20px 0;
+}
+
+.input-container {
+    display: flex;
+    background: rgba(0, 0, 0, 0.6);
+    border-radius: 25px;
+    padding: 8px;
+    box-shadow: 0 5px 15px rgba(0, 0, 0, 0.6);
+    border: 1px solid rgba(255, 255, 255, 0.1);
+}
+
+.input-field {
+    flex: 1;
+    background: transparent;
+    border: none;
+    padding: 15px 20px;
+    color: #fff;
+    font-size: 16px;
+    resize: none;
+    max-height: 150px;
+    outline: none;
+    line-height: 1.5;
+}
+
+.input-field::placeholder {
+    color: rgba(255, 255, 255, 0.5);
+}
+
+.send-button {
+    background: linear-gradient(45deg, var(--primary-color), #bb8fce);
+    border: none;
+    border-radius: 50%;
+    width: 50px;
+    height: 50px;
+    display: flex;
+    align-items: center;
+    justify-content: center;
+    cursor: pointer;
+    transition: all 0.3s ease;
+    flex-shrink: 0;
+}
+
+.send-button:hover {
+    transform: scale(1.05);
+    box-shadow: 0 0 15px rgba(155, 89, 182, 0.5);
+}
+
+.send-button svg {
+    width: 20px;
+    height: 20px;
+    fill: white;
+}
+
+/* Animations */
+@keyframes fadeIn {
+    from { opacity: 0; transform: translateY(10px); }
+    to { opacity: 1; transform: translateY(0); }
+}
+
+@keyframes typingAnimation {
+    0%, 60%, 100% { transform: translateY(0); }
+    30% { transform: translateY(-5px); }
+}
+
+/* Responsive */
+@media (max-width: 768px) {
+    body {
+        flex-direction: column;
+        height: auto;
+    }
+    .sidebar {
+        width: 100%;
+        padding: 15px;
+        height: auto;
+    }
+    .logo { margin-bottom: 20px; }
+    .main-content { padding: 15px; }
+    .message { max-width: 90%; }
+    .modal-content {
+        width: 95%;
+        margin: 20px;
+    }
+    .theme-options {
+        flex-direction: column;
+        align-items: center;
+    }
+}
+
+/* Scrollbar */
+::-webkit-scrollbar {
+    width: 8px;
+}
+::-webkit-scrollbar-track {
+    background: rgba(255, 255, 255, 0.05);
+    border-radius: 10px;
+}
+::-webkit-scrollbar-thumb {
+    background: rgba(155, 89, 182, 0.3);
+    border-radius: 10px;
+}
+::-webkit-scrollbar-thumb:hover {
+    background: rgba(155, 89, 182, 0.5);
+}
diff --git a/frontend/css/style-guide.css b/frontend/css/style-guide.css
new file mode 100644
index 0000000..b6c667f
--- /dev/null
+++ b/frontend/css/style-guide.css
@@ -0,0 +1,440 @@
+/* AI4ORG Style Guide - Consistent Design System */
+
+/* ===== CSS VARIABLES ===== */
+:root {
+  /* Colors */
+  --bg: #0b0a14;                    /* Main background */
+  --text: #e8e6ff;                  /* Primary text */
+  --muted: #b7b5d3;                 /* Secondary text */
+  --glass: rgba(255,255,255,0.06);  /* Glass effect */
+  --accent: #6c53ff;                /* Primary accent */
+  --accent-2: #b388ff;              /* Secondary accent */
+  --border: rgba(255,255,255,0.15); /* Borders */
+  --shadow: rgba(0,0,0,0.35);       /* Shadows */
+
+  /* Typography */
+  --font-family: ui-sans-serif, system-ui, -apple-system, 'Segoe UI', Roboto, Helvetica, Arial, sans-serif;
+  --font-mono: 'Courier New', monospace;
+
+  /* Spacing */
+  --spacing-xs: 4px;
+  --spacing-sm: 8px;
+  --spacing-md: 12px;
+  --spacing-lg: 16px;
+  --spacing-xl: 20px;
+  --spacing-2xl: 24px;
+  --spacing-3xl: 32px;
+  --spacing-4xl: 40px;
+
+  /* Border Radius */
+  --radius-sm: 6px;
+  --radius-md: 10px;
+  --radius-lg: 12px;
+  --radius-xl: 15px;
+  --radius-2xl: 20px;
+  --radius-full: 999px;
+
+  /* Transitions */
+  --transition-fast: 0.2s ease;
+  --transition-normal: 0.3s ease;
+  --transition-slow: 0.5s ease;
+}
+
+/* ===== BASE STYLES ===== */
+* {
+  box-sizing: border-box;
+  font-family: var(--font-family);
+}
+
+html, body {
+  height: 100%;
+  margin: 0;
+  padding: 0;
+  background: var(--bg);
+  color: var(--text);
+  overflow-x: hidden;
+  font-family: var(--font-family);
+}
+
+/* ===== TYPOGRAPHY ===== */
+h1, h2, h3, h4, h5, h6 {
+  margin: 0;
+  font-weight: 700;
+  line-height: 1.2;
+  color: var(--text);
+}
+
+h1 { font-size: clamp(2.2rem, 5vw, 4.2rem); }
+h2 { font-size: clamp(1.8rem, 4vw, 3rem); }
+h3 { font-size: clamp(1.4rem, 3vw, 2rem); }
+h4 { font-size: clamp(1.2rem, 2.5vw, 1.5rem); }
+h5 { font-size: clamp(1rem, 2vw, 1.25rem); }
+h6 { font-size: clamp(0.9rem, 1.5vw, 1.1rem); }
+
+p {
+  margin: 0;
+  line-height: 1.6;
+  color: var(--text);
+}
+
+.text-muted { color: var(--muted); }
+.text-accent { color: var(--accent); }
+.text-center { text-align: center; }
+.text-left { text-align: left; }
+.text-right { text-align: right; }
+
+/* ===== BUTTONS ===== */
+.btn {
+  border: none;
+  border-radius: var(--radius-full);
+  padding: var(--spacing-md) var(--spacing-xl);
+  font-weight: 600;
+  cursor: pointer;
+  transition: all var(--transition-normal);
+  font-size: 0.95rem;
+  display: inline-flex;
+  align-items: center;
+  justify-content: center;
+  gap: var(--spacing-sm);
+  text-decoration: none;
+  font-family: inherit;
+}
+
+.btn:disabled {
+  opacity: 0.5;
+  cursor: not-allowed;
+}
+
+.btn-ghost {
+  background: transparent;
+  color: var(--text);
+  border: 1px solid var(--border);
+}
+
+.btn-ghost:hover:not(:disabled) {
+  background: var(--glass);
+  border-color: var(--accent);
+}
+
+.btn-solid {
+  background: linear-gradient(135deg, var(--accent), var(--accent-2));
+  color: white;
+  box-shadow: 0 4px 12px rgba(108, 83, 255, 0.3);
+}
+
+.btn-solid:hover:not(:disabled) {
+  transform: translateY(-2px);
+  box-shadow: 0 6px 16px rgba(108, 83, 255, 0.4);
+}
+
+.btn-secondary {
+  background: var(--glass);
+  color: var(--text);
+  border: 1px solid var(--border);
+}
+
+.btn-secondary:hover:not(:disabled) {
+  background: rgba(255, 255, 255, 0.1);
+  border-color: var(--accent);
+}
+
+/* ===== INPUTS ===== */
+.input {
+  width: 100%;
+  padding: var(--spacing-md) var(--spacing-lg);
+  background: var(--glass);
+  backdrop-filter: blur(12px);
+  border: 1px solid var(--border);
+  border-radius: var(--radius-lg);
+  color: var(--text);
+  font-size: 0.95rem;
+  outline: none;
+  transition: all var(--transition-normal);
+  font-family: inherit;
+}
+
+.input::placeholder {
+  color: var(--muted);
+}
+
+.input:focus {
+  border-color: var(--accent);
+  box-shadow: 0 0 0 3px rgba(108, 83, 255, 0.1);
+}
+
+.input-mono {
+  font-family: var(--font-mono);
+  text-align: center;
+  letter-spacing: 2px;
+}
+
+/* ===== CARDS ===== */
+.card {
+  background: var(--glass);
+  backdrop-filter: blur(12px);
+  border: 1px solid var(--border);
+  border-radius: var(--radius-2xl);
+  padding: var(--spacing-3xl);
+  box-shadow: 0 8px 24px var(--shadow);
+  transition: all var(--transition-normal);
+}
+
+.card:hover {
+  transform: translateY(-4px);
+  box-shadow: 0 12px 32px rgba(108, 83, 255, 0.15);
+}
+
+.card-compact {
+  padding: var(--spacing-xl);
+}
+
+.card-large {
+  padding: var(--spacing-4xl);
+}
+
+/* ===== GLASS EFFECTS ===== */
+.glass {
+  background: var(--glass);
+  backdrop-filter: blur(12px);
+  border: 1px solid var(--border);
+}
+
+.glass-strong {
+  background: rgba(255, 255, 255, 0.1);
+  backdrop-filter: blur(16px);
+  border: 1px solid var(--border);
+}
+
+/* ===== GRADIENTS ===== */
+.gradient-bg {
+  background: linear-gradient(135deg, var(--bg), #1a1a2e, #16213e);
+}
+
+.gradient-accent {
+  background: linear-gradient(135deg, var(--accent), var(--accent-2));
+}
+
+.gradient-text {
+  background: linear-gradient(135deg, var(--text), var(--muted));
+  -webkit-background-clip: text;
+  -webkit-text-fill-color: transparent;
+}
+
+.gradient-accent-text {
+  background: linear-gradient(135deg, var(--accent), var(--accent-2));
+  -webkit-background-clip: text;
+  -webkit-text-fill-color: transparent;
+}
+
+/* ===== LAYOUT ===== */
+.container {
+  max-width: 1200px;
+  margin: 0 auto;
+  padding: 0 var(--spacing-xl);
+}
+
+.flex {
+  display: flex;
+}
+
+.flex-col {
+  flex-direction: column;
+}
+
+.items-center {
+  align-items: center;
+}
+
+.justify-center {
+  justify-content: center;
+}
+
+.justify-between {
+  justify-content: space-between;
+}
+
+.gap-sm { gap: var(--spacing-sm); }
+.gap-md { gap: var(--spacing-md); }
+.gap-lg { gap: var(--spacing-lg); }
+.gap-xl { gap: var(--spacing-xl); }
+.gap-2xl { gap: var(--spacing-2xl); }
+
+/* ===== SPACING ===== */
+.p-xs { padding: var(--spacing-xs); }
+.p-sm { padding: var(--spacing-sm); }
+.p-md { padding: var(--spacing-md); }
+.p-lg { padding: var(--spacing-lg); }
+.p-xl { padding: var(--spacing-xl); }
+.p-2xl { padding: var(--spacing-2xl); }
+.p-3xl { padding: var(--spacing-3xl); }
+.p-4xl { padding: var(--spacing-4xl); }
+
+.m-xs { margin: var(--spacing-xs); }
+.m-sm { margin: var(--spacing-sm); }
+.m-md { margin: var(--spacing-md); }
+.m-lg { margin: var(--spacing-lg); }
+.m-xl { margin: var(--spacing-xl); }
+.m-2xl { margin: var(--spacing-2xl); }
+.m-3xl { margin: var(--spacing-3xl); }
+.m-4xl { margin: var(--spacing-4xl); }
+
+/* ===== ANIMATIONS ===== */
+@keyframes fadeIn {
+  from {
+    opacity: 0;
+    transform: translateY(20px);
+  }
+  to {
+    opacity: 1;
+    transform: translateY(0);
+  }
+}
+
+@keyframes fadeInUp {
+  from {
+    opacity: 0;
+    transform: translateY(30px);
+  }
+  to {
+    opacity: 1;
+    transform: translateY(0);
+  }
+}
+
+@keyframes slideIn {
+  from {
+    opacity: 0;
+    transform: translateX(-20px);
+  }
+  to {
+    opacity: 1;
+    transform: translateX(0);
+  }
+}
+
+@keyframes pulse {
+  0%, 100% {
+    opacity: 1;
+  }
+  50% {
+    opacity: 0.5;
+  }
+}
+
+@keyframes spin {
+  from {
+    transform: rotate(0deg);
+  }
+  to {
+    transform: rotate(360deg);
+  }
+}
+
+.animate-fadeIn { animation: fadeIn 0.6s ease forwards; }
+.animate-fadeInUp { animation: fadeInUp 0.6s ease forwards; }
+.animate-slideIn { animation: slideIn 0.6s ease forwards; }
+.animate-pulse { animation: pulse 2s infinite; }
+.animate-spin { animation: spin 1s linear infinite; }
+
+/* ===== UTILITIES ===== */
+.hidden { display: none; }
+.visible { display: block; }
+.invisible { visibility: hidden; }
+.opacity-0 { opacity: 0; }
+.opacity-50 { opacity: 0.5; }
+.opacity-100 { opacity: 1; }
+
+.w-full { width: 100%; }
+.h-full { height: 100%; }
+.min-h-screen { min-height: 100vh; }
+
+.rounded-sm { border-radius: var(--radius-sm); }
+.rounded-md { border-radius: var(--radius-md); }
+.rounded-lg { border-radius: var(--radius-lg); }
+.rounded-xl { border-radius: var(--radius-xl); }
+.rounded-2xl { border-radius: var(--radius-2xl); }
+.rounded-full { border-radius: var(--radius-full); }
+
+.shadow-sm { box-shadow: 0 2px 4px var(--shadow); }
+.shadow-md { box-shadow: 0 4px 8px var(--shadow); }
+.shadow-lg { box-shadow: 0 8px 16px var(--shadow); }
+.shadow-xl { box-shadow: 0 12px 24px var(--shadow); }
+
+/* ===== RESPONSIVE ===== */
+@media (max-width: 768px) {
+  .container {
+    padding: 0 var(--spacing-lg);
+  }
+
+  .card {
+    padding: var(--spacing-xl);
+  }
+
+  .btn {
+    padding: var(--spacing-sm) var(--spacing-lg);
+    font-size: 0.9rem;
+  }
+}
+
+@media (max-width: 480px) {
+  .container {
+    padding: 0 var(--spacing-md);
+  }
+
+  .card {
+    padding: var(--spacing-lg);
+  }
+
+  .btn {
+    padding: var(--spacing-sm) var(--spacing-md);
+    font-size: 0.85rem;
+  }
+}
+
+/* ===== SCROLLBAR ===== */
+::-webkit-scrollbar {
+  width: 8px;
+}
+
+::-webkit-scrollbar-track {
+  background: var(--glass);
+  border-radius: var(--radius-md);
+}
+
+::-webkit-scrollbar-thumb {
+  background: rgba(108, 83, 255, 0.3);
+  border-radius: var(--radius-md);
+  transition: all var(--transition-normal);
+}
+
+::-webkit-scrollbar-thumb:hover {
+  background: rgba(108, 83, 255, 0.5);
+}
+
+/* ===== ACCESSIBILITY ===== */
+@media (prefers-reduced-motion: reduce) {
+  * {
+    animation-duration: 0.01ms !important;
+    animation-iteration-count: 1 !important;
+    transition-duration: 0.01ms !important;
+  }
+}
+
+@media (prefers-contrast: high) {
+  :root {
+    --border: rgba(255,255,255,0.3);
+    --glass: rgba(255,255,255,0.1);
+  }
+}
+
+/* Focus styles for accessibility */
+*:focus {
+  outline: 2px solid var(--accent);
+  outline-offset: 2px;
+}
+
+.btn:focus,
+.input:focus {
+  outline: none;
+  box-shadow: 0 0 0 3px rgba(108, 83, 255, 0.3);
+}
diff --git a/frontend/css/style.css b/frontend/css/style.css
new file mode 100644
index 0000000..14080c9
--- /dev/null
+++ b/frontend/css/style.css
@@ -0,0 +1,201 @@
+:root {
+    --primary-color: #9b59b6;      /* Brighter Purple */
+    --dark-color: #000000;         /* Black */
+    --light-color: #f0f0f0;        /* Soft White */
+    --gray-color: #bbbbbb;         /* Mid Gray */
+    --gradient-start: #000000;     /* Black start */
+    --gradient-mid: #64278e;       /* Rich Purple mid */
+    --gradient-end: #7f8c8d;       /* Grey end */
+}
+
+body {
+    margin: 0;
+    padding: 0;
+    font-family: 'Segoe UI', Tahoma, Geneva, Verdana, sans-serif;
+    background: linear-gradient(135deg, var(--gradient-start), var(--gradient-mid), var(--gradient-end));
+    color: var(--light-color);
+    height: 100vh;
+    display: flex;
+    flex-direction: column;
+    overflow: hidden;
+}
+
+.header {
+    padding: 0.75rem;
+    text-align: center;
+    background-color: rgba(0, 0, 0, 0.85);
+    border-bottom: 1px solid rgba(255, 255, 255, 0.1);
+}
+
+.header h1 {
+    margin: 0;
+    font-size: 1.25rem;
+    font-weight: 600;
+    white-space: nowrap;
+    overflow: hidden;
+    text-overflow: ellipsis;
+}
+
+.chat-container {
+    flex: 1;
+    overflow-y: scroll;
+    padding: 0.75rem;
+    display: flex;
+    flex-direction: column;
+    gap: 0.5rem;
+    max-width: 800px;
+    width: 100%;
+    margin: 0 auto;
+}
+
+.message {
+    padding: 0.6rem 0.8rem;
+    margin-bottom: 0.25rem;
+    border-radius: 0.75rem;
+    max-width: 80%;
+    font-size: 0.9rem;
+    line-height: 1.4;
+    word-wrap: break-word;
+    overflow-wrap: break-word;
+}
+
+.user-message {
+    align-self: flex-end;
+    background-color: rgba(100, 39, 142, 0.85); /* Purple with 85% opacity */
+    color: var(--light-color); /* Remains white for readability */
+}
+
+
+.ai-message {
+    align-self: flex-start;
+    background-color: rgba(255, 255, 255, 0.08);
+    color: var(--light-color);
+}
+
+.feedback-buttons {
+    display: flex;
+    gap: 0.5rem;
+    margin-top: 0.5rem;
+    justify-content: flex-end;
+}
+
+.feedback-button {
+    background: none;
+    border: none;
+    color: var(--gray-color);
+    cursor: pointer;
+    font-size: 0.9rem;
+    padding: 0.15rem 0.3rem;
+    border-radius: 0.25rem;
+    transition: all 0.2s;
+}
+
+.feedback-button:hover {
+    background-color: rgba(255, 255, 255, 0.1);
+    color: var(--light-color);
+}
+
+.feedback-button.active {
+    color: var(--primary-color);
+}
+
+.input-area {
+    padding: 0.75rem;
+    background-color: rgba(0, 0, 0, 0.85);
+    border-top: 1px solid rgba(255, 255, 255, 0.1);
+    display: flex;
+    justify-content: center;
+}
+
+.input-container {
+    max-width: 800px;
+    width: 100%;
+    display: flex;
+    gap: 0.5rem;
+}
+
+.input-field {
+    flex: 1;
+    padding: 0.6rem 0.8rem;
+    border-radius: 0.5rem;
+    border: 1px solid rgba(255, 255, 255, 0.2);
+    background-color: #1e1e1e;
+    color: var(--light-color);
+    font-size: 0.9rem;
+    outline: none;
+    white-space: pre-wrap;
+    min-height: 1.5rem;
+    max-height: 5rem;
+    overflow-y: auto;
+    resize: none;
+}
+
+.input-field:focus {
+    border-color: var(--primary-color);
+}
+
+.send-button {
+    padding: 0.6rem 1rem;
+    background-color: var(--primary-color);
+    color: white;
+    border: none;
+    border-radius: 0.5rem;
+    cursor: pointer;
+    font-size: 0.9rem;
+    transition: background-color 0.2s;
+    align-self: flex-end;
+    height: fit-content;
+}
+
+.send-button:hover {
+    background-color: #7d3c98;
+}
+
+.typing-indicator {
+    display: none;
+    padding: 0.6rem 0.8rem;
+    align-self: flex-start;
+    background-color: rgba(255, 255, 255, 0.1);
+    border-radius: 0.75rem;
+    margin-bottom: 0.25rem;
+}
+
+.typing-dots {
+    display: flex;
+    gap: 0.25rem;
+}
+
+.typing-dot {
+    width: 0.4rem;
+    height: 0.4rem;
+    background-color: var(--gray-color);
+    border-radius: 50%;
+    animation: typingAnimation 1.4s infinite ease-in-out;
+}
+
+.typing-dot:nth-child(1) { animation-delay: 0s; }
+.typing-dot:nth-child(2) { animation-delay: 0.2s; }
+.typing-dot:nth-child(3) { animation-delay: 0.4s; }
+
+@keyframes typingAnimation {
+    0%, 60%, 100% { transform: translateY(0); }
+    30% { transform: translateY(-0.15rem); }
+}
+
+/* Scrollbar styling */
+::-webkit-scrollbar {
+    width: 0.5rem;
+}
+::-webkit-scrollbar-track {
+    background: var(--primary-color);
+}
+::-webkit-scrollbar-thumb {
+    background: rgba(255, 255, 255, 0.2);
+    border-radius: 0.25rem;
+}
+::-webkit-scrollbar-thumb:hover {
+    background: rgba(255, 255, 255, 0.3);
+}
+::-webkit-scrollbar {
+    display: none;  /* Hides the scrollbar */
+}
diff --git a/frontend/html/account.html b/frontend/html/account.html
new file mode 100644
index 0000000..6d7e885
--- /dev/null
+++ b/frontend/html/account.html
@@ -0,0 +1,785 @@
+<!DOCTYPE html>
+<html lang="en">
+<head>
+    <meta charset="UTF-8">
+    <meta name="viewport" content="width=device-width, initial-scale=1.0">
+    <title>Account Selection - AI4ORG</title>
+    <style>
+        :root {
+            --bg: #0b0a14;
+            --text: #e8e6ff;
+            --muted: #b7b5d3;
+            --glass: rgba(255,255,255,0.06);
+            --accent: #6c53ff;
+            --accent-2: #b388ff;
+            --border: rgba(255,255,255,0.15);
+            --shadow: rgba(0,0,0,0.35);
+        }
+
+        * {
+            margin: 0;
+            padding: 0;
+            box-sizing: border-box;
+            font-family: ui-sans-serif, system-ui, -apple-system, 'Segoe UI', Roboto, Helvetica, Arial, sans-serif;
+        }
+
+        body {
+            background: var(--bg);
+            color: var(--text);
+            min-height: 100vh;
+            overflow-x: hidden;
+        }
+
+        /* Background Video */
+        #bgVideo {
+            position: fixed;
+            inset: 0;
+            width: 100vw;
+            height: 100%;
+            object-fit: cover;
+            z-index: -2;
+        }
+
+        /* Overlay */
+        .overlay {
+            position: fixed;
+            inset: 0;
+            z-index: -1;
+            background:
+                radial-gradient(60rem 25rem at 50% 80%, rgba(150, 97, 255, 0.55), rgba(108,83,255,0.15) 35%, rgba(0,0,0,0) 65%),
+                radial-gradient(1400px 600px at 50% 110%, rgba(255,255,255,0.22), rgba(255,255,255,0.0) 60%);
+            pointer-events: none;
+        }
+
+        .overlay::after {
+            content: '';
+            position: absolute;
+            inset: 0;
+            background-image: radial-gradient(rgba(255,255,255,0.55) 1px, transparent 1px);
+            background-size: 3px 3px;
+            opacity: 0.08;
+            mask-image: radial-gradient(60rem 30rem at 50% 70%, black, transparent 70%);
+        }
+
+        /* Header */
+        .header {
+            position: fixed;
+            top: 0;
+            left: 0;
+            right: 0;
+            display: flex;
+            align-items: center;
+            justify-content: space-between;
+            padding: 14px 24px;
+            backdrop-filter: blur(10px);
+            background: linear-gradient(to bottom, rgba(0,0,0,0.35), rgba(0,0,0,0.0));
+            z-index: 100;
+        }
+
+        .brand {
+            display: flex;
+            align-items: center;
+            gap: 0.6rem;
+            font-weight: 700;
+        }
+
+        .brand-logo {
+            width: 28px;
+            height: 28px;
+            border-radius: 10px;
+            display: grid;
+            place-items: center;
+            background: linear-gradient(135deg, var(--accent), var(--accent-2));
+            color: white;
+            font-size: 14px;
+        }
+
+        .back-btn {
+            background: var(--glass);
+            border: 1px solid var(--border);
+            border-radius: 20px;
+            padding: 8px 16px;
+            color: var(--muted);
+            font-size: 0.9rem;
+            cursor: pointer;
+            transition: all 0.3s ease;
+            display: flex;
+            align-items: center;
+            gap: 8px;
+            text-decoration: none;
+        }
+
+        .back-btn:hover {
+            background: rgba(255, 255, 255, 0.1);
+            color: var(--text);
+        }
+
+        /* Main Container */
+        .container {
+            min-height: 100vh;
+            display: flex;
+            flex-direction: column;
+            align-items: center;
+            justify-content: center;
+            padding: 100px 20px 40px;
+            text-align: center;
+        }
+
+        /* Title Section */
+        .title-section {
+            margin-bottom: 60px;
+        }
+
+        .ai-pill {
+            border-radius: 999px;
+            padding: 8px 14px;
+            border: 1px solid var(--border);
+            background: var(--glass);
+            color: var(--text);
+            font-weight: 600;
+            letter-spacing: 0.1px;
+            backdrop-filter: blur(6px);
+            display: inline-block;
+            margin-bottom: 20px;
+        }
+
+        .main-title {
+            font-size: clamp(2.5rem, 5vw, 4rem);
+            font-weight: 700;
+            line-height: 1.1;
+            margin-bottom: 15px;
+            background: linear-gradient(135deg, var(--text), var(--muted));
+            -webkit-background-clip: text;
+            -webkit-text-fill-color: transparent;
+            text-shadow: 0 8px 40px rgba(108, 83, 255, 0.45);
+        }
+
+        .subtitle {
+            font-size: 1.2rem;
+            color: var(--muted);
+            max-width: 600px;
+            margin: 0 auto;
+            line-height: 1.6;
+        }
+
+        /* Account Selection */
+        .account-selection {
+            display: flex;
+            gap: 30px;
+            max-width: 800px;
+            width: 100%;
+            justify-content: center;
+            flex-wrap: wrap;
+        }
+
+        .account-btn {
+            flex: 1;
+            min-width: 300px;
+            max-width: 350px;
+            background: var(--glass);
+            backdrop-filter: blur(12px);
+            border: 1px solid var(--border);
+            border-radius: 20px;
+            padding: 40px 30px;
+            cursor: pointer;
+            transition: all 0.3s ease;
+            text-align: center;
+            color: var(--text);
+            text-decoration: none;
+            display: flex;
+            flex-direction: column;
+            align-items: center;
+            gap: 20px;
+            box-shadow: 0 8px 24px var(--shadow);
+        }
+
+        .account-btn:hover {
+            transform: translateY(-8px);
+            box-shadow: 0 16px 40px rgba(108, 83, 255, 0.2);
+            border-color: var(--accent);
+        }
+
+        .account-btn:active {
+            transform: translateY(-4px);
+        }
+
+        .account-icon {
+            width: 60px;
+            height: 60px;
+            border-radius: 50%;
+            display: flex;
+            align-items: center;
+            justify-content: center;
+            margin-bottom: 10px;
+            transition: all 0.3s ease;
+        }
+
+        .admin-btn .account-icon {
+            background: linear-gradient(135deg, #ff6b6b, #ff8e8e);
+            color: white;
+        }
+
+        .user-btn .account-icon {
+            background: linear-gradient(135deg, var(--accent), var(--accent-2));
+            color: white;
+        }
+
+        .account-btn:hover .account-icon {
+            transform: scale(1.1);
+        }
+
+        .account-title {
+            font-size: 1.5rem;
+            font-weight: 700;
+            margin-bottom: 10px;
+            color: var(--text);
+        }
+
+        .account-description {
+            font-size: 1rem;
+            color: var(--muted);
+            line-height: 1.5;
+            margin-bottom: 20px;
+        }
+
+        .account-features {
+            list-style: none;
+            text-align: left;
+            width: 100%;
+        }
+
+        .account-features li {
+            font-size: 0.9rem;
+            color: var(--muted);
+            margin-bottom: 8px;
+            display: flex;
+            align-items: center;
+            gap: 8px;
+        }
+
+        .account-features li::before {
+            content: '✓';
+            color: var(--accent);
+            font-weight: bold;
+            font-size: 0.8rem;
+        }
+
+        /* Icon Styles */
+        .icon {
+            width: 24px;
+            height: 24px;
+            fill: currentColor;
+        }
+
+        .icon-small {
+            width: 16px;
+            height: 16px;
+        }
+
+        /* PIN Modal */
+        .pin-modal {
+            position: fixed;
+            top: 0;
+            left: 0;
+            width: 100%;
+            height: 100%;
+            background: rgba(0, 0, 0, 0.8);
+            backdrop-filter: blur(10px);
+            z-index: 10000;
+            display: flex;
+            align-items: center;
+            justify-content: center;
+            opacity: 0;
+            visibility: hidden;
+            transition: all 0.3s ease;
+        }
+
+        .pin-modal.show {
+            opacity: 1;
+            visibility: visible;
+        }
+
+        .pin-content {
+            background: var(--glass);
+            backdrop-filter: blur(12px);
+            border: 1px solid var(--border);
+            border-radius: 20px;
+            padding: 40px;
+            text-align: center;
+            max-width: 400px;
+            width: 90%;
+            box-shadow: 0 20px 40px var(--shadow);
+            transform: scale(0.9);
+            transition: all 0.3s ease;
+        }
+
+        .pin-modal.show .pin-content {
+            transform: scale(1);
+        }
+
+        .pin-title {
+            font-size: 1.8rem;
+            font-weight: 700;
+            margin-bottom: 10px;
+            color: var(--text);
+        }
+
+        .pin-subtitle {
+            font-size: 1rem;
+            color: var(--muted);
+            margin-bottom: 30px;
+            line-height: 1.5;
+        }
+
+        .pin-input {
+            width: 100%;
+            padding: 15px 20px;
+            background: rgba(255, 255, 255, 0.05);
+            border: 1px solid var(--border);
+            border-radius: 12px;
+            color: var(--text);
+            font-size: 1.1rem;
+            text-align: center;
+            letter-spacing: 2px;
+            margin-bottom: 20px;
+            outline: none;
+            transition: all 0.3s ease;
+            font-family: 'Courier New', monospace;
+        }
+
+        .pin-input:focus {
+            border-color: var(--accent);
+            box-shadow: 0 0 0 3px rgba(108, 83, 255, 0.1);
+        }
+
+        .pin-buttons {
+            display: flex;
+            gap: 15px;
+            justify-content: center;
+        }
+
+        .btn {
+            border: none;
+            border-radius: 12px;
+            padding: 12px 24px;
+            font-weight: 600;
+            cursor: pointer;
+            transition: all 0.3s ease;
+            font-size: 1rem;
+            display: flex;
+            align-items: center;
+            gap: 8px;
+        }
+
+        .btn-primary {
+            background: linear-gradient(135deg, var(--accent), var(--accent-2));
+            color: white;
+            box-shadow: 0 4px 12px rgba(108, 83, 255, 0.3);
+        }
+
+        .btn-primary:hover {
+            transform: translateY(-2px);
+            box-shadow: 0 6px 16px rgba(108, 83, 255, 0.4);
+        }
+
+        .btn-secondary {
+            background: var(--glass);
+            color: var(--text);
+            border: 1px solid var(--border);
+        }
+
+        .btn-secondary:hover {
+            background: rgba(255, 255, 255, 0.1);
+        }
+
+        .pin-error {
+            color: #ff6b6b;
+            margin-top: 15px;
+            font-size: 0.9rem;
+            display: none;
+            align-items: center;
+            justify-content: center;
+            gap: 8px;
+        }
+
+        .pin-error.show {
+            display: flex;
+        }
+
+        .pin-success {
+            color: #4ade80;
+            margin-top: 15px;
+            font-size: 0.9rem;
+            display: none;
+            align-items: center;
+            justify-content: center;
+            gap: 8px;
+        }
+
+        .pin-success.show {
+            display: flex;
+        }
+
+        /* Responsive Design */
+        @media (max-width: 768px) {
+            .container {
+                padding: 80px 15px 30px;
+            }
+
+            .account-selection {
+                flex-direction: column;
+                align-items: center;
+                gap: 20px;
+            }
+
+            .account-btn {
+                min-width: 280px;
+                max-width: 100%;
+                padding: 30px 25px;
+            }
+
+            .main-title {
+                font-size: 2.5rem;
+            }
+
+            .subtitle {
+                font-size: 1.1rem;
+            }
+
+            .pin-content {
+                padding: 30px 25px;
+            }
+
+            .pin-title {
+                font-size: 1.5rem;
+            }
+        }
+
+        @media (max-width: 480px) {
+            .header {
+                padding: 12px 15px;
+            }
+
+            .container {
+                padding: 70px 10px 20px;
+            }
+
+            .account-btn {
+                min-width: 260px;
+                padding: 25px 20px;
+            }
+
+            .main-title {
+                font-size: 2rem;
+            }
+
+            .subtitle {
+                font-size: 1rem;
+            }
+
+            .pin-content {
+                padding: 25px 20px;
+            }
+
+            .pin-buttons {
+                flex-direction: column;
+            }
+
+            .btn {
+                width: 100%;
+                justify-content: center;
+            }
+        }
+
+        /* Animations */
+        @keyframes fadeInUp {
+            from {
+                opacity: 0;
+                transform: translateY(30px);
+            }
+            to {
+                opacity: 1;
+                transform: translateY(0);
+            }
+        }
+
+        .account-btn {
+            animation: fadeInUp 0.6s ease forwards;
+        }
+
+        .account-btn:nth-child(1) {
+            animation-delay: 0.1s;
+        }
+
+        .account-btn:nth-child(2) {
+            animation-delay: 0.2s;
+        }
+
+        /* Scrollbar */
+        ::-webkit-scrollbar {
+            width: 8px;
+        }
+
+        ::-webkit-scrollbar-track {
+            background: var(--glass);
+            border-radius: 10px;
+        }
+
+        ::-webkit-scrollbar-thumb {
+            background: rgba(108, 83, 255, 0.3);
+            border-radius: 10px;
+            transition: all 0.3s ease;
+        }
+
+        ::-webkit-scrollbar-thumb:hover {
+            background: rgba(108, 83, 255, 0.5);
+        }
+    </style>
+</head>
+<body>
+    <!-- Background Video -->
+    <video id="bgVideo" autoplay muted loop playsinline>
+        <source src="../assets/images/bg.mp4" type="video/mp4" />
+    </video>
+
+    <!-- Overlay -->
+    <div class="overlay"></div>
+
+    <!-- Header -->
+    <header class="header">
+        <img src="../assets/images/logo.png" alt="" height="100" width="100" style="border-radius: 50%;">
+
+        <a href="index.html" class="back-btn">
+            <svg class="icon icon-small" viewBox="0 0 16 16" fill="currentColor">
+                <path d="M15 7H3.414l3.293-3.293a1 1 0 0 0-1.414-1.414l-5 5a1 1 0 0 0 0 1.414l5 5a1 1 0 0 0 1.414-1.414L3.414 9H15a1 1 0 1 0 0-2z"/>
+            </svg>
+            Back to Home
+        </a>
+    </header>
+
+    <!-- Main Container -->
+    <div class="container">
+        <!-- Title Section -->
+        <div class="title-section">
+            <div class="ai-pill">
+                <svg class="icon icon-small" viewBox="0 0 16 16" fill="currentColor">
+                    <path d="M8 0a1 1 0 0 1 1 1v1a1 1 0 0 1-2 0V1a1 1 0 0 1 1-1zM4.854 2.854a.5.5 0 0 1 0-.708l.707-.707a.5.5 0 0 1 .708 0l.707.707a.5.5 0 0 1-.708.708l-.707-.707a.5.5 0 0 1-.708 0zm6.292 0a.5.5 0 0 0 0-.708l-.707-.707a.5.5 0 0 0-.708 0l-.707.707a.5.5 0 0 0 .708.708l.707-.707a.5.5 0 0 0 .708 0zM8 13a1 1 0 0 1 1 1v1a1 1 0 0 1-2 0v-1a1 1 0 0 1 1-1zm-3.146-1.854a.5.5 0 0 0 0 .708l.707.707a.5.5 0 0 0 .708 0l.707-.707a.5.5 0 0 0-.708-.708l-.707.707a.5.5 0 0 0-.708 0zm6.292 0a.5.5 0 0 1 0 .708l-.707.707a.5.5 0 0 1-.708 0l-.707-.707a.5.5 0 0 1 .708-.708l.707.707a.5.5 0 0 1 .708 0zM1 8a1 1 0 0 1 1-1h1a1 1 0 0 1 0 2H2a1 1 0 0 1-1-1zm12 0a1 1 0 0 1 1-1h1a1 1 0 0 1 0 2h-1a1 1 0 0 1-1-1z"/>
+                    <path d="M8 4a4 4 0 1 0 0 8 4 4 0 0 0 0-8z"/>
+                </svg>
+                Secure Access
+            </div>
+            <h1 class="main-title">Choose Your Access Level</h1>
+            <p class="subtitle">
+                Select how you'd like to access the AI4ORG platform. Each option provides different features and capabilities.
+            </p>
+        </div>
+
+        <!-- Account Selection -->
+        <div class="account-selection">
+            <!-- Admin Access -->
+            <button class="account-btn admin-btn" onclick="loginAsAdmin()" style="background-color: #000000bb !important;">
+                <div class="account-icon">
+                    <svg class="icon" viewBox="0 0 24 24" fill="white">
+                        <path d="M12 2L2 7l10 5 10-5-10-5zM2 17l10 5 10-5M2 12l10 5 10-5"/>
+                    </svg>
+                </div>
+                <h3 class="account-title">Administrator</h3>
+                <p class="account-description">
+                    Full system access with advanced management capabilities and user analytics.
+                </p>
+                <ul class="account-features">
+                    <li>View user login history</li>
+                    <li>System analytics dashboard</li>
+                    <li>User management tools</li>
+                    <li>Advanced AI model controls</li>
+                </ul>
+            </button>
+
+            <!-- User Access -->
+            <button class="account-btn user-btn" onclick="loginAsUser()" style="background-color: #000000bb !important;">
+                <div class="account-icon">
+                    <svg class="icon" viewBox="0 0 24 24" fill="white">
+                        <path d="M12 12c2.21 0 4-1.79 4-4s-1.79-4-4-4-4 1.79-4 4 1.79 4 4 4zm0 2c-2.67 0-8 1.34-8 4v2h16v-2c0-2.66-5.33-4-8-4z"/>
+                    </svg>
+                </div>
+                <h3 class="account-title">Standard User</h3>
+                <p class="account-description">
+                    Access the AI chat interface with personalized experience and conversation history.
+                </p>
+                <ul class="account-features">
+                    <li>AI chat interface</li>
+                    <li>Personal conversation history</li>
+                    <li>File upload capabilities</li>
+                    <li>Custom AI responses</li>
+                </ul>
+            </button>
+        </div>
+    </div>
+
+    <!-- PIN Modal -->
+    <div class="pin-modal" id="pinModal">
+        <div class="pin-content">
+            <h2 class="pin-title">Enter Your PIN</h2>
+            <p class="pin-subtitle">
+                Please enter your 4-digit PIN to access your account securely.
+            </p>
+            <input type="password" class="pin-input" id="pinInput" placeholder="••••" maxlength="4" autocomplete="off">
+            <div class="pin-buttons">
+                <button class="btn btn-primary" onclick="validatePin()">
+                    <svg class="icon icon-small" viewBox="0 0 16 16" fill="currentColor">
+                        <path d="M13.854 3.646a.5.5 0 0 1 0 .708l-7 7a.5.5 0 0 1-.708 0l-3.5-3.5a.5.5 0 1 1 .708-.708L6.5 10.293l6.646-6.647a.5.5 0 0 1 .708 0z"/>
+                    </svg>
+                    Login
+                </button>
+                <button class="btn btn-secondary" onclick="closePinDialog()">
+                    <svg class="icon icon-small" viewBox="0 0 16 16" fill="currentColor">
+                        <path d="M4.646 4.646a.5.5 0 0 1 .708 0L8 7.293l2.646-2.647a.5.5 0 0 1 .708.708L8.707 8l2.647 2.646a.5.5 0 0 1-.708.708L8 8.707l-2.646 2.647a.5.5 0 0 1-.708-.708L7.293 8 4.646 5.354a.5.5 0 0 1 0-.708z"/>
+                    </svg>
+                    Cancel
+                </button>
+            </div>
+            <div class="pin-error" id="pinError">
+                <svg class="icon icon-small" viewBox="0 0 16 16" fill="currentColor">
+                    <path d="M8 15A7 7 0 1 1 8 1a7 7 0 0 1 0 14zm0 1A8 8 0 1 0 8 0a8 8 0 0 0 0 16z"/>
+                    <path d="M7.002 11a1 1 0 1 1 2 0 1 1 0 0 1-2 0zM7.1 4.995a.905.905 0 1 1 1.8 0l-.35 3.507a.552.552 0 0 1-1.1 0L7.1 4.995z"/>
+                </svg>
+                Invalid PIN. Please try again.
+            </div>
+            <div class="pin-success" id="pinSuccess">
+                <svg class="icon icon-small" viewBox="0 0 16 16" fill="currentColor">
+                    <path d="M16 8A8 8 0 1 1 0 8a8 8 0 0 1 16 0zm-3.97-3.03a.75.75 0 0 0-1.08.022L7.477 9.417 5.384 7.323a.75.75 0 0 0-1.06 1.06L6.97 11.03a.75.75 0 0 0 1.079-.02l3.992-4.99a.75.75 0 0 0-.01-1.05z"/>
+                </svg>
+                Login successful! Redirecting...
+            </div>
+        </div>
+    </div>
+
+    <script>
+        // Login as Admin - redirect to login page
+        function loginAsAdmin() {
+            // Add loading animation
+            const btn = event.target.closest('.admin-btn');
+            btn.style.transform = 'scale(0.95)';
+            btn.style.opacity = '0.8';
+
+            setTimeout(() => {
+                window.location.href = 'login.html';
+            }, 200);
+        }
+
+        // Login as User - show PIN dialog
+        function loginAsUser() {
+            showPinDialog();
+        }
+
+        // Show PIN dialog
+        function showPinDialog() {
+            const pinModal = document.getElementById('pinModal');
+            const pinInput = document.getElementById('pinInput');
+
+            pinModal.classList.add('show');
+            setTimeout(() => {
+                pinInput.focus();
+            }, 300);
+
+            // Handle Enter key
+            pinInput.addEventListener('keypress', function(e) {
+                if (e.key === 'Enter') {
+                    validatePin();
+                }
+            });
+        }
+
+        // Close PIN dialog
+        function closePinDialog() {
+            const pinModal = document.getElementById('pinModal');
+            const pinInput = document.getElementById('pinInput');
+            const pinError = document.getElementById('pinError');
+            const pinSuccess = document.getElementById('pinSuccess');
+
+            pinModal.classList.remove('show');
+            pinInput.value = '';
+            pinError.classList.remove('show');
+            pinSuccess.classList.remove('show');
+        }
+
+        // Validate PIN
+        function validatePin() {
+            const pinInput = document.getElementById('pinInput');
+            const pin = pinInput.value;
+            const pinError = document.getElementById('pinError');
+            const pinSuccess = document.getElementById('pinSuccess');
+
+            // Hide any previous messages
+            pinError.classList.remove('show');
+            pinSuccess.classList.remove('show');
+
+            // Simple validation
+            if (pin === '1111') {
+                // User 1
+                localStorage.setItem('userPin', '1111');
+                localStorage.setItem('userSession', 'active');
+                localStorage.setItem('userType', 'user1');
+                localStorage.setItem('userLoginTime', new Date().toISOString());
+
+                // Log user login if API is available
+                if (typeof pywebview !== 'undefined' && pywebview.api) {
+                    try {
+                        pywebview.api.log_user_login('User 1', 'user1@example.com');
+                    } catch (error) {
+                        console.log('Could not log user login:', error);
+                    }
+                }
+
+                // Show success and redirect
+                pinSuccess.classList.add('show');
+                setTimeout(() => {
+                    window.location.href = 'chat.html';
+                }, 1000);
+
+            } else if (pin === '2222') {
+                // User 2
+                localStorage.setItem('userPin', '2222');
+                localStorage.setItem('userSession', 'active');
+                localStorage.setItem('userType', 'user2');
+                localStorage.setItem('userLoginTime', new Date().toISOString());
+
+                // Log user login if API is available
+                if (typeof pywebview !== 'undefined' && pywebview.api) {
+                    try {
+                        pywebview.api.log_user_login('User 2', 'user2@example.com');
+                    } catch (error) {
+                        console.log('Could not log user login:', error);
+                    }
+                }
+
+                // Show success and redirect
+                pinSuccess.classList.add('show');
+                setTimeout(() => {
+                    window.location.href = 'chat.html';
+                }, 1000);
+
+            } else {
+                // Invalid PIN
+                pinError.classList.add('show');
+                pinInput.value = '';
+                pinInput.focus();
+            }
+        }
+
+        // Close modal when clicking outside
+        document.getElementById('pinModal').addEventListener('click', function(e) {
+            if (e.target === this) {
+                closePinDialog();
+            }
+        });
+
+        // Handle ESC key
+        document.addEventListener('keydown', function(e) {
+            if (e.key === 'Escape') {
+                closePinDialog();
+            }
+        });
+    </script>
+</body>
+</html>
diff --git a/frontend/html/admin.html b/frontend/html/admin.html
new file mode 100644
index 0000000..9d9e691
--- /dev/null
+++ b/frontend/html/admin.html
@@ -0,0 +1,1172 @@
+<!DOCTYPE html>
+<html lang="en">
+<head>
+    <meta charset="UTF-8">
+    <meta name="viewport" content="width=device-width, initial-scale=1.0">
+    <title>Admin Dashboard - AI4ORG</title>
+    <style>
+        :root {
+            --bg: #0b0a14;
+            --text: #e8e6ff;
+            --muted: #b7b5d3;
+            --glass: rgba(255,255,255,0.06);
+            --accent: #6c53ff;
+            --accent-2: #b388ff;
+            --border: rgba(255,255,255,0.15);
+            --shadow: rgba(0,0,0,0.35);
+            --success: #4ade80;
+            --warning: #fbbf24;
+            --error: #ef4444;
+        }
+
+        * {
+            margin: 0;
+            padding: 0;
+            box-sizing: border-box;
+            font-family: ui-sans-serif, system-ui, -apple-system, 'Segoe UI', Roboto, Helvetica, Arial, sans-serif;
+        }
+
+        body {
+            background: var(--bg);
+            color: var(--text);
+            min-height: 100vh;
+            overflow-x: hidden;
+        }
+
+        /* Background Video */
+        #bgVideo {
+            position: fixed;
+            inset: 0;
+            width: 100vw;
+            height: 100%;
+            object-fit: cover;
+            z-index: -2;
+        }
+
+        /* Overlay */
+        .overlay {
+            position: fixed;
+            inset: 0;
+            z-index: -1;
+            background:
+                radial-gradient(60rem 25rem at 50% 80%, rgba(150, 97, 255, 0.55), rgba(108,83,255,0.15) 35%, rgba(0,0,0,0) 65%),
+                radial-gradient(1400px 600px at 50% 110%, rgba(255,255,255,0.22), rgba(255,255,255,0.0) 60%);
+            pointer-events: none;
+        }
+
+        .overlay::after {
+            content: '';
+            position: absolute;
+            inset: 0;
+            background-image: radial-gradient(rgba(255,255,255,0.55) 1px, transparent 1px);
+            background-size: 3px 3px;
+            opacity: 0.08;
+            mask-image: radial-gradient(60rem 30rem at 50% 70%, black, transparent 70%);
+        }
+
+        /* Header */
+        .header {
+            position: fixed;
+            top: 0;
+            left: 0;
+            right: 0;
+            display: flex;
+            align-items: center;
+            justify-content: space-between;
+            padding: 14px 24px;
+            backdrop-filter: blur(10px);
+            background: linear-gradient(to bottom, rgba(0,0,0,0.35), rgba(0,0,0,0.0));
+            z-index: 100;
+        }
+
+        .brand {
+            display: flex;
+            align-items: center;
+            gap: 0.6rem;
+            font-weight: 700;
+        }
+
+        .brand-logo {
+            width: 28px;
+            height: 28px;
+            border-radius: 10px;
+            display: grid;
+            place-items: center;
+            background: linear-gradient(135deg, var(--accent), var(--accent-2));
+            color: white;
+            font-size: 14px;
+        }
+
+        .back-btn {
+            background: var(--glass);
+            border: 1px solid var(--border);
+            border-radius: 20px;
+            padding: 8px 16px;
+            color: var(--muted);
+            font-size: 0.9rem;
+            cursor: pointer;
+            transition: all 0.3s ease;
+            display: flex;
+            align-items: center;
+            gap: 8px;
+            text-decoration: none;
+        }
+
+        .back-btn:hover {
+            background: rgba(255, 255, 255, 0.1);
+            color: var(--text);
+        }
+
+        /* Admin Container */
+        .admin-container {
+            min-height: 100vh;
+            padding: 100px 20px 40px;
+            max-width: 1400px;
+            margin: 0 auto;
+        }
+
+        /* Admin Header */
+        .admin-header {
+            text-align: center;
+            margin-bottom: 40px;
+            padding: 20px;
+            background: var(--glass);
+            backdrop-filter: blur(12px);
+            border: 1px solid var(--border);
+            border-radius: 20px;
+            box-shadow: 0 8px 24px var(--shadow);
+        }
+
+        .admin-header h1 {
+            font-size: 2.5rem;
+            font-weight: 700;
+            margin-bottom: 10px;
+            background: linear-gradient(135deg, var(--text), var(--muted));
+            -webkit-background-clip: text;
+            -webkit-text-fill-color: transparent;
+            display: flex;
+            align-items: center;
+            justify-content: center;
+            gap: 15px;
+        }
+
+        .admin-header p {
+            font-size: 1.1rem;
+            color: var(--muted);
+        }
+
+        /* Admin Navigation */
+        .admin-nav {
+            display: flex;
+            gap: 15px;
+            margin-bottom: 40px;
+            flex-wrap: wrap;
+            justify-content: center;
+        }
+
+        .nav-btn {
+            background: var(--glass);
+            backdrop-filter: blur(12px);
+            border: 1px solid var(--border);
+            border-radius: 15px;
+            padding: 15px 25px;
+            color: var(--text);
+            cursor: pointer;
+            transition: all 0.3s ease;
+            display: flex;
+            align-items: center;
+            gap: 10px;
+            font-weight: 600;
+            text-decoration: none;
+            box-shadow: 0 4px 12px var(--shadow);
+        }
+
+        .nav-btn:hover {
+            transform: translateY(-5px);
+            box-shadow: 0 8px 20px rgba(108, 83, 255, 0.2);
+            border-color: var(--accent);
+        }
+
+        .nav-btn.active {
+            background: linear-gradient(135deg, var(--accent), var(--accent-2));
+            color: white;
+            border-color: var(--accent);
+        }
+
+        /* Content Sections */
+        .content-section {
+            display: none;
+            animation: fadeIn 0.5s ease forwards;
+        }
+
+        .content-section.active {
+            display: block;
+        }
+
+        @keyframes fadeIn {
+            from { opacity: 0; transform: translateY(20px); }
+            to { opacity: 1; transform: translateY(0); }
+        }
+
+        /* Section Styling */
+        .section {
+            background: var(--glass);
+            backdrop-filter: blur(12px);
+            border: 1px solid var(--border);
+            border-radius: 20px;
+            padding: 30px;
+            margin-bottom: 30px;
+            box-shadow: 0 8px 24px var(--shadow);
+        }
+
+        .section-title {
+            font-size: 1.5rem;
+            font-weight: 700;
+            margin-bottom: 25px;
+            color: var(--text);
+            display: flex;
+            align-items: center;
+            gap: 10px;
+        }
+
+        /* Stats Grid */
+        .stats-grid {
+            display: grid;
+            grid-template-columns: repeat(auto-fit, minmax(200px, 1fr));
+            gap: 20px;
+            margin-bottom: 30px;
+        }
+
+        .stat-card {
+            background: rgba(255, 255, 255, 0.05);
+            border: 1px solid var(--border);
+            border-radius: 15px;
+            padding: 25px 20px;
+            text-align: center;
+            transition: all 0.3s ease;
+        }
+
+        .stat-card:hover {
+            transform: translateY(-5px);
+            box-shadow: 0 8px 20px rgba(108, 83, 255, 0.2);
+            border-color: var(--accent);
+        }
+
+        .stat-card h3 {
+            font-size: 2.5rem;
+            font-weight: 700;
+            margin-bottom: 10px;
+            color: var(--accent);
+        }
+
+        .stat-card p {
+            color: var(--muted);
+            font-size: 0.9rem;
+        }
+
+        /* User List */
+        .user-list {
+            display: grid;
+            gap: 15px;
+        }
+
+        .user-card {
+            background: rgba(255, 255, 255, 0.05);
+            border: 1px solid var(--border);
+            border-radius: 15px;
+            padding: 20px;
+            display: flex;
+            align-items: center;
+            justify-content: space-between;
+            transition: all 0.3s ease;
+        }
+
+        .user-card:hover {
+            transform: translateY(-3px);
+            box-shadow: 0 5px 15px rgba(108, 83, 255, 0.2);
+            border-color: var(--accent);
+        }
+
+        .user-info {
+            display: flex;
+            align-items: center;
+            gap: 15px;
+        }
+
+        .user-avatar {
+            width: 50px;
+            height: 50px;
+            border-radius: 50%;
+            background: linear-gradient(135deg, var(--accent), var(--accent-2));
+            display: flex;
+            align-items: center;
+            justify-content: center;
+            color: white;
+            font-weight: bold;
+        }
+
+        .user-details h4 {
+            font-size: 1.1rem;
+            margin-bottom: 5px;
+        }
+
+        .user-details p {
+            color: var(--muted);
+            font-size: 0.9rem;
+        }
+
+        .user-status {
+            display: flex;
+            align-items: center;
+            gap: 10px;
+        }
+
+        .status-indicator {
+            width: 10px;
+            height: 10px;
+            border-radius: 50%;
+        }
+
+        .status-active {
+            background: var(--success);
+        }
+
+        .status-inactive {
+            background: var(--muted);
+        }
+
+        /* Upload Area */
+        .upload-area {
+            border: 2px dashed var(--border);
+            border-radius: 15px;
+            padding: 40px 20px;
+            text-align: center;
+            transition: all 0.3s ease;
+            cursor: pointer;
+            margin-bottom: 20px;
+        }
+
+        .upload-area:hover {
+            border-color: var(--accent);
+            background: rgba(108, 83, 255, 0.05);
+        }
+
+        .upload-area i {
+            font-size: 3rem;
+            color: var(--accent);
+            margin-bottom: 15px;
+        }
+
+        .upload-area h3 {
+            font-size: 1.3rem;
+            margin-bottom: 10px;
+        }
+
+        .upload-area p {
+            color: var(--muted);
+            margin-bottom: 20px;
+        }
+
+        .file-input {
+            display: none;
+        }
+
+        .upload-btn {
+            background: linear-gradient(135deg, var(--accent), var(--accent-2));
+            border: none;
+            border-radius: 12px;
+            padding: 12px 24px;
+            color: white;
+            font-weight: 600;
+            cursor: pointer;
+            transition: all 0.3s ease;
+            display: inline-flex;
+            align-items: center;
+            gap: 8px;
+        }
+
+        .upload-btn:hover {
+            transform: translateY(-2px);
+            box-shadow: 0 6px 16px rgba(108, 83, 255, 0.4);
+        }
+
+        /* GPU Stats */
+        .gpu-stats {
+            display: grid;
+            grid-template-columns: repeat(auto-fit, minmax(250px, 1fr));
+            gap: 20px;
+        }
+
+        .gpu-card {
+            background: rgba(255, 255, 255, 0.05);
+            border: 1px solid var(--border);
+            border-radius: 15px;
+            padding: 20px;
+        }
+
+        .gpu-card h4 {
+            font-size: 1.1rem;
+            margin-bottom: 15px;
+            color: var(--text);
+        }
+
+        .progress-bar {
+            height: 10px;
+            background: rgba(255, 255, 255, 0.1);
+            border-radius: 5px;
+            overflow: hidden;
+            margin-bottom: 10px;
+        }
+
+        .progress-fill {
+            height: 100%;
+            background: linear-gradient(90deg, var(--accent), var(--accent-2));
+            border-radius: 5px;
+            transition: width 0.5s ease;
+        }
+
+        .gpu-info {
+            display: flex;
+            justify-content: space-between;
+            font-size: 0.9rem;
+            color: var(--muted);
+        }
+
+        /* Button Groups */
+        .btn-group {
+            display: flex;
+            gap: 15px;
+            flex-wrap: wrap;
+        }
+
+        .btn {
+            border: none;
+            border-radius: 12px;
+            padding: 12px 24px;
+            font-weight: 600;
+            cursor: pointer;
+            transition: all 0.3s ease;
+            display: inline-flex;
+            align-items: center;
+            gap: 8px;
+        }
+
+        .btn-primary {
+            background: linear-gradient(135deg, var(--accent), var(--accent-2));
+            color: white;
+            box-shadow: 0 4px 12px rgba(108, 83, 255, 0.3);
+        }
+
+        .btn-primary:hover {
+            transform: translateY(-2px);
+            box-shadow: 0 6px 16px rgba(108, 83, 255, 0.4);
+        }
+
+        .btn-secondary {
+            background: var(--glass);
+            color: var(--text);
+            border: 1px solid var(--border);
+        }
+
+        .btn-secondary:hover {
+            background: rgba(255, 255, 255, 0.1);
+        }
+
+        /* Settings Grid */
+        .settings-grid {
+            display: grid;
+            grid-template-columns: repeat(auto-fit, minmax(300px, 1fr));
+            gap: 30px;
+            margin-bottom: 30px;
+        }
+
+        .setting-group {
+            margin-bottom: 20px;
+        }
+
+        .setting-label {
+            display: block;
+            margin-bottom: 8px;
+            font-weight: 600;
+            color: var(--text);
+        }
+
+        .setting-input {
+            width: 100%;
+            padding: 12px 15px;
+            background: rgba(255, 255, 255, 0.05);
+            border: 1px solid var(--border);
+            border-radius: 10px;
+            color: var(--text);
+            font-size: 1rem;
+            outline: none;
+            transition: all 0.3s ease;
+        }
+
+        .setting-input:focus {
+            border-color: var(--accent);
+            box-shadow: 0 0 0 3px rgba(108, 83, 255, 0.1);
+        }
+
+        .checkbox-group {
+            display: flex;
+            align-items: center;
+            gap: 10px;
+            margin-bottom: 15px;
+        }
+
+        .checkbox-group input {
+            width: 18px;
+            height: 18px;
+        }
+
+        /* Status Messages */
+        .loading, .error, .no-data {
+            padding: 20px;
+            text-align: center;
+            border-radius: 15px;
+            margin: 20px 0;
+            display: flex;
+            align-items: center;
+            justify-content: center;
+            gap: 10px;
+        }
+
+        .loading {
+            background: rgba(59, 130, 246, 0.1);
+            color: #3b82f6;
+        }
+
+        .error {
+            background: rgba(239, 68, 68, 0.1);
+            color: var(--error);
+        }
+
+        .no-data {
+            background: rgba(107, 114, 128, 0.1);
+            color: var(--muted);
+        }
+
+        /* Icon Styles */
+        .icon {
+            width: 24px;
+            height: 24px;
+            fill: currentColor;
+        }
+
+        .icon-small {
+            width: 16px;
+            height: 16px;
+        }
+
+        /* Responsive Design */
+        @media (max-width: 768px) {
+            .admin-container {
+                padding: 80px 15px 30px;
+            }
+
+            .admin-nav {
+                flex-direction: column;
+            }
+
+            .nav-btn {
+                justify-content: center;
+            }
+
+            .stats-grid {
+                grid-template-columns: repeat(2, 1fr);
+            }
+
+            .btn-group {
+                flex-direction: column;
+            }
+
+            .btn {
+                width: 100%;
+                justify-content: center;
+            }
+
+            .settings-grid {
+                grid-template-columns: 1fr;
+            }
+        }
+
+        @media (max-width: 480px) {
+            .admin-container {
+                padding: 70px 10px 20px;
+            }
+
+            .admin-header h1 {
+                font-size: 2rem;
+            }
+
+            .stats-grid {
+                grid-template-columns: 1fr;
+            }
+
+            .user-card {
+                flex-direction: column;
+                align-items: flex-start;
+                gap: 15px;
+            }
+
+            .user-status {
+                align-self: flex-end;
+            }
+        }
+
+        /* Scrollbar */
+        ::-webkit-scrollbar {
+            width: 8px;
+        }
+
+        ::-webkit-scrollbar-track {
+            background: var(--glass);
+            border-radius: 10px;
+        }
+
+        ::-webkit-scrollbar-thumb {
+            background: rgba(108, 83, 255, 0.3);
+            border-radius: 10px;
+            transition: all 0.3s ease;
+        }
+
+        ::-webkit-scrollbar-thumb:hover {
+            background: rgba(108, 83, 255, 0.5);
+        }
+    </style>
+</head>
+<body>
+    <!-- Background Video -->
+    <video id="bgVideo" autoplay muted loop playsinline>
+        <source src="../assets/images/bg.mp4" type="video/mp4" />
+    </video>
+
+    <!-- Overlay -->
+    <div class="overlay"></div>
+
+    <!-- Header -->
+    <header class="header">
+        <img src="../assets/images/logo.png" alt="AI4ORG Logo" height="100" width="100" style="border-radius: 50%;">
+
+        <a href="index.html" class="back-btn">
+            <svg class="icon icon-small" viewBox="0 0 24 24" fill="currentColor">
+                <path d="M20 11H7.83l5.59-5.59L12 4l-8 8 8 8 1.41-1.41L7.83 13H20v-2z"/>
+            </svg>
+            Back to Home
+        </a>
+    </header>
+
+    <!-- Admin Container -->
+    <div class="admin-container">
+        <div class="admin-header">
+            <h1>
+                <svg class="icon" viewBox="0 0 24 24" fill="currentColor">
+                    <path d="M12 1L3 5v6c0 5.55 3.84 10.74 9 12 5.16-1.26 9-6.45 9-12V5l-9-4zm0 10.99h7c-.53 4.12-3.28 7.79-7 8.94V12H5V6.3l7-3.11v8.8z"/>
+                </svg>
+                Admin Dashboard
+            </h1>
+            <p>Complete System Management & Monitoring</p>
+        </div>
+
+        <div class="admin-nav">
+            <button class="nav-btn active" onclick="showSection('dashboard')">
+                <svg class="icon" viewBox="0 0 24 24" fill="currentColor">
+                    <path d="M3 13h8V3H3v10zm0 8h8v-6H3v6zm10 0h8V11h-8v10zm0-18v6h8V3h-8z"/>
+                </svg>
+                Dashboard
+            </button>
+            <button class="nav-btn" onclick="showSection('users')">
+                <svg class="icon" viewBox="0 0 24 24" fill="currentColor">
+                    <path d="M16 4c0-1.11.89-2 2-2s2 .89 2 2-.89 2-2 2-2-.89-2-2zm4 18v-6h2.5l-2.54-7.63A2.01 2.01 0 0 0 18.06 7h-.12a2 2 0 0 0-1.9 1.37l-.86 2.58c1.08.6 1.82 1.73 1.82 3.05v8h3zm-7.5-10.5c.83 0 1.5-.67 1.5-1.5s-.67-1.5-1.5-1.5S11 9.17 11 10s.67 1.5 1.5 1.5zM5.5 6c1.11 0 2-.89 2-2s-.89-2-2-2-2 .89-2 2 .89 2 2 2zm2 16v-7H9c.55 0 1-.45 1-1v-4c0-.55-.45-1-1-1H4c-.55 0-1 .45-1 1v4c0 .55.45 1 1 1h1.5v7h3zm6.5 0v-4h1v-2.5c0-1.1-.9-2-2-2H11c-1.1 0-2 .9-2 2V16h1v4h4z"/>
+                </svg>
+                Users
+            </button>
+            <a href="./upload.html" style="text-decoration: none;">
+                <button class="nav-btn">
+                    <svg class="icon" viewBox="0 0 24 24" fill="currentColor">
+                        <path d="M19.35 10.04C18.67 6.59 15.64 4 12 4 9.11 4 6.6 5.64 5.35 8.04 2.34 8.36 0 10.91 0 14c0 3.31 2.69 6 6 6h13c2.76 0 5-2.24 5-5 0-2.64-2.05-4.78-4.65-4.96zM14 13v4h-4v-4H7l5-5 5 5h-3z"/>
+                    </svg>
+                    Files
+                </button>
+            </a>
+            <button class="nav-btn" onclick="showSection('gpu')">
+                <svg class="icon" viewBox="0 0 24 24" fill="currentColor">
+                    <path d="M4 6H2v14c0 1.1.9 2 2 2h14v-2H4V6zm16-4H8c-1.1 0-2 .9-2 2v12c0 1.1.9 2 2 2h12c1.1 0 2-.9 2-2V4c0-1.1-.9-2-2-2zm0 14H8V4h12v12zM12 5.5v9l6-4.5z"/>
+                </svg>
+                GPU Monitoring
+            </button>
+            <button class="nav-btn" onclick="showSection('chatbot')">
+                <svg class="icon" viewBox="0 0 24 24" fill="currentColor">
+                    <path d="M20 2H4c-1.1 0-2 .9-2 2v18l4-4h14c1.1 0 2-.9 2-2V4c0-1.1-.9-2-2-2zM6 14v-2.47l6.88-6.88c.2-.2.51-.2.71 0l1.77 1.77c.2.2.2.51 0 .71L8.47 14H6zm11 0h-5.5l2-2H17c.55 0 1 .45 1 1s-.45 1-1 1z"/>
+                </svg>
+                Chatbot
+            </button>
+            <button class="nav-btn" onclick="showSection('settings')">
+                <svg class="icon" viewBox="0 0 24 24" fill="currentColor">
+                    <path d="M19.14 12.94c.04-.3.06-.61.06-.94 0-.32-.02-.64-.07-.94l2.03-1.58c.18-.14.23-.41.12-.61l-1.92-3.32c-.12-.22-.37-.29-.59-.22l-2.39.96c-.5-.38-1.03-.7-1.62-.94l-.36-2.54c-.04-.24-.24-.41-.48-.41h-3.84c-.24 0-.43.17-.47.41l-.36 2.54c-.59.24-1.13.57-1.62.94l-2.39-.96c-.22-.08-.47 0-.59.22L2.74 8.87c-.12.21-.08.47.12.61l2.03 1.58c-.05.3-.09.63-.09.94s.02.64.07.94l-2.03 1.58c-.18.14-.23.41-.12.61l1.92 3.32c.12.22.37.29.59.22l2.39-.96c.5.38 1.03.7 1.62.94l.36 2.54c.05.24.24.41.48.41h3.84c.24 0 .44-.17.47-.41l.36-2.54c.59-.24 1.13-.56 1.62-.94l2.39.96c.22.08.47 0 .59-.22l1.92-3.32c.12-.22.07-.47-.12-.61l-2.01-1.58zM12 15.6c-1.98 0-3.6-1.62-3.6-3.6s1.62-3.6 3.6-3.6 3.6 1.62 3.6 3.6-1.62 3.6-3.6 3.6z"/>
+                </svg>
+                Settings
+            </button>
+        </div>
+
+        <!-- Dashboard Section -->
+        <div id="dashboard" class="content-section active">
+            <div class="stats-grid">
+                <div class="stat-card">
+                    <h3 id="totalUsers">0</h3>
+                    <p>Total Users</p>
+                </div>
+                <div class="stat-card">
+                    <h3 id="totalLogins">0</h3>
+                    <p>Total Logins</p>
+                </div>
+                <div class="stat-card">
+                    <h3 id="activeUsers">0</h3>
+                    <p>Active Users</p>
+                </div>
+                <div class="stat-card">
+                    <h3 id="gpuUsage">0%</h3>
+                    <p>GPU Usage</p>
+                </div>
+            </div>
+
+            <div class="section">
+                <h2 class="section-title">
+                    <svg class="icon" viewBox="0 0 24 24" fill="currentColor">
+                        <path d="M16 11c1.66 0 2.99-1.34 2.99-3S17.66 5 16 5c-1.66 0-3 1.34-3 3s1.34 3 3 3zm-8 0c1.66 0 2.99-1.34 2.99-3S9.66 5 8 5C6.34 5 5 6.34 5 8s1.34 3 3 3zm0 2c-2.33 0-7 1.17-7 3.5V19h14v-2.5c0-2.33-4.67-3.5-7-3.5zm8 0c-.29 0-.62.02-.97.05 1.16.84 1.97 1.97 1.97 3.45V19h6v-2.5c0-2.33-4.67-3.5-7-3.5z"/>
+                    </svg>
+                    System Overview
+                </h2>
+                <div id="systemStats">
+                    <!-- System stats will be loaded here -->
+                </div>
+            </div>
+        </div>
+
+        <!-- Users Section -->
+        <div id="users" class="content-section">
+            <div class="section">
+                <h2 class="section-title">
+                    <svg class="icon" viewBox="0 0 24 24" fill="currentColor">
+                        <path d="M16 4c0-1.11.89-2 2-2s2 .89 2 2-.89 2-2 2-2-.89-2-2zm4 18v-6h2.5l-2.54-7.63A2.01 2.01 0 0 0 18.06 7h-.12a2 2 0 0 0-1.9 1.37l-.86 2.58c1.08.6 1.82 1.73 1.82 3.05v8h3zm-7.5-10.5c.83 0 1.5-.67 1.5-1.5s-.67-1.5-1.5-1.5S11 9.17 11 10s.67 1.5 1.5 1.5zM5.5 6c1.11 0 2-.89 2-2s-.89-2-2-2-2 .89-2 2 .89 2 2 2zm2 16v-7H9c.55 0 1-.45 1-1v-4c0-.55-.45-1-1-1H4c-.55 0-1 .45-1 1v4c0 .55.45 1 1 1h1.5v7h3zm6.5 0v-4h1v-2.5c0-1.1-.9-2-2-2H11c-1.1 0-2 .9-2 2V16h1v4h4z"/>
+                    </svg>
+                    User Management
+                </h2>
+                <div id="userList" class="user-list">
+                    <!-- User data will be loaded here -->
+                </div>
+            </div>
+        </div>
+
+        <!-- GPU Monitoring Section -->
+        <div id="gpu" class="content-section">
+            <div class="section">
+                <h2 class="section-title">
+                    <svg class="icon" viewBox="0 0 24 24" fill="currentColor">
+                        <path d="M4 6H2v14c0 1.1.9 2 2 2h14v-2H4V6zm16-4H8c-1.1 0-2 .9-2 2v12c0 1.1.9 2 2 2h12c1.1 0 2-.9 2-2V4c0-1.1-.9-2-2-2zm0 14H8V4h12v12zM12 5.5v9l6-4.5z"/>
+                    </svg>
+                    GPU Monitoring
+                </h2>
+                <div class="gpu-stats" id="gpuStats">
+                    <!-- GPU stats will be loaded here -->
+                </div>
+            </div>
+        </div>
+
+        <!-- Chatbot Section -->
+        <div id="chatbot" class="content-section">
+            <div class="section">
+                <h2 class="section-title">
+                    <svg class="icon" viewBox="0 0 24 24" fill="currentColor">
+                        <path d="M20 2H4c-1.1 0-2 .9-2 2v18l4-4h14c1.1 0 2-.9 2-2V4c0-1.1-.9-2-2-2zM6 14v-2.47l6.88-6.88c.2-.2.51-.2.71 0l1.77 1.77c.2.2.2.51 0 .71L8.47 14H6zm11 0h-5.5l2-2H17c.55 0 1 .45 1 1s-.45 1-1 1z"/>
+                    </svg>
+                    Chatbot Management
+                </h2>
+                <div class="btn-group">
+                    <button class="btn btn-primary" onclick="openChatbot()">
+                        <svg class="icon icon-small" viewBox="0 0 24 24" fill="currentColor">
+                            <path d="M20 2H4c-1.1 0-2 .9-2 2v18l4-4h14c1.1 0 2-.9 2-2V4c0-1.1-.9-2-2-2z"/>
+                        </svg>
+                        Open Chatbot
+                    </button>
+                    <button class="btn btn-secondary" onclick="restartChatbot()">
+                        <svg class="icon icon-small" viewBox="0 0 24 24" fill="currentColor">
+                            <path d="M17.65 6.35C16.2 4.9 14.21 4 12 4c-4.42 0-7.99 3.58-7.99 8s3.57 8 7.99 8c3.73 0 6.84-2.55 7.73-6h-2.08c-.82 2.33-3.04 4-5.65 4-3.31 0-6-2.69-6-6s2.69-6 6-6c1.66 0 3.14.69 4.22 1.78L13 11h7V4l-2.35 2.35z"/>
+                        </svg>
+                        Restart Chatbot
+                    </button>
+                    <button class="btn btn-secondary" onclick="viewChatbotLogs()">
+                        <svg class="icon icon-small" viewBox="0 0 24 24" fill="currentColor">
+                            <path d="M14 2H6c-1.1 0-1.99.9-1.99 2L4 20c0 1.1.89 2 1.99 2H18c1.1 0 2-.9 2-2V8l-6-6zm2 16H8v-2h8v2zm0-4H8v-2h8v2zm-3-5V3.5L18.5 9H13z"/>
+                        </svg>
+                        View Logs
+                    </button>
+                </div>
+                <div id="chatbotStatus" style="margin-top: 20px;">
+                    <!-- Chatbot status will be shown here -->
+                </div>
+            </div>
+        </div>
+
+        <!-- Settings Section -->
+        <div id="settings" class="content-section">
+            <div class="section">
+                <h2 class="section-title">
+                    <svg class="icon" viewBox="0 0 24 24" fill="currentColor">
+                        <path d="M19.14 12.94c.04-.3.06-.61.06-.94 0-.32-.02-.64-.07-.94l2.03-1.58c.18-.14.23-.41.12-.61l-1.92-3.32c-.12-.22-.37-.29-.59-.22l-2.39.96c-.5-.38-1.03-.7-1.62-.94l-.36-2.54c-.04-.24-.24-.41-.48-.41h-3.84c-.24 0-.43.17-.47.41l-.36 2.54c-.59.24-1.13.57-1.62.94l-2.39-.96c-.22-.08-.47 0-.59.22L2.74 8.87c-.12.21-.08.47.12.61l2.03 1.58c-.05.3-.09.63-.09.94s.02.64.07.94l-2.03 1.58c-.18.14-.23.41-.12.61l1.92 3.32c.12.22.37.29.59.22l2.39-.96c.5.38 1.03.7 1.62.94l.36 2.54c.05.24.24.41.48.41h3.84c.24 0 .44-.17.47-.41l.36-2.54c.59-.24 1.13-.56 1.62-.94l2.39.96c.22.08.47 0 .59-.22l1.92-3.32c.12-.22.07-.47-.12-.61l-2.01-1.58zM12 15.6c-1.98 0-3.6-1.62-3.6-3.6s1.62-3.6 3.6-3.6 3.6 1.62 3.6 3.6-1.62 3.6-3.6 3.6z"/>
+                    </svg>
+                    System Settings
+                </h2>
+                <div class="settings-grid">
+                    <div>
+                        <h3 style="color: var(--accent); margin-bottom: 20px;">General Settings</h3>
+                        <div class="setting-group">
+                            <label class="setting-label">Admin PIN</label>
+                            <input type="password" class="setting-input" id="adminPin" placeholder="Enter new PIN">
+                        </div>
+                        <div class="setting-group">
+                            <label class="setting-label">Session Timeout (minutes)</label>
+                            <input type="number" class="setting-input" id="sessionTimeout" value="30">
+                        </div>
+                        <div class="checkbox-group">
+                            <input type="checkbox" id="autoBackup" checked>
+                            <label class="setting-label">Enable Auto Backup</label>
+                        </div>
+                    </div>
+                    <div>
+                        <h3 style="color: var(--accent); margin-bottom: 20px;">GPU Settings</h3>
+                        <div class="setting-group">
+                            <label class="setting-label">VRAM Allocation (%)</label>
+                            <input type="range" class="setting-input" id="vramAllocation" min="10" max="100" value="80">
+                            <span id="vramValue">80%</span>
+                        </div>
+                        <div class="checkbox-group">
+                            <input type="checkbox" id="gpuMonitoring" checked>
+                            <label class="setting-label">Enable GPU Monitoring</label>
+                        </div>
+                    </div>
+                </div>
+                <div class="btn-group">
+                    <button class="btn btn-primary" onclick="saveSettings()">
+                        <svg class="icon icon-small" viewBox="0 0 24 24" fill="currentColor">
+                            <path d="M17 3H5c-1.11 0-2 .9-2 2v14c0 1.1.89 2 2 2h14c1.1 0 2-.9 2-2V7l-4-4zm-5 16c-1.66 0-3-1.34-3-3s1.34-3 3-3 3 1.34 3 3-1.34 3-3 3zm3-10H5V5h10v4z"/>
+                        </svg>
+                        Save Settings
+                    </button>
+                    <button class="btn btn-secondary" onclick="resetSettings()">
+                        <svg class="icon icon-small" viewBox="0 0 24 24" fill="currentColor">
+                            <path d="M17.65 6.35C16.2 4.9 14.21 4 12 4c-4.42 0-7.99 3.58-7.99 8s3.57 8 7.99 8c3.73 0 6.84-2.55 7.73-6h-2.08c-.82 2.33-3.04 4-5.65 4-3.31 0-6-2.69-6-6s2.69-6 6-6c1.66 0 3.14.69 4.22 1.78L13 11h7V4l-2.35 2.35z"/>
+                        </svg>
+                        Reset to Default
+                    </button>
+                </div>
+            </div>
+        </div>
+
+        <!-- Loading and Error Messages -->
+        <div id="loadingMessage" class="loading" style="display: none;">
+            <svg class="icon icon-small" viewBox="0 0 24 24" fill="currentColor">
+                <path d="M12 2C6.48 2 2 6.48 2 12s4.48 10 10 10 10-4.48 10-10S17.52 2 12 2zm0 18c-4.42 0-8-3.58-8-8s3.58-8 8-8 8 3.58 8 8-3.58 8-8 8z"/>
+                <path d="M12 6c-3.31 0-6 2.69-6 6s2.69 6 6 6 6-2.69 6-6-2.69-6-6-6zm0 10c-2.21 0-4-1.79-4-4s1.79-4 4-4 4 1.79 4 4-1.79 4-4 4z"/>
+            </svg>
+            Loading data...
+        </div>
+
+        <div id="errorMessage" class="error" style="display: none;"></div>
+
+        <div id="noDataMessage" class="no-data" style="display: none;">
+            <svg class="icon icon-small" viewBox="0 0 24 24" fill="currentColor">
+                <path d="M12 2C6.48 2 2 6.48 2 12s4.48 10 10 10 10-4.48 10-10S17.52 2 12 2zm1 15h-2v-2h2v2zm0-4h-2V7h2v6z"/>
+            </svg>
+            No data available yet.
+        </div>
+    </div>
+
+    <script>
+        // Admin PIN for authentication
+        const ADMIN_PIN = "9999";
+
+        // Navigation function
+        function showSection(sectionId) {
+            // Hide all sections
+            document.querySelectorAll('.content-section').forEach(section => {
+                section.classList.remove('active');
+            });
+
+            // Remove active class from all buttons
+            document.querySelectorAll('.nav-btn').forEach(btn => {
+                btn.classList.remove('active');
+            });
+
+            // Show selected section
+            document.getElementById(sectionId).classList.add('active');
+
+            // Add active class to clicked button
+            event.currentTarget.classList.add('active');
+
+            // Load section-specific data
+            switch(sectionId) {
+                case 'dashboard':
+                    loadDashboardData();
+                    break;
+                case 'users':
+                    loadUserData();
+                    break;
+                case 'gpu':
+                    loadGPUData();
+                    break;
+                case 'chatbot':
+                    loadChatbotStatus();
+                    break;
+            }
+        }
+
+        // File upload handling
+        document.getElementById('fileInput').addEventListener('change', handleFileUpload);
+        document.getElementById('uploadArea').addEventListener('dragover', handleDragOver);
+        document.getElementById('uploadArea').addEventListener('drop', handleDrop);
+
+        function handleDragOver(e) {
+            e.preventDefault();
+            e.currentTarget.style.borderColor = 'var(--primary-color)';
+            e.currentTarget.style.background = 'rgba(108, 83, 255, 0.1)';
+        }
+
+        function handleDrop(e) {
+            e.preventDefault();
+            e.currentTarget.style.borderColor = 'rgba(108, 83, 255, 0.3)';
+            e.currentTarget.style.background = 'transparent';
+
+            const files = e.dataTransfer.files;
+            handleFiles(files);
+        }
+
+        function handleFileUpload(e) {
+            const files = e.target.files;
+            handleFiles(files);
+        }
+
+        function handleFiles(files) {
+            const uploadedFiles = document.getElementById('uploadedFiles');
+
+            Array.from(files).forEach(file => {
+                // Simulate file upload
+                const fileItem = document.createElement('div');
+                fileItem.className = 'file-item';
+                fileItem.innerHTML = `
+                    <div class="file-info">
+                        <i class="fas fa-file file-icon"></i>
+                        <div>
+                            <div style="font-weight: 600;">${file.name}</div>
+                            <div style="font-size: 0.8rem; color: var(--text-muted);">
+                                ${(file.size / 1024 / 1024).toFixed(2)} MB
+                            </div>
+                        </div>
+                    </div>
+                    <span class="status-indicator status-online">
+                        <i class="fas fa-check"></i> Uploaded
+                    </span>
+                `;
+                uploadedFiles.appendChild(fileItem);
+            });
+
+            // Show success message
+            showNotification('Files uploaded successfully!', 'success');
+        }
+
+        // Data loading functions
+        async function loadDashboardData() {
+            showLoading();
+            try {
+                // Simulate API calls
+                setTimeout(() => {
+                    document.getElementById('totalUsers').textContent = '1,247';
+                    document.getElementById('totalLogins').textContent = '8,956';
+                    document.getElementById('activeUsers').textContent = '342';
+                    document.getElementById('gpuUsage').textContent = '45%';
+                    hideLoading();
+                }, 1000);
+            } catch (error) {
+                showError('Failed to load dashboard data: ' + error.message);
+            }
+        }
+
+        async function loadUserData() {
+            showLoading();
+            try {
+                // Simulate user data
+                const users = [
+                    { name: 'John Doe', email: 'john@example.com', login_count: 45, last_login: '2 hours ago', status: 'online' },
+                    { name: 'Jane Smith', email: 'jane@example.com', login_count: 23, last_login: '1 day ago', status: 'offline' },
+                    { name: 'Mike Johnson', email: 'mike@example.com', login_count: 67, last_login: '5 minutes ago', status: 'online' },
+                    { name: 'Sarah Wilson', email: 'sarah@example.com', login_count: 12, last_login: '3 days ago', status: 'offline' }
+                ];
+
+                displayUsers(users);
+                hideLoading();
+            } catch (error) {
+                showError('Failed to load user data: ' + error.message);
+            }
+        }
+
+        async function loadGPUData() {
+            showLoading();
+            try {
+                // Simulate GPU data
+                const gpuData = [
+                    { name: 'NVIDIA RTX 4090', vram_used: 12, vram_total: 24, utilization: 45, temperature: 68 },
+                    { name: 'NVIDIA RTX 4080', vram_used: 8, vram_total: 16, utilization: 32, temperature: 55 }
+                ];
+
+                displayGPUData(gpuData);
+                hideLoading();
+            } catch (error) {
+                showError('Failed to load GPU data: ' + error.message);
+            }
+        }
+
+        function displayUsers(users) {
+            const userList = document.getElementById('userList');
+
+            if (users.length === 0) {
+                document.getElementById('noDataMessage').style.display = 'block';
+                return;
+            }
+
+            userList.innerHTML = users.map(user => `
+                <div class="user-item">
+                    <div style="display: flex; justify-content: space-between; align-items: start;">
+                        <div>
+                            <div class="user-name">${user.name}</div>
+                            <div class="user-email">${user.email}</div>
+                        </div>
+                        <span class="status-indicator ${user.status === 'online' ? 'status-online' : 'status-offline'}">
+                            <i class="fas fa-circle"></i> ${user.status}
+                        </span>
+                    </div>
+                    <div class="user-stats">
+                        <span>Logins: <strong>${user.login_count}</strong></span>
+                        <span>Last Login: <strong>${user.last_login}</strong></span>
+                    </div>
+                </div>
+            `).join('');
+        }
+
+        function displayGPUData(gpus) {
+            const gpuStats = document.getElementById('gpuStats');
+
+            gpuStats.innerHTML = gpus.map(gpu => `
+                <div class="gpu-card">
+                    <div class="gpu-info">
+                        <div class="gpu-name">${gpu.name}</div>
+                        <div>VRAM: ${gpu.vram_used}GB / ${gpu.vram_total}GB</div>
+                    </div>
+                    <div class="progress-bar">
+                        <div class="progress-fill" style="width: ${(gpu.vram_used / gpu.vram_total) * 100}%"></div>
+                    </div>
+                    <div class="gpu-details">
+                        <span>Utilization: ${gpu.utilization}%</span>
+                        <span>Temperature: ${gpu.temperature}°C</span>
+                    </div>
+                </div>
+            `).join('');
+        }
+
+        // Chatbot functions
+        function openChatbot() {
+            window.open('chat.html', '_blank');
+        }
+
+        function restartChatbot() {
+            showNotification('Restarting chatbot service...', 'warning');
+            // Simulate restart
+            setTimeout(() => {
+                showNotification('Chatbot service restarted successfully!', 'success');
+                loadChatbotStatus();
+            }, 2000);
+        }
+
+        function viewChatbotLogs() {
+            showNotification('Opening chatbot logs...', 'info');
+            // In a real app, this would open a log viewer
+        }
+
+        function loadChatbotStatus() {
+            const statusDiv = document.getElementById('chatbotStatus');
+            statusDiv.innerHTML = `
+                <div class="stat-card" style="text-align: left; display: inline-block; margin-right: 20px;">
+                    <h3>Online</h3>
+                    <p>Chatbot Status</p>
+                </div>
+                <div class="stat-card" style="text-align: left; display: inline-block;">
+                    <h3>1,234</h3>
+                    <p>Active Conversations</p>
+                </div>
+            `;
+        }
+
+        // Settings functions
+        function saveSettings() {
+            showNotification('Settings saved successfully!', 'success');
+        }
+
+        function resetSettings() {
+            if (confirm('Are you sure you want to reset all settings to default?')) {
+                showNotification('Settings reset to default!', 'info');
+            }
+        }
+
+        // VRAM allocation slider
+        document.getElementById('vramAllocation').addEventListener('input', function() {
+            document.getElementById('vramValue').textContent = this.value + '%';
+        });
+
+        // Utility functions
+        function showLoading() {
+            document.getElementById('loadingMessage').style.display = 'block';
+            document.getElementById('errorMessage').style.display = 'none';
+        }
+
+        function hideLoading() {
+            document.getElementById('loadingMessage').style.display = 'none';
+        }
+
+        function showError(message) {
+            document.getElementById('errorMessage').textContent = message;
+            document.getElementById('errorMessage').style.display = 'block';
+            document.getElementById('loadingMessage').style.display = 'none';
+        }
+
+        function showNotification(message, type = 'info') {
+            // Create notification element
+            const notification = document.createElement('div');
+            notification.className = `status-indicator status-${type}`;
+            notification.style.position = 'fixed';
+            notification.style.top = '20px';
+            notification.style.right = '20px';
+            notification.style.zIndex = '10000';
+            notification.style.padding = '15px 20px';
+            notification.style.borderRadius = '10px';
+            notification.style.boxShadow = '0 5px 15px rgba(0,0,0,0.3)';
+            notification.innerHTML = `
+                <i class="fas fa-${type === 'success' ? 'check' : type === 'error' ? 'exclamation-triangle' : 'info-circle'}"></i>
+                ${message}
+            `;
+
+            document.body.appendChild(notification);
+
+            // Remove notification after 3 seconds
+            setTimeout(() => {
+                notification.remove();
+            }, 3000);
+        }
+
+        // Initialize dashboard on load
+        document.addEventListener('DOMContentLoaded', function() {
+            loadDashboardData();
+            loadChatbotStatus();
+        });
+    </script>
+</body>
+</html>
diff --git a/frontend/html/chat.html b/frontend/html/chat.html
new file mode 100644
index 0000000..8d84003
--- /dev/null
+++ b/frontend/html/chat.html
@@ -0,0 +1,249 @@
+<!DOCTYPE html>
+<html lang="en">
+<head>
+    <meta charset="UTF-8">
+    <meta name="viewport" content="width=device-width, initial-scale=1.0">
+    <title>AI4ORG Chat - Your Personal Intelligence Platform</title>
+    <link rel="stylesheet" href="../css/chat.css">
+    <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/6.4.0/css/all.min.css">
+    <script type="text/javascript" src="https://cdn.jsdelivr.net/npm/@emailjs/browser@3/dist/email.min.js"></script>
+
+
+</head>
+<body>
+<div class="sidebar">
+<div class="logo">
+<svg class="logo-icon" viewBox="0 0 24 24">
+    <path d="M12 2C6.48 2 2 6.48 2 12s4.48 10 10 10 10-4.48 10-10S17.52 2 12 2zm-1 17.93c-3.94-.49-7-3.85-7-7.93 0-.62.08-1.21.21-1.79L9 15v1c0 1.1.9 2 2 2v1.93zm6.9-2.54c-.26-.81-1-1.39-1.9-1.39h-1v-3c0-.55-.45-1-1-1H8v-2h2c.55 0 1-.45 1-1V7h2c1.1 0 2-.9 2-2v-.41c2.93 1.19 5 4.06 5 7.41 0 2.08-.8 3.97-2.1 5.39z"/>
+</svg>
+<span class="logo-text">AI4ORG</span>
+</div>
+
+<!-- Chat -->
+<div class="nav-section">
+<div class="nav-item active">
+    <svg class="nav-icon" viewBox="0 0 24 24">
+        <path d="M20 2H4c-1.1 0-2 .9-2 2v18l4-4h14c1.1 0 2-.9 2-2V4c0-1.1-.9-2-2-2z"/>
+    </svg>
+    <span class="nav-text">Chat</span>
+</div>
+</div>
+
+<div class="nav-section">
+<div class="nav-item" onclick="showChatHistory()">
+    <svg class="nav-icon" viewBox="0 0 24 24">
+        <path d="M13 3c-4.97 0-9 4.03-9 9H1l3.89 3.89.07.14L9 12H6c0-3.87 3.13-7 7-7s7 3.13 7 7-3.13 7-7 7c-1.93 0-3.68-.79-4.94-2.06l-1.42 1.42C8.27 19.99 10.51 21 13 21c4.97 0 9-4.03 9-9s-4.03-9-9-9zm-1 5v5l4.28 2.54.72-1.21-3.5-2.08V8H12z"/>
+    </svg>
+    <span class="nav-text">History</span>
+</div>
+</div>
+
+<!-- Settings -->
+<div class="nav-section">
+<div class="nav-item" onclick="showSettings()">
+    <svg class="nav-icon" viewBox="0 0 24 24">
+        <path d="M19.14 12.94c.04-.3.06-.61.06-.94 0-.32-.02-.64-.07-.94l2.03-1.58c.18-.14.23-.41.12-.61l-1.92-3.32c-.12-.22-.37-.29-.59-.22l-2.39.96c-.5-.38-1.03-.7-1.62-.94l-.36-2.54c-.04-.24-.24-.41-.48-.41h-3.84c-.24 0-.43.17-.47.41l-.36 2.54c-.59.24-1.13.57-1.62.94l-2.39-.96c-.22-.08-.47 0-.59.22L2.74 8.87c-.12.21-.08.47.12.61l2.03 1.58c-.05.3-.09.63-.09.94s.02.64.07.94l-2.03 1.58c-.18.14-.23.41-.12.61l1.92 3.32c.12.22.37.29.59.22l2.39-.96c.5.38 1.03.7 1.62.94l.36 2.54c.05.24.24.41.48.41h3.84c.24 0 .44-.17.47-.41l.36-2.54c.59-.24 1.13-.56 1.62-.94l2.39.96c.22.08.47 0 .59-.22l1.92-3.32c.12-.22.07-.47-.12-.61l-2.01-1.58zM12 15.6c-1.98 0-3.6-1.62-3.6-3.6s1.62-3.6 3.6-3.6 3.6 1.62 3.6 3.6-1.62 3.6-3.6 3.6z"/>
+    </svg>
+    <span class="nav-text">Settings</span>
+</div>
+</div>
+
+<!-- Help Center -->
+<div class="nav-section">
+<div class="nav-item" onclick="showHelpCenter()">
+    <svg class="nav-icon" viewBox="0 0 24 24">
+        <path d="M12 2C6.48 2 2 6.48 2 12s4.48 10 10 10 10-4.48 10-10S17.52 2 12 2zm1 17h-2v-2h2v2zm2.07-7.75l-.9.92C13.45 12.9 13 13.5 13 15h-2v-.5c0-1.1.45-2.1 1.17-2.83l1.24-1.26c.37-.36.59-.86.59-1.41 0-1.1-.9-2-2-2s-2 .9-2 2H8c0-2.21 1.79-4 4-4s4 1.79 4 4c0 .88-.36 1.68-.93 2.25z"/>
+    </svg>
+    <span class="nav-text">Help Center</span>
+</div>
+</div>
+
+<!-- Logout -->
+<div class="nav-section">
+<div class="nav-item" onclick="logout()" style="cursor: pointer; color: #ff6b6b;">
+    <svg class="nav-icon" viewBox="0 0 24 24">
+        <path d="M17 7l-1.41 1.41L18.17 11H8v2h10.17l-2.58 2.58L17 17l5-5zM4 5h8V3H4c-1.1 0-2 .9-2 2v14c0 1.1.9 2 2 2h8v-2H4V5z"/>
+    </svg>
+    <span class="nav-text">Logout</span>
+</div>
+</div>
+
+<!-- User Profile -->
+<div class="user-profile">
+<div class="user-avatar">
+    <svg viewBox="0 0 24 24">
+        <path d="M12 12c2.21 0 4-1.79 4-4s-1.79-4-4-4-4 1.79-4 4 1.79 4 4 4zm0 2c-2.67 0-8 1.34-8 4v2h16v-2c0-2.66-5.33-4-8-4z"/>
+    </svg>
+</div>
+<div class="user-info">
+    <div class="user-name">Maha Rehan</div>
+    <div class="user-email">maha@example.com</div>
+</div>
+</div>
+</div>
+
+<!-- Main Content -->
+<div class="main-content">
+<div class="chat-container" id="chatContainer">
+<div class="message ai-message">
+    <p>Hello! I'm your personal AI assistant. How can I help you today?</p>
+    <div class="feedback-buttons">
+        <button class="feedback-button" title="Like">👍</button>
+        <button class="feedback-button" title="Dislike">👎</button>
+    </div>
+</div>
+</div>
+
+<div class="typing-indicator" id="typingIndicator">
+<div class="typing-dots">
+    <div class="typing-dot"></div>
+    <div class="typing-dot"></div>
+    <div class="typing-dot"></div>
+</div>
+</div>
+
+<div class="input-area">
+<div class="input-container">
+    <textarea class="input-field" id="userInput" placeholder="Type your message here..." rows="1"></textarea>
+    <button class="send-button" id="sendButton">
+        <svg viewBox="0 0 24 24">
+            <path d="M2.01 21L23 12 2.01 3 2 10l15 2-15 2z"/>
+        </svg>
+    </button>
+</div>
+</div>
+</div>
+
+<!-- History Modal -->
+<div id="historyModal" class="modal" style="display: none;">
+<div class="modal-content">
+<div class="modal-header">
+    <h2>Chat History</h2>
+    <div class="header-actions">
+        <button class="clear-history-btn" onclick="clearChatHistory()" title="Clear All History">
+            <svg viewBox="0 0 24 24">
+                <path d="M6 19c0 1.1.9 2 2 2h8c1.1 0 2-.9 2-2V7H6v12zM19 4h-3.5l-1-1h-5l-1 1H5v2h14V4z"/>
+            </svg>
+            Clear History
+        </button>
+        <span class="close" onclick="closeHistoryModal()">&times;</span>
+    </div>
+</div>
+<div class="modal-body" id="historyContent">
+    <!-- History content will be loaded here -->
+</div>
+</div>
+</div>
+
+<!-- Settings Modal -->
+<div id="settingsModal" class="modal" style="display: none;">
+<div class="modal-content">
+<div class="modal-header">
+    <h2>Settings</h2>
+    <span class="close" onclick="closeSettingsModal()">&times;</span>
+</div>
+<div class="modal-body">
+    <div class="settings-section">
+        <h3>🎨 Theme</h3>
+        <div class="theme-options">
+            <label class="theme-option">
+                <input type="radio" name="theme" value="dark" checked>
+                <span class="theme-preview dark-theme">Dark</span>
+            </label>
+            <label class="theme-option">
+                <input type="radio" name="theme" value="light">
+                <span class="theme-preview light-theme">Light</span>
+            </label>
+        </div>
+    </div>
+
+    <div class="settings-section">
+        <h3>📝 Font Size</h3>
+        <div class="font-size-controls">
+            <label for="fontSizeSlider">Size: <span id="fontSizeValue">16</span>px</label>
+            <input type="range" id="fontSizeSlider" min="12" max="24" value="16" oninput="updateFontSize(this.value)">
+        </div>
+    </div>
+
+    <div class="settings-section">
+        <h3>💾 Save Settings</h3>
+        <button onclick="saveSettings()" class="save-btn">Save Settings</button>
+        <button onclick="resetSettings()" class="reset-btn">Reset to Default</button>
+    </div>
+</div>
+</div>
+</div>
+
+<!-- Help Center Modal -->
+<div id="helpModal" class="modal" style="display: none;">
+<div class="modal-content">
+<div class="modal-header">
+    <h2>Help Center</h2>
+    <span class="close" onclick="closeHelpModal()">&times;</span>
+</div>
+<div class="modal-body">
+    <div class="help-section">
+        <h3>📚 Quick Help</h3>
+        <div class="help-items">
+            <div class="help-item">
+                <svg viewBox="0 0 24 24">
+                    <path d="M20 2H4c-1.1 0-2 .9-2 2v18l4-4h14c1.1 0 2-.9 2-2V4c0-1.1-.9-2-2-2z"/>
+                </svg>
+                <div>
+                    <strong>Chat with AI</strong>
+                    <p>Type your questions and get intelligent responses from our AI assistant.</p>
+                </div>
+            </div>
+            <div class="help-item">
+                <svg viewBox="0 0 24 24">
+                    <path d="M13 3c-4.97 0-9 4.03-9 9H1l3.89 3.89.07.14L9 12H6c0-3.87 3.13-7 7-7s7 3.13 7 7-3.13 7-7 7c-1.93 0-3.68-.79-4.94-2.06l-1.42 1.42C8.27 19.99 10.51 21 13 21c4.97 0 9-4.03 9-9s-4.03-9-9-9zm-1 5v5l4.28 2.54.72-1.21-3.5-2.08V8H12z"/>
+                </svg>
+                <div>
+                    <strong>View History</strong>
+                    <p>Access your previous conversations anytime from the History section.</p>
+                </div>
+            </div>
+            <div class="help-item">
+                <svg viewBox="0 0 24 24">
+                    <path d="M19.14 12.94c.04-.3.06-.61.06-.94 0-.32-.02-.64-.07-.94l2.03-1.58c.18-.14.23-.41.12-.61l-1.92-3.32c-.12-.22-.37-.29-.59-.22l-2.39.96c-.5-.38-1.03-.7-1.62-.94l-.36-2.54c-.04-.24-.24-.41-.48-.41h-3.84c-.24 0-.43.17-.47.41l-.36 2.54c-.59.24-1.13.57-1.62.94l-2.39-.96c-.22-.08-.47 0-.59.22L2.74 8.87c-.12.21-.08.47.12.61l2.03 1.58c-.05.3-.09.63-.09.94s.02.64.07.94l-2.03 1.58c-.18.14-.23.41-.12.61l1.92 3.32c.12.22.37.29.59.22l2.39-.96c.5.38 1.03.7 1.62.94l.36 2.54c.05.24.24.41.48.41h3.84c.24 0 .44-.17.47-.41l.36-2.54c.59-.24 1.13-.56 1.62-.94l2.39.96c.22.08.47 0 .59-.22l1.92-3.32c.12-.22.07-.47-.12-.61l-2.01-1.58zM12 15.6c-1.98 0-3.6-1.62-3.6-3.6s1.62-3.6 3.6-3.6 3.6 1.62 3.6 3.6-1.62 3.6-3.6 3.6z"/>
+                </svg>
+                <div>
+                    <strong>Customize Settings</strong>
+                    <p>Change themes and font sizes to personalize your experience.</p>
+                </div>
+            </div>
+        </div>
+    </div>
+
+    <div class="help-section">
+        <h3>💬 Send Feedback</h3>
+        <div class="feedback-form">
+            <textarea id="feedbackText" placeholder="Tell us how we can improve your experience..." rows="4"></textarea>
+            <div class="feedback-actions">
+                <button onclick="submitFeedback()" class="submit-feedback-btn">
+                    <svg viewBox="0 0 24 24">
+                        <path d="M2.01 21L23 12 2.01 3 2 10l15 2-15 2z"/>
+                    </svg>
+                    Send Feedback
+                </button>
+                <span class="feedback-note">Your feedback helps us improve!</span>
+            </div>
+        </div>
+    </div>
+</div>
+</div>
+</div>
+
+<!-- Notification System -->
+<div id="notification" class="notification" style="display: none;">
+<div class="notification-content">
+<svg class="notification-icon" viewBox="0 0 24 24">
+    <path d="M12 2C6.48 2 2 6.48 2 12s4.48 10 10 10 10-4.48 10-10S17.52 2 12 2zm-2 15l-5-5 1.41-1.41L10 14.17l7.59-7.59L19 8l-9 9z"/>
+</svg>
+<span class="notification-message"></span>
+</div>
+</div>
+
+    <script src="../script/chat.js"></script>
+</body>
+</html>
diff --git a/frontend/html/forgotPW.html b/frontend/html/forgotPW.html
new file mode 100644
index 0000000..4070c51
--- /dev/null
+++ b/frontend/html/forgotPW.html
@@ -0,0 +1,418 @@
+<!DOCTYPE html>
+<html lang="en">
+<head>
+  <meta charset="UTF-8">
+  <meta name="viewport" content="width=device-width, initial-scale=1.0">
+  <title>Password Reset</title>
+  <style>
+    :root {
+      --primary-color: #9b59b6;      /* Brighter Purple */
+      --primary-dark: #8e44ad;       /* Darker Purple */
+      --secondary-color: #bb8fce;    /* Light Purple */
+      --dark-color: #000000;         /* Black */
+      --bg-dark: #1e1e1e;
+      --bg-light: rgba(40, 40, 40, 0.75);
+      --text-light: #f0f0f0;        /* Soft White */
+      --gray-color: #bbbbbb;         /* Mid Gray */
+      --error-color: #e74c3c;
+      --gradient-start: #000000;     /* Black start */
+      --gradient-mid: #64278e;       /* Rich Purple mid */
+      --gradient-end: #7f8c8d;       /* Gray end */
+    }
+
+    body {
+      font-family: 'Segoe UI', sans-serif;
+      background: linear-gradient(135deg, var(--gradient-start), var(--gradient-mid), var(--gradient-end));
+      height: 100vh;
+      margin: 0;
+      display: flex;
+      align-items: center;
+      justify-content: center;
+      color: var(--text-light);
+    }
+
+    .reset-box {
+      width: 380px;
+      padding: 2rem;
+      background: rgba(24, 24, 26, 0.95);
+      border-radius: 16px;
+      backdrop-filter: blur(12px) saturate(180%);
+      border: 1px solid rgba(155, 89, 182, 0.3);
+      box-shadow: 0 8px 30px rgba(0, 0, 0, 0.5);
+      text-align: center;
+      position: relative;
+      overflow: hidden;
+    }
+
+    .reset-box::before {
+      content: '';
+      position: absolute;
+      top: 0;
+      left: 0;
+      right: 0;
+      height: 3px;
+      background: linear-gradient(45deg, var(--primary-color), var(--secondary-color));
+    }
+
+    h2 {
+      margin-bottom: 1.5rem;
+      font-size: 1.6rem;
+      font-weight: 600;
+      background: linear-gradient(45deg, var(--primary-color), var(--secondary-color));
+      -webkit-background-clip: text;
+      -webkit-text-fill-color: transparent;
+    }
+
+    .input-group {
+      margin-bottom: 1.2rem;
+      text-align: left;
+    }
+
+    label {
+      font-size: 0.9rem;
+      color: var(--gray-color);
+      display: block;
+      margin-bottom: 0.4rem;
+      font-weight: 500;
+    }
+
+    input {
+      width: 100%;
+      padding: 0.8rem;
+      border-radius: 8px;
+      border: 1px solid rgba(255, 255, 255, 0.2);
+      background: rgba(255, 255, 255, 0.05);
+      color: var(--text-light);
+      font-size: 1rem;
+      transition: all 0.3s ease;
+    }
+
+    input:focus {
+      border-color: var(--primary-color);
+      outline: none;
+      box-shadow: 0 0 0 3px rgba(155, 89, 182, 0.3);
+      background: rgba(255, 255, 255, 0.08);
+    }
+
+    input::placeholder {
+      color: rgba(255, 255, 255, 0.4);
+    }
+
+    .strength-bar {
+      height: 4px;
+      background: rgba(255, 255, 255, 0.2);
+      border-radius: 2px;
+      margin-top: 6px;
+      overflow: hidden;
+    }
+
+    .bar {
+      height: 100%;
+      width: 0%;
+      background: linear-gradient(45deg, var(--primary-color), var(--secondary-color));
+      border-radius: 2px;
+      transition: width 0.3s ease;
+    }
+
+    .error {
+      font-size: 0.8rem;
+      color: var(--error-color);
+      margin-top: 4px;
+      display: none;
+    }
+
+    button {
+      width: 100%;
+      padding: 0.9rem;
+      background: linear-gradient(45deg, var(--primary-color), var(--secondary-color));
+      border: none;
+      border-radius: 8px;
+      font-size: 1rem;
+      font-weight: 600;
+      color: #fff;
+      margin-top: 1rem;
+      cursor: pointer;
+      transition: all 0.3s ease;
+      position: relative;
+      overflow: hidden;
+    }
+
+    button:hover {
+      transform: translateY(-2px);
+      box-shadow: 0 6px 20px rgba(155, 89, 182, 0.4);
+    }
+
+    button:active {
+      transform: translateY(0);
+    }
+
+    .back {
+      margin-top: 1.5rem;
+      font-size: 0.9rem;
+    }
+
+    .back a {
+      color: var(--secondary-color);
+      text-decoration: none;
+      font-weight: 500;
+      transition: color 0.3s ease;
+      display: inline-flex;
+      align-items: center;
+      gap: 5px;
+    }
+
+    .back a:hover {
+      color: var(--primary-color);
+      text-decoration: none;
+    }
+
+    /* Security badge */
+    .security-badge {
+      display: inline-flex;
+      align-items: center;
+      gap: 6px;
+      background: rgba(155, 89, 182, 0.1);
+      color: var(--secondary-color);
+      padding: 6px 12px;
+      border-radius: 15px;
+      font-size: 0.8rem;
+      margin-bottom: 1rem;
+      border: 1px solid rgba(155, 89, 182, 0.2);
+    }
+
+    /* Password requirements */
+    .requirements {
+      text-align: left;
+      font-size: 0.8rem;
+      color: var(--gray-color);
+      margin-top: 0.5rem;
+      padding: 10px;
+      background: rgba(255, 255, 255, 0.03);
+      border-radius: 6px;
+      border-left: 3px solid var(--primary-color);
+    }
+
+    .requirements ul {
+      margin: 0;
+      padding-left: 1.2rem;
+    }
+
+    .requirements li {
+      margin-bottom: 3px;
+    }
+
+    /* Success state for inputs */
+    input.valid {
+      border-color: var(--primary-color);
+    }
+
+    input.invalid {
+      border-color: var(--error-color);
+    }
+
+    /* Animation for success */
+    @keyframes successPulse {
+      0% { transform: scale(1); }
+      50% { transform: scale(1.02); }
+      100% { transform: scale(1); }
+    }
+
+    .success {
+      animation: successPulse 0.6s ease;
+    }
+  </style>
+</head>
+<body>
+  <div class="reset-box">
+    <h2>Change Password</h2>
+    <div class="security-badge">
+      <i class="fas fa-lock"></i> Secure Password Reset
+    </div>
+
+    <form id="resetForm">
+
+      <!-- Admin Key -->
+      <div class="input-group">
+        <label for="admin-key">
+          <i class="fas fa-key"></i> Admin Key (4 digits)
+        </label>
+        <input type="password" id="admin-key" maxlength="4" required placeholder="Enter 4-digit admin key">
+        <div class="error" id="key-error">Admin key must be 4 digits</div>
+      </div>
+
+      <!-- Current Password -->
+      <div class="input-group">
+        <label for="current-pass">
+          <i class="fas fa-lock"></i> Current Password
+        </label>
+        <input type="password" id="current-pass" required placeholder="Enter current password">
+        <div class="error" id="current-error">Invalid current password</div>
+      </div>
+
+      <!-- New Password -->
+      <div class="input-group">
+        <label for="new-pass">
+          <i class="fas fa-shield-alt"></i> New Password
+        </label>
+        <input type="password" id="new-pass" required placeholder="Create new password">
+        <div class="strength-bar">
+          <div class="bar" id="bar"></div>
+        </div>
+        <div class="error" id="pass-error">Password must be 8+ chars with number & special char</div>
+
+        <div class="requirements">
+          <strong>Password Requirements:</strong>
+          <ul>
+            <li>Minimum 8 characters</li>
+            <li>At least one number</li>
+            <li>At least one special character</li>
+          </ul>
+        </div>
+      </div>
+
+      <!-- Confirm -->
+      <div class="input-group">
+        <label for="confirm-pass">
+          <i class="fas fa-check-double"></i> Confirm New Password
+        </label>
+        <input type="password" id="confirm-pass" required placeholder="Re-enter new password">
+        <div class="error" id="confirm-error">Passwords don't match</div>
+      </div>
+
+      <button type="submit">
+        <i class="fas fa-sync-alt"></i> Update Password
+      </button>
+    </form>
+
+    <div class="back">
+      <a href="login.html">
+        <i class="fas fa-arrow-left"></i> Back to Login
+      </a>
+    </div>
+  </div>
+
+  <script src="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/6.4.0/js/all.min.js"></script>
+  <script>
+    const adminKey = document.getElementById('admin-key');
+    const currentPass = document.getElementById('current-pass');
+    const newPass = document.getElementById('new-pass');
+    const confirmPass = document.getElementById('confirm-pass');
+    const bar = document.getElementById('bar');
+
+    const keyError = document.getElementById('key-error');
+    const currentError = document.getElementById('current-error');
+    const passError = document.getElementById('pass-error');
+    const confirmError = document.getElementById('confirm-error');
+
+    // Fake stored credentials (simulate dataset)
+    const storedAdminKey = "1234";
+    const storedPassword = "oldpass123";
+
+    // Input validation with visual feedback
+    function validateInput(input, isValid) {
+      if (isValid) {
+        input.classList.remove('invalid');
+        input.classList.add('valid');
+      } else {
+        input.classList.remove('valid');
+        input.classList.add('invalid');
+      }
+    }
+
+    // Admin key validation
+    adminKey.addEventListener("input", () => {
+      const isValid = /^\d{4}$/.test(adminKey.value);
+      validateInput(adminKey, isValid);
+      keyError.style.display = isValid ? "none" : "block";
+    });
+
+    // Current password validation
+    currentPass.addEventListener("input", () => {
+      const isValid = currentPass.value.length >= 1;
+      validateInput(currentPass, isValid);
+    });
+
+    // Strength check for new password
+    newPass.addEventListener("input", () => {
+      const val = newPass.value;
+      let strength = 0;
+
+      if (val.length >= 8) strength += 30;
+      if (/[0-9]/.test(val)) strength += 30;
+      if (/[^A-Za-z0-9]/.test(val)) strength += 40;
+
+      bar.style.width = Math.min(strength, 100) + "%";
+
+      const isValid = val.length >= 8 && /[0-9]/.test(val) && /[^A-Za-z0-9]/.test(val);
+      validateInput(newPass, isValid);
+      passError.style.display = isValid ? "none" : "block";
+    });
+
+    // Confirm password match
+    confirmPass.addEventListener("input", () => {
+      const isValid = confirmPass.value === newPass.value && newPass.value.length > 0;
+      validateInput(confirmPass, isValid);
+      confirmError.style.display = isValid ? "none" : "block";
+    });
+
+    // Form submission
+    document.getElementById("resetForm").addEventListener("submit", (e) => {
+      e.preventDefault();
+      let valid = true;
+
+      // Validate admin key
+      if (adminKey.value !== storedAdminKey) {
+        keyError.style.display = "block";
+        validateInput(adminKey, false);
+        valid = false;
+      } else {
+        keyError.style.display = "none";
+        validateInput(adminKey, true);
+      }
+
+      // Validate current password
+      if (currentPass.value !== storedPassword) {
+        currentError.style.display = "block";
+        validateInput(currentPass, false);
+        valid = false;
+      } else {
+        currentError.style.display = "none";
+        validateInput(currentPass, true);
+      }
+
+      // Validate new password strength
+      const isStrongPassword = newPass.value.length >= 8 &&
+                              /[0-9]/.test(newPass.value) &&
+                              /[^A-Za-z0-9]/.test(newPass.value);
+      if (!isStrongPassword) {
+        passError.style.display = "block";
+        validateInput(newPass, false);
+        valid = false;
+      }
+
+      // Validate password match
+      if (newPass.value !== confirmPass.value) {
+        confirmError.style.display = "block";
+        validateInput(confirmPass, false);
+        valid = false;
+      }
+
+      if (valid) {
+        // Add success animation
+        document.querySelector('.reset-box').classList.add('success');
+
+        // Simulate API call
+        setTimeout(() => {
+          alert("✅ Password updated successfully!");
+          window.location.href = "login.html";
+        }, 800);
+      }
+    });
+
+    // Remove success class after animation
+    document.querySelector('.reset-box').addEventListener('animationend', () => {
+      document.querySelector('.reset-box').classList.remove('success');
+    });
+  </script>
+</body>
+</html>
diff --git a/frontend/html/index.html b/frontend/html/index.html
new file mode 100644
index 0000000..4c07c27
--- /dev/null
+++ b/frontend/html/index.html
@@ -0,0 +1,298 @@
+<!DOCTYPE html>
+<html lang="en">
+
+<head>
+  <meta charset="UTF-8" />
+  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
+  <title></title>
+  <link rel="stylesheet" href="../assets/style/styles.css" />
+   <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/6.4.0/css/all.min.css">
+</head>
+
+<body>
+  <!-- Background video -->
+  <video id="bgVideo" autoplay muted loop playsinline>
+    <source src="../assets/images/bg.mp4" type="video/mp4" />
+  </video>
+
+  <!-- Overlay gradient & stars -->
+  <div class="overlay"></div>
+
+  <!-- Navbar -->
+  <header class="nav">
+    <div class="brand">
+      <!-- <div class="brand-logo"> -->
+        <img src="../assets/images/logo.png" alt="" height="100" width="100" style="border-radius: 50%;">
+      <!-- </div> -->
+    </div>
+    <nav class="links">
+      <a href="#Our_project">Our Project</a>
+      <a href="#How_It _Works">How It Works</a>
+      <a href="#Why_Prefer_Us">Why Prefer Us</a>
+      <a href="#Our_Team">Our Team</a>
+      <a href="#contact_us">Contact Us</a>
+    </nav>
+    <div class="auth">
+      <a class="btn ghost" href="account.html">GET STARTED</a>
+    </div>
+  </header>
+
+  <!-- Hero -->
+  <main class="hero" id="Our_project">
+    <h1>AI For Organization</h1>
+    <!-- <p class="sub">Lorem ipsum dolor sit amet dolores velit iusto praesentium quidem eius qui laborum </p> -->
+  </main>
+
+  <!-- Cards Section -->
+
+  <h1 class="how_it_work" id="How_It _Works">How It Works</h1>
+  <section class="features" >
+
+    <div class="feature-card">
+      <img src="../assets/images/data-collection.png" class="img_icon" alt="">
+      <h3>Step 1</h3>
+      <p>Data Collection</p>
+    </div>
+    <div class="feature-card">
+      <img src="../assets/images/data-cleaning.png" class="img_icon" alt="">
+
+      <h3>Step 2</h3>
+      <p>Text Cleaning
+
+      </p>
+    </div>
+    <div class="feature-card">
+      <img src="../assets/images/data-processing.png" class="img_icon" alt="">
+
+      <h3>Step 3</h3>
+      <p>Preprocessing</p>
+    </div>
+    <div class="feature-card">
+      <img src="../assets/images/feature.png" class="img_icon" alt="">
+
+      <h3>Step 4</h3>
+      <p>Feature Engineering</p>
+    </div>
+
+    <div class="feature-card">
+      <img src="../assets/images/deep-learning.png" class="img_icon" alt="">
+
+      <h3>Step 5</h3>
+      <p>Modeling</p>
+    </div>
+    <div class="feature-card">
+      <img src="../assets/images/evaluation.png" class="img_icon" alt="">
+
+      <h3>Step 6</h3>
+      <p>Evaluation</p>
+    </div>
+    <div class="feature-card">
+      <img src="../assets/images/file-upload.png" class="img_icon" alt="">
+
+      <h3>Step 7</h3>
+      <p>Deployment</p>
+    </div>
+    <div class="feature-card">
+      <img src="../assets/images/monitoring.png" class="img_icon" alt="">
+
+      <h3>Step 8</h3>
+      <p>Monitoring and Model Updating</p>
+    </div>
+    <!-- <div class="feature-card">
+      <h3>Step 5</h3>
+      <p>Reinforcement learno</p>
+    </div>
+    <div class="feature-card">
+      <h3>flow 6</h3>
+      <p>Lorem ipsum dolor sit amet consectetur.</p>
+    </div>
+    <div class="feature-card">
+      <h3>flow 1</h3>
+      <p>Lorem ipsum dolor sit amet consectetur.</p>
+    </div>
+    <div class="feature-card">
+      <h3>flow 1</h3>
+      <p>Lorem ipsum dolor sit amet consectetur.</p>
+    </div> -->
+  </section>
+
+  <!-- Security Section -->
+  <section class="security" id="Why_Prefer_Us">
+    <video class="security-video" autoplay muted loop playsinline id="security-video">
+      <source src="../assets/images/bg2.mp4" type="video/mp4" />
+    </video>
+    <div class="security-content">
+      <h2 id="security-flow">TRUST IN PRIVACY</h2>
+      <p class="security-text" id="slogan-text">Your information stays with you.</p>
+    </div>
+  </section>
+  <!--  -->
+ <!-- Team Section -->
+  <section class="team-section" id="Our_Team">
+    <h1 class="team-title">Meet Our Team</h1>
+    <div class="team-container">
+      <div class="team-scroll">
+        <!-- Team Member 1 -->
+        <div class="team-member">
+          <h2 class="member-name">Adeia</h2>
+          <!-- <p>AI Engineer</p> -->
+          <div class="member-links">
+            <a href="https://github.com/" class="member-link" target="_blank">
+              <i class="fab fa-github"></i>
+            </a>
+            <a href="https://linkedin.com/in/" class="member-link" target="_blank">
+              <i class="fab fa-linkedin"></i>
+            </a>
+          </div>
+        </div>
+
+        <!-- Team Member 2 -->
+        <div class="team-member">
+          <h2 class="member-name">Shahroz Kashif</h2>
+          <!-- <p>Data Scientist</p> -->
+          <div class="member-links">
+            <a href="https://github.com/" class="member-link" target="_blank">
+              <i class="fab fa-github"></i>
+            </a>
+            <a href="https://linkedin.com/in/" class="member-link" target="_blank">
+              <i class="fab fa-linkedin"></i>
+            </a>
+          </div>
+        </div>
+
+        <!-- Team Member 3 -->
+        <div class="team-member">
+          <h2 class="member-name">Maha Rehan</h2>
+          <!-- <p>ML Engineer</p> -->
+          <div class="member-links">
+            <a href="https://github.com/" class="member-link" target="_blank">
+              <i class="fab fa-github"></i>
+            </a>
+            <a href="https://linkedin.com/in/" class="member-link" target="_blank">
+              <i class="fab fa-linkedin"></i>
+            </a>
+          </div>
+        </div>
+
+        <!-- Team Member 4 -->
+        <div class="team-member">
+          <h2 class="member-name">Saad Maqsood</h2>
+          <!-- <p>Full Stack Developer</p> -->
+          <div class="member-links">
+            <a href="https://github.com/" class="member-link" target="_blank">
+              <i class="fab fa-github"></i>
+            </a>
+            <a href="https://linkedin.com/in/" class="member-link" target="_blank">
+              <i class="fab fa-linkedin"></i>
+            </a>
+          </div>
+        </div>
+
+        <!-- Duplicate set for seamless scrolling -->
+        <div class="team-member">
+          <h2 class="member-name">Adeia</h2>
+          <!-- <p>AI Engineer</p> -->
+          <div class="member-links">
+            <a href="https://github.com/" class="member-link" target="_blank">
+              <i class="fab fa-github"></i>
+            </a>
+            <a href="https://linkedin.com/in/" class="member-link" target="_blank">
+              <i class="fab fa-linkedin"></i>
+            </a>
+          </div>
+        </div>
+
+        <div class="team-member">
+          <h2 class="member-name">Shahroz Kashif</h2>
+          <!-- <p>Data Scientist</p> -->
+          <div class="member-links">
+            <a href="https://github.com/" class="member-link" target="_blank">
+              <i class="fab fa-github"></i>
+            </a>
+            <a href="https://linkedin.com/" class="member-link" target="_blank">
+              <i class="fab fa-linkedin"></i>
+            </a>
+          </div>
+        </div>
+
+        <div class="team-member">
+          <h2 class="member-name">Maha Rehan</h2>
+          <!-- <p>ML Engineer</p> -->
+          <div class="member-links">
+            <a href="https://github.com/" class="member-link" target="_blank">
+              <i class="fab fa-github"></i>
+            </a>
+            <a href="https://linkedin.com/" class="member-link" target="_blank">
+              <i class="fab fa-linkedin"></i>
+            </a>
+          </div>
+        </div>
+
+        <div class="team-member">
+          <h2 class="member-name">Saad Maqsood</h2>
+          <!-- <p>Full Stack Developer</p> -->
+          <div class="member-links">
+            <a href="https://github.com/" class="member-link" target="_blank">
+              <i class="fab fa-github"></i>
+            </a>
+            <a href="https://linkedin.com/" class="member-link" target="_blank">
+              <i class="fab fa-linkedin"></i>
+            </a>
+          </div>
+        </div>
+      </div>
+    </div>
+  </section>
+
+  <!-- Contact Us Section -->
+  <section class="contact" id="contact_us">
+    <video class="contact-video" autoplay muted loop playsinline id="contact-video">
+      <source src="assets/bg3.mp4" type="video/mp4" />
+    </video>
+    <div class="contact-content">
+      <h2 class="contact-title">Contact Us</h2>
+      <p class="contact-text">Get in touch with us for support or inquiries. Your privacy is our priority.</p>
+      <form class="contact-form">
+        <input type="text" placeholder="Your Name" class="input-field" required>
+        <input type="email" placeholder="Your Email" class="input-field" required>
+        <textarea placeholder="Your Message" class="input-field textarea" required></textarea>
+        <button type="submit" class="btn solid btn-animated">Send Message</button>
+      </form>
+      <!-- <p class="contact-info">Email: support@yourdomain.com | Phone: +1-234-567-8900</p> -->
+    </div>
+  </section>
+
+  <!-- Footer -->
+  <footer class="footer">
+    <div class="footer-content">
+      <div class="footer-section">
+        <h3>Quick Links</h3>
+        <ul>
+          <li> <a href="#Our_project">Our project</a></li>
+      <li><a href="#How_It _Works">How It Works</a></li>
+      <li><a href="#Why_Prefer_Us">Why Prefer Us</a></li>
+      <li><a href="#Our_Team">Our Team</a></li>
+      <li><a href="#contact_us">Contact Us</a></li>
+        </ul>
+      </div>
+      <!-- <div class="footer-section">
+        <h3>Contact</h3>
+        <p>Email: support@yourdomain.com</p>
+        <p>Phone: +1-234-567-8900</p>
+      </div> -->
+      <div class="footer-section">
+        <h3>Follow Us</h3>
+        <div class="social-links">
+          <a href="#">Twitter</a>
+          <a href="#">LinkedIn</a>
+          <a href="#">Instagram</a>
+        </div>
+      </div>
+    </div>
+
+  </footer>
+
+  <script src="../assets/js/script.js"></script>
+</body>
+
+</html>
diff --git a/frontend/html/login.html b/frontend/html/login.html
new file mode 100644
index 0000000..21f7065
--- /dev/null
+++ b/frontend/html/login.html
@@ -0,0 +1,184 @@
+<!DOCTYPE html>
+<html lang="en">
+<head>
+  <meta charset="UTF-8">
+  <meta name="viewport" content="width=device-width, initial-scale=1.0">
+  <title>Login</title>
+  <style>
+    :root {
+      --primary: #9b59b6;
+      --primary-dark: #8e44ad;
+      --bg-dark: #000;
+      --bg-mid: #2d0b3d;
+      --bg-light: #4a4a4a;
+      --text: #e0e0e0;
+      --gray: #bbbbbb;
+      --error: #e74c3c;
+    }
+
+    body {
+      font-family: 'Segoe UI', sans-serif;
+      background: linear-gradient(135deg, var(--bg-dark), var(--bg-mid), var(--bg-light));
+      display: flex;
+      justify-content: center;
+      align-items: center;
+      height: 100vh;
+      margin: 0;
+      color: var(--text);
+    }
+
+    .login-container {
+      width: 400px;
+      padding: 2rem;
+      background: rgba(40, 40, 40, 0.7);
+      border-radius: 14px;
+      backdrop-filter: blur(12px) saturate(180%);
+      border: 1px solid rgba(255, 255, 255, 0.15);
+      box-shadow: 0 8px 30px rgba(0, 0, 0, 0.35);
+      text-align: center;
+    }
+
+    h2 {
+      font-size: 1.8rem;
+      margin-bottom: 2rem;
+      font-weight: 600;
+      letter-spacing: 0.5px;
+      color: #fff;
+    }
+
+    .input-group {
+      margin-bottom: 1.2rem;
+      text-align: left;
+    }
+
+    label {
+      display: block;
+      margin-bottom: 0.6rem;
+      font-size: 0.95rem;
+      color: var(--gray);
+      font-weight: 500;
+    }
+
+    input {
+      width: 93%;
+      padding: 0.9rem;
+      margin-top: 1rem;
+      border-radius: 8px;
+      /* background: var(--primary); */
+      /* color: #fff; */
+      border: none;
+      font-size: 1rem;
+    }
+
+    input:focus {
+      border-color: var(--primary);
+      outline: none;
+      box-shadow: 0 0 0 3px rgba(155, 89, 182, 0.3);
+    }
+
+    .error {
+      font-size: 0.85rem;
+      color: var(--error);
+      margin-top: 4px;
+      display: none;
+    }
+
+    button {
+      width: 100%;
+      padding: 0.9rem;
+      margin-top: 1rem;
+      border-radius: 8px;
+      background: var(--primary);
+      color: #fff;
+      border: none;
+      font-size: 1rem;
+      font-weight: 600;
+      cursor: pointer;
+      transition: 0.3s;
+    }
+
+    button:hover {
+      background: var(--primary-dark);
+      transform: translateY(-2px);
+      box-shadow: 0 4px 12px rgba(155, 89, 182, 0.4);
+    }
+
+    .forgot-pw {
+      margin-top: 1rem;
+      text-align: right;
+    }
+
+    a {
+      color: var(--primary);
+      text-decoration: none;
+      font-size: 0.9rem;
+      font-weight: 500;
+    }
+
+    a:hover {
+      color: var(--primary-dark);
+      text-decoration: underline;
+    }
+  </style>
+</head>
+<body>
+  <div class="login-container">
+    <h2>Login Admin Panel</h2>
+    <form id="loginForm">
+      <div class="input-group">
+        <label for="username">Username</label>
+        <input type="text" id="username" required placeholder="Enter your username">
+        <div class="error" id="user-error">⚠ Username not found</div>
+      </div>
+      <div class="input-group">
+        <label for="password">Password</label>
+        <input type="password" id="password" required placeholder="••••••••">
+        <div class="error" id="pass-error">⚠ Incorrect password</div>
+      </div>
+      <button type="submit">Login</button>
+      <div class="forgot-pw">
+        <a href="forgotPW.html">Forgot Password?</a>
+      </div>
+    </form>
+  </div>
+
+  <script>
+    // Fake dataset (replace with JSON fetch)
+    const users = [
+      { username: "admin", password: "oldpass123" },
+      { username: "maha", password: "mypassword" }
+    ];
+
+    const loginForm = document.getElementById("loginForm");
+    const userError = document.getElementById("user-error");
+    const passError = document.getElementById("pass-error");
+
+    loginForm.addEventListener("submit", (e) => {
+      e.preventDefault();
+      const username = document.getElementById("username").value.trim();
+      const password = document.getElementById("password").value.trim();
+
+      const user = users.find(u => u.username === username);
+
+      if (!user) {
+        userError.style.display = "block";
+        passError.style.display = "none";
+        return;
+      } else {
+        userError.style.display = "none";
+      }
+
+      if (user.password !== password) {
+        passError.style.display = "block";
+        return;
+      } else {
+        passError.style.display = "none";
+      }
+
+      // ✅ Success
+      alert("Welcome " + username + "!");
+      window.location.href = "admin.html";
+    });
+  </script>
+</body>
+</html>
diff --git a/frontend/html/upload.html b/frontend/html/upload.html
new file mode 100644
index 0000000..a49c9e3
--- /dev/null
+++ b/frontend/html/upload.html
@@ -0,0 +1,149 @@
+<!DOCTYPE html>
+<html lang="en">
+<head>
+  <meta charset="UTF-8" />
+  <meta name="viewport" content="width=device-width, initial-scale=1" />
+  <title>File Upload with Redirect</title>
+  <style>
+    /* ---------- Base Styles ---------- */
+    body {
+      font-family: "Poppins", Arial, sans-serif;
+      display: flex;
+      flex-direction: column;
+      align-items: center;
+      justify-content: center;
+      min-height: 100vh;
+      margin: 0;
+      background: radial-gradient(circle at 20% 20%, #1b1b2f, #121212);
+      color: #e0e0e0;
+      overflow: hidden;
+    }
+
+    h2 {
+      color: #b388ff;
+      font-size: 2em;
+      margin-bottom: 30px;
+      text-shadow: 0 0 10px #6c53ff66;
+    }
+
+    /* ---------- File Input & Buttons ---------- */
+    input[type="file"] {
+      padding: 10px;
+      border-radius: 10px;
+      border: 2px dashed #6c53ff99;
+      background: rgba(255, 255, 255, 0.05);
+      color: #ccc;
+      cursor: pointer;
+      transition: all 0.3s ease;
+    }
+
+    input[type="file"]:hover {
+      background: rgba(255, 255, 255, 0.1);
+      border-color: #b388ff;
+    }
+
+    button {
+      margin-top: 20px;
+      padding: 12px 24px;
+      border: none;
+      border-radius: 30px;
+      font-size: 1em;
+      font-weight: 600;
+      cursor: pointer;
+      transition: all 0.3s ease;
+      background: linear-gradient(90deg, #6c53ff, #b388ff);
+      color: white;
+      box-shadow: 0 0 10px #6c53ff66;
+    }
+
+    button:hover {
+      transform: translateY(-2px);
+      box-shadow: 0 0 15px #b388ff99;
+    }
+
+    button.secondary {
+      background: transparent;
+      border: 2px solid #b388ff;
+      color: #b388ff;
+      margin-left: 10px;
+    }
+
+    button.secondary:hover {
+      background: #b388ff22;
+      box-shadow: 0 0 10px #b388ff55;
+    }
+
+    /* ---------- Progress Bar ---------- */
+    .progress-container {
+      width: 80%;
+      max-width: 500px;
+      background: rgba(255, 255, 255, 0.06);
+      border-radius: 30px;
+      margin: 40px auto 20px;
+      height: 25px;
+      overflow: hidden;
+      display: none;
+      box-shadow: 0 0 10px #6c53ff66;
+      position: relative;
+    }
+
+    .progress-bar {
+      height: 100%;
+      width: 0%;
+      background: linear-gradient(90deg, #6c53ff, #b388ff);
+      transition: width 0.3s ease;
+      border-radius: 30px;
+    }
+
+    .progress-text {
+      position: absolute;
+      width: 100%;
+      top: 0;
+      left: 0;
+      text-align: center;
+      line-height: 25px;
+      font-size: 14px;
+      color: #ddd;
+    }
+
+    /* ---------- Done Message ---------- */
+    .done-message {
+      display: none;
+      margin-top: 20px;
+      font-size: 18px;
+      font-weight: 600;
+      color: #b388ff;
+      text-shadow: 0 0 10px #6c53ff99;
+    }
+
+    /* ---------- Animation ---------- */
+    @keyframes fadeIn {
+      from { opacity: 0; transform: translateY(20px); }
+      to { opacity: 1; transform: translateY(0); }
+    }
+
+    h2, input, button, .progress-container {
+      animation: fadeIn 0.6s ease;
+    }
+  </style>
+</head>
+<body>
+  <h2>Upload a File</h2>
+
+  <input type="file" id="fileInput" /><br />
+  <div>
+    <button onclick="uploadFile()">Upload</button>
+    <button onclick="goToChat()" class="secondary">Go to Chat</button>
+  </div>
+
+  <div class="progress-container">
+    <div class="progress-bar" id="progressBar"></div>
+    <div class="progress-text" id="progressText">0%</div>
+  </div>
+
+  <div class="done-message" id="doneMessage">✅ Upload Complete!</div>
+
+  <script src="../script/upload.js""></script>
+
+</body>
+</html>
diff --git a/frontend/main.py b/frontend/main.py
new file mode 100644
index 0000000..3ad5235
--- /dev/null
+++ b/frontend/main.py
@@ -0,0 +1,293 @@
+import base64
+import json
+import os
+import subprocess
+import sys
+from datetime import datetime
+
+try:
+    import webview
+except ImportError:
+    webview = None
+
+# === Add project root to sys.path ===
+here = os.path.dirname(os.path.abspath(__file__))  # frontend/
+project_root = os.path.abspath(os.path.join(here, ".."))  # ai4org/
+sys.path.append(project_root)
+
+# === Import your inference logic ===
+from hallucination_reduction.inference import (  # noqa: E402
+    build_embeddings,
+    generate_answer,
+    load_corpus,
+    load_model,
+    retrieve_relevant_chunks,
+)
+
+# User login history file
+USER_HISTORY_FILE = os.path.join(here, "user_history.json")
+CORPUS_FILE = os.path.join(project_root, "data", "processed", "corpus.txt")
+
+
+class Api:
+    def __init__(self):
+        # Load once on startup to save time
+        self.model, self.tokenizer, self.device = load_model()
+        self.docs = load_corpus(CORPUS_FILE)
+        self.embedder, self.corpus_embeddings = build_embeddings(
+            self.docs, device=self.device
+        )
+
+        # Initialize user history
+        self.user_history = self.load_user_history()
+
+    def get_ai_response(self, question):
+        try:
+            retrieved_docs = retrieve_relevant_chunks(
+                question, self.embedder, self.corpus_embeddings, self.docs
+            )
+            answer = generate_answer(
+                self.model, self.tokenizer, self.device, question, retrieved_docs
+            )
+            return {"status": "ok", "answer": answer}
+        except Exception as e:
+            return {"status": "error", "message": str(e)}
+
+    def load_user_history(self):
+        """Load user login history from file"""
+        try:
+            if os.path.exists(USER_HISTORY_FILE):
+                with open(USER_HISTORY_FILE, "r", encoding="utf-8") as f:
+                    return json.load(f)
+            return {}
+        except Exception as e:
+            print(f"Error loading user history: {e}")
+            return {}
+
+    def save_user_history(self):
+        """Save user login history to file"""
+        try:
+            with open(USER_HISTORY_FILE, "w", encoding="utf-8") as f:
+                json.dump(self.user_history, f, indent=2, ensure_ascii=False)
+        except Exception as e:
+            print(f"Error saving user history: {e}")
+
+    def log_user_login(self, user_name, user_email):
+        """Log user login with timestamp"""
+        current_time = datetime.now().strftime("%Y-%m-%d %H:%M:%S")
+
+        if user_name not in self.user_history:
+            self.user_history[user_name] = {"email": user_email, "login_history": []}
+
+        self.user_history[user_name]["login_history"].append(
+            {
+                "timestamp": current_time,
+                "date": current_time.split()[0],
+                "time": current_time.split()[1],
+            }
+        )
+
+        # Keep only last 50 logins per user
+        if len(self.user_history[user_name]["login_history"]) > 50:
+            self.user_history[user_name]["login_history"] = self.user_history[
+                user_name
+            ]["login_history"][-50:]
+
+        self.save_user_history()
+        return {"status": "success", "message": "Login logged successfully"}
+
+    def get_user_history(self, admin_pin):
+        """Get user login history (admin only)"""
+        if admin_pin != "9999":
+            return {"status": "error", "message": "Unauthorized access"}
+
+        return {
+            "status": "success",
+            "data": self.user_history,
+            "total_users": len(self.user_history),
+        }
+
+    def get_user_stats(self, admin_pin):
+        """Get user statistics (admin only)"""
+        if admin_pin != "9999":
+            return {"status": "error", "message": "Unauthorized access"}
+
+        stats = {
+            "total_users": len(self.user_history),
+            "total_logins": sum(
+                len(user["login_history"]) for user in self.user_history.values()
+            ),
+            "users": [],
+        }
+
+        for user_name, user_data in self.user_history.items():
+            user_stats = {
+                "name": user_name,
+                "email": user_data["email"],
+                "login_count": len(user_data["login_history"]),
+                "last_login": (
+                    user_data["login_history"][-1]["timestamp"]
+                    if user_data["login_history"]
+                    else "Never"
+                ),
+            }
+            stats["users"].append(user_stats)
+
+        return {"status": "success", "data": stats}
+
+    def save_file(self, filename, file_data_base64):
+        try:
+            file_data = base64.b64decode(file_data_base64)
+            folder = os.path.join(project_root, "data", "raw")
+            os.makedirs(folder, exist_ok=True)
+            filepath = os.path.join(folder, filename)
+            with open(filepath, "wb") as f:
+                f.write(file_data)
+
+            # Force CPU to avoid CUDA OOM during training
+            env = os.environ.copy()
+            env["CUDA_VISIBLE_DEVICES"] = ""
+            env["TOKENIZERS_PARALLELISM"] = "false"
+            env.setdefault("PYTORCH_CUDA_ALLOC_CONF", "expandable_segments:true")
+            subprocess.run(
+                ["python", "-m", "hallucination_reduction.main"],
+                cwd=project_root,
+                check=True,
+                env=env,
+            )
+
+            return "success"
+        except Exception as e:
+            return f"error: {str(e)}"
+
+    def save_file_chunk(self, filename, chunk_data, chunk_index, is_last) :
+        """
+        Persist a single chunk of an uploaded file to disk and trigger
+        post-processing once the final chunk is received.
+
+        This method is invoked repeatedly during a chunked file upload
+        initiated from the frontend. Each call writes base64-decoded
+        binary data to a target file, either creating it on the first
+        chunk or appending to it for subsequent chunks.
+
+        Parameters
+        ----------
+        filename : str
+            Name of the file being uploaded.
+        chunk_data : str
+            Base64-encoded string representing the current file chunk.
+        chunk_index : int
+            Zero-based index of the current chunk. Used to determine
+            whether to open the file in write or append mode.
+        is_last : bool
+            Indicates whether this is the final chunk of the upload.
+            When True, a post-upload processing pipeline is executed.
+
+        Side Effects
+        ------------
+        - Creates the upload directory if it does not exist.
+        - Writes binary data to disk.
+        - Executes a subprocess for hallucination reduction when the
+        final chunk is received.
+
+        Returns
+        -------
+        str
+            "success" if the chunk is saved successfully and any required
+            post-processing completes, otherwise an error message
+            prefixed with "error:".
+        """
+        try:
+            folder = os.path.join(here, "../data/raw")
+            os.makedirs(folder, exist_ok=True)
+            filepath = os.path.join(folder, filename)
+
+            mode = "ab" if chunk_index > 0 else "wb"
+
+            with open(filepath, mode) as f:
+                f.write(base64.b64decode(chunk_data))
+
+            if is_last:
+                project_root = os.path.abspath(os.path.join(here, ".."))
+                env = os.environ.copy()
+                env["CUDA_VISIBLE_DEVICES"] = ""
+                env["TOKENIZERS_PARALLELISM"] = "false"
+                env.setdefault("PYTORCH_CUDA_ALLOC_CONF", "expandable_segments:true")
+                subprocess.run(
+                    ["python", "-m", "hallucination_reduction.main"],
+                    cwd=project_root,
+                    check=True,
+                    env=env,
+                )
+            
+            return "success"
+        except Exception as e:
+            return f"error: {str(e)}"
+
+
+def try_backends():
+    if webview is None:
+        print("pywebview is not available in this environment.")
+        return False
+    # Suppress tokenizers parallelism warning
+    os.environ["TOKENIZERS_PARALLELISM"] = "false"
+
+    import http.server
+    import socket
+    import socketserver
+    import threading
+
+    def get_free_port():
+        with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
+            s.bind(("", 0))
+            return s.getsockname()[1]
+
+    PORT = get_free_port()
+
+    def start_server():
+        class Handler(http.server.SimpleHTTPRequestHandler):
+            def __init__(self, *args, **kwargs):
+                super().__init__(*args, directory=here, **kwargs)
+
+            def log_message(self, format, *args):
+                pass
+
+        try:
+            with socketserver.TCPServer(("127.0.0.1", PORT), Handler) as httpd:
+                httpd.serve_forever()
+        except OSError as e:
+            print(f"Port {PORT} is in use or could not be bound: {e}")
+
+    server_thread = threading.Thread(target=start_server, daemon=True)
+    server_thread.start()
+
+    backends = ["qt", "gtk", "edgechromium", "cef"]
+    for backend in backends:
+        try:
+            print(f"\nAttempting {backend} backend...")
+            api = Api()
+            url = f"http://127.0.0.1:{PORT}/html/index.html"
+            print(f"Loading URL: {url}")
+
+            webview.create_window(
+                title="AI4ORG - AI For Organization",
+                url=url,
+                width=1400,
+                height=900,
+                resizable=True,
+                js_api=api,
+                min_size=(800, 600),
+            )
+            webview.start(gui=backend, debug=False)
+            return True
+        except Exception as e:
+            print(f"{backend} backend failed: {e}")
+            continue
+    return False
+
+
+if __name__ == "__main__":
+    success = try_backends()
+    if not success:
+        print("All GUI backends failed.")
+        sys.exit(1)
diff --git a/frontend/new-QA.py b/frontend/new-QA.py
new file mode 100644
index 0000000..19e814c
--- /dev/null
+++ b/frontend/new-QA.py
@@ -0,0 +1,357 @@
+# ==============================================================
+#  CGSMF Q&A Generator (100+ high-quality, logically correct)
+# ==============================================================
+
+# !pip install -q -U transformers accelerate bitsandbytes sentencepiece tqdm
+
+import hashlib
+import json
+import random
+import re
+import time
+
+import torch
+from tqdm import tqdm
+from transformers import (
+    AutoModelForCausalLM,
+    AutoTokenizer,
+    BitsAndBytesConfig,
+    pipeline,
+)
+
+# ------------------- 1. Load quantized model -------------------
+MODEL_NAME = "TinyLLaMA/TinyLLaMA-1.1B-intermediate-step-1431k-3T"
+
+bnb_config = BitsAndBytesConfig(
+    load_in_4bit=True,
+    bnb_4bit_compute_dtype=torch.float16,
+    bnb_4bit_use_double_quant=True,
+    bnb_4bit_quant_type="nf4",
+)
+
+print("Loading model & tokenizer...")
+model = AutoModelForCausalLM.from_pretrained(
+    MODEL_NAME, quantization_config=bnb_config, device_map="auto"
+)
+tokenizer = AutoTokenizer.from_pretrained(MODEL_NAME)
+pipe = pipeline("text-generation", model=model, tokenizer=tokenizer, device_map="auto")
+
+# ------------------- 2. Input passage -------------------------
+passage = """
+Allocation of Guarantee Limits to the Participating Financial Institutions (PFIs)
+All banks/MFBs/specialized institutions are eligible to participate under the CGSMF. Credit
+Guarantee Limits (CGLs) will be assigned to all financial institutions involved in agri. financing
+based on their exposure and potential in agricultural credit disbursements. All those banks
+which are not currently involved in agri. financing may also apply to Agricultural Credit &
+Microfinance Department (ACMFD) expressing their willingness to participate in the Scheme.
+Upon receiving the request, guarantee limits may be allocated to the interested financial
+institutions.
+2. Eligibility of Borrowers
+The Scheme will target small farmers/tenants across the country cultivating land, however,
+irrespective of land ownership or lease/ tenancy;
+a) 5 acres for irrigated land
+b) 10 acres for rain-fed land
+The borrowers under the Scheme should be those who do not have required collateral to secure
+the bank loans and may avail one loan up to the maximum amount of Rs.100,000 at one time,
+renewable upon maturity.
+PFIs shall take into account the following factors while determining eligibility of the borrowers;
+a) Verification of cultivation by the bank/ revenue authorities.
+b) Fresh borrowers having no collateral.
+c) Cash flows of the borrower/cropping pattern.
+d) Obtain e-CIB record of the borrower.
+e) In line with the credit policy of the Bank.
+f) Be in conformity with the relevant rules and regulations.
+g) Shall have valid CNIC.
+Annexure - 2
+CGSMF SOPs Page 2
+3. Tenor of Loan
+The loan tenor shall be based on cropping cycle up to a maximum period of one year. However,
+for sugarcane crop with 18 months cropping cycle, tenor may be fixed in accordance to its
+cropping cycle.
+4. Treatment as Unsecured Financing
+For the purpose of this Scheme all financing done under CGSMF shall be treated as secured to
+the extent of guaranteed amount and the remaining amount shall be treated as Clean Exposure
+(collateral free).
+5. Provisioning
+For the loans extended under CGSMF and classified as ‘Substandard’ the provision process
+would be as below:
+For Agricultural Loans extended by Commercial/Specialized Banks:
+Classification Determinant Treatment of
+Income
+Provisions to be
+Made
+(1) (2) (3) (4)
+OAEM
+(Other Assets
+Especially
+Mentioned)
+Where mark- up /interest or
+principal is overdue (past
+due) by 90 days from the
+due date
+Unrealized mark up/
+interest to be put in
+Memorandum
+Account and not to
+be credited to Income
+Account except when
+realized in cash
+No provision is
+required.
+Substandard Where mark- up /interest or
+principal is overdue (past
+due) by one year or more
+from the due date
+As Above 20% of the
+outstanding principal
+net of guaranteed
+amount under
+CGSMF
+Doubtful Where mark- up /interest or
+principal is overdue (past
+due) by one and a half year
+or more from the due date
+As Above 50% of the
+outstanding principal
+net of guaranteed
+amount under
+CGSMF
+Loss Where mark- up /interest or
+principal is overdue (past
+due) beyond two years or
+more from the due date
+As Above 100 % of the
+outstanding principal
+net of guaranteed
+amount under
+CGSMF
+Annexure - 2
+CGSMF SOPs Page 3
+For Microfinance Banks
+Category Determinant Treatment of Income Provisioning
+Requirement
+OAEM
+(Other Assets
+Especially
+Mentioned)
+Loans (principal/mark-up)
+is overdue for 30 days or
+more but less than 60 days
+The unrealized
+interest / profit / mark-
+up / service charges
+on NPLs shall be
+suspended and
+credited to interest
+suspense account.
+No provision is
+required
+Substandard Loans (principal/mark-up)
+is overdue for 60 days or
+more but less than 90 days
+As Above 25% of outstanding
+principal net of
+guaranteed amount
+under CGSMF
+Doubtful Loans (principal/mark-up)
+is overdue for 90 days or
+more but less than 180
+days
+As Above 50% of outstanding
+principal net of
+guaranteed amount
+under CGSMF
+Loss Loans (principal/mark-up)
+is overdue for 180 days or
+more
+As Above 100% of
+outstanding
+principal net of
+guaranteed amount
+under CGSMF
+6. Monitoring of Portfolio
+a) Banks will submit their fresh borrowers’ data, sanctioned during the quarter, on CF-1
+Form (Annexure 3) to CGO on quarterly basis.
+b) The responsibility of due diligence rest with PFIs which should follow all relevant
+guidelines of SBP and their internal SOPs for approving credit under the Scheme.
+c) Since the system places primary responsibility on the PFIs and does not require
+evaluation on part of CGO prior to disbursement of the loan amount, the credit
+guarantee shall automatically stand issued, for a customer which the bank has evaluated
+to be eligible and the PFI shall extend lending facility to the borrower treating him/her as
+a guaranteed customer under the Scheme.
+d) This, in principle, consent for a partial guarantee of maximum 50% to borrowers
+evaluated as eligible by the PFIs subject to compliance with borrower’s
+evaluation/eligibility criteria. Each PFI shall ensure that the outstanding guarantee
+amount does not exceed its allocated guarantee limit at any time.
+e) Each PFI shall report its outstanding position of all previously guaranteed loans to CGO
+on quarterly basis as per the format CF-2 (Annexure 3).
+Annexure - 2
+CGSMF SOPs Page 4
+7. Payment of Claims:
+a) The bank shall have the right to lodge a claim to the extent of 50% of the outstanding
+amount (Principal only), as soon as a particular borrower, is classified as
+‘Substandard’, as per the respective classification criteria given under Prudential
+Regulations for both Agri. Financing and Prudential Regulations for Microfinance Banks.
+b) The PFIs shall lodge claims on biannual basis on prescribed formats. Claims against
+loans classified as substandard during 1st January to 30th June should be filed by 20th
+July and from 1st July to 31st December by 20th January to CGO.
+c) All claims lodged by a PFI must be complete in terms of relevant annexure and required
+information. The claims shall be verified by the Internal Audit Department of the claimant
+bank under its seal and stamp. Besides, e-CIB reports of the delinquent borrowers under
+the Scheme shall also be submitted along with the claims to CGO.
+d) The claims will be scrutinized and verified by the CGO against the borrowers’ data within
+15 days.
+e) Claims shall be paid by CGO to the respective PFI within 05 working days under
+intimation to ACMFD.
+f) In case of multiple borrowings, from one or multiple banks, only single claim will be
+reimbursed for a loan which is senior in terms of date of sanctioning among all such
+sanctioned loans to single borrower.
+g) SBP and or its subsidiary BSC reserves the right to conduct a special inspection of all
+the claims reimbursed to a PFI through external auditors at any time.
+h) If at any point in time, claims are found to be incorrect or without basis during inspection
+by the Banking Inspection Department of SBP or otherwise, the same will be recovered
+from PFI’s account maintained with the SBP: BSC. In such case, the PFI will be liable for
+penalty under relevant provisions of the Banking Companies Ordinance 1962, and
+Microfinance Institutions Ordinance 2001.
+8. Recoveries
+a) The payment under the CGSMF shall not obviate the PFI from its right of recovery of the
+defaulted amount.
+b) The PFIs shall continue with their regular procedure for recovery of loan and take all
+necessary steps in this regard. The PFIs shall update their recovery status to the
+CGO on bi-annual basis.
+Annexure - 2
+CGSMF SOPs Page 5
+c) In the event of recoveries from delinquent borrowers, all such recoveries shall be
+treated as the recovery of principal and the PFI shall return the proportionate amount to
+CGO on bi-annual basis and will be reported to CGO on CF-4 format. CGSMF’s
+proportionate share against recovery from defaulted borrowers during 1st January to 30th
+June should be filed /reimbursed by 20th July and from 1st July to 31st December by 20th
+January to CGO. Delayed reimbursement of recovered amount shall attract penal
+action from State Bank.
+d) The costs incurred on recovery efforts shall be borne by the concerned PFI and shall not
+be passed on to the Guarantee Fund.
+9. Reporting
+The PFIs shall report to CGO on prescribed formats (Annexure 3) on quarterly, bi-annual and
+annual basis. PFIs shall ensure that all the reports are duly verified and submitted within the
+prescribed time limits as given below.
+S. No Name of Report Frequency Time Line
+1 CF-1 (Fresh Guarantee Loan Report) Quarterly 20 working days
+2 CF-2 (Existing Guaranteed Loans Report) Quarterly 20 working days
+3 CF-3 (Claim on Guarantee Fund Report) Bi-annually 20 calendar days
+4 CF-4 (Recoveries from Delinquent
+Borrowers Report)
+Bi-annually 20 calendar days
+10. Termination of the Scheme
+The Scheme shall be terminated as and when announced by the Government. SBP will formally
+issue circular in this regard.
+In case of termination/discontinuation of the scheme, claims pertaining to the loans guaranteed
+by CGO shall remain eligible for coverage under the scheme.
+Annexure - 2
+CGSMF SOPs Page 6
+PART B: Roles and Responsibilities
+Roles and Responsibilities of PFI:
+a) Each PFI shall nominate at least two senior officials (at least VP/Equivalent) as authorized
+officials/ signatories (along with their duly verified signatures, names, designations and
+email / contact address) to communicate with the CGO, SBP:BSC, Karachi and ACMFD,
+SBP, Karachi for matters pertaining to CGSMF.
+b) Only those claims which are signed by designated authorized officials shall be
+entertained by CGO.
+c) The PFIs shall ensure that a separate record of all the borrowers and portfolio is
+maintained as advised by CGO while observing their limits allocated by ACMFD. The
+PFI shall submit reports on prescribed formats along with its soft copies to CGO.
+d) The PFIs shall ensure implementation of internal controls and monitoring mechanism
+for addressing the issue of adverse selection under the Scheme.
+e) In addition, PFIs shall take all necessary measures to avoid multiple borrowings under the
+Scheme. The PFI shall obtain an undertaking from the borrower that he /she has not
+obtained any loan facility under CGSMF from any other bank.
+f) PFIs shall ensure verification of all the claims along with annexure (e-CIB reports etc)
+through internal audit before submission to CGO.
+g) PFIs shall ensure to separately review their guaranteed portfolio and claims through
+external audit or as a part of annual audit process of their financial statements at the end
+of each year and obtain an independent audit certificate in this regard. Relevant extract
+will be forwarded to CGO.
+h) PFIs shall arrange regular training and skill development programs for its officials
+working in this area particularly under this Scheme to ensure smooth processing and
+management of CGSMF
+"""  # ← keep the triple-quoted block exactly as you gave it
+
+# ------------------- 3. Settings ------------------------------
+OUTPUT_FILE = "cgsmf_qas.jsonl"
+TARGET_QA = 120  # we aim for >100, script stops when reached
+BATCH_SIZE = 5  # questions per LLM call
+SLEEP = 0.5  # polite pause
+
+# ------------------- 4. Prompt templates ----------------------
+PROMPT_TEMPLATES = [
+    "Generate {n} **basic** Q&A pairs for a newcomer. Keep answers short and verbatim from the text.",
+    "Create {n} **explanatory** Q&A pairs (why/how). Quote the exact rule that justifies the answer.",
+    "Formulate {n} **scenario-based** Q&A pairs that a branch manager might face. Answer must be provable.",
+    "Produce {n} **definition / eligibility** Q&A pairs. Use only the wording in the passage.",
+    "Make {n} **provisioning / claim** Q&A pairs with exact percentages and timelines.",
+]
+
+
+def build_prompt(text: str, n: int) -> str:
+    tmpl = random.choice(PROMPT_TEMPLATES)
+    return f"""You are a precise document-QA expert.
+Read the passage below and output **exactly {n}** Q&A pairs in the format:
+
+Q: <question>
+A: <answer>
+
+Rules:
+- Answer must be a direct quote or a provable derivation from the passage.
+- No hallucination, no extra explanation.
+- Keep each answer ≤ 2 sentences.
+
+{tmpl}
+
+-
+
+
+{text}
+"""
+
+
+# ------------------- 5. LLM generation -----------------------
+def generate_batch(text: str, n: int = BATCH_SIZE):
+    prompt = build_prompt(text, n)
+    out = pipe(
+        prompt, max_new_tokens=4096, temperature=0.7, do_sample=True, top_p=0.92
+    )[0]["generated_text"]
+    # extract Q: … A: … blocks
+    pairs = re.findall(r"Q:\s*(.+?)\s*A:\s*(.+?)(?=Q:|$)", out, re.DOTALL)
+    return [(q.strip(), a.strip()) for q, a in pairs]
+
+
+# ------------------- 6. Deduplication & saving ---------------
+seen_hashes = set()
+
+with open(OUTPUT_FILE, "a", encoding="utf-8") as f:
+    generated = 0
+    pbar = tqdm(total=TARGET_QA, desc="Generating Q&A")
+
+    while generated < TARGET_QA:
+        raw = generate_batch(passage, BATCH_SIZE)
+        for q, a in raw:
+            q_hash = hashlib.sha1(q.encode("utf-8")).hexdigest()[:12]
+            if q_hash in seen_hashes:
+                continue
+            seen_hashes.add(q_hash)
+
+            record = {
+                "id": q_hash,
+                "question": q,
+                "answer": a,
+                "source_passage": passage.strip()[:500] + "…",  # short preview
+            }
+            f.write(json.dumps(record, ensure_ascii=False) + "\n")
+            generated += 1
+            pbar.update(1)
+            if generated >= TARGET_QA:
+                break
+        time.sleep(SLEEP)
+
+    pbar.close()
+
+print(f"\nFinished! {generated} unique Q&A saved to **{OUTPUT_FILE}**")
diff --git a/frontend/requirements.txt b/frontend/requirements.txt
new file mode 100644
index 0000000..53e65d7
--- /dev/null
+++ b/frontend/requirements.txt
@@ -0,0 +1 @@
+pywebview>=4.4
diff --git a/frontend/script/chat.js b/frontend/script/chat.js
new file mode 100644
index 0000000..31e4d42
--- /dev/null
+++ b/frontend/script/chat.js
@@ -0,0 +1,912 @@
+document.addEventListener('DOMContentLoaded', function() {
+    const chatContainer = document.getElementById('chatContainer');
+    const userInput = document.getElementById('userInput');
+    const sendButton = document.getElementById('sendButton');
+    const typingIndicator = document.getElementById('typingIndicator');
+
+    // No PIN prompt; use a default key
+    if (!localStorage.getItem('userPin')) {
+        localStorage.setItem('userPin', 'default');
+    }
+    // Load chat history on page load
+    loadChatHistory();
+
+    // Auto-resize textarea
+    userInput.addEventListener('input', function() {
+        this.style.height = 'auto';
+        this.style.height = (this.scrollHeight) + 'px';
+    });
+
+    // Load chat history from localStorage
+    function getHistoryKey() {
+        const pin = localStorage.getItem('userPin') || 'default';
+        return `chatHistory_${pin}`;
+    }
+
+    function loadChatHistory() {
+        const savedHistory = localStorage.getItem(getHistoryKey());
+        if (savedHistory) {
+            const messages = JSON.parse(savedHistory);
+            // Clear the default AI message
+            chatContainer.innerHTML = '';
+            // Load all saved messages
+            messages.forEach(msg => {
+                addMessageToDOM(msg.text, msg.type, false);
+            });
+        }
+    }
+
+    // Save chat history to localStorage
+    function saveChatHistory() {
+        const messages = [];
+        const messageElements = chatContainer.querySelectorAll('.message');
+        messageElements.forEach(element => {
+            const text = element.querySelector('p').textContent;
+            const type = element.classList.contains('user-message') ? 'user' : 'ai';
+            messages.push({ text, type, timestamp: new Date().toISOString() });
+        });
+        localStorage.setItem(getHistoryKey(), JSON.stringify(messages));
+    }
+
+// Clear chat history
+function clearChatHistory() {
+    // Create a custom confirmation with buttons
+    const confirmDiv = document.createElement('div');
+    confirmDiv.innerHTML = `
+        <div style="position: fixed; top: 50%; left: 50%; transform: translate(-50%, -50%);
+                   background: linear-gradient(135deg, #2c3e50, #34495e); color: white;
+                   padding: 30px; border-radius: 15px; box-shadow: 0 20px 40px rgba(0,0,0,0.5);
+                   z-index: 10001; text-align: center; max-width: 400px;">
+            <h3 style="margin-bottom: 20px;">Clear Chat History</h3>
+            <p style="margin-bottom: 25px; color: rgba(255,255,255,0.8);">Are you sure you want to clear all chat history? This action cannot be undone.</p>
+            <div style="display: flex; gap: 15px; justify-content: center;">
+                <button onclick="confirmClearHistory()" style="background: #e74c3c; color: white; border: none;
+                             padding: 10px 20px; border-radius: 8px; cursor: pointer; font-weight: 600;">
+                    Yes, Clear All
+                </button>
+                <button onclick="cancelClearHistory()" style="background: #3b82f6; color: white; border: none;
+                             padding: 10px 20px; border-radius: 8px; cursor: pointer; font-weight: 600;">
+                    Cancel
+                </button>
+            </div>
+        </div>
+    `;
+    document.body.appendChild(confirmDiv);
+
+    window.confirmClearHistory = function() {
+        localStorage.removeItem(getHistoryKey());
+        chatContainer.innerHTML = '';
+        addMessageToDOM("Hello! I'm your personal AI assistant. How can I help you today?", 'ai', false);
+        // Close the history modal after clearing
+        closeHistoryModal();
+        document.body.removeChild(confirmDiv);
+        showNotification('Chat history cleared successfully!', 'success');
+    };
+
+    window.cancelClearHistory = function() {
+        document.body.removeChild(confirmDiv);
+    };
+}
+
+    // Send message function
+    function sendMessage() {
+        const message = userInput.value.trim();
+        if (message) {
+            // Add user message
+            addMessage(message, 'user');
+            userInput.value = '';
+            userInput.style.height = 'auto';
+
+            // Show typing indicator
+            typingIndicator.style.display = 'block';
+
+            // Simulate AI response after a delay
+            // Call Python backend using pywebview
+window.pywebview.api.get_ai_response(message)
+.then(response => {
+typingIndicator.style.display = 'none';
+if (response.status === "ok") {
+    addMessage(response.answer, 'ai');
+} else {
+    addMessage("⚠️ Error: " + response.message, 'ai');
+}
+// Save history after AI response
+saveChatHistory();
+})
+.catch(err => {
+typingIndicator.style.display = 'none';
+addMessage("⚠️ Failed to reach backend: " + err, 'ai');
+// Save history even if there's an error
+saveChatHistory();
+});
+
+        }
+    }
+
+    // Add message to chat (with save option)
+    function addMessage(text, type, saveToHistory = true) {
+        addMessageToDOM(text, type, saveToHistory);
+    }
+
+    // Add message to DOM
+    function addMessageToDOM(text, type, saveToHistory = true) {
+        const messageDiv = document.createElement('div');
+        messageDiv.className = `message ${type}-message`;
+        messageDiv.innerHTML = `
+            <p>${text}</p>
+            ${type === 'ai' ? `
+            <div class="feedback-buttons">
+                <button class="feedback-button" title="Like">👍</button>
+                <button class="feedback-button" title="Dislike">👎</button>
+            </div>
+            ` : ''}
+        `;
+        chatContainer.appendChild(messageDiv);
+        chatContainer.scrollTop = chatContainer.scrollHeight;
+
+        // Save to history if requested
+        if (saveToHistory) {
+            saveChatHistory();
+        }
+    }
+
+    // Event listeners
+    sendButton.addEventListener('click', sendMessage);
+
+    userInput.addEventListener('keypress', function(e) {
+        if (e.key === 'Enter' && !e.shiftKey) {
+            e.preventDefault();
+            sendMessage();
+        }
+    });
+
+    // Add navigation functionality
+    const navItems = document.querySelectorAll('.nav-item');
+    navItems.forEach(item => {
+        item.addEventListener('click', function() {
+            navItems.forEach(i => i.classList.remove('active'));
+            this.classList.add('active');
+        });
+    });
+
+    // Add clear history button functionality
+    window.clearChatHistory = clearChatHistory;
+
+    // Add logout functionality
+    window.logout = logout;
+
+    // Add history modal functionality
+    window.showChatHistory = showChatHistory;
+    window.closeHistoryModal = closeHistoryModal;
+
+    // Add settings functionality
+    window.showSettings = showSettings;
+    window.closeSettingsModal = closeSettingsModal;
+    window.updateFontSize = updateFontSize;
+    window.saveSettings = saveSettings;
+    window.resetSettings = resetSettings;
+
+    // Add help center functionality
+    window.showHelpCenter = showHelpCenter;
+    window.closeHelpModal = closeHelpModal;
+    window.submitFeedback = submitFeedback;
+
+    // Add notification functionality
+    window.showNotification = showNotification;
+
+    // Load saved settings on page load
+    loadSettings();
+});
+
+// Show chat history in modal
+function showChatHistory() {
+    const modal = document.getElementById('historyModal');
+    const historyContent = document.getElementById('historyContent');
+
+    const savedHistory = localStorage.getItem('chatHistory');
+    if (savedHistory) {
+        const messages = JSON.parse(savedHistory);
+        let historyHTML = '';
+
+        messages.forEach(msg => {
+            const timestamp = new Date(msg.timestamp).toLocaleString();
+            historyHTML += `
+                <div class="history-message ${msg.type}">
+                    <div>${msg.text}</div>
+                    <div class="history-timestamp">${timestamp}</div>
+                </div>
+            `;
+        });
+
+        historyContent.innerHTML = historyHTML;
+    } else {
+        historyContent.innerHTML = '<div class="no-history">No chat history found.</div>';
+    }
+
+    modal.style.display = 'flex';
+}
+
+// Close history modal
+function closeHistoryModal() {
+    document.getElementById('historyModal').style.display = 'none';
+}
+
+// Logout function
+function logout() {
+    // Create a custom confirmation with buttons
+    const confirmDiv = document.createElement('div');
+    confirmDiv.innerHTML = `
+        <div style="position: fixed; top: 50%; left: 50%; transform: translate(-50%, -50%);
+                   background: linear-gradient(135deg, #2c3e50, #34495e); color: white;
+                   padding: 30px; border-radius: 15px; box-shadow: 0 20px 40px rgba(0,0,0,0.5);
+                   z-index: 10001; text-align: center; max-width: 400px;">
+            <h3 style="margin-bottom: 20px;">Logout</h3>
+            <p style="margin-bottom: 25px; color: rgba(255,255,255,0.8);">Are you sure you want to logout?</p>
+            <div style="display: flex; gap: 15px; justify-content: center;">
+                <button onclick="confirmLogout()" style="background: #e74c3c; color: white; border: none;
+                             padding: 10px 20px; border-radius: 8px; cursor: pointer; font-weight: 600;">
+                    Yes, Logout
+                </button>
+                <button onclick="cancelLogout()" style="background: #3b82f6; color: white; border: none;
+                             padding: 10px 20px; border-radius: 8px; cursor: pointer; font-weight: 600;">
+                    Cancel
+                </button>
+            </div>
+        </div>
+    `;
+    document.body.appendChild(confirmDiv);
+
+    window.confirmLogout = function() {
+        // Clear any session data if needed
+        // Redirect to upload page
+        document.body.removeChild(confirmDiv);
+        window.location.href = 'admin.html';
+    };
+
+    window.cancelLogout = function() {
+        document.body.removeChild(confirmDiv);
+    };
+}
+
+// Close modal when clicking outside
+window.onclick = function(event) {
+    const historyModal = document.getElementById('historyModal');
+    const settingsModal = document.getElementById('settingsModal');
+    const helpModal = document.getElementById('helpModal');
+    if (event.target === historyModal) {
+        closeHistoryModal();
+    }
+    if (event.target === settingsModal) {
+        closeSettingsModal();
+    }
+    if (event.target === helpModal) {
+        closeHelpModal();
+    }
+}
+
+// Settings Modal Functions
+function showSettings() {
+    document.getElementById('settingsModal').style.display = 'flex';
+    loadSettings(); // Load current settings into the modal
+}
+
+function closeSettingsModal() {
+    document.getElementById('settingsModal').style.display = 'none';
+}
+
+// Font size update function
+function updateFontSize(value) {
+    document.getElementById('fontSizeValue').textContent = value;
+    document.body.style.fontSize = value + 'px';
+}
+
+// Load settings from localStorage
+function loadSettings() {
+    const savedTheme = localStorage.getItem('chatTheme') || 'dark';
+    const savedFontSize = localStorage.getItem('chatFontSize') || '16';
+
+    // Apply theme
+    document.body.className = 'theme-' + savedTheme;
+
+    // Apply font size
+    document.body.style.fontSize = savedFontSize + 'px';
+    document.getElementById('fontSizeSlider').value = savedFontSize;
+    document.getElementById('fontSizeValue').textContent = savedFontSize;
+
+    // Set radio button
+    document.querySelector(`input[name="theme"][value="${savedTheme}"]`).checked = true;
+}
+
+// Save settings to localStorage
+function saveSettings() {
+    const selectedTheme = document.querySelector('input[name="theme"]:checked').value;
+    const fontSize = document.getElementById('fontSizeSlider').value;
+
+    // Save to localStorage
+    localStorage.setItem('chatTheme', selectedTheme);
+    localStorage.setItem('chatFontSize', fontSize);
+
+    // Apply settings immediately
+    document.body.className = 'theme-' + selectedTheme;
+    document.body.style.fontSize = fontSize + 'px';
+
+    // Show success message
+    showNotification('Settings saved successfully!', 'success');
+    closeSettingsModal();
+}
+
+// Reset settings to default
+function resetSettings() {
+    showNotification('Are you sure you want to reset all settings to default?', 'warning', 5000);
+
+    // Create a custom confirmation with buttons
+    const confirmDiv = document.createElement('div');
+    confirmDiv.innerHTML = `
+        <div style="position: fixed; top: 50%; left: 50%; transform: translate(-50%, -50%);
+                   background: linear-gradient(135deg, #2c3e50, #34495e); color: white;
+                   padding: 30px; border-radius: 15px; box-shadow: 0 20px 40px rgba(0,0,0,0.5);
+                   z-index: 10001; text-align: center; max-width: 400px;">
+            <h3 style="margin-bottom: 20px;">Reset Settings</h3>
+            <p style="margin-bottom: 25px; color: rgba(255,255,255,0.8);">Are you sure you want to reset all settings to default?</p>
+            <div style="display: flex; gap: 15px; justify-content: center;">
+                <button onclick="confirmReset()" style="background: #e74c3c; color: white; border: none;
+                             padding: 10px 20px; border-radius: 8px; cursor: pointer; font-weight: 600;">
+                    Yes, Reset
+                </button>
+                <button onclick="cancelReset()" style="background: #3b82f6; color: white; border: none;
+                             padding: 10px 20px; border-radius: 8px; cursor: pointer; font-weight: 600;">
+                    Cancel
+                </button>
+            </div>
+        </div>
+    `;
+    document.body.appendChild(confirmDiv);
+
+    window.confirmReset = function() {
+        localStorage.removeItem('chatTheme');
+        localStorage.removeItem('chatFontSize');
+
+        // Reset to default values
+        document.body.className = '';
+        document.body.style.fontSize = '16px';
+        document.getElementById('fontSizeSlider').value = '16';
+        document.getElementById('fontSizeValue').textContent = '16';
+        document.querySelector('input[name="theme"][value="dark"]').checked = true;
+
+        showNotification('Settings reset to default!', 'success');
+        document.body.removeChild(confirmDiv);
+        closeSettingsModal();
+    };
+
+    window.cancelReset = function() {
+        document.body.removeChild(confirmDiv);
+    };
+}
+
+// Help Center Functions
+function showHelpCenter() {
+    document.getElementById('helpModal').style.display = 'flex';
+}
+
+function closeHelpModal() {
+    document.getElementById('helpModal').style.display = 'none';
+}
+
+// Notification system
+function showNotification(message, type = 'info', duration = 3000) {
+    const notification = document.getElementById('notification');
+    const icon = notification.querySelector('.notification-icon');
+    const messageEl = notification.querySelector('.notification-message');
+
+    // Set message
+    messageEl.textContent = message;
+
+    // Set icon and type
+    notification.className = `notification ${type}`;
+    switch(type) {
+        case 'success':
+            icon.className = 'notification-icon fas fa-check-circle';
+            break;
+        case 'error':
+            icon.className = 'notification-icon fas fa-exclamation-circle';
+            break;
+        case 'warning':
+            icon.className = 'notification-icon fas fa-exclamation-triangle';
+            break;
+        default:
+            icon.className = 'notification-icon fas fa-info-circle';
+    }
+
+    // Show notification
+    notification.style.display = 'block';
+    setTimeout(() => notification.classList.add('show'), 100);
+
+    // Auto hide
+    setTimeout(() => {
+        notification.classList.remove('show');
+        setTimeout(() => notification.style.display = 'none', 300);
+    }, duration);
+}
+
+// Submit feedback function
+function submitFeedback() {
+    const feedbackText = document.getElementById('feedbackText').value.trim();
+
+    if (!feedbackText) {
+        showNotification('Please enter your feedback before submitting.', 'warning');
+        return;
+    }
+
+    // Here you would typically send the feedback to your backend
+    // For now, we'll just show a success message and save to localStorage
+    const feedback = {
+        text: feedbackText,
+        timestamp: new Date().toISOString(),
+        userAgent: navigator.userAgent
+    };
+
+    // Save feedback to localStorage (in a real app, this would go to a server)
+    const existingFeedback = JSON.parse(localStorage.getItem('userFeedback') || '[]');
+    existingFeedback.push(feedback);
+    localStorage.setItem('userFeedback', JSON.stringify(existingFeedback)); document.addEventListener('DOMContentLoaded', function() {
+            const chatContainer = document.getElementById('chatContainer');
+            const userInput = document.getElementById('userInput');
+            const sendButton = document.getElementById('sendButton');
+            const typingIndicator = document.getElementById('typingIndicator');
+
+            // Load chat history on page load
+            loadChatHistory();
+
+            // Auto-resize textarea
+            userInput.addEventListener('input', function() {
+                this.style.height = 'auto';
+                this.style.height = (this.scrollHeight) + 'px';
+            });
+
+            // Load chat history from localStorage
+            function loadChatHistory() {
+                const savedHistory = localStorage.getItem('chatHistory');
+                if (savedHistory) {
+                    const messages = JSON.parse(savedHistory);
+                    // Clear the default AI message
+                    chatContainer.innerHTML = '';
+                    // Load all saved messages
+                    messages.forEach(msg => {
+                        addMessageToDOM(msg.text, msg.type, false);
+                    });
+                }
+            }
+
+            // Save chat history to localStorage
+            function saveChatHistory() {
+                const messages = [];
+                const messageElements = chatContainer.querySelectorAll('.message');
+                messageElements.forEach(element => {
+                    const text = element.querySelector('p').textContent;
+                    const type = element.classList.contains('user-message') ? 'user' : 'ai';
+                    messages.push({ text, type, timestamp: new Date().toISOString() });
+                });
+                localStorage.setItem('chatHistory', JSON.stringify(messages));
+            }
+
+        // Clear chat history
+        function clearChatHistory() {
+            // Create a custom confirmation with buttons
+            const confirmDiv = document.createElement('div');
+            confirmDiv.innerHTML = `
+                <div style="position: fixed; top: 50%; left: 50%; transform: translate(-50%, -50%);
+                           background: linear-gradient(135deg, #2c3e50, #34495e); color: white;
+                           padding: 30px; border-radius: 15px; box-shadow: 0 20px 40px rgba(0,0,0,0.5);
+                           z-index: 10001; text-align: center; max-width: 400px;">
+                    <h3 style="margin-bottom: 20px;">Clear Chat History</h3>
+                    <p style="margin-bottom: 25px; color: rgba(255,255,255,0.8);">Are you sure you want to clear all chat history? This action cannot be undone.</p>
+                    <div style="display: flex; gap: 15px; justify-content: center;">
+                        <button onclick="confirmClearHistory()" style="background: #e74c3c; color: white; border: none;
+                                     padding: 10px 20px; border-radius: 8px; cursor: pointer; font-weight: 600;">
+                            Yes, Clear All
+                        </button>
+                        <button onclick="cancelClearHistory()" style="background: #3b82f6; color: white; border: none;
+                                     padding: 10px 20px; border-radius: 8px; cursor: pointer; font-weight: 600;">
+                            Cancel
+                        </button>
+                    </div>
+                </div>
+            `;
+            document.body.appendChild(confirmDiv);
+
+            window.confirmClearHistory = function() {
+                localStorage.removeItem('chatHistory');
+                chatContainer.innerHTML = '';
+                addMessageToDOM("Hello! I'm your personal AI assistant. How can I help you today?", 'ai', false);
+                // Close the history modal after clearing
+                closeHistoryModal();
+                document.body.removeChild(confirmDiv);
+                showNotification('Chat history cleared successfully!', 'success');
+            };
+
+            window.cancelClearHistory = function() {
+                document.body.removeChild(confirmDiv);
+            };
+        }
+
+            // Send message function
+            function sendMessage() {
+                const message = userInput.value.trim();
+                if (message) {
+                    // Add user message
+                    addMessage(message, 'user');
+                    userInput.value = '';
+                    userInput.style.height = 'auto';
+
+                    // Show typing indicator
+                    typingIndicator.style.display = 'block';
+
+                    // Simulate AI response after a delay
+                    // Call Python backend using pywebview
+window.pywebview.api.get_ai_response(message)
+.then(response => {
+        typingIndicator.style.display = 'none';
+        if (response.status === "ok") {
+            addMessage(response.answer, 'ai');
+        } else {
+            addMessage("⚠️ Error: " + response.message, 'ai');
+        }
+        // Save history after AI response
+        saveChatHistory();
+    })
+    .catch(err => {
+        typingIndicator.style.display = 'none';
+        addMessage("⚠️ Failed to reach backend: " + err, 'ai');
+        // Save history even if there's an error
+        saveChatHistory();
+    });
+
+                }
+            }
+
+            // Add message to chat (with save option)
+            function addMessage(text, type, saveToHistory = true) {
+                addMessageToDOM(text, type, saveToHistory);
+            }
+
+            // Add message to DOM
+            function addMessageToDOM(text, type, saveToHistory = true) {
+                const messageDiv = document.createElement('div');
+                messageDiv.className = `message ${type}-message`;
+                messageDiv.innerHTML = `
+                    <p>${text}</p>
+                    ${type === 'ai' ? `
+                    <div class="feedback-buttons">
+                        <button class="feedback-button" title="Like">👍</button>
+                        <button class="feedback-button" title="Dislike">👎</button>
+                    </div>
+                    ` : ''}
+                `;
+                chatContainer.appendChild(messageDiv);
+                chatContainer.scrollTop = chatContainer.scrollHeight;
+
+                // Save to history if requested
+                if (saveToHistory) {
+                    saveChatHistory();
+                }
+            }
+
+            // Event listeners
+            sendButton.addEventListener('click', sendMessage);
+
+            userInput.addEventListener('keypress', function(e) {
+                if (e.key === 'Enter' && !e.shiftKey) {
+                    e.preventDefault();
+                    sendMessage();
+                }
+            });
+
+            // Add navigation functionality
+            const navItems = document.querySelectorAll('.nav-item');
+            navItems.forEach(item => {
+                item.addEventListener('click', function() {
+                    navItems.forEach(i => i.classList.remove('active'));
+                    this.classList.add('active');
+                });
+            });
+
+            // Add clear history button functionality
+            window.clearChatHistory = clearChatHistory;
+
+            // Add logout functionality
+            window.logout = logout;
+
+            // Add history modal functionality
+            window.showChatHistory = showChatHistory;
+            window.closeHistoryModal = closeHistoryModal;
+
+            // Add settings functionality
+            window.showSettings = showSettings;
+            window.closeSettingsModal = closeSettingsModal;
+            window.updateFontSize = updateFontSize;
+            window.saveSettings = saveSettings;
+            window.resetSettings = resetSettings;
+
+            // Add help center functionality
+            window.showHelpCenter = showHelpCenter;
+            window.closeHelpModal = closeHelpModal;
+            window.submitFeedback = submitFeedback;
+
+            // Add notification functionality
+            window.showNotification = showNotification;
+
+            // Load saved settings on page load
+            loadSettings();
+        });
+
+        // Show chat history in modal
+        function showChatHistory() {
+            const modal = document.getElementById('historyModal');
+            const historyContent = document.getElementById('historyContent');
+
+            const savedHistory = localStorage.getItem('chatHistory');
+            if (savedHistory) {
+                const messages = JSON.parse(savedHistory);
+                let historyHTML = '';
+
+                messages.forEach(msg => {
+                    const timestamp = new Date(msg.timestamp).toLocaleString();
+                    historyHTML += `
+                        <div class="history-message ${msg.type}">
+                            <div>${msg.text}</div>
+                            <div class="history-timestamp">${timestamp}</div>
+                        </div>
+                    `;
+                });
+
+                historyContent.innerHTML = historyHTML;
+            } else {
+                historyContent.innerHTML = '<div class="no-history">No chat history found.</div>';
+            }
+
+            modal.style.display = 'flex';
+        }
+
+        // Close history modal
+        function closeHistoryModal() {
+            document.getElementById('historyModal').style.display = 'none';
+        }
+
+        // Logout function
+        function logout() {
+            // Create a custom confirmation with buttons
+            const confirmDiv = document.createElement('div');
+            confirmDiv.innerHTML = `
+                <div style="position: fixed; top: 50%; left: 50%; transform: translate(-50%, -50%);
+                           background: linear-gradient(135deg, #2c3e50, #34495e); color: white;
+                           padding: 30px; border-radius: 15px; box-shadow: 0 20px 40px rgba(0,0,0,0.5);
+                           z-index: 10001; text-align: center; max-width: 400px;">
+                    <h3 style="margin-bottom: 20px;">Logout</h3>
+                    <p style="margin-bottom: 25px; color: rgba(255,255,255,0.8);">Are you sure you want to logout?</p>
+                    <div style="display: flex; gap: 15px; justify-content: center;">
+                        <button onclick="confirmLogout()" style="background: #e74c3c; color: white; border: none;
+                                     padding: 10px 20px; border-radius: 8px; cursor: pointer; font-weight: 600;">
+                            Yes, Logout
+                        </button>
+                        <button onclick="cancelLogout()" style="background: #3b82f6; color: white; border: none;
+                                     padding: 10px 20px; border-radius: 8px; cursor: pointer; font-weight: 600;">
+                            Cancel
+                        </button>
+                    </div>
+                </div>
+            `;
+            document.body.appendChild(confirmDiv);
+
+            window.confirmLogout = function() {
+                // Clear any session data if needed
+                // Redirect to upload page
+                document.body.removeChild(confirmDiv);
+                window.location.href = 'admin.html';
+            };
+
+            window.cancelLogout = function() {
+                document.body.removeChild(confirmDiv);
+            };
+        }
+
+        // Close modal when clicking outside
+        window.onclick = function(event) {
+            const historyModal = document.getElementById('historyModal');
+            const settingsModal = document.getElementById('settingsModal');
+            const helpModal = document.getElementById('helpModal');
+            if (event.target === historyModal) {
+                closeHistoryModal();
+            }
+            if (event.target === settingsModal) {
+                closeSettingsModal();
+            }
+            if (event.target === helpModal) {
+                closeHelpModal();
+            }
+        }
+
+        // Settings Modal Functions
+        function showSettings() {
+            document.getElementById('settingsModal').style.display = 'flex';
+            loadSettings(); // Load current settings into the modal
+        }
+
+        function closeSettingsModal() {
+            document.getElementById('settingsModal').style.display = 'none';
+        }
+
+        // Font size update function
+        function updateFontSize(value) {
+            document.getElementById('fontSizeValue').textContent = value;
+            document.body.style.fontSize = value + 'px';
+        }
+
+        // Load settings from localStorage
+        function loadSettings() {
+            const savedTheme = localStorage.getItem('chatTheme') || 'dark';
+            const savedFontSize = localStorage.getItem('chatFontSize') || '16';
+
+            // Apply theme
+            document.body.className = 'theme-' + savedTheme;
+
+            // Apply font size
+            document.body.style.fontSize = savedFontSize + 'px';
+            document.getElementById('fontSizeSlider').value = savedFontSize;
+            document.getElementById('fontSizeValue').textContent = savedFontSize;
+
+            // Set radio button
+            document.querySelector(`input[name="theme"][value="${savedTheme}"]`).checked = true;
+        }
+
+        // Save settings to localStorage
+        function saveSettings() {
+            const selectedTheme = document.querySelector('input[name="theme"]:checked').value;
+            const fontSize = document.getElementById('fontSizeSlider').value;
+
+            // Save to localStorage
+            localStorage.setItem('chatTheme', selectedTheme);
+            localStorage.setItem('chatFontSize', fontSize);
+
+            // Apply settings immediately
+            document.body.className = 'theme-' + selectedTheme;
+            document.body.style.fontSize = fontSize + 'px';
+
+            // Show success message
+            showNotification('Settings saved successfully!', 'success');
+            closeSettingsModal();
+        }
+
+        // Reset settings to default
+        function resetSettings() {
+            showNotification('Are you sure you want to reset all settings to default?', 'warning', 5000);
+
+            // Create a custom confirmation with buttons
+            const confirmDiv = document.createElement('div');
+            confirmDiv.innerHTML = `
+                <div style="position: fixed; top: 50%; left: 50%; transform: translate(-50%, -50%);
+                           background: linear-gradient(135deg, #2c3e50, #34495e); color: white;
+                           padding: 30px; border-radius: 15px; box-shadow: 0 20px 40px rgba(0,0,0,0.5);
+                           z-index: 10001; text-align: center; max-width: 400px;">
+                    <h3 style="margin-bottom: 20px;">Reset Settings</h3>
+                    <p style="margin-bottom: 25px; color: rgba(255,255,255,0.8);">Are you sure you want to reset all settings to default?</p>
+                    <div style="display: flex; gap: 15px; justify-content: center;">
+                        <button onclick="confirmReset()" style="background: #e74c3c; color: white; border: none;
+                                     padding: 10px 20px; border-radius: 8px; cursor: pointer; font-weight: 600;">
+                            Yes, Reset
+                        </button>
+                        <button onclick="cancelReset()" style="background: #3b82f6; color: white; border: none;
+                                     padding: 10px 20px; border-radius: 8px; cursor: pointer; font-weight: 600;">
+                            Cancel
+                        </button>
+                    </div>
+                </div>
+            `;
+            document.body.appendChild(confirmDiv);
+
+            window.confirmReset = function() {
+                localStorage.removeItem('chatTheme');
+                localStorage.removeItem('chatFontSize');
+
+                // Reset to default values
+                document.body.className = '';
+                document.body.style.fontSize = '16px';
+                document.getElementById('fontSizeSlider').value = '16';
+                document.getElementById('fontSizeValue').textContent = '16';
+                document.querySelector('input[name="theme"][value="dark"]').checked = true;
+
+                showNotification('Settings reset to default!', 'success');
+                document.body.removeChild(confirmDiv);
+                closeSettingsModal();
+            };
+
+            window.cancelReset = function() {
+                document.body.removeChild(confirmDiv);
+            };
+        }
+
+        // Help Center Functions
+        function showHelpCenter() {
+            document.getElementById('helpModal').style.display = 'flex';
+        }
+
+        function closeHelpModal() {
+            document.getElementById('helpModal').style.display = 'none';
+        }
+
+        // Notification system
+        function showNotification(message, type = 'info', duration = 3000) {
+            const notification = document.getElementById('notification');
+            const icon = notification.querySelector('.notification-icon');
+            const messageEl = notification.querySelector('.notification-message');
+
+            // Set message
+            messageEl.textContent = message;
+
+            // Set icon and type
+            notification.className = `notification ${type}`;
+            switch(type) {
+                case 'success':
+                    icon.className = 'notification-icon fas fa-check-circle';
+                    break;
+                case 'error':
+                    icon.className = 'notification-icon fas fa-exclamation-circle';
+                    break;
+                case 'warning':
+                    icon.className = 'notification-icon fas fa-exclamation-triangle';
+                    break;
+                default:
+                    icon.className = 'notification-icon fas fa-info-circle';
+            }
+
+            // Show notification
+            notification.style.display = 'block';
+            setTimeout(() => notification.classList.add('show'), 100);
+
+            // Auto hide
+            setTimeout(() => {
+                notification.classList.remove('show');
+                setTimeout(() => notification.style.display = 'none', 300);
+            }, duration);
+        }
+
+        // Submit feedback function
+        function submitFeedback() {
+            const feedbackText = document.getElementById('feedbackText').value.trim();
+
+            if (!feedbackText) {
+                showNotification('Please enter your feedback before submitting.', 'warning');
+                return;
+            }
+
+            // Here you would typically send the feedback to your backend
+            // For now, we'll just show a success message and save to localStorage
+            const feedback = {
+                text: feedbackText,
+                timestamp: new Date().toISOString(),
+                userAgent: navigator.userAgent
+            };
+
+            // Save feedback to localStorage (in a real app, this would go to a server)
+            const existingFeedback = JSON.parse(localStorage.getItem('userFeedback') || '[]');
+            existingFeedback.push(feedback);
+            localStorage.setItem('userFeedback', JSON.stringify(existingFeedback));
+
+            // Show success message
+            showNotification('Thank you for your feedback! We appreciate your input.', 'success');
+
+            // Clear the form
+            document.getElementById('feedbackText').value = '';
+
+            // Close the modal
+            closeHelpModal();
+        }
+
+    // Show success message
+    showNotification('Thank you for your feedback! We appreciate your input.', 'success');
+
+    // Clear the form
+    document.getElementById('feedbackText').value = '';
+
+    // Close the modal
+    closeHelpModal();
+}
diff --git a/frontend/script/script.js b/frontend/script/script.js
new file mode 100644
index 0000000..08a07f8
--- /dev/null
+++ b/frontend/script/script.js
@@ -0,0 +1,99 @@
+document.addEventListener('DOMContentLoaded', function() {
+  const chatContainer = document.getElementById('chatContainer');
+  const userInput = document.getElementById('userInput');
+  const sendButton = document.getElementById('sendButton');
+  const typingIndicator = document.getElementById('typingIndicator');
+
+  // Auto-resize textarea
+  userInput.addEventListener('input', function() {
+      this.style.height = 'auto';
+      this.style.height = (this.scrollHeight) + 'px';
+  });
+
+  // Function to add a message to the chat
+  function addMessage(text, isUser) {
+      const messageDiv = document.createElement('div');
+      messageDiv.className = `message ${isUser ? 'user-message' : 'ai-message'}`;
+
+      const messageText = document.createElement('p');
+      messageText.textContent = text;
+      messageDiv.appendChild(messageText);
+
+      if (!isUser) {
+          const feedbackDiv = document.createElement('div');
+          feedbackDiv.className = 'feedback-buttons';
+
+          const thumbsUp = document.createElement('button');
+          thumbsUp.className = 'feedback-button';
+          thumbsUp.title = 'Like';
+          thumbsUp.textContent = '👍';
+          thumbsUp.addEventListener('click', function() {
+              thumbsUp.classList.toggle('active');
+              thumbsDown.classList.remove('active');
+              console.log('User liked the response');
+          });
+
+          const thumbsDown = document.createElement('button');
+          thumbsDown.className = 'feedback-button';
+          thumbsDown.title = 'Dislike';
+          thumbsDown.textContent = '👎';
+          thumbsDown.addEventListener('click', function() {
+              thumbsDown.classList.toggle('active');
+              thumbsUp.classList.remove('active');
+              console.log('User disliked the response');
+          });
+
+          feedbackDiv.appendChild(thumbsUp);
+          feedbackDiv.appendChild(thumbsDown);
+          messageDiv.appendChild(feedbackDiv);
+      }
+
+      chatContainer.appendChild(messageDiv);
+      chatContainer.scrollTop = chatContainer.scrollHeight;
+  }
+
+  // Function to simulate AI response
+  function getAIResponse(userMessage) {
+      const responses = [
+          "I understand you're asking about " + userMessage + ". Here's what I can tell you...",
+          "That's an interesting question about " + userMessage + ". Let me think...",
+          "I can help with " + userMessage + ". Here's some information...",
+          "Regarding " + userMessage + ", here's what I found...",
+          userMessage + " is a great topic. Here are my thoughts..."
+      ];
+
+      return responses[Math.floor(Math.random() * responses.length)];
+  }
+
+  // Handle send button click
+  sendButton.addEventListener('click', function() {
+      const message = userInput.value.trim();
+      if (message) {
+          addMessage(message, true);
+          userInput.value = '';
+          userInput.style.height = 'auto';
+
+          // Show typing indicator
+          typingIndicator.style.display = 'block';
+          chatContainer.scrollTop = chatContainer.scrollHeight;
+
+          // Simulate AI thinking and responding
+          setTimeout(function() {
+              typingIndicator.style.display = 'none';
+              const aiResponse = getAIResponse(message);
+              addMessage(aiResponse, false);
+          }, 1500 + Math.random() * 2000);
+      }
+  });
+
+  // Handle Enter key press (Shift+Enter for new line)
+  userInput.addEventListener('keydown', function(e) {
+      if (e.key === 'Enter' && !e.shiftKey) {
+          e.preventDefault();
+          sendButton.click();
+      }
+  });
+
+  // Focus the input field when the page loads
+  userInput.focus();
+});
diff --git a/frontend/script/upload.js b/frontend/script/upload.js
new file mode 100644
index 0000000..55de2ee
--- /dev/null
+++ b/frontend/script/upload.js
@@ -0,0 +1,103 @@
+//Define Maximum File Size as 50MB
+const MAX_FILE_SIZE = 50 * 1024 * 1024;
+
+//Define Upload Chunk Size as 1MB
+const CHUNK_SIZE = 1024 * 1024;
+
+function arrayBufferToBase64(buffer) {
+  let binary = "";
+  const bytes = new Uint8Array(buffer);
+  const len = bytes.byteLength;
+
+  for (let i = 0; i < len; i++) {
+    binary += String.fromCharCode(bytes[i]);
+  }
+
+  return btoa(binary);
+}
+
+function resetUploadUI() {
+  const progressContainer = document.querySelector(".progress-container");
+  const progressBar = document.getElementById("progressBar");
+  const progressText = document.getElementById("progressText");
+  const doneMessage = document.getElementById("doneMessage");
+
+  if (progressContainer) {
+    progressContainer.style.display = "none";
+  }
+  if (progressBar) {
+    progressBar.style.width = "0%";
+  }
+  if (progressText) {
+    progressText.textContent = "0%";
+  }
+  if (doneMessage) {
+    doneMessage.style.display = "none";
+  }
+}
+
+async function uploadFile() {
+  const fileInput = document.getElementById("fileInput");
+
+  if (!fileInput || !fileInput.files || fileInput.files.length === 0) {
+    alert("Please select a file first.");
+    return;
+  }
+
+  const file = fileInput.files[0];
+
+  if (file.size > MAX_FILE_SIZE) {
+    alert("File is too large. Maximum allowed size is 50 MB.");
+    return;
+  }
+
+  const progressContainer = document.querySelector(".progress-container");
+  const progressBar = document.getElementById("progressBar");
+  const progressText = document.getElementById("progressText");
+  const doneMessage = document.getElementById("doneMessage");
+
+  progressContainer.style.display = "block";
+  progressBar.style.width = "0%";
+  progressText.textContent = "0%";
+  doneMessage.style.display = "none";
+
+  let offset = 0;
+  let chunkIndex = 0;
+
+  if (!window.pywebview || !window.pywebview.api || typeof window.pywebview.api.save_file_chunk !== "function") {
+    alert("Upload service is not available. Please try again.");
+    resetUploadUI();
+    return;
+  }
+
+  while (offset < file.size) {
+    const chunk = file.slice(offset, offset + CHUNK_SIZE);
+    const arrayBuffer = await chunk.arrayBuffer();
+
+    const base64Chunk = arrayBufferToBase64(arrayBuffer);
+    const result = await window.pywebview.api.save_file_chunk(
+      file.name,
+      base64Chunk,
+      chunkIndex,
+      offset + CHUNK_SIZE >= file.size
+    );
+    if (result !== "success") {
+      alert("Upload failed: " + result);
+      resetUploadUI();
+      return;
+    }
+
+    offset = Math.min(offset + CHUNK_SIZE, file.size);
+    chunkIndex++;
+
+    const progress = Math.round(Math.min((offset / file.size) * 100, 100));
+    progressBar.style.width = progress + "%";
+    progressText.textContent = progress + "%";
+  }
+  doneMessage.style.display = "block";
+  setTimeout(() => { window.location.href = "chat.html"; }, 1000);
+}
+
+function goToChat() {
+  window.location.href = "chat.html";
+}
diff --git a/frontend/user_history.json b/frontend/user_history.json
new file mode 100644
index 0000000..a826a35
--- /dev/null
+++ b/frontend/user_history.json
@@ -0,0 +1,52 @@
+{
+  "User 1": {
+    "email": "user1@example.com",
+    "login_history": [
+      {
+        "timestamp": "2025-10-28 11:55:13",
+        "date": "2025-10-28",
+        "time": "11:55:13"
+      },
+      {
+        "timestamp": "2025-10-28 11:58:35",
+        "date": "2025-10-28",
+        "time": "11:58:35"
+      },
+      {
+        "timestamp": "2025-10-28 12:02:58",
+        "date": "2025-10-28",
+        "time": "12:02:58"
+      },
+      {
+        "timestamp": "2025-10-28 12:19:07",
+        "date": "2025-10-28",
+        "time": "12:19:07"
+      },
+      {
+        "timestamp": "2025-10-28 15:45:16",
+        "date": "2025-10-28",
+        "time": "15:45:16"
+      },
+      {
+        "timestamp": "2025-10-28 18:16:36",
+        "date": "2025-10-28",
+        "time": "18:16:36"
+      },
+      {
+        "timestamp": "2025-10-28 19:19:22",
+        "date": "2025-10-28",
+        "time": "19:19:22"
+      },
+      {
+        "timestamp": "2025-10-28 19:47:55",
+        "date": "2025-10-28",
+        "time": "19:47:55"
+      },
+      {
+        "timestamp": "2026-01-11 16:58:21",
+        "date": "2026-01-11",
+        "time": "16:58:21"
+      }
+    ]
+  }
+}
diff --git a/hallucination_reduction/__pycache__/__init__.cpython-313.pyc b/hallucination_reduction/__pycache__/__init__.cpython-313.pyc
deleted file mode 100644
index 6226753..0000000
Binary files a/hallucination_reduction/__pycache__/__init__.cpython-313.pyc and /dev/null differ
diff --git a/hallucination_reduction/__pycache__/data_utils.cpython-313.pyc b/hallucination_reduction/__pycache__/data_utils.cpython-313.pyc
deleted file mode 100644
index fabdbc4..0000000
Binary files a/hallucination_reduction/__pycache__/data_utils.cpython-313.pyc and /dev/null differ
diff --git a/hallucination_reduction/__pycache__/discriminator.cpython-313.pyc b/hallucination_reduction/__pycache__/discriminator.cpython-313.pyc
deleted file mode 100644
index 1d7e7a1..0000000
Binary files a/hallucination_reduction/__pycache__/discriminator.cpython-313.pyc and /dev/null differ
diff --git a/hallucination_reduction/__pycache__/discriminator_training_utils.cpython-313.pyc b/hallucination_reduction/__pycache__/discriminator_training_utils.cpython-313.pyc
deleted file mode 100644
index 9104bb2..0000000
Binary files a/hallucination_reduction/__pycache__/discriminator_training_utils.cpython-313.pyc and /dev/null differ
diff --git a/hallucination_reduction/__pycache__/evaluation.cpython-313.pyc b/hallucination_reduction/__pycache__/evaluation.cpython-313.pyc
deleted file mode 100644
index d9f4954..0000000
Binary files a/hallucination_reduction/__pycache__/evaluation.cpython-313.pyc and /dev/null differ
diff --git a/hallucination_reduction/__pycache__/generator.cpython-313.pyc b/hallucination_reduction/__pycache__/generator.cpython-313.pyc
deleted file mode 100644
index 7e9381a..0000000
Binary files a/hallucination_reduction/__pycache__/generator.cpython-313.pyc and /dev/null differ
diff --git a/hallucination_reduction/__pycache__/main.cpython-313.pyc b/hallucination_reduction/__pycache__/main.cpython-313.pyc
deleted file mode 100644
index d8a8f54..0000000
Binary files a/hallucination_reduction/__pycache__/main.cpython-313.pyc and /dev/null differ
diff --git a/hallucination_reduction/__pycache__/retriever.cpython-313.pyc b/hallucination_reduction/__pycache__/retriever.cpython-313.pyc
deleted file mode 100644
index 3eb5283..0000000
Binary files a/hallucination_reduction/__pycache__/retriever.cpython-313.pyc and /dev/null differ
diff --git a/hallucination_reduction/__pycache__/rl_utils.cpython-313.pyc b/hallucination_reduction/__pycache__/rl_utils.cpython-313.pyc
deleted file mode 100644
index 6c6b13d..0000000
Binary files a/hallucination_reduction/__pycache__/rl_utils.cpython-313.pyc and /dev/null differ
diff --git a/hallucination_reduction/config.py b/hallucination_reduction/config.py
index 04f7d4a..8a60059 100644
--- a/hallucination_reduction/config.py
+++ b/hallucination_reduction/config.py
@@ -1,8 +1,8 @@
 import os
-import torch
 import random
-import numpy as np
 
+import numpy as np
+import torch
 
 SEED = 42
 random.seed(SEED)
@@ -29,7 +29,6 @@
     print(" No GPU detected. Using CPU.")
 
 
-
 GEN_MODEL = os.environ.get("GEN_MODEL", "TinyLlama/TinyLlama-1.1B-Chat-v1.0")
 DISC_MODEL = os.environ.get("DISC_MODEL", "distilbert-base-uncased")
 SAVE_DIR = "./saved_models_improved"
@@ -58,7 +57,7 @@
 FACT_WEIGHT = 0.8
 STYLE_WEIGHT = 0.15
 SAFETY_WEIGHT = 0.05
-HARD_PENALTY_IF_FACT_LT = 0.4  
+HARD_PENALTY_IF_FACT_LT = 0.4
 
 
 try:
diff --git a/hallucination_reduction/data_utils.py b/hallucination_reduction/data_utils.py
index cac7f8b..9394ba9 100644
--- a/hallucination_reduction/data_utils.py
+++ b/hallucination_reduction/data_utils.py
@@ -1,7 +1,7 @@
-from dataclasses import dataclass
-from typing import List, Tuple
-import random
 import json
+import os
+from dataclasses import dataclass
+from typing import List
 
 
 @dataclass
@@ -10,29 +10,41 @@ class QAPair:
     answer: str
     supporting_passages: List[str]
 
-def build_corpus_and_qa():
 
+def build_corpus_and_qa():
     with open("data/processed/corpus.txt", "r", encoding="utf-8") as f:
         passages = [line.strip() for line in f if line.strip()]
 
-
-    with open("data/qa/qa.json", "r", encoding="utf-8") as f:
-        raw_qas = json.load(f)
-
-    base_qa = [
-        QAPair(
-            qa["question"],
-            qa["answer"],
-            qa["supporting_passages"]
-        )
-        for qa in raw_qas
-    ]
-
-
-    augmented = []
+    qa_path = "data/qa/qa.json"
+    raw_qas: List[dict] = []
+    if os.path.exists(qa_path):
+        try:
+            with open(qa_path, "r", encoding="utf-8") as f:
+                data = json.load(f)
+                if isinstance(data, list):
+                    raw_qas = data
+        except Exception:
+            raw_qas = []
+
+    base_qa: List[QAPair] = []
+    for qa in raw_qas:
+        question = qa.get("question")
+        answer = qa.get("answer")
+        supp = qa.get("supporting_passages") or []
+        if isinstance(supp, str):
+            supp = [supp]
+        if question and answer:
+            base_qa.append(QAPair(question, answer, supp))
+
+    if not base_qa:
+        for p in passages[:200]:  # keep it bounded
+            q = "What does this passage say?"
+            a = p[:500]
+            base_qa.append(QAPair(q, a, [p]))
+
+    augmented: List[QAPair] = []
     for qa in base_qa:
         augmented.append(qa)
-
         q1 = qa.question.replace("Can a customer", "Is it possible for a customer")
         q2 = qa.question + " (please advise)"
         a1 = qa.answer
diff --git a/hallucination_reduction/discriminator.py b/hallucination_reduction/discriminator.py
index 3282fb9..0800086 100644
--- a/hallucination_reduction/discriminator.py
+++ b/hallucination_reduction/discriminator.py
@@ -1,23 +1,32 @@
-import torch
-from transformers import AutoTokenizer, AutoModelForSequenceClassification
-from torch.utils.data import Dataset
 from typing import List
+
 import numpy as np
+import torch
+from torch.utils.data import Dataset
+from transformers import AutoModelForSequenceClassification, AutoTokenizer
+
+from .config import DEVICE, DISC_MODEL
 
-from .config import DEVICE,DISC_MODEL
 
 def load_discriminator(model_name=DISC_MODEL, device=DEVICE, num_labels=2):
     tokenizer = AutoTokenizer.from_pretrained(model_name)
-    model = AutoModelForSequenceClassification.from_pretrained(model_name, num_labels=num_labels).to(device)
+    model = AutoModelForSequenceClassification.from_pretrained(
+        model_name, num_labels=num_labels
+    ).to(device)
     model.eval()
     return tokenizer, model
 
-def discriminator_predict_text(classifier, tokenizer, texts: List[str], device=DEVICE, batch_size=8):
+
+def discriminator_predict_text(
+    classifier, tokenizer, texts: List[str], device=DEVICE, batch_size=8
+):
     classifier.eval()
     results = []
     for i in range(0, len(texts), batch_size):
-        batch = texts[i:i+batch_size]
-        inputs = tokenizer(batch, return_tensors="pt", padding=True, truncation=True).to(device)
+        batch = texts[i : i + batch_size]
+        inputs = tokenizer(
+            batch, return_tensors="pt", padding=True, truncation=True
+        ).to(device)
         with torch.no_grad():
             logits = classifier(**inputs).logits
             probs = torch.softmax(logits, dim=-1).cpu().numpy()
@@ -26,15 +35,25 @@ def discriminator_predict_text(classifier, tokenizer, texts: List[str], device=D
             results.append({"pred": int(p), "probs": prob.tolist()})
     return results
 
+
 class SimpleTextDataset(Dataset):
     def __init__(self, texts, labels, tokenizer, max_length=256):
         self.texts = texts
         self.labels = labels
         self.tokenizer = tokenizer
         self.max_length = max_length
-    def __len__(self): return len(self.texts)
+
+    def __len__(self):
+        return len(self.texts)
+
     def __getitem__(self, idx):
-        enc = self.tokenizer(self.texts[idx], truncation=True, padding="max_length", max_length=self.max_length, return_tensors="pt")
+        enc = self.tokenizer(
+            self.texts[idx],
+            truncation=True,
+            padding="max_length",
+            max_length=self.max_length,
+            return_tensors="pt",
+        )
         item = {k: v.squeeze(0) for k, v in enc.items()}
         item["labels"] = torch.tensor(self.labels[idx], dtype=torch.long)
         return item
diff --git a/hallucination_reduction/discriminator_training_utils.py b/hallucination_reduction/discriminator_training_utils.py
index 62d90ce..8dfe9bd 100644
--- a/hallucination_reduction/discriminator_training_utils.py
+++ b/hallucination_reduction/discriminator_training_utils.py
@@ -1,17 +1,32 @@
 import numpy as np
-import torch
+from sklearn.metrics import accuracy_score, precision_recall_fscore_support
+from sklearn.model_selection import train_test_split
 from torch import nn, optim
 from torch.utils.data import DataLoader
-from sklearn.model_selection import train_test_split
-from sklearn.metrics import accuracy_score, precision_recall_fscore_support
 
+from .config import DEVICE, SEED
 from .discriminator import SimpleTextDataset, discriminator_predict_text
-from .config import SEED, DEVICE
 
 
-def train_discriminator_minibatch(classifier, tokenizer, texts, labels, device=DEVICE, epochs=5, batch_size=8, lr=2e-5, val_split=0.2):
+def train_discriminator_minibatch(
+    classifier,
+    tokenizer,
+    texts,
+    labels,
+    device=DEVICE,
+    epochs=5,
+    batch_size=8,
+    lr=2e-5,
+    val_split=0.2,
+):
 
-    tr_texts, val_texts, tr_labels, val_labels = train_test_split(texts, labels, test_size=val_split, random_state=SEED, stratify=labels if len(set(labels))>1 else None)
+    tr_texts, val_texts, tr_labels, val_labels = train_test_split(
+        texts,
+        labels,
+        test_size=val_split,
+        random_state=SEED,
+        stratify=labels if len(set(labels)) > 1 else None,
+    )
     ds = SimpleTextDataset(tr_texts, tr_labels, tokenizer)
     dl = DataLoader(ds, batch_size=batch_size, shuffle=True)
     optimizer = optim.AdamW(classifier.parameters(), lr=lr)
@@ -20,7 +35,9 @@ def train_discriminator_minibatch(classifier, tokenizer, texts, labels, device=D
         losses = []
         for batch in dl:
             batch = {k: v.to(device) for k, v in batch.items()}
-            outputs = classifier(input_ids=batch["input_ids"], attention_mask=batch["attention_mask"])
+            outputs = classifier(
+                input_ids=batch["input_ids"], attention_mask=batch["attention_mask"]
+            )
             loss = nn.CrossEntropyLoss()(outputs.logits, batch["labels"])
             optimizer.zero_grad()
             loss.backward()
@@ -31,16 +48,22 @@ def train_discriminator_minibatch(classifier, tokenizer, texts, labels, device=D
         val_preds = []
         val_true = []
         for vt, vl in zip(val_texts, val_labels):
-            res = discriminator_predict_text(classifier, tokenizer, [vt], device=device)[0]
-            prob_pos = res["probs"][1] if len(res["probs"])>1 else res["probs"][0]
+            res = discriminator_predict_text(
+                classifier, tokenizer, [vt], device=device
+            )[0]
+            prob_pos = res["probs"][1] if len(res["probs"]) > 1 else res["probs"][0]
             pred = 1 if prob_pos > 0.5 else 0
-            val_preds.append(pred); val_true.append(int(vl))
-        acc = accuracy_score(val_true, val_preds) if len(val_true)>0 else 0.0
-        print(f"Disc train epoch {epoch+1}/{epochs}, loss={np.mean(losses):.4f}, val_acc={acc:.4f}")
+            val_preds.append(pred)
+            val_true.append(int(vl))
+        acc = accuracy_score(val_true, val_preds) if len(val_true) > 0 else 0.0
+        print(
+            f"Disc train epoch {epoch+1}/{epochs}, loss={np.mean(losses):.4f}, val_acc={acc:.4f}"
+        )
         classifier.train()
     classifier.eval()
     return classifier
 
+
 def evaluate_classifier(cls, tokenizer, texts, labels, device=DEVICE):
     cls.eval()
     preds = []
@@ -48,6 +71,8 @@ def evaluate_classifier(cls, tokenizer, texts, labels, device=DEVICE):
         res = discriminator_predict_text(cls, tokenizer, [t], device=device)[0]
         p = 1 if res["probs"][1] > 0.5 else 0
         preds.append(p)
-    acc = accuracy_score(labels, preds) if len(labels)>0 else 0.0
-    prec, rec, f1, _ = precision_recall_fscore_support(labels, preds, average='binary', zero_division=0)
+    acc = accuracy_score(labels, preds) if len(labels) > 0 else 0.0
+    prec, rec, f1, _ = precision_recall_fscore_support(
+        labels, preds, average="binary", zero_division=0
+    )
     return {"acc": acc, "prec": prec, "rec": rec, "f1": f1}
diff --git a/hallucination_reduction/evaluation.py b/hallucination_reduction/evaluation.py
index 227a3d6..234fe4f 100644
--- a/hallucination_reduction/evaluation.py
+++ b/hallucination_reduction/evaluation.py
@@ -1,14 +1,51 @@
 from collections import Counter
+from typing import List
+
 import numpy as np
+
+from .config import DEVICE, MAX_GEN_TOKENS, MIN_GEN_TOKENS, TOP_K
 from .discriminator import discriminator_predict_text
-from .config import DEVICE,TOP_K,MAX_GEN_TOKENS,MIN_GEN_TOKENS
-from typing import List
+from .generator import build_rag_prompt, generate_answer
 
-from .generator import build_rag_prompt,generate_answer
 
 def exact_match(a: str, b: str) -> int:
     return int(a.strip().lower() == b.strip().lower())
 
+
+def accuracy_score(y_true, y_pred):
+    """
+    Compute the fraction of correct predictions.
+    """
+    if not y_true:
+        return 0.0
+    correct = sum(1 for t, p in zip(y_true, y_pred) if t == p)
+    return correct / len(y_true)
+
+
+def precision_recall_fscore_support(y_true, y_pred, average="binary", zero_division=0):
+    """
+    Compute precision, recall, F1 score for binary classification.
+    Returns (precision, recall, f1, support)
+    """
+    if not y_true:
+        return 0.0, 0.0, 0.0, 0
+
+    tp = sum(1 for t, p in zip(y_true, y_pred) if t == 1 and p == 1)
+    fp = sum(1 for t, p in zip(y_true, y_pred) if t == 0 and p == 1)
+    fn = sum(1 for t, p in zip(y_true, y_pred) if t == 1 and p == 0)
+    support = sum(1 for t in y_true if t == 1)
+
+    precision = tp / (tp + fp) if (tp + fp) > 0 else zero_division
+    recall = tp / (tp + fn) if (tp + fn) > 0 else zero_division
+    f1 = (
+        2 * precision * recall / (precision + recall)
+        if (precision + recall) > 0
+        else zero_division
+    )
+
+    return precision, recall, f1, support
+
+
 def f1_score(pred: str, gold: str) -> float:
     p_tokens = pred.split()
     g_tokens = gold.split()
@@ -22,53 +59,86 @@ def f1_score(pred: str, gold: str) -> float:
         return 0.0
     return 2 * precision * recall / (precision + recall)
 
+
 def overlap_fact_check(answer: str, supporting_passages: List[str]) -> float:
     """
     Compute fraction of supporting passage tokens that overlap with the generated answer.
     Returns value in [0,1] average across passages.
     """
+
     def overlap_ratio(a, b):
         atoks = set(a.lower().split())
         btoks = set(b.lower().split())
         if len(btoks) == 0:
             return 0.0
         return len(atoks & btoks) / len(btoks)
+
     scores = [overlap_ratio(answer, p) for p in supporting_passages]
     return float(np.mean(scores)) if scores else 0.0
 
-def evaluate_old_vs_new_generator(old_gen, new_gen, tokenizer, retriever, qa_pairs, fact_disc, fact_tok, device=DEVICE):
+
+def evaluate_old_vs_new_generator(
+    old_gen, new_gen, tokenizer, retriever, qa_pairs, fact_disc, fact_tok, device=DEVICE
+):
     rows = []
-    old_metrics = {"total":0, "exact":0, "f1_sum":0.0, "hallucinated":0}
-    new_metrics = {"total":0, "exact":0, "f1_sum":0.0, "hallucinated":0}
+    old_metrics = {"total": 0, "exact": 0, "f1_sum": 0.0, "hallucinated": 0}
+    new_metrics = {"total": 0, "exact": 0, "f1_sum": 0.0, "hallucinated": 0}
     for qa in qa_pairs:
-        retrieved = [p for idx,p in retriever.retrieve(qa.question, k=TOP_K)]
+        retrieved = [p for idx, p in retriever.retrieve(qa.question, k=TOP_K)]
         prompt = build_rag_prompt(qa.question, retrieved)
-        old_out = generate_answer(old_gen, tokenizer, prompt, max_new_tokens=MAX_GEN_TOKENS, min_new_tokens=MIN_GEN_TOKENS, device=device, num_return_sequences=1)[0]
-        new_out = generate_answer(new_gen, tokenizer, prompt, max_new_tokens=MAX_GEN_TOKENS, min_new_tokens=MIN_GEN_TOKENS, device=device, num_return_sequences=1)[0]
+        old_out = generate_answer(
+            old_gen,
+            tokenizer,
+            prompt,
+            max_new_tokens=MAX_GEN_TOKENS,
+            min_new_tokens=MIN_GEN_TOKENS,
+            device=device,
+            num_return_sequences=1,
+        )[0]
+        new_out = generate_answer(
+            new_gen,
+            tokenizer,
+            prompt,
+            max_new_tokens=MAX_GEN_TOKENS,
+            min_new_tokens=MIN_GEN_TOKENS,
+            device=device,
+            num_return_sequences=1,
+        )[0]
 
-        for label, out, metrics in [("old", old_out, old_metrics), ("new", new_out, new_metrics)]:
+        for _label, out, metrics in [
+            ("old", old_out, old_metrics),
+            ("new", new_out, new_metrics),
+        ]:
             metrics["total"] += 1
             metrics["exact"] += exact_match(out, qa.answer)
             metrics["f1_sum"] += f1_score(out, qa.answer)
-            
-            fact_pred = discriminator_predict_text(fact_disc, fact_tok, [out], device=device)[0]
-            p_fact = fact_pred["probs"][1] if len(fact_pred["probs"])>1 else fact_pred["probs"][0]
+
+            fact_pred = discriminator_predict_text(
+                fact_disc, fact_tok, [out], device=device
+            )[0]
+            p_fact = (
+                fact_pred["probs"][1]
+                if len(fact_pred["probs"]) > 1
+                else fact_pred["probs"][0]
+            )
             overlap = overlap_fact_check(out, qa.supporting_passages)
-            
+
             if (p_fact < 0.5) and (overlap < 0.3):
                 metrics["hallucinated"] += 1
 
-        rows.append({"question": qa.question, "gold": qa.answer, "old": old_out, "new": new_out})
+        rows.append(
+            {"question": qa.question, "gold": qa.answer, "old": old_out, "new": new_out}
+        )
 
     old_summary = {
-        "exact_match_rate": old_metrics["exact"]/old_metrics["total"],
-        "avg_f1": old_metrics["f1_sum"]/old_metrics["total"],
-        "hallucination_rate": old_metrics["hallucinated"]/old_metrics["total"]
+        "exact_match_rate": old_metrics["exact"] / old_metrics["total"],
+        "avg_f1": old_metrics["f1_sum"] / old_metrics["total"],
+        "hallucination_rate": old_metrics["hallucinated"] / old_metrics["total"],
     }
     new_summary = {
-        "exact_match_rate": new_metrics["exact"]/new_metrics["total"],
-        "avg_f1": new_metrics["f1_sum"]/new_metrics["total"],
-        "hallucination_rate": new_metrics["hallucinated"]/new_metrics["total"]
+        "exact_match_rate": new_metrics["exact"] / new_metrics["total"],
+        "avg_f1": new_metrics["f1_sum"] / new_metrics["total"],
+        "hallucination_rate": new_metrics["hallucinated"] / new_metrics["total"],
     }
     return rows, old_summary, new_summary
 
@@ -80,6 +150,8 @@ def evaluate_classifier(cls, tokenizer, texts, labels, device=DEVICE):
         res = discriminator_predict_text(cls, tokenizer, [t], device=device)[0]
         p = 1 if res["probs"][1] > 0.5 else 0
         preds.append(p)
-    acc = accuracy_score(labels, preds) if len(labels)>0 else 0.0
-    prec, rec, f1, _ = precision_recall_fscore_support(labels, preds, average='binary', zero_division=0)
+    acc = accuracy_score(labels, preds) if len(labels) > 0 else 0.0
+    prec, rec, f1, _ = precision_recall_fscore_support(
+        labels, preds, average="binary", zero_division=0
+    )  # noqa: F821
     return {"acc": acc, "prec": prec, "rec": rec, "f1": f1}
diff --git a/hallucination_reduction/generator.py b/hallucination_reduction/generator.py
index bcb528a..078bb67 100644
--- a/hallucination_reduction/generator.py
+++ b/hallucination_reduction/generator.py
@@ -1,21 +1,33 @@
+from typing import List
+
+import numpy as np
 import torch
-from transformers import AutoTokenizer, AutoModelForCausalLM
 from torch import optim
 from torch.utils.data import DataLoader
-from typing import List
-import numpy as np
+from transformers import AutoModelForCausalLM, AutoTokenizer
+
+from .config import (
+    DEVICE,
+    GEN_MODEL,
+    MAX_GEN_TOKENS,
+    MIN_GEN_TOKENS,
+    SFT_BATCH,
+    SFT_EPOCHS,
+    SFT_LR,
+)
 
-from .config import MAX_GEN_TOKENS, MIN_GEN_TOKENS, SFT_EPOCHS, SFT_BATCH, SFT_LR,GEN_MODEL
 
-DEVICE="cuda"
 def load_generator(model_name=GEN_MODEL, device=DEVICE):
     tokenizer = AutoTokenizer.from_pretrained(model_name)
     if tokenizer.pad_token is None:
         tokenizer.pad_token = tokenizer.eos_token
-    model = AutoModelForCausalLM.from_pretrained(model_name,device_map="auto",dtype=torch.bfloat16,load_in_4bit=True)
+    model = AutoModelForCausalLM.from_pretrained(
+        model_name, device_map="auto", dtype=torch.bfloat16, load_in_4bit=True
+    )
     model.eval()
     return tokenizer, model
 
+
 def build_rag_prompt(question: str, retrieved_docs: List[str]) -> str:
     prompt = "### Context:\n"
     for i, doc in enumerate(retrieved_docs, 1):
@@ -23,10 +35,19 @@ def build_rag_prompt(question: str, retrieved_docs: List[str]) -> str:
     prompt += "\n### Question:\n" + question + "\n### Answer:\n"
     return prompt
 
-def generate_answer(generator, tokenizer, prompt: str, max_new_tokens=MAX_GEN_TOKENS, min_new_tokens=MIN_GEN_TOKENS,
-                    device=DEVICE, num_return_sequences=1, temperature=0.8):
+
+def generate_answer(
+    generator,
+    tokenizer,
+    prompt: str,
+    max_new_tokens=MAX_GEN_TOKENS,
+    min_new_tokens=MIN_GEN_TOKENS,
+    device=DEVICE,
+    num_return_sequences=1,
+    temperature=0.8,
+):
     inputs = tokenizer(prompt, return_tensors="pt", truncation=True).to(device)
-    
+
     out = generator.generate(
         **inputs,
         max_new_tokens=max_new_tokens,
@@ -35,16 +56,28 @@ def generate_answer(generator, tokenizer, prompt: str, max_new_tokens=MAX_GEN_TO
         top_k=50,
         temperature=temperature,
         num_return_sequences=num_return_sequences,
-        pad_token_id=tokenizer.eos_token_id
+        pad_token_id=tokenizer.eos_token_id,
     )
     texts = []
     for seq in out:
-        texts.append(tokenizer.decode(seq[inputs['input_ids'].shape[1]:], skip_special_tokens=True).strip())
+        texts.append(
+            tokenizer.decode(
+                seq[inputs["input_ids"].shape[1] :], skip_special_tokens=True
+            ).strip()
+        )
     return texts
 
 
-def sft_finetune_generator(generator, tokenizer, qa_pairs, device=DEVICE, epochs=SFT_EPOCHS, batch_size=SFT_BATCH, lr=SFT_LR):
-    
+def sft_finetune_generator(
+    generator,
+    tokenizer,
+    qa_pairs,
+    device=DEVICE,
+    epochs=SFT_EPOCHS,
+    batch_size=SFT_BATCH,
+    lr=SFT_LR,
+):
+
     inputs = []
     for qa in qa_pairs:
         prompt = build_rag_prompt(qa.question, qa.supporting_passages)
@@ -57,7 +90,8 @@ def sft_finetune_generator(generator, tokenizer, qa_pairs, device=DEVICE, epochs
     for epoch in range(epochs):
         epoch_losses = []
         for ids, masks in dl:
-            ids = ids.to(device); masks = masks.to(device)
+            ids = ids.to(device)
+            masks = masks.to(device)
             outputs = generator(input_ids=ids, attention_mask=masks, labels=ids)
             loss = outputs.loss
             optimizer.zero_grad()
diff --git a/hallucination_reduction/inference.py b/hallucination_reduction/inference.py
index 4dcfb1c..6a88180 100644
--- a/hallucination_reduction/inference.py
+++ b/hallucination_reduction/inference.py
@@ -1,12 +1,11 @@
 import os
+import time
+from threading import Thread
+
 import torch
-from transformers import AutoTokenizer, AutoModelForCausalLM, TextIteratorStreamer
 from sentence_transformers import SentenceTransformer
 from sklearn.metrics.pairwise import cosine_similarity
-import numpy as np
-import sys, time
-from threading import Thread
-
+from transformers import AutoModelForCausalLM, AutoTokenizer, TextIteratorStreamer
 
 CORPUS_PATH = "data/processed/corpus.txt"
 EMBED_MODEL = "sentence-transformers/all-MiniLM-L6-v2"
@@ -27,7 +26,9 @@ def load_corpus(corpus_path=CORPUS_PATH):
 def build_embeddings(docs, embed_model_name=EMBED_MODEL, device="cpu"):
     embedder = SentenceTransformer(embed_model_name, device=device)
     print("Encoding corpus embeddings...")
-    corpus_embeddings = embedder.encode(docs, convert_to_numpy=True, show_progress_bar=True)
+    corpus_embeddings = embedder.encode(
+        docs, convert_to_numpy=True, show_progress_bar=True
+    )
     return embedder, corpus_embeddings
 
 
@@ -50,15 +51,18 @@ def find_best_model(weights_dir=WEIGHTS_DIR):
         print("No generator checkpoints found.")
         return None
 
-
     if "generator_final.pt" in candidates:
         return os.path.join(weights_dir, "generator_final.pt")
     if any("best" in f for f in candidates):
-        return os.path.join(weights_dir, sorted([f for f in candidates if "best" in f])[0])
+        return os.path.join(
+            weights_dir, sorted([f for f in candidates if "best" in f])[0]
+        )
 
     epoch_files = [f for f in candidates if "epoch" in f]
     if epoch_files:
-        latest = sorted(epoch_files, key=lambda x: int(x.split("_")[-1].split(".")[0]))[-1]
+        latest = sorted(epoch_files, key=lambda x: int(x.split("_")[-1].split(".")[0]))[
+            -1
+        ]
         return os.path.join(weights_dir, latest)
 
     return os.path.join(weights_dir, candidates[0])
@@ -70,7 +74,7 @@ def load_model(model_name=BASE_MODEL, weights_dir=WEIGHTS_DIR):
     model = AutoModelForCausalLM.from_pretrained(
         model_name,
         torch_dtype=torch.bfloat16 if torch.cuda.is_available() else torch.float32,
-        device_map="auto"
+        device_map="auto",
     )
 
     weights_path = find_best_model(weights_dir)
@@ -78,9 +82,12 @@ def load_model(model_name=BASE_MODEL, weights_dir=WEIGHTS_DIR):
         print(f"Attempting to load fine-tuned weights from: {weights_path}")
         state_dict = torch.load(weights_path, map_location="cpu")
 
-        
         model_state = model.state_dict()
-        filtered_dict = {k: v for k, v in state_dict.items() if k in model_state and model_state[k].shape == v.shape}
+        filtered_dict = {
+            k: v
+            for k, v in state_dict.items()
+            if k in model_state and model_state[k].shape == v.shape
+        }
 
         missing = len(model_state) - len(filtered_dict)
         if missing > 0:
@@ -95,11 +102,9 @@ def load_model(model_name=BASE_MODEL, weights_dir=WEIGHTS_DIR):
     return model, tokenizer, next(model.parameters()).device
 
 
-import sys, time
-from threading import Thread
-from transformers import TextIteratorStreamer
-
-def generate_answer(model, tokenizer, device, question, retrieved_docs, max_new_tokens=1024):
+def generate_answer(
+    model, tokenizer, device, question, retrieved_docs, max_new_tokens=1024
+):
     context = "\n".join(retrieved_docs)
     prompt = f"""
 ### Context:
@@ -109,30 +114,29 @@ def generate_answer(model, tokenizer, device, question, retrieved_docs, max_new_
 {question}
 
 ### Instructions:
-Provide a long, thoughtful, and well-structured answer based only on the given context. 
+Provide a long, thoughtful, and well-structured answer based only on the given context.
 Include reasoning, relevant details, and explanations, but avoid speculation or hallucination.
 
 ### Answer:
 """
 
-    
     inputs = tokenizer(prompt, return_tensors="pt", truncation=True).to(device)
 
-    
-    streamer = TextIteratorStreamer(tokenizer, skip_prompt=True, skip_special_tokens=True)
+    streamer = TextIteratorStreamer(
+        tokenizer, skip_prompt=True, skip_special_tokens=True
+    )
 
     print("\n Generator ", end="", flush=True)
 
-    
     generation_thread = Thread(
         target=model.generate,
         kwargs=dict(
             **inputs,
             max_new_tokens=max_new_tokens,
-            temperature=0.6,           
-            top_p=0.9,                 
+            temperature=0.6,
+            top_p=0.9,
             do_sample=True,
-            repetition_penalty=1.05,   
+            repetition_penalty=1.05,
             pad_token_id=tokenizer.eos_token_id,
             eos_token_id=tokenizer.eos_token_id,
             streamer=streamer,
@@ -140,20 +144,21 @@ def generate_answer(model, tokenizer, device, question, retrieved_docs, max_new_
     )
     generation_thread.start()
 
-    
+    generated_tokens = []
     for token in streamer:
+        generated_tokens.append(token)
         print(token, end="", flush=True)
-        time.sleep(0.015)  
+        time.sleep(0.015)
 
     generation_thread.join()
-    print("\n")  
+    print("\n")
+    return "".join(generated_tokens)
 
 
 def main():
     model, tokenizer, device = load_model()
     docs = load_corpus()
     embedder, corpus_embeddings = build_embeddings(docs, device=device)
-    
 
     print("\n RAG-Enhanced Chat Mode Started — type 'exit' to quit.\n")
 
@@ -163,7 +168,9 @@ def main():
             print(" Exiting chat. Goodbye!")
             break
 
-        retrieved_docs = retrieve_relevant_chunks(question, embedder, corpus_embeddings, docs)
+        retrieved_docs = retrieve_relevant_chunks(
+            question, embedder, corpus_embeddings, docs
+        )
         print(f"\n Retrieved {len(retrieved_docs)} relevant context chunks.")
         for i, doc in enumerate(retrieved_docs, 1):
             print(f"   [{i}] {doc[:100]}...")
diff --git a/hallucination_reduction/main.py b/hallucination_reduction/main.py
index 35c90c7..7319be8 100644
--- a/hallucination_reduction/main.py
+++ b/hallucination_reduction/main.py
@@ -1,18 +1,31 @@
-from .data_utils import build_corpus_and_qa
-from .retriever import SimpleRetriever
-from .generator import load_generator, sft_finetune_generator
-from .discriminator import load_discriminator
-from .discriminator_training_utils import train_discriminator_minibatch, evaluate_classifier
-from .evaluation import evaluate_old_vs_new_generator
-from .rl_utils import reinforcement_learning_loop
-from .config import GEN_MODEL, DISC_MODEL, SAVE_DIR, SFT_EPOCHS, SFT_BATCH, SFT_LR, DISC_EPOCHS, DISC_BATCH, DISC_LR, RL_EPOCHS
 import copy
-import torch
 import os
 import random
-import numpy as np
+
+import torch
 from torch import nn
 
+from .config import (
+    DISC_BATCH,
+    DISC_EPOCHS,
+    DISC_LR,
+    DISC_MODEL,
+    GEN_MODEL,
+    SAVE_DIR,
+    SFT_BATCH,
+    SFT_EPOCHS,
+    SFT_LR,
+)
+from .data_utils import build_corpus_and_qa
+from .discriminator import load_discriminator
+from .discriminator_training_utils import (
+    evaluate_classifier,
+    train_discriminator_minibatch,
+)
+from .evaluation import evaluate_old_vs_new_generator
+from .generator import load_generator, sft_finetune_generator
+from .retriever import SimpleRetriever
+from .rl_utils import reinforcement_learning_loop
 
 
 def unwrap(model):
@@ -21,20 +34,18 @@ def unwrap(model):
 
 
 def main():
-    
+
     if torch.cuda.is_available():
-        DEVICE = "cuda"  
+        DEVICE = "cuda"
     elif hasattr(torch.backends, "mps") and torch.backends.mps.is_available():
-        DEVICE = "mps"  
+        DEVICE = "mps"
     else:
         DEVICE = "cpu"
     print(f" Using device: {DEVICE}")
 
-    
     passages, qa_pairs = build_corpus_and_qa()
     retriever = SimpleRetriever(passages)
 
-    
     print("Loading generator and discriminators...")
     gen_tok, generator = load_generator(GEN_MODEL, DEVICE)
     baseline_generator = copy.deepcopy(generator)
@@ -43,7 +54,6 @@ def main():
     style_tok, style_disc = load_discriminator(DISC_MODEL, DEVICE)
     safety_tok, safety_disc = load_discriminator(DISC_MODEL, DEVICE)
 
-    
     try:
         if hasattr(generator, "gradient_checkpointing_enable"):
             generator.gradient_checkpointing_enable()
@@ -51,8 +61,6 @@ def main():
     except Exception as e:
         print("Could not enable gradient checkpointing:", e)
 
-    
-
     n_gpus = torch.cuda.device_count() if torch.cuda.is_available() else 0
     if n_gpus > 1:
         print(f" Using {n_gpus} GPUs with DataParallel (generator only).")
@@ -65,7 +73,6 @@ def main():
     style_disc = style_disc.to(DEVICE)
     safety_disc = safety_disc.to(DEVICE)
 
-
     fact_texts, fact_labels = [], []
     style_texts, style_labels = [], []
     safety_texts, safety_labels = [], []
@@ -95,69 +102,127 @@ def main():
     ]
 
     for qa in qa_pairs:
-        
-        fact_texts.append(qa.answer); fact_labels.append(1)
-        style_texts.append(qa.answer); style_labels.append(1)
-        safety_texts.append(qa.answer); safety_labels.append(1)
 
-        
+        fact_texts.append(qa.answer)
+        fact_labels.append(1)
+        style_texts.append(qa.answer)
+        style_labels.append(1)
+        safety_texts.append(qa.answer)
+        safety_labels.append(1)
+
         fabricated = qa.answer + random.choice(fabrication_patterns)
-        fact_texts.append(fabricated); fact_labels.append(0)
-        safety_texts.append(fabricated); safety_labels.append(0)
+        fact_texts.append(fabricated)
+        fact_labels.append(0)
+        safety_texts.append(fabricated)
+        safety_labels.append(0)
 
-        
         unsafe = qa.answer + random.choice(unsafe_patterns)
-        fact_texts.append(unsafe); fact_labels.append(0)
-        safety_texts.append(unsafe); safety_labels.append(0)
+        fact_texts.append(unsafe)
+        fact_labels.append(0)
+        safety_texts.append(unsafe)
+        safety_labels.append(0)
 
-        
         bad_style = random.choice(bad_style_patterns)
-        style_texts.append(bad_style); style_labels.append(0)
+        style_texts.append(bad_style)
+        style_labels.append(0)
 
-        
         random_neg = "Misc unrelated content " + str(random.randint(0, 10000))
-        fact_texts.append(random_neg); fact_labels.append(0)
-        style_texts.append(random_neg); style_labels.append(0)
-        safety_texts.append(random_neg); safety_labels.append(0)
+        fact_texts.append(random_neg)
+        fact_labels.append(0)
+        style_texts.append(random_neg)
+        style_labels.append(0)
+        safety_texts.append(random_neg)
+        safety_labels.append(0)
 
-    
-    
     print("Training fact discriminator...")
-    fact_disc = train_discriminator_minibatch(fact_disc, fact_tok, fact_texts, fact_labels,
-                                              device=DEVICE, epochs=DISC_EPOCHS, batch_size=DISC_BATCH, lr=DISC_LR)
+    fact_disc = train_discriminator_minibatch(
+        fact_disc,
+        fact_tok,
+        fact_texts,
+        fact_labels,
+        device=DEVICE,
+        epochs=DISC_EPOCHS,
+        batch_size=DISC_BATCH,
+        lr=DISC_LR,
+    )
     print("Training style discriminator...")
-    style_disc = train_discriminator_minibatch(style_disc, style_tok, style_texts, style_labels,
-                                               device=DEVICE, epochs=DISC_EPOCHS, batch_size=DISC_BATCH, lr=DISC_LR)
+    style_disc = train_discriminator_minibatch(
+        style_disc,
+        style_tok,
+        style_texts,
+        style_labels,
+        device=DEVICE,
+        epochs=DISC_EPOCHS,
+        batch_size=DISC_BATCH,
+        lr=DISC_LR,
+    )
     print("Training safety discriminator...")
-    safety_disc = train_discriminator_minibatch(safety_disc, safety_tok, safety_texts, safety_labels,
-                                                device=DEVICE, epochs=DISC_EPOCHS, batch_size=DISC_BATCH, lr=DISC_LR)
-
-    
+    safety_disc = train_discriminator_minibatch(
+        safety_disc,
+        safety_tok,
+        safety_texts,
+        safety_labels,
+        device=DEVICE,
+        epochs=DISC_EPOCHS,
+        batch_size=DISC_BATCH,
+        lr=DISC_LR,
+    )
 
     print("\nSanity-check discriminator metrics:")
-    print("Fact disc:", evaluate_classifier(fact_disc, fact_tok, fact_texts, fact_labels, device=DEVICE))
-    print("Style disc:", evaluate_classifier(style_disc, style_tok, style_texts, style_labels, device=DEVICE))
-    print("Safety disc:", evaluate_classifier(safety_disc, safety_tok, safety_texts, safety_labels, device=DEVICE))
-
-    
+    print(
+        "Fact disc:",
+        evaluate_classifier(
+            fact_disc, fact_tok, fact_texts, fact_labels, device=DEVICE
+        ),
+    )
+    print(
+        "Style disc:",
+        evaluate_classifier(
+            style_disc, style_tok, style_texts, style_labels, device=DEVICE
+        ),
+    )
+    print(
+        "Safety disc:",
+        evaluate_classifier(
+            safety_disc, safety_tok, safety_texts, safety_labels, device=DEVICE
+        ),
+    )
 
     print("\nEvaluation before SFT/RL (baseline):")
-    _, old_before, _ = evaluate_old_vs_new_generator(baseline_generator, generator,
-                                                     gen_tok, retriever, qa_pairs,
-                                                     fact_disc, fact_tok, device=DEVICE)
+    _, old_before, _ = evaluate_old_vs_new_generator(
+        baseline_generator,
+        generator,
+        gen_tok,
+        retriever,
+        qa_pairs,
+        fact_disc,
+        fact_tok,
+        device=DEVICE,
+    )
     print("Baseline summary:", old_before)
 
-    
-
     print("\nRunning supervised fine-tuning (SFT) on QA pairs...")
-    generator = sft_finetune_generator(generator, gen_tok, qa_pairs,
-                                       device=DEVICE, epochs=SFT_EPOCHS,
-                                       batch_size=SFT_BATCH, lr=SFT_LR)
+    generator = sft_finetune_generator(
+        generator,
+        gen_tok,
+        qa_pairs,
+        device=DEVICE,
+        epochs=SFT_EPOCHS,
+        batch_size=SFT_BATCH,
+        lr=SFT_LR,
+    )
 
     print("\nEvaluation after SFT (before RL):")
-    rows_sft, old_sft, new_sft = evaluate_old_vs_new_generator(baseline_generator, generator,
-                                                               gen_tok, retriever, qa_pairs,
-                                                               fact_disc, fact_tok, device=DEVICE)
+    rows_sft, old_sft, new_sft = evaluate_old_vs_new_generator(
+        baseline_generator,
+        generator,
+        gen_tok,
+        retriever,
+        qa_pairs,
+        fact_disc,
+        fact_tok,
+        device=DEVICE,
+    )
     print("Old (baseline) summary:", old_sft)
     print("New (after SFT) summary:", new_sft)
     for r in rows_sft:
@@ -166,28 +231,46 @@ def main():
         print("Old:", r["old"])
         print("New:", r["new"])
 
-    
-
     print("\nStarting Reinforcement Learning (REINFORCE)...")
-    history = reinforcement_learning_loop(generator, gen_tok,
-                                          fact_disc, style_disc, safety_disc,
-                                          fact_tok, style_tok, safety_tok,
-                                          retriever, qa_pairs, device=DEVICE)
-
-    
-
-    torch.save(unwrap(generator).state_dict(), os.path.join(SAVE_DIR, "generator_final.pt"))
-    torch.save(unwrap(fact_disc).state_dict(), os.path.join(SAVE_DIR, "fact_disc_final.pt"))
-    torch.save(unwrap(style_disc).state_dict(), os.path.join(SAVE_DIR, "style_disc_final.pt"))
-    torch.save(unwrap(safety_disc).state_dict(), os.path.join(SAVE_DIR, "safety_disc_final.pt"))
+    reinforcement_learning_loop(
+        generator,
+        gen_tok,
+        fact_disc,
+        style_disc,
+        safety_disc,
+        fact_tok,
+        style_tok,
+        safety_tok,
+        retriever,
+        qa_pairs,
+        device=DEVICE,
+    )
+
+    torch.save(
+        unwrap(generator).state_dict(), os.path.join(SAVE_DIR, "generator_final.pt")
+    )
+    torch.save(
+        unwrap(fact_disc).state_dict(), os.path.join(SAVE_DIR, "fact_disc_final.pt")
+    )
+    torch.save(
+        unwrap(style_disc).state_dict(), os.path.join(SAVE_DIR, "style_disc_final.pt")
+    )
+    torch.save(
+        unwrap(safety_disc).state_dict(), os.path.join(SAVE_DIR, "safety_disc_final.pt")
+    )
     print("✅ Models saved to", SAVE_DIR)
 
-    
-    
     print("\nFinal Evaluation (baseline old vs new generator):")
-    rows, old_summary, new_summary = evaluate_old_vs_new_generator(baseline_generator, generator,
-                                                                   gen_tok, retriever, qa_pairs,
-                                                                   fact_disc, fact_tok, device=DEVICE)
+    rows, old_summary, new_summary = evaluate_old_vs_new_generator(
+        baseline_generator,
+        generator,
+        gen_tok,
+        retriever,
+        qa_pairs,
+        fact_disc,
+        fact_tok,
+        device=DEVICE,
+    )
     print("\n=== Metrics Summary ===")
     print("Old (baseline):", old_summary)
     print("New (fine-tuned + RL):", new_summary)
@@ -199,11 +282,13 @@ def main():
         print("New:", r["new"])
         print("-" * 60)
 
-    print("\nHallucination rate reduction: {:.2%} -> {:.2%} (Δ {:.2%})".format(
-        old_summary["hallucination_rate"],
-        new_summary["hallucination_rate"],
-        old_summary["hallucination_rate"] - new_summary["hallucination_rate"]
-    ))
+    print(
+        "\nHallucination rate reduction: {:.2%} -> {:.2%} (Δ {:.2%})".format(
+            old_summary["hallucination_rate"],
+            new_summary["hallucination_rate"],
+            old_summary["hallucination_rate"] - new_summary["hallucination_rate"],
+        )
+    )
 
 
 if __name__ == "__main__":
diff --git a/hallucination_reduction/retriever.py b/hallucination_reduction/retriever.py
index 3dcc95e..cc77b18 100644
--- a/hallucination_reduction/retriever.py
+++ b/hallucination_reduction/retriever.py
@@ -1,8 +1,10 @@
 from typing import List, Tuple
+
 import numpy as np
 from sklearn.feature_extraction.text import TfidfVectorizer
 from sklearn.metrics.pairwise import cosine_similarity
 
+
 class SimpleRetriever:
     def __init__(self, passages: List[str]):
         self.passages = passages
diff --git a/hallucination_reduction/rl_utils.py b/hallucination_reduction/rl_utils.py
index 067f508..7a3f618 100644
--- a/hallucination_reduction/rl_utils.py
+++ b/hallucination_reduction/rl_utils.py
@@ -1,21 +1,29 @@
-import torch
-from torch import optim, nn
-import numpy as np
-from typing import List
-import random
 import os
-import math
+import random
 from collections import Counter
+from typing import List
 
+import numpy as np
+import torch
+from torch import nn, optim
+
+from .config import (
+    FACT_WEIGHT,
+    GEN_BATCH_SIZE,
+    GEN_LR,
+    HARD_PENALTY_IF_FACT_LT,
+    MAX_GEN_TOKENS,
+    MC_ROLLOUTS,
+    MIN_GEN_TOKENS,
+    RL_EPOCHS,
+    SAFETY_WEIGHT,
+    SAVE_DIR,
+    STYLE_WEIGHT,
+    TOP_K,
+)
 from .discriminator import discriminator_predict_text
 from .evaluation import overlap_fact_check
 from .generator import build_rag_prompt, generate_answer
-from .config import (
-    FACT_WEIGHT, STYLE_WEIGHT, SAFETY_WEIGHT,
-    HARD_PENALTY_IF_FACT_LT, MC_ROLLOUTS, GEN_LR, GEN_BATCH_SIZE,
-    RL_EPOCHS, TOP_K, MAX_GEN_TOKENS, MIN_GEN_TOKENS, SAVE_DIR
-)
-
 
 DEVICE = "cuda" if torch.cuda.is_available() else "cpu"
 
@@ -37,63 +45,108 @@ def safe_save_state(model, path):
         print("Warning: failed to save checkpoint:", e)
 
 
-
-def compute_reward(generated_answer: str, retrieved_docs: List[str], supporting_passages: List[str],
-                   fact_disc, style_disc, safety_disc,
-                   fact_tok, style_tok, safety_tok,
-                   fact_weight=FACT_WEIGHT, style_weight=STYLE_WEIGHT, safety_weight=SAFETY_WEIGHT,
-                   device=DEVICE):
+def compute_reward(
+    generated_answer: str,
+    retrieved_docs: List[str],
+    supporting_passages: List[str],
+    fact_disc,
+    style_disc,
+    safety_disc,
+    fact_tok,
+    style_tok,
+    safety_tok,
+    fact_weight=FACT_WEIGHT,
+    style_weight=STYLE_WEIGHT,
+    safety_weight=SAFETY_WEIGHT,
+    device=DEVICE,
+):
     """Compute scalar reward combining factuality, style, safety, and overlap."""
-    fact_res = discriminator_predict_text(fact_disc, fact_tok, [generated_answer], device=device)[0]
-    style_res = discriminator_predict_text(style_disc, style_tok, [generated_answer], device=device)[0]
-    safe_res = discriminator_predict_text(safety_disc, safety_tok, [generated_answer], device=device)[0]
-
-    p_fact = fact_res["probs"][1] if len(fact_res["probs"]) > 1 else fact_res["probs"][0]
-    p_style = style_res["probs"][1] if len(style_res["probs"]) > 1 else style_res["probs"][0]
-    p_safe = safe_res["probs"][1] if len(safe_res["probs"]) > 1 else safe_res["probs"][0]
+    fact_res = discriminator_predict_text(
+        fact_disc, fact_tok, [generated_answer], device=device
+    )[0]
+    style_res = discriminator_predict_text(
+        style_disc, style_tok, [generated_answer], device=device
+    )[0]
+    safe_res = discriminator_predict_text(
+        safety_disc, safety_tok, [generated_answer], device=device
+    )[0]
+
+    p_fact = (
+        fact_res["probs"][1] if len(fact_res["probs"]) > 1 else fact_res["probs"][0]
+    )
+    p_style = (
+        style_res["probs"][1] if len(style_res["probs"]) > 1 else style_res["probs"][0]
+    )
+    p_safe = (
+        safe_res["probs"][1] if len(safe_res["probs"]) > 1 else safe_res["probs"][0]
+    )
 
     overlap_score = overlap_fact_check(generated_answer, supporting_passages)
 
-
     combined = fact_weight * p_fact + style_weight * p_style + safety_weight * p_safe
     total_w = fact_weight + style_weight + safety_weight
     combined /= total_w
 
-
     combined = combined * 0.7 + overlap_score * 0.3
     if p_fact < 0.5:
         combined = max(0.0, combined - HARD_PENALTY_IF_FACT_LT)
 
-
     if is_repetitive(generated_answer):
         combined *= 0.2
 
     combined = float(max(0.0, min(1.0, combined)))
-    debug = {"p_fact": p_fact, "p_style": p_style, "p_safe": p_safe,
-             "overlap": overlap_score, "combined": combined}
+    debug = {
+        "p_fact": p_fact,
+        "p_style": p_style,
+        "p_safe": p_safe,
+        "overlap": overlap_score,
+        "combined": combined,
+    }
     return combined, debug
 
 
-def monte_carlo_rewards(prompt: str, generator, tokenizer, retrieved_docs, supporting_passages,
-                        fact_disc, style_disc, safety_disc,
-                        fact_tok, style_tok, safety_tok,
-                        n_rollouts=MC_ROLLOUTS, device=DEVICE):
+def monte_carlo_rewards(
+    prompt: str,
+    generator,
+    tokenizer,
+    retrieved_docs,
+    supporting_passages,
+    fact_disc,
+    style_disc,
+    safety_disc,
+    fact_tok,
+    style_tok,
+    safety_tok,
+    n_rollouts=MC_ROLLOUTS,
+    device=DEVICE,
+):
     """Sample multiple generations and compute their average reward."""
     generator.eval()
     with torch.no_grad():
         samples = generate_answer(
-            generator, tokenizer, prompt,
+            generator,
+            tokenizer,
+            prompt,
             max_new_tokens=MAX_GEN_TOKENS,
             min_new_tokens=MIN_GEN_TOKENS,
             num_return_sequences=n_rollouts,
-            device=device
+            device=device,
         )
 
     rewards, debug_list = [], []
     for s in samples:
-        r, dbg = compute_reward(s, retrieved_docs, supporting_passages,
-                                fact_disc, style_disc, safety_disc,
-                                fact_tok, style_tok, safety_tok, device=device)
+        r, dbg = compute_reward(
+            s,
+            retrieved_docs,
+            supporting_passages,
+            fact_disc,
+            style_disc,
+            safety_disc,
+            fact_tok,
+            style_tok,
+            safety_tok,
+            device=device,
+        )
         rewards.append(r)
         debug_list.append({"sample": s, "debug": dbg})
 
@@ -101,9 +154,19 @@ def monte_carlo_rewards(prompt: str, generator, tokenizer, retrieved_docs, suppo
     return avg_reward, debug_list, samples
 
 
-def reinforce_update(generator, tokenizer, prompts: List[str], sampled_texts: List[str], rewards: List[float],
-                     gen_optimizer, baseline=0.0, device=DEVICE,
-                     max_adv=5.0, min_adv=-5.0, clip_grad_norm=1.0):
+def reinforce_update(
+    generator,
+    tokenizer,
+    prompts: List[str],
+    sampled_texts: List[str],
+    rewards: List[float],
+    gen_optimizer,
+    baseline=0.0,
+    device=DEVICE,
+    max_adv=5.0,
+    min_adv=-5.0,
+    clip_grad_norm=1.0,
+):
     """
     REINFORCE update with label masking and clipped advantages.
     Safer against tokenizer shifts and truncation.
@@ -115,28 +178,31 @@ def reinforce_update(generator, tokenizer, prompts: List[str], sampled_texts: Li
     losses = []
 
     for prompt, sample, reward in zip(prompts, sampled_texts, rewards):
-        
+
         sep = "\n\n"
         full_text = prompt + sep + sample
 
         enc_full = tokenizer(full_text, return_tensors="pt", truncation=True).to(device)
-        enc_prompt = tokenizer(prompt + sep, return_tensors="pt", truncation=True).to(device)
+        enc_prompt = tokenizer(prompt + sep, return_tensors="pt", truncation=True).to(
+            device
+        )
 
         input_ids = enc_full.input_ids
         attention_mask = enc_full.attention_mask
         labels = input_ids.clone()
         prompt_len = enc_prompt.input_ids.shape[1]
 
-        
         labels[:, :prompt_len] = -100
 
         try:
-            outputs = generator(input_ids=input_ids, attention_mask=attention_mask, labels=labels)
+            outputs = generator(
+                input_ids=input_ids, attention_mask=attention_mask, labels=labels
+            )
         except RuntimeError as e:
             print("Generator forward error, skipping sample:", e)
             continue
 
-        logits = outputs.logits  
+        logits = outputs.logits
         shift_logits = logits[..., :-1, :].contiguous()
         shift_labels = labels[..., 1:].contiguous()
 
@@ -176,11 +242,19 @@ def reinforce_update(generator, tokenizer, prompts: List[str], sampled_texts: Li
     return float(loss_tensor.detach().cpu().item())
 
 
-
-def reinforcement_learning_loop(generator, gen_tokenizer,
-                                fact_disc, style_disc, safety_disc,
-                                fact_tok, style_tok, safety_tok,
-                                retriever, qa_pairs, device=DEVICE):
+def reinforcement_learning_loop(
+    generator,
+    gen_tokenizer,
+    fact_disc,
+    style_disc,
+    safety_disc,
+    fact_tok,
+    style_tok,
+    safety_tok,
+    retriever,
+    qa_pairs,
+    device=DEVICE,
+):
     """Main reinforcement learning loop for generator fine-tuning."""
     generator.to(device)
     fact_disc.to(device)
@@ -203,23 +277,35 @@ def reinforcement_learning_loop(generator, gen_tokenizer,
         batch_index = 0
 
         for i in range(0, len(qa_pairs), GEN_BATCH_SIZE):
-            batch = qa_pairs[i:i+GEN_BATCH_SIZE]
+            batch = qa_pairs[i : i + GEN_BATCH_SIZE]
             batch_prompts, batch_samples, batch_rewards, batch_debugs = [], [], [], []
 
             for qa in batch:
                 retrieved_pairs = retriever.retrieve(qa.question, k=TOP_K)
-                retrieved_docs = [p if isinstance(p, str) else p[0] for p in (retrieved_pairs or [])]
+                retrieved_docs = [
+                    p if isinstance(p, str) else p[0] for p in (retrieved_pairs or [])
+                ]
                 prompt = build_rag_prompt(qa.question, retrieved_docs)
 
                 avg_reward, debug_list, samples = monte_carlo_rewards(
-                    prompt, generator, gen_tokenizer, retrieved_docs,
+                    prompt,
+                    generator,
+                    gen_tokenizer,
+                    retrieved_docs,
                     getattr(qa, "supporting_passages", retrieved_docs),
-                    fact_disc, style_disc, safety_disc,
-                    fact_tok, style_tok, safety_tok,
-                    n_rollouts=MC_ROLLOUTS, device=device
+                    fact_disc,
+                    style_disc,
+                    safety_disc,
+                    fact_tok,
+                    style_tok,
+                    safety_tok,
+                    n_rollouts=MC_ROLLOUTS,
+                    device=device,
                 )
 
-                repetitive_count = sum(1 for d in debug_list if is_repetitive(d["sample"]))
+                repetitive_count = sum(
+                    1 for d in debug_list if is_repetitive(d["sample"])
+                )
                 if repetitive_count == len(debug_list) and len(debug_list) > 0:
                     avg_reward *= 0.1
 
@@ -242,20 +328,37 @@ def reinforcement_learning_loop(generator, gen_tokenizer,
             else:
                 used_rewards = rewards_arr.tolist()
 
-            loss_val = reinforce_update(generator, gen_tokenizer,
-                                        batch_prompts, batch_samples, used_rewards,
-                                        gen_optimizer, baseline=baseline, device=device,
-                                        max_adv=5.0, min_adv=-5.0, clip_grad_norm=1.0)
-
-            history.append({
-                "epoch": epoch, "batch_idx": batch_index,
-                "loss": loss_val, "baseline": baseline,
-                "mean_reward": float(np.mean(batch_rewards) if batch_rewards else 0.0)
-            })
+            loss_val = reinforce_update(
+                generator,
+                gen_tokenizer,
+                batch_prompts,
+                batch_samples,
+                used_rewards,
+                gen_optimizer,
+                baseline=baseline,
+                device=device,
+                max_adv=5.0,
+                min_adv=-5.0,
+                clip_grad_norm=1.0,
+            )
+
+            history.append(
+                {
+                    "epoch": epoch,
+                    "batch_idx": batch_index,
+                    "loss": loss_val,
+                    "baseline": baseline,
+                    "mean_reward": float(
+                        np.mean(batch_rewards) if batch_rewards else 0.0
+                    ),
+                }
+            )
             epoch_rewards.extend(batch_rewards)
 
-            print(f"Epoch {epoch} batch {batch_index} | loss {loss_val:.4f} | baseline {baseline:.4f} | "
-                  f"mean_reward {(np.mean(batch_rewards) if batch_rewards else 0.0):.4f}")
+            print(
+                f"Epoch {epoch} batch {batch_index} | loss {loss_val:.4f} | baseline {baseline:.4f} | "
+                f"mean_reward {(np.mean(batch_rewards) if batch_rewards else 0.0):.4f}"
+            )
             if batch_debugs:
                 print("Sample debug:", batch_debugs[0])
 
@@ -285,7 +388,9 @@ def reinforcement_learning_loop(generator, gen_tokenizer,
             print("Mean reward collapsed — reverting to best checkpoint (if any).")
             if best_ckpt and os.path.exists(best_ckpt):
                 try:
-                    generator.load_state_dict(torch.load(best_ckpt, map_location=device))
+                    generator.load_state_dict(
+                        torch.load(best_ckpt, map_location=device)
+                    )
                     print("Restored best checkpoint:", best_ckpt)
                 except Exception as e:
                     print("Failed to restore best checkpoint:", e)
diff --git a/inference_log.txt b/inference_log.txt
index 97bfb50..ea0540e 100644
--- a/inference_log.txt
+++ b/inference_log.txt
@@ -1,2 +1,273 @@
 === RAG Inference Log ===
 
+🚀 Starting QA + Corpus generation...
+
+📘 Processing: Elite_Dynamics_Partners_Policies
+✏️ Added 4 chunks to corpus file.
+
Generating QAs for Elite_Dynamics_Partners_Policies:   0%|                                            | 0/4 [00:00<?, ?it/s]
Generating QAs for Elite_Dynamics_Partners_Policies: 100%|█████████████████████████████████| 4/4 [00:00<00:00, 99864.38it/s]
+⚠️ OPENAI_API_KEY not set. Skipping QA generation for this run.
+⚠️ OPENAI_API_KEY not set. Skipping QA generation for this run.
+⚠️ OPENAI_API_KEY not set. Skipping QA generation for this run.
+⚠️ OPENAI_API_KEY not set. Skipping QA generation for this run.
+✅ Saved 0 QAs for Elite_Dynamics_Partners_Policies
+
+🎯 Done! All QAs saved to:
+   → data/qa/qa.json
+   And corpus appended to:
+   → data/processed/corpus.txt
+The `load_in_4bit` and `load_in_8bit` arguments are deprecated and will be removed in the future versions. Please, pass a `BitsAndBytesConfig` object in `quantization_config` argument instead.
+Some weights of DistilBertForSequenceClassification were not initialized from the model checkpoint at distilbert-base-uncased and are newly initialized: ['classifier.bias', 'classifier.weight', 'pre_classifier.bias', 'pre_classifier.weight']
+You should probably TRAIN this model on a down-stream task to be able to use it for predictions and inference.
+Some weights of DistilBertForSequenceClassification were not initialized from the model checkpoint at distilbert-base-uncased and are newly initialized: ['classifier.bias', 'classifier.weight', 'pre_classifier.bias', 'pre_classifier.weight']
+You should probably TRAIN this model on a down-stream task to be able to use it for predictions and inference.
+Some weights of DistilBertForSequenceClassification were not initialized from the model checkpoint at distilbert-base-uncased and are newly initialized: ['classifier.bias', 'classifier.weight', 'pre_classifier.bias', 'pre_classifier.weight']
+You should probably TRAIN this model on a down-stream task to be able to use it for predictions and inference.
+Traceback (most recent call last):
+  File "<frozen runpy>", line 198, in _run_module_as_main
+  File "<frozen runpy>", line 88, in _run_code
+  File "/home/shehroz/Desktop/New Folder/ai4org/hallucination_reduction/main.py", line 210, in <module>
+    main()
+    ~~~~^^
+  File "/home/shehroz/Desktop/New Folder/ai4org/hallucination_reduction/main.py", line 126, in main
+    fact_disc = train_discriminator_minibatch(fact_disc, fact_tok, fact_texts, fact_labels,
+                                              device=DEVICE, epochs=DISC_EPOCHS, batch_size=DISC_BATCH, lr=DISC_LR)
+  File "/home/shehroz/Desktop/New Folder/ai4org/hallucination_reduction/discriminator_training_utils.py", line 27, in train_discriminator_minibatch
+    optimizer.step()
+    ~~~~~~~~~~~~~~^^
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/torch/optim/optimizer.py", line 516, in wrapper
+    out = func(*args, **kwargs)
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/torch/optim/optimizer.py", line 81, in _use_grad
+    ret = func(*args, **kwargs)
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/torch/optim/adam.py", line 237, in step
+    has_complex = self._init_group(
+        group,
+    ...<5 lines>...
+        state_steps,
+    )
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/torch/optim/adam.py", line 177, in _init_group
+    state["exp_avg"] = torch.zeros_like(
+                       ~~~~~~~~~~~~~~~~^
+        p, memory_format=torch.preserve_format
+        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+    )
+    ^
+torch.OutOfMemoryError: CUDA out of memory. Tried to allocate 20.00 MiB. GPU 0 has a total capacity of 5.79 GiB of which 21.88 MiB is free. Process 61757 has 2.47 GiB memory in use. Including non-PyTorch memory, this process has 3.28 GiB memory in use. Of the allocated memory 3.06 GiB is allocated by PyTorch, and 118.23 MiB is reserved by PyTorch but unallocated. If reserved but unallocated memory is large try setting PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True to avoid fragmentation.  See documentation for Memory Management  (https://pytorch.org/docs/stable/notes/cuda.html#environment-variables)
+ Single GPU detected. Using cuda:0
+ Using device: cuda
+Loading generator and discriminators...
+Enabled gradient checkpointing on generator.
+Using single GPU or CPU.
+Training fact discriminator...
+🚀 Starting QA + Corpus generation...
+
+📘 Processing: Elite_Dynamics_Partners_Policies
+✏️ Added 4 chunks to corpus file.
+
Generating QAs for Elite_Dynamics_Partners_Policies:   0%|                                            | 0/4 [00:00<?, ?it/s]
Generating QAs for Elite_Dynamics_Partners_Policies: 100%|█████████████████████████████████| 4/4 [00:00<00:00, 93727.46it/s]
+⚠️ OPENAI_API_KEY not set. Skipping QA generation for this run.
+⚠️ OPENAI_API_KEY not set. Skipping QA generation for this run.
+⚠️ OPENAI_API_KEY not set. Skipping QA generation for this run.
+⚠️ OPENAI_API_KEY not set. Skipping QA generation for this run.
+✅ Saved 0 QAs for Elite_Dynamics_Partners_Policies
+
+🎯 Done! All QAs saved to:
+   → data/qa/qa.json
+   And corpus appended to:
+   → data/processed/corpus.txt
+The `load_in_4bit` and `load_in_8bit` arguments are deprecated and will be removed in the future versions. Please, pass a `BitsAndBytesConfig` object in `quantization_config` argument instead.
+Some weights of DistilBertForSequenceClassification were not initialized from the model checkpoint at distilbert-base-uncased and are newly initialized: ['classifier.bias', 'classifier.weight', 'pre_classifier.bias', 'pre_classifier.weight']
+You should probably TRAIN this model on a down-stream task to be able to use it for predictions and inference.
+Some weights of DistilBertForSequenceClassification were not initialized from the model checkpoint at distilbert-base-uncased and are newly initialized: ['classifier.bias', 'classifier.weight', 'pre_classifier.bias', 'pre_classifier.weight']
+You should probably TRAIN this model on a down-stream task to be able to use it for predictions and inference.
+Some weights of DistilBertForSequenceClassification were not initialized from the model checkpoint at distilbert-base-uncased and are newly initialized: ['classifier.bias', 'classifier.weight', 'pre_classifier.bias', 'pre_classifier.weight']
+You should probably TRAIN this model on a down-stream task to be able to use it for predictions and inference.
+Traceback (most recent call last):
+  File "<frozen runpy>", line 198, in _run_module_as_main
+  File "<frozen runpy>", line 88, in _run_code
+  File "/home/shehroz/Desktop/New Folder/ai4org/hallucination_reduction/main.py", line 210, in <module>
+    main()
+    ~~~~^^
+  File "/home/shehroz/Desktop/New Folder/ai4org/hallucination_reduction/main.py", line 145, in main
+    _, old_before, _ = evaluate_old_vs_new_generator(baseline_generator, generator,
+                       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+                                                     gen_tok, retriever, qa_pairs,
+                                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+                                                     fact_disc, fact_tok, device=DEVICE)
+                                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+  File "/home/shehroz/Desktop/New Folder/ai4org/hallucination_reduction/evaluation.py", line 46, in evaluate_old_vs_new_generator
+    old_out = generate_answer(old_gen, tokenizer, prompt, max_new_tokens=MAX_GEN_TOKENS, min_new_tokens=MIN_GEN_TOKENS, device=device, num_return_sequences=1)[0]
+              ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+  File "/home/shehroz/Desktop/New Folder/ai4org/hallucination_reduction/generator.py", line 30, in generate_answer
+    out = generator.generate(
+        **inputs,
+    ...<6 lines>...
+        pad_token_id=tokenizer.eos_token_id
+    )
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/torch/utils/_contextlib.py", line 120, in decorate_context
+    return func(*args, **kwargs)
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/transformers/generation/utils.py", line 2539, in generate
+    result = self._sample(
+        input_ids,
+    ...<5 lines>...
+        **model_kwargs,
+    )
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/transformers/generation/utils.py", line 2867, in _sample
+    outputs = self(**model_inputs, return_dict=True)
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/torch/nn/modules/module.py", line 1773, in _wrapped_call_impl
+    return self._call_impl(*args, **kwargs)
+           ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/torch/nn/modules/module.py", line 1784, in _call_impl
+    return forward_call(*args, **kwargs)
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/transformers/utils/generic.py", line 940, in wrapper
+    output = func(self, *args, **kwargs)
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/transformers/models/llama/modeling_llama.py", line 459, in forward
+    outputs: BaseModelOutputWithPast = self.model(
+                                       ~~~~~~~~~~^
+        input_ids=input_ids,
+        ^^^^^^^^^^^^^^^^^^^^
+    ...<6 lines>...
+        **kwargs,
+        ^^^^^^^^^
+    )
+    ^
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/torch/nn/modules/module.py", line 1773, in _wrapped_call_impl
+    return self._call_impl(*args, **kwargs)
+           ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/torch/nn/modules/module.py", line 1784, in _call_impl
+    return forward_call(*args, **kwargs)
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/transformers/utils/generic.py", line 1064, in wrapper
+    outputs = func(self, *args, **kwargs)
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/transformers/models/llama/modeling_llama.py", line 395, in forward
+    hidden_states = decoder_layer(
+        hidden_states,
+    ...<5 lines>...
+        **kwargs,
+    )
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/transformers/modeling_layers.py", line 94, in __call__
+    return super().__call__(*args, **kwargs)
+           ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/torch/nn/modules/module.py", line 1773, in _wrapped_call_impl
+    return self._call_impl(*args, **kwargs)
+           ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/torch/nn/modules/module.py", line 1784, in _call_impl
+    return forward_call(*args, **kwargs)
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/transformers/utils/deprecation.py", line 172, in wrapped_func
+    return func(*args, **kwargs)
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/transformers/models/llama/modeling_llama.py", line 294, in forward
+    hidden_states, _ = self.self_attn(
+                       ~~~~~~~~~~~~~~^
+        hidden_states=hidden_states,
+        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+    ...<6 lines>...
+        **kwargs,
+        ^^^^^^^^^
+    )
+    ^
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/torch/nn/modules/module.py", line 1773, in _wrapped_call_impl
+    return self._call_impl(*args, **kwargs)
+           ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/torch/nn/modules/module.py", line 1784, in _call_impl
+    return forward_call(*args, **kwargs)
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/transformers/utils/deprecation.py", line 172, in wrapped_func
+    return func(*args, **kwargs)
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/transformers/models/llama/modeling_llama.py", line 252, in forward
+    attn_output, attn_weights = attention_interface(
+                                ~~~~~~~~~~~~~~~~~~~^
+        self,
+        ^^^^^
+    ...<6 lines>...
+        **kwargs,
+        ^^^^^^^^^
+    )
+    ^
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/transformers/integrations/sdpa_attention.py", line 83, in sdpa_attention_forward
+    attn_output = torch.nn.functional.scaled_dot_product_attention(
+        query,
+    ...<6 lines>...
+        **sdpa_kwargs,
+    )
+torch.OutOfMemoryError: CUDA out of memory. Tried to allocate 512.00 MiB. GPU 0 has a total capacity of 5.79 GiB of which 249.88 MiB is free. Including non-PyTorch memory, this process has 4.24 GiB memory in use. Process 65257 has 1.30 GiB memory in use. Of the allocated memory 3.72 GiB is allocated by PyTorch, and 417.37 MiB is reserved by PyTorch but unallocated. If reserved but unallocated memory is large try setting PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True to avoid fragmentation.  See documentation for Memory Management  (https://pytorch.org/docs/stable/notes/cuda.html#environment-variables)
+ Single GPU detected. Using cuda:0
+ Using device: cuda
+Loading generator and discriminators...
+Enabled gradient checkpointing on generator.
+Using single GPU or CPU.
+Training fact discriminator...
+Disc train epoch 1/4, loss=0.5201, val_acc=0.7500
+Disc train epoch 2/4, loss=0.2322, val_acc=1.0000
+Disc train epoch 3/4, loss=0.0366, val_acc=1.0000
+Disc train epoch 4/4, loss=0.0120, val_acc=1.0000
+Training style discriminator...
+Disc train epoch 1/4, loss=0.4904, val_acc=1.0000
+Disc train epoch 2/4, loss=0.1207, val_acc=1.0000
+Disc train epoch 3/4, loss=0.0324, val_acc=1.0000
+Disc train epoch 4/4, loss=0.0150, val_acc=1.0000
+Training safety discriminator...
+Disc train epoch 1/4, loss=0.5335, val_acc=0.7500
+Disc train epoch 2/4, loss=0.2243, val_acc=1.0000
+Disc train epoch 3/4, loss=0.0391, val_acc=1.0000
+Disc train epoch 4/4, loss=0.0122, val_acc=1.0000
+
+Sanity-check discriminator metrics:
+Fact disc: {'acc': 1.0, 'prec': 1.0, 'rec': 1.0, 'f1': 1.0}
+Style disc: {'acc': 1.0, 'prec': 1.0, 'rec': 1.0, 'f1': 1.0}
+Safety disc: {'acc': 1.0, 'prec': 1.0, 'rec': 1.0, 'f1': 1.0}
+
+Evaluation before SFT/RL (baseline):
+🚀 Starting QA + Corpus generation...
+
+📘 Processing: Elite_Dynamics_Partners_Policies
+✏️ Added 4 chunks to corpus file.
+
Generating QAs for Elite_Dynamics_Partners_Policies:   0%|                                            | 0/4 [00:00<?, ?it/s]
Generating QAs for Elite_Dynamics_Partners_Policies: 100%|████████████████████████████████| 4/4 [00:00<00:00, 100462.37it/s]
+⚠️ OPENAI_API_KEY not set. Skipping QA generation for this run.
+⚠️ OPENAI_API_KEY not set. Skipping QA generation for this run.
+⚠️ OPENAI_API_KEY not set. Skipping QA generation for this run.
+⚠️ OPENAI_API_KEY not set. Skipping QA generation for this run.
+✅ Saved 0 QAs for Elite_Dynamics_Partners_Policies
+
+🎯 Done! All QAs saved to:
+   → data/qa/qa.json
+   And corpus appended to:
+   → data/processed/corpus.txt
+The `load_in_4bit` and `load_in_8bit` arguments are deprecated and will be removed in the future versions. Please, pass a `BitsAndBytesConfig` object in `quantization_config` argument instead.
+Some weights of DistilBertForSequenceClassification were not initialized from the model checkpoint at distilbert-base-uncased and are newly initialized: ['classifier.bias', 'classifier.weight', 'pre_classifier.bias', 'pre_classifier.weight']
+You should probably TRAIN this model on a down-stream task to be able to use it for predictions and inference.
+Some weights of DistilBertForSequenceClassification were not initialized from the model checkpoint at distilbert-base-uncased and are newly initialized: ['classifier.bias', 'classifier.weight', 'pre_classifier.bias', 'pre_classifier.weight']
+You should probably TRAIN this model on a down-stream task to be able to use it for predictions and inference.
+Some weights of DistilBertForSequenceClassification were not initialized from the model checkpoint at distilbert-base-uncased and are newly initialized: ['classifier.bias', 'classifier.weight', 'pre_classifier.bias', 'pre_classifier.weight']
+You should probably TRAIN this model on a down-stream task to be able to use it for predictions and inference.
+Traceback (most recent call last):
+  File "<frozen runpy>", line 198, in _run_module_as_main
+  File "<frozen runpy>", line 88, in _run_code
+  File "/home/shehroz/Desktop/New Folder/ai4org/hallucination_reduction/main.py", line 210, in <module>
+    main()
+    ~~~~^^
+  File "/home/shehroz/Desktop/New Folder/ai4org/hallucination_reduction/main.py", line 126, in main
+    fact_disc = train_discriminator_minibatch(fact_disc, fact_tok, fact_texts, fact_labels,
+                                              device=DEVICE, epochs=DISC_EPOCHS, batch_size=DISC_BATCH, lr=DISC_LR)
+  File "/home/shehroz/Desktop/New Folder/ai4org/hallucination_reduction/discriminator_training_utils.py", line 27, in train_discriminator_minibatch
+    optimizer.step()
+    ~~~~~~~~~~~~~~^^
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/torch/optim/optimizer.py", line 516, in wrapper
+    out = func(*args, **kwargs)
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/torch/optim/optimizer.py", line 81, in _use_grad
+    ret = func(*args, **kwargs)
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/torch/optim/adam.py", line 237, in step
+    has_complex = self._init_group(
+        group,
+    ...<5 lines>...
+        state_steps,
+    )
+  File "/home/shehroz/miniconda3/lib/python3.13/site-packages/torch/optim/adam.py", line 177, in _init_group
+    state["exp_avg"] = torch.zeros_like(
+                       ~~~~~~~~~~~~~~~~^
+        p, memory_format=torch.preserve_format
+        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+    )
+    ^
+torch.OutOfMemoryError: CUDA out of memory. Tried to allocate 20.00 MiB. GPU 0 has a total capacity of 5.79 GiB of which 21.88 MiB is free. Process 75192 has 2.47 GiB memory in use. Including non-PyTorch memory, this process has 3.28 GiB memory in use. Of the allocated memory 3.06 GiB is allocated by PyTorch, and 118.23 MiB is reserved by PyTorch but unallocated. If reserved but unallocated memory is large try setting PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True to avoid fragmentation.  See documentation for Memory Management  (https://pytorch.org/docs/stable/notes/cuda.html#environment-variables)
+ Single GPU detected. Using cuda:0
+ Using device: cuda
+Loading generator and discriminators...
+Enabled gradient checkpointing on generator.
+Using single GPU or CPU.
+Training fact discriminator...
diff --git a/pre_commit_hooks/placeholder.py b/pre_commit_hooks/placeholder.py
new file mode 100644
index 0000000..e389d00
--- /dev/null
+++ b/pre_commit_hooks/placeholder.py
@@ -0,0 +1,12 @@
+#!/usr/bin/env python3
+import sys
+
+
+def main():
+    print("Running custom pre-commit hook...")
+    # Add your custom logic here
+    return 0
+
+
+if __name__ == "__main__":
+    sys.exit(main())
diff --git a/pyproject.toml b/pyproject.toml
new file mode 100644
index 0000000..2ff6211
--- /dev/null
+++ b/pyproject.toml
@@ -0,0 +1,30 @@
+[tool.black]
+line-length = 88
+target-version = ['py38']
+include = '\.pyi?$'
+exclude = '''
+/(
+    \.git
+  | \.hg
+  | \.mypy_cache
+  | \.tox
+  | \.venv
+  | _build
+  | buck-out
+  | build
+  | dist
+)/
+'''
+
+[tool.isort]
+profile = "black"
+multi_line_output = 3
+
+[tool.pytest.ini_options]
+pythonpath = [
+    "data_generation_pipeline/data-pipeline/src"
+]
+testpaths = [
+    "tests",
+    "data_generation_pipeline/data-pipeline/tests"
+]
diff --git a/requirements.txt b/requirements.txt
index 3351f75..3291fee 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -1,8 +1,16 @@
 # Core
-torch>=1.12
-transformers>=4.30
-scikit-learn
-tqdm
+torch>=2.1.0
+transformers>=4.35.0
+scikit-learn>=1.3.0
+tqdm>=4.66.0
 numpy
-pyyaml
+pyyaml>=6.0.1
 sentencepiece
+sentence-transformers>=2.2.2
+accelerate>=0.26.0
+pre-commit
+PyPDF2>=3.0.0
+faiss-cpu>=1.7.4
+nltk>=3.8.1
+loguru>=0.7.0
+bitsandbytes>=0.42.0
diff --git a/scripts/validate_setup.py b/scripts/validate_setup.py
new file mode 100644
index 0000000..f16e461
--- /dev/null
+++ b/scripts/validate_setup.py
@@ -0,0 +1,286 @@
+#!/usr/bin/env python3
+"""
+AI4Org Setup Validation Script
+
+This script validates that your environment is properly configured
+to run the AI4Org application.
+"""
+
+import os
+import sys
+from pathlib import Path
+
+
+def print_header(text):
+    """Print a formatted header"""
+    print("\n" + "=" * 60)
+    print(f"  {text}")
+    print("=" * 60)
+
+
+def print_check(passed, message):
+    """Print a check result"""
+    symbol = "✓" if passed else "✗"
+    status = "PASS" if passed else "FAIL"
+    print(f"{symbol} [{status}] {message}")
+    return passed
+
+
+def check_python_version():
+    """Check if Python version is 3.10+"""
+    print_header("Python Version Check")
+    version = sys.version_info
+    required = (3, 10)
+    passed = version >= required
+    print_check(
+        passed,
+        f"Python {version.major}.{version.minor}.{version.micro} "
+        f"(required: {required[0]}.{required[1]}+)",
+    )
+    return passed
+
+
+def check_packages():
+    """Check if required packages are installed"""
+    print_header("Package Installation Check")
+
+    packages = [
+        ("torch", "PyTorch"),
+        ("transformers", "Transformers"),
+        ("sklearn", "scikit-learn"),
+        ("sentence_transformers", "Sentence Transformers"),
+        ("faiss", "FAISS (CPU)"),
+        ("dotenv", "python-dotenv"),
+        ("numpy", "NumPy"),
+        ("tqdm", "tqdm"),
+    ]
+
+    all_passed = True
+    for module_name, display_name in packages:
+        try:
+            __import__(module_name)
+            print_check(True, f"{display_name} installed")
+        except ImportError:
+            print_check(False, f"{display_name} NOT installed")
+            all_passed = False
+
+    return all_passed
+
+
+def check_optional_packages():
+    """Check optional packages"""
+    print_header("Optional Package Check")
+
+    # Check PyWebView for frontend
+    try:
+        pass
+
+        print_check(True, "PyWebView installed (frontend will work)")
+    except ImportError:
+        print_check(False, "PyWebView NOT installed (frontend won't work)")
+
+    # Check for GPU support
+    try:
+        import torch
+
+        if torch.cuda.is_available():
+            gpu_count = torch.cuda.device_count()
+            gpu_name = torch.cuda.get_device_name(0)
+            print_check(True, f"CUDA available: {gpu_count} GPU(s) - {gpu_name}")
+        else:
+            print_check(False, "CUDA not available (will use CPU)")
+    except Exception as e:
+        print_check(False, f"Error checking CUDA: {e}")
+
+
+def check_data_files():
+    """Check if required data files exist"""
+    print_header("Data Files Check")
+
+    project_root = Path(__file__).parent.parent
+
+    files = [
+        ("data/processed/corpus.txt", "Corpus file"),
+        ("data/qa/qa.json", "QA pairs file"),
+    ]
+
+    all_passed = True
+    for file_path, description in files:
+        full_path = project_root / file_path
+        exists = full_path.exists()
+        size = full_path.stat().st_size if exists else 0
+
+        if exists:
+            print_check(True, f"{description}: {full_path} ({size:,} bytes)")
+        else:
+            print_check(False, f"{description}: {full_path} NOT FOUND")
+            all_passed = False
+
+    return all_passed
+
+
+def check_environment_variables():
+    """Check environment variables"""
+    print_header("Environment Variables Check")
+
+    # Check if .env file exists
+    project_root = Path(__file__).parent.parent
+    env_file = project_root / ".env"
+    env_example = project_root / ".env.example"
+
+    if env_file.exists():
+        print_check(True, f".env file exists: {env_file}")
+    else:
+        print_check(False, ".env file NOT found (using defaults)")
+        if env_example.exists():
+            print(f"  → Copy {env_example} to {env_file} and customize")
+
+    # Check some important env vars
+    from dotenv import load_dotenv
+
+    load_dotenv()
+
+    vars_to_check = [
+        ("ADMIN_PIN", "Admin PIN for frontend"),
+        ("GEN_MODEL", "Generator model name"),
+        ("DEVICE", "Device configuration"),
+    ]
+
+    for var_name, description in vars_to_check:
+        value = os.getenv(var_name)
+        if value:
+            # Mask sensitive values
+            display_value = "***" if "PIN" in var_name or "KEY" in var_name else value
+            print_check(True, f"{var_name}={display_value} ({description})")
+        else:
+            print_check(False, f"{var_name} not set ({description})")
+
+
+def check_model_cache():
+    """Check if models are cached"""
+    print_header("Model Cache Check")
+
+    cache_dir = Path.home() / ".cache" / "huggingface" / "hub"
+
+    if cache_dir.exists():
+        cached_models = list(cache_dir.glob("models--*"))
+        print_check(
+            True, f"HuggingFace cache exists: {len(cached_models)} models cached"
+        )
+
+        # Check for specific models
+        models_to_check = [
+            "TinyLlama",
+            "distilbert",
+        ]
+
+        for model_name in models_to_check:
+            found = any(model_name.lower() in str(m).lower() for m in cached_models)
+            if found:
+                print(f"  → {model_name} appears to be cached")
+    else:
+        print_check(
+            False,
+            "HuggingFace cache not found (models will be downloaded on first run)",
+        )
+
+
+def check_write_permissions():
+    """Check write permissions for important directories"""
+    print_header("Write Permissions Check")
+
+    project_root = Path(__file__).parent.parent
+
+    dirs_to_check = [
+        "saved_models_improved",
+        "data/raw",
+        "logs",
+    ]
+
+    all_passed = True
+    for dir_path in dirs_to_check:
+        full_path = project_root / dir_path
+        full_path.mkdir(parents=True, exist_ok=True)
+
+        # Try to write a test file
+        test_file = full_path / ".write_test"
+        try:
+            test_file.write_text("test")
+            test_file.unlink()
+            print_check(True, f"Write access to {dir_path}/")
+        except Exception as e:
+            print_check(False, f"Cannot write to {dir_path}/: {e}")
+            all_passed = False
+
+    return all_passed
+
+
+def main():
+    """Run all validation checks"""
+    print("\n" + "=" * 60)
+    print("  AI4Org Setup Validation")
+    print("=" * 60)
+
+    checks = [
+        ("Python Version", check_python_version),
+        ("Required Packages", check_packages),
+        ("Data Files", check_data_files),
+        ("Write Permissions", check_write_permissions),
+    ]
+
+    results = {}
+    for name, check_func in checks:
+        try:
+            results[name] = check_func()
+        except Exception as e:
+            print(f"\n✗ Error running {name} check: {e}")
+            results[name] = False
+
+    # Optional checks (don't affect overall status)
+    try:
+        check_optional_packages()
+    except Exception as e:
+        print(f"\n⚠ Error running optional checks: {e}")
+
+    try:
+        check_environment_variables()
+    except Exception as e:
+        print(f"\n⚠ Error checking environment variables: {e}")
+
+    try:
+        check_model_cache()
+    except Exception as e:
+        print(f"\n⚠ Error checking model cache: {e}")
+
+    # Summary
+    print_header("Validation Summary")
+
+    passed_count = sum(1 for v in results.values() if v)
+    total_count = len(results)
+
+    for name, passed in results.items():
+        print_check(passed, name)
+
+    print(f"\nPassed: {passed_count}/{total_count} checks")
+
+    if all(results.values()):
+        print("\n✓ All critical checks passed! You're ready to run AI4Org.")
+        print("\nNext steps:")
+        print("  1. Install dependencies: pip install -r requirements.txt")
+        print("  2. Train the model: python -m hallucination_reduction.main")
+        print("  3. Run inference: python -m hallucination_reduction.inference")
+        print("  4. Launch frontend: cd frontend && python main.py")
+        return 0
+    else:
+        print(
+            "\n✗ Some checks failed. Please fix the issues above before running AI4Org."
+        )
+        print("\nCommon fixes:")
+        print("  - Install missing packages: pip install -r requirements.txt")
+        print("  - Ensure data files exist in data/processed/ and data/qa/")
+        print("  - Check file permissions")
+        return 1
+
+
+if __name__ == "__main__":
+    sys.exit(main())
diff --git a/tests/__init__.py b/tests/__init__.py
new file mode 100644
index 0000000..e69de29
diff --git a/tests/e2e/__init__.py b/tests/e2e/__init__.py
new file mode 100644
index 0000000..e69de29
diff --git a/tests/integration/__init__.py b/tests/integration/__init__.py
new file mode 100644
index 0000000..e69de29
diff --git a/tests/unit/__init__.py b/tests/unit/__init__.py
new file mode 100644
index 0000000..e69de29
diff --git a/tests/unit/retriever.py b/tests/unit/retriever.py
new file mode 100644
index 0000000..9d870ad
--- /dev/null
+++ b/tests/unit/retriever.py
@@ -0,0 +1,357 @@
+from unittest.mock import patch
+
+import numpy as np
+import pytest
+
+from hallucination_reduction.retriever import SimpleRetriever
+
+
+class TestSimpleRetriever:
+    """Test suite for SimpleRetriever class."""
+
+    @pytest.fixture
+    def sample_passages(self):
+        """Create sample passages for testing."""
+        return [
+            "Python is a programming language",
+            "Java is used for enterprise applications",
+            "JavaScript runs in web browsers",
+            "Machine learning uses algorithms",
+            "Deep learning is a subset of machine learning",
+        ]
+
+    def test_class_exists(self):
+        """Test that SimpleRetriever class can be imported."""
+        assert SimpleRetriever is not None
+
+    def test_initialization(self, sample_passages):
+        """Test retriever initialization."""
+        retriever = SimpleRetriever(sample_passages)
+        assert retriever is not None
+
+    def test_stores_passages(self, sample_passages):
+        """Test that passages are stored."""
+        retriever = SimpleRetriever(sample_passages)
+        assert retriever.passages == sample_passages
+
+    def test_creates_vectorizer(self, sample_passages):
+        """Test that TfidfVectorizer is created."""
+        retriever = SimpleRetriever(sample_passages)
+        assert retriever.vectorizer is not None
+
+    def test_creates_vectors(self, sample_passages):
+        """Test that document vectors are created."""
+        retriever = SimpleRetriever(sample_passages)
+        assert retriever.vectors is not None
+
+    def test_vectors_match_passage_count(self, sample_passages):
+        """Test that number of vectors matches number of passages."""
+        retriever = SimpleRetriever(sample_passages)
+        assert retriever.vectors.shape[0] == len(sample_passages)
+
+    def test_retrieve_returns_list(self, sample_passages):
+        """Test that retrieve returns a list."""
+        retriever = SimpleRetriever(sample_passages)
+        query = "What is Python?"
+        result = retriever.retrieve(query)
+        assert isinstance(result, list)
+
+    def test_retrieve_returns_tuples(self, sample_passages):
+        """Test that retrieve returns list of tuples."""
+        retriever = SimpleRetriever(sample_passages)
+        query = "What is Python?"
+        result = retriever.retrieve(query)
+        assert all(isinstance(item, tuple) for item in result)
+
+    def test_retrieve_tuple_structure(self, sample_passages):
+        """Test that each tuple contains (index, passage)."""
+        retriever = SimpleRetriever(sample_passages)
+        query = "What is Python?"
+        result = retriever.retrieve(query)
+
+        for idx, passage in result:
+            assert isinstance(idx, int)
+            assert isinstance(passage, str)
+
+    def test_retrieve_default_k_is_three(self, sample_passages):
+        """Test that default k returns 3 results."""
+        retriever = SimpleRetriever(sample_passages)
+        query = "programming"
+        result = retriever.retrieve(query)
+        assert len(result) == 3
+
+    def test_retrieve_custom_k(self, sample_passages):
+        """Test that custom k parameter works."""
+        retriever = SimpleRetriever(sample_passages)
+        query = "programming"
+        k = 2
+        result = retriever.retrieve(query, k=k)
+        assert len(result) == k
+
+    def test_retrieve_k_equals_one(self, sample_passages):
+        """Test retrieving single result."""
+        retriever = SimpleRetriever(sample_passages)
+        query = "Python programming"
+        result = retriever.retrieve(query, k=1)
+        assert len(result) == 1
+
+    def test_retrieve_k_larger_than_passages(self, sample_passages):
+        """Test that k larger than passage count returns all passages."""
+        retriever = SimpleRetriever(sample_passages)
+        query = "programming"
+        k = 100
+        result = retriever.retrieve(query, k=k)
+        assert len(result) == len(sample_passages)
+
+    def test_retrieve_returns_valid_indices(self, sample_passages):
+        """Test that returned indices are valid."""
+        retriever = SimpleRetriever(sample_passages)
+        query = "programming"
+        result = retriever.retrieve(query)
+
+        for idx, _ in result:
+            assert 0 <= idx < len(sample_passages)
+
+    def test_retrieve_returns_correct_passages(self, sample_passages):
+        """Test that returned passages match the indices."""
+        retriever = SimpleRetriever(sample_passages)
+        query = "programming"
+        result = retriever.retrieve(query)
+
+        for idx, passage in result:
+            assert passage == sample_passages[idx]
+
+    def test_retrieve_relevant_result_for_python(self, sample_passages):
+        """Test that Python query returns Python passage."""
+        retriever = SimpleRetriever(sample_passages)
+        query = "Python programming language"
+        result = retriever.retrieve(query, k=1)
+
+        idx, passage = result[0]
+        assert "Python" in passage
+
+    def test_retrieve_relevant_result_for_machine_learning(self, sample_passages):
+        """Test that machine learning query returns ML passage."""
+        retriever = SimpleRetriever(sample_passages)
+        query = "machine learning algorithms"
+        result = retriever.retrieve(query, k=1)
+
+        idx, passage = result[0]
+        assert "machine learning" in passage.lower()
+
+    def test_retrieve_handles_empty_query(self, sample_passages):
+        """Test that empty query is handled."""
+        retriever = SimpleRetriever(sample_passages)
+        query = ""
+        result = retriever.retrieve(query)
+
+        # Should still return k results
+        assert len(result) == 3
+
+    def test_retrieve_handles_query_with_no_matches(self, sample_passages):
+        """Test query with words not in any passage."""
+        retriever = SimpleRetriever(sample_passages)
+        query = "quantum physics relativity"
+        result = retriever.retrieve(query)
+
+        # Should still return k results (lowest scores)
+        assert len(result) == 3
+
+    def test_retrieve_case_insensitive(self, sample_passages):
+        """Test that retrieval works regardless of case."""
+        retriever = SimpleRetriever(sample_passages)
+
+        query_lower = "python programming"
+        query_upper = "PYTHON PROGRAMMING"
+
+        result_lower = retriever.retrieve(query_lower, k=1)
+        result_upper = retriever.retrieve(query_upper, k=1)
+
+        # Should retrieve same passage (case-insensitive)
+        assert result_lower[0][1] == result_upper[0][1]
+
+    def test_returns_ordered_by_relevance(self, sample_passages):
+        """Test that results are ordered by relevance (descending)."""
+        retriever = SimpleRetriever(sample_passages)
+        query = "machine learning deep learning"
+        result = retriever.retrieve(query, k=3)
+
+        # First result should be most relevant
+        # Check that machine learning passages come first
+        top_passage = result[0][1]
+        assert "learning" in top_passage.lower()
+
+    def test_single_passage(self):
+        """Test retriever with single passage."""
+        passages = ["Single passage about Python"]
+        retriever = SimpleRetriever(passages)
+
+        query = "Python"
+        result = retriever.retrieve(query, k=1)
+
+        assert len(result) == 1
+        assert result[0][1] == passages[0]
+
+    def test_two_passages(self):
+        """Test retriever with two passages."""
+        passages = ["Python programming", "Java development"]
+        retriever = SimpleRetriever(passages)
+
+        query = "Python"
+        result = retriever.retrieve(query, k=2)
+
+        assert len(result) == 2
+
+    def test_identical_passages(self):
+        """Test retriever with identical passages."""
+        passages = ["Same text", "Same text", "Same text"]
+        retriever = SimpleRetriever(passages)
+
+        query = "Same text"
+        result = retriever.retrieve(query, k=3)
+
+        assert len(result) == 3
+        # All should have same text
+        assert all(passage == "Same text" for _, passage in result)
+
+    def test_retrieve_with_special_characters(self, sample_passages):
+        """Test query with special characters."""
+        retriever = SimpleRetriever(sample_passages)
+        query = "What is Python? Can you explain!"
+        result = retriever.retrieve(query)
+
+        assert len(result) > 0
+        assert all(isinstance(idx, int) for idx, _ in result)
+
+    def test_retrieve_with_numbers(self):
+        """Test passages and queries with numbers."""
+        passages = [
+            "Python 3.9 is the latest version",
+            "Java version 11 is stable",
+            "JavaScript ES6 features",
+        ]
+        retriever = SimpleRetriever(passages)
+
+        query = "Python 3.9"
+        result = retriever.retrieve(query, k=1)
+
+        assert "Python" in result[0][1]
+
+    def test_retrieve_preserves_index_order_information(self, sample_passages):
+        """Test that indices correspond to original passage positions."""
+        retriever = SimpleRetriever(sample_passages)
+        query = "programming"
+        result = retriever.retrieve(query, k=len(sample_passages))
+
+        # Verify all indices are valid positions
+        retrieved_indices = [idx for idx, _ in result]
+        assert all(idx in range(len(sample_passages)) for idx in retrieved_indices)
+
+    def test_vectorizer_fitted_on_passages(self, sample_passages):
+        """Test that vectorizer is fitted on all passages."""
+        retriever = SimpleRetriever(sample_passages)
+
+        # Vectorizer should have vocabulary from passages
+        vocab = retriever.vectorizer.get_feature_names_out()
+        assert len(vocab) > 0
+
+    def test_cosine_similarity_used(self, sample_passages):
+        """Test that cosine similarity is computed."""
+        retriever = SimpleRetriever(sample_passages)
+
+        with patch(
+            "hallucination_reduction.retriever.cosine_similarity"
+        ) as mock_cosine:
+            # Return dummy similarities
+            mock_cosine.return_value = np.array([[0.5, 0.3, 0.8, 0.1, 0.2]])
+
+            query = "test query"
+            retriever.retrieve(query, k=2)
+
+            # Cosine similarity should be called
+            mock_cosine.assert_called_once()
+
+    def test_retrieve_k_zero(self, sample_passages):
+        """Test that k=0 returns empty list."""
+        retriever = SimpleRetriever(sample_passages)
+        query = "Python"
+        result = retriever.retrieve(query, k=0)
+
+        assert result == []
+
+    def test_retrieve_negative_k_returns_empty(self, sample_passages):
+        """Test that negative k returns empty list."""
+        retriever = SimpleRetriever(sample_passages)
+        query = "Python"
+        result = retriever.retrieve(query, k=-1)
+
+        # argsort with negative slice returns empty
+        assert result == []
+
+    def test_multiple_queries_same_retriever(self, sample_passages):
+        """Test that same retriever can handle multiple queries."""
+        retriever = SimpleRetriever(sample_passages)
+
+        query1 = "Python"
+        query2 = "Java"
+        query3 = "machine learning"
+
+        result1 = retriever.retrieve(query1, k=1)
+        result2 = retriever.retrieve(query2, k=1)
+        result3 = retriever.retrieve(query3, k=1)
+
+        assert len(result1) == 1
+        assert len(result2) == 1
+        assert len(result3) == 1
+
+    def test_passages_not_modified(self, sample_passages):
+        """Test that original passages are not modified."""
+        original_passages = sample_passages.copy()
+        retriever = SimpleRetriever(sample_passages)
+
+        query = "Python"
+        retriever.retrieve(query)
+
+        assert retriever.passages == original_passages
+
+    def test_long_query(self, sample_passages):
+        """Test with a very long query."""
+        retriever = SimpleRetriever(sample_passages)
+        query = " ".join(["Python programming language"] * 100)
+        result = retriever.retrieve(query, k=2)
+
+        assert len(result) == 2
+
+    def test_passages_with_unicode(self):
+        """Test passages with Unicode characters."""
+        passages = [
+            "Python es un lenguaje de programación",
+            "Java est un langage de programmation",
+            "JavaScript 是一种编程语言",
+        ]
+        retriever = SimpleRetriever(passages)
+
+        query = "programming"
+        result = retriever.retrieve(query)
+
+        assert len(result) > 0
+
+    def test_retrieve_consistent_results(self, sample_passages):
+        """Test that same query returns consistent results."""
+        retriever = SimpleRetriever(sample_passages)
+        query = "Python programming"
+
+        result1 = retriever.retrieve(query, k=3)
+        result2 = retriever.retrieve(query, k=3)
+
+        # Should return same results
+        assert result1 == result2
+
+    def test_index_type_is_int(self, sample_passages):
+        """Test that returned indices are Python int type."""
+        retriever = SimpleRetriever(sample_passages)
+        query = "Python"
+        result = retriever.retrieve(query)
+
+        for idx, _ in result:
+            assert isinstance(idx, int)  # Not np.int64 or other numpy types
diff --git a/tests/unit/test_config.py b/tests/unit/test_config.py
new file mode 100644
index 0000000..7d4fab9
--- /dev/null
+++ b/tests/unit/test_config.py
@@ -0,0 +1,391 @@
+import os
+import random
+from unittest.mock import patch
+
+import numpy as np
+import pytest
+import torch
+
+
+class TestConfigConstants:
+    """Test suite for config.py constants and configurations."""
+
+    def test_seed_value(self):
+        """Verify SEED constant is set correctly."""
+        from hallucination_reduction.config import SEED
+
+        assert SEED == 42
+
+    def test_random_seed_set(self):
+        """Verify random seed is set and reproducible."""
+        # Import triggers seed setting
+
+        # Generate random values
+        val1 = random.random()
+
+        # Reset and regenerate
+        random.seed(42)
+        val2 = random.random()
+
+        assert val1 == val2, "Random seed should produce reproducible results"
+
+    def test_numpy_seed_set(self):
+        """Verify numpy seed is set and reproducible."""
+
+        val1 = np.random.rand()
+        np.random.seed(42)
+        val2 = np.random.rand()
+
+        assert val1 == val2, "Numpy seed should produce reproducible results"
+
+    def test_torch_seed_set(self):
+        """Verify torch seed is set and reproducible."""
+
+        val1 = torch.rand(1).item()
+        torch.manual_seed(42)
+        val2 = torch.rand(1).item()
+
+        assert val1 == val2, "Torch seed should produce reproducible results"
+
+    @patch("torch.cuda.is_available")
+    def test_device_cpu_when_no_cuda(self, mock_cuda):
+        """Test DEVICE is set to 'cpu' when CUDA is not available."""
+        mock_cuda.return_value = False
+
+        # Reload module to trigger device detection
+        import importlib
+
+        import hallucination_reduction.config as config
+
+        importlib.reload(config)
+
+        assert config.DEVICE == "cpu"
+        assert config.MULTI_GPU is False
+        assert config.N_GPUS == 0
+
+    @patch("torch.cuda.device_count")
+    @patch("torch.cuda.is_available")
+    def test_device_single_gpu(self, mock_cuda, mock_count):
+        """Test DEVICE configuration with single GPU."""
+        mock_cuda.return_value = True
+        mock_count.return_value = 1
+
+        import importlib
+
+        import hallucination_reduction.config as config
+
+        importlib.reload(config)
+
+        assert config.DEVICE == "cuda"
+        assert config.MULTI_GPU is False
+        assert config.N_GPUS == 1
+
+    @patch("torch.cuda.device_count")
+    @patch("torch.cuda.is_available")
+    def test_device_multi_gpu(self, mock_cuda, mock_count):
+        """Test DEVICE configuration with multiple GPUs."""
+        mock_cuda.return_value = True
+        mock_count.return_value = 4
+
+        import importlib
+
+        import hallucination_reduction.config as config
+
+        importlib.reload(config)
+
+        assert config.DEVICE == "cuda"
+        assert config.MULTI_GPU is True
+        assert config.N_GPUS == 4
+
+    def test_gen_model_default(self):
+        """Test default GEN_MODEL value."""
+        # Clear environment variable if set
+        if "GEN_MODEL" in os.environ:
+            del os.environ["GEN_MODEL"]
+
+        import importlib
+
+        import hallucination_reduction.config as config
+
+        importlib.reload(config)
+
+        assert config.GEN_MODEL == "TinyLlama/TinyLlama-1.1B-Chat-v1.0"
+
+    def test_gen_model_from_env(self):
+        """Test GEN_MODEL reads from environment variable."""
+        os.environ["GEN_MODEL"] = "custom/model"
+
+        import importlib
+
+        import hallucination_reduction.config as config
+
+        importlib.reload(config)
+
+        assert config.GEN_MODEL == "custom/model"
+
+        # Cleanup
+        del os.environ["GEN_MODEL"]
+
+    def test_disc_model_default(self):
+        """Test default DISC_MODEL value."""
+        if "DISC_MODEL" in os.environ:
+            del os.environ["DISC_MODEL"]
+
+        import importlib
+
+        import hallucination_reduction.config as config
+
+        importlib.reload(config)
+
+        assert config.DISC_MODEL == "distilbert-base-uncased"
+
+    def test_disc_model_from_env(self):
+        """Test DISC_MODEL reads from environment variable."""
+        os.environ["DISC_MODEL"] = "bert-base-uncased"
+
+        import importlib
+
+        import hallucination_reduction.config as config
+
+        importlib.reload(config)
+
+        assert config.DISC_MODEL == "bert-base-uncased"
+
+        # Cleanup
+        del os.environ["DISC_MODEL"]
+
+    def test_save_dir_constant(self):
+        """Test SAVE_DIR is set correctly."""
+        from hallucination_reduction.config import SAVE_DIR
+
+        assert SAVE_DIR == "./saved_models_improved"
+
+    def test_save_dir_created(self):
+        """Test that SAVE_DIR is created during module import."""
+        from hallucination_reduction.config import SAVE_DIR
+
+        assert os.path.exists(SAVE_DIR)
+
+    def test_gen_model_path(self):
+        """Test GEN_MODEL_PATH construction."""
+        from hallucination_reduction.config import GEN_MODEL_PATH, SAVE_DIR
+
+        expected = os.path.join(SAVE_DIR, "generator_final.pt")
+        assert GEN_MODEL_PATH == expected
+
+    def test_corpus_path(self):
+        """Test CORPUS_PATH is set correctly."""
+        from hallucination_reduction.config import CORPUS_PATH
+
+        assert CORPUS_PATH == "./data/processed/corpus.txt"
+
+    def test_sft_hyperparameters(self):
+        """Test SFT training hyperparameters."""
+        from hallucination_reduction.config import SFT_BATCH, SFT_EPOCHS, SFT_LR
+
+        assert SFT_EPOCHS == 4
+        assert SFT_BATCH == 1
+        assert SFT_LR == 3e-5
+        assert isinstance(SFT_LR, float)
+
+    def test_disc_hyperparameters(self):
+        """Test discriminator training hyperparameters."""
+        from hallucination_reduction.config import DISC_BATCH, DISC_EPOCHS, DISC_LR
+
+        assert DISC_EPOCHS == 4
+        assert DISC_BATCH == 8
+        assert DISC_LR == 2e-5
+        assert isinstance(DISC_LR, float)
+
+    def test_mc_rollouts(self):
+        """Test Monte Carlo rollouts parameter."""
+        from hallucination_reduction.config import MC_ROLLOUTS
+
+        assert MC_ROLLOUTS == 6
+        assert isinstance(MC_ROLLOUTS, int)
+
+    def test_gen_batch_size(self):
+        """Test generator batch size."""
+        from hallucination_reduction.config import GEN_BATCH_SIZE
+
+        assert GEN_BATCH_SIZE == 1
+
+    def test_gen_learning_rate(self):
+        """Test generator learning rate."""
+        from hallucination_reduction.config import GEN_LR
+
+        assert GEN_LR == 1e-5
+        assert isinstance(GEN_LR, float)
+
+    def test_token_limits(self):
+        """Test token generation limits."""
+        from hallucination_reduction.config import MAX_GEN_TOKENS, MIN_GEN_TOKENS
+
+        assert MAX_GEN_TOKENS == 64
+        assert MIN_GEN_TOKENS == 5
+        assert MAX_GEN_TOKENS > MIN_GEN_TOKENS
+
+    def test_top_k_parameter(self):
+        """Test TOP_K parameter."""
+        from hallucination_reduction.config import TOP_K
+
+        assert TOP_K == 3
+        assert isinstance(TOP_K, int)
+
+    def test_rl_epochs(self):
+        """Test RL training epochs."""
+        from hallucination_reduction.config import RL_EPOCHS
+
+        assert RL_EPOCHS == 4
+
+    def test_reward_weights(self):
+        """Test reward weight configuration."""
+        from hallucination_reduction.config import (
+            FACT_WEIGHT,
+            SAFETY_WEIGHT,
+            STYLE_WEIGHT,
+        )
+
+        assert FACT_WEIGHT == 0.8
+        assert STYLE_WEIGHT == 0.15
+        assert SAFETY_WEIGHT == 0.05
+
+        # Weights should sum to 1.0
+        total = FACT_WEIGHT + STYLE_WEIGHT + SAFETY_WEIGHT
+        assert abs(total - 1.0) < 1e-6, "Weights should sum to 1.0"
+
+    def test_reward_weights_types(self):
+        """Test reward weights are floats."""
+        from hallucination_reduction.config import (
+            FACT_WEIGHT,
+            SAFETY_WEIGHT,
+            STYLE_WEIGHT,
+        )
+
+        assert isinstance(FACT_WEIGHT, float)
+        assert isinstance(STYLE_WEIGHT, float)
+        assert isinstance(SAFETY_WEIGHT, float)
+
+    def test_hard_penalty_threshold(self):
+        """Test hard penalty threshold."""
+        from hallucination_reduction.config import HARD_PENALTY_IF_FACT_LT
+
+        assert HARD_PENALTY_IF_FACT_LT == 0.4
+        assert 0 <= HARD_PENALTY_IF_FACT_LT <= 1
+
+    def test_all_epochs_positive(self):
+        """Test all epoch values are positive integers."""
+        from hallucination_reduction.config import DISC_EPOCHS, RL_EPOCHS, SFT_EPOCHS
+
+        assert SFT_EPOCHS > 0
+        assert DISC_EPOCHS > 0
+        assert RL_EPOCHS > 0
+        assert isinstance(SFT_EPOCHS, int)
+        assert isinstance(DISC_EPOCHS, int)
+        assert isinstance(RL_EPOCHS, int)
+
+    def test_all_batch_sizes_positive(self):
+        """Test all batch sizes are positive integers."""
+        from hallucination_reduction.config import DISC_BATCH, GEN_BATCH_SIZE, SFT_BATCH
+
+        assert SFT_BATCH > 0
+        assert DISC_BATCH > 0
+        assert GEN_BATCH_SIZE > 0
+
+    def test_all_learning_rates_positive(self):
+        """Test all learning rates are positive floats."""
+        from hallucination_reduction.config import DISC_LR, GEN_LR, SFT_LR
+
+        assert SFT_LR > 0
+        assert DISC_LR > 0
+        assert GEN_LR > 0
+
+    def test_learning_rates_reasonable_range(self):
+        """Test learning rates are in reasonable range."""
+        from hallucination_reduction.config import DISC_LR, GEN_LR, SFT_LR
+
+        # Typical LR range: 1e-6 to 1e-3
+        assert 1e-6 <= SFT_LR <= 1e-3
+        assert 1e-6 <= DISC_LR <= 1e-3
+        assert 1e-6 <= GEN_LR <= 1e-3
+
+
+def test_cudnn_benchmark_set():
+
+    # Ensure that cudnn.benchmark is a boolean
+    assert isinstance(torch.backends.cudnn.benchmark, bool)
+
+    def test_weights_are_non_negative(self):
+        """Test all weights are non-negative."""
+        from hallucination_reduction.config import (
+            FACT_WEIGHT,
+            SAFETY_WEIGHT,
+            STYLE_WEIGHT,
+        )
+
+        assert FACT_WEIGHT >= 0
+        assert STYLE_WEIGHT >= 0
+        assert SAFETY_WEIGHT >= 0
+
+    def test_fact_weight_dominates(self):
+        """Test that FACT_WEIGHT is the largest weight."""
+        from hallucination_reduction.config import (
+            FACT_WEIGHT,
+            SAFETY_WEIGHT,
+            STYLE_WEIGHT,
+        )
+
+        assert FACT_WEIGHT > STYLE_WEIGHT
+        assert FACT_WEIGHT > SAFETY_WEIGHT
+
+    def test_module_imports_without_error(self):
+        """Test that config module can be imported without errors."""
+        try:
+            pass
+
+            assert True
+        except Exception as e:
+            pytest.fail(f"Config import failed: {e}")
+
+    def test_constants_are_immutable_types(self):
+        """Test that configuration constants use immutable types."""
+        from hallucination_reduction.config import (
+            DEVICE,
+            FACT_WEIGHT,
+            GEN_MODEL,
+            SEED,
+            SFT_EPOCHS,
+        )
+
+        # These should all be immutable types
+        assert isinstance(SEED, int)
+        assert isinstance(SFT_EPOCHS, int)
+        assert isinstance(FACT_WEIGHT, float)
+        assert isinstance(GEN_MODEL, str)
+        assert isinstance(DEVICE, str)
+
+    def test_path_strings_valid(self):
+        """Test that path strings are valid."""
+        from hallucination_reduction.config import CORPUS_PATH, GEN_MODEL_PATH, SAVE_DIR
+
+        # Should not be empty
+        assert len(SAVE_DIR) > 0
+        assert len(CORPUS_PATH) > 0
+        assert len(GEN_MODEL_PATH) > 0
+
+        # Should be strings
+        assert isinstance(SAVE_DIR, str)
+        assert isinstance(CORPUS_PATH, str)
+        assert isinstance(GEN_MODEL_PATH, str)
+
+    def test_mc_rollouts_reasonable(self):
+        """Test MC_ROLLOUTS is in reasonable range."""
+        from hallucination_reduction.config import MC_ROLLOUTS
+
+        assert 1 <= MC_ROLLOUTS <= 20, "MC rollouts should be reasonable"
+
+    def test_top_k_reasonable(self):
+        """Test TOP_K is in reasonable range."""
+        from hallucination_reduction.config import TOP_K
+
+        assert 1 <= TOP_K <= 50, "TOP_K should be reasonable"
diff --git a/tests/unit/test_data_utils.py b/tests/unit/test_data_utils.py
new file mode 100644
index 0000000..5391615
--- /dev/null
+++ b/tests/unit/test_data_utils.py
@@ -0,0 +1,292 @@
+import json
+from unittest.mock import mock_open, patch
+
+from hallucination_reduction.data_utils import QAPair, build_corpus_and_qa
+
+
+class TestBuildCorpusAndQA:
+    """Comprehensive test suite for build_corpus_and_qa function."""
+
+    def test_build_returns_two_items(self):
+        """Ensure build_corpus_and_qa returns exactly two items."""
+        with patch("builtins.open", mock_open(read_data="passage1\npassage2\n")):
+            with patch("os.path.exists", return_value=False):
+                passages, qa_pairs = build_corpus_and_qa()
+                assert isinstance(passages, list)
+                assert isinstance(qa_pairs, list)
+
+    def test_returns_correct_types(self):
+        """Verify return types are lists."""
+        with patch("builtins.open", mock_open(read_data="test passage\n")):
+            with patch("os.path.exists", return_value=False):
+                passages, qa_pairs = build_corpus_and_qa()
+                assert isinstance(passages, list)
+                assert isinstance(qa_pairs, list)
+
+    def test_passages_loaded_correctly(self):
+        """Test that passages are read and stripped properly."""
+        corpus_data = "passage one\n\npassage two\n  passage three  \n"
+        with patch("builtins.open", mock_open(read_data=corpus_data)):
+            with patch("os.path.exists", return_value=False):
+                passages, _ = build_corpus_and_qa()
+                assert len(passages) == 3
+                assert passages[0] == "passage one"
+                assert passages[1] == "passage two"
+                assert passages[2] == "passage three"
+
+    def test_empty_lines_filtered_out(self):
+        """Ensure empty lines in corpus are filtered."""
+        corpus_data = "passage1\n\n\npassage2\n"
+        with patch("builtins.open", mock_open(read_data=corpus_data)):
+            with patch("os.path.exists", return_value=False):
+                passages, _ = build_corpus_and_qa()
+                assert len(passages) == 2
+
+    def test_qa_json_not_exists_generates_default_qa(self):
+        """When qa.json doesn't exist, generate default Q&A pairs."""
+        corpus_data = "passage1\npassage2\n"
+        with patch("builtins.open", mock_open(read_data=corpus_data)):
+            with patch("os.path.exists", return_value=False):
+                _, qa_pairs = build_corpus_and_qa()
+                # Should have 2 passages * 3 augmentations = 6 QA pairs
+                assert len(qa_pairs) == 6
+                assert all(isinstance(qa, QAPair) for qa in qa_pairs)
+
+    def test_qa_json_exists_and_valid(self):
+        """Test loading valid QA pairs from JSON file."""
+        corpus_data = "passage1\n"
+        qa_json_data = json.dumps(
+            [
+                {
+                    "question": "What is X?",
+                    "answer": "X is Y",
+                    "supporting_passages": ["passage1"],
+                }
+            ]
+        )
+
+        def mock_open_handler(filename, *args, **kwargs):
+            if "corpus.txt" in filename:
+                return mock_open(read_data=corpus_data)()
+            elif "qa.json" in filename:
+                return mock_open(read_data=qa_json_data)()
+
+        with patch("builtins.open", side_effect=mock_open_handler):
+            with patch("os.path.exists", return_value=True):
+                _, qa_pairs = build_corpus_and_qa()
+                # 1 base QA * 3 augmentations = 3
+                assert len(qa_pairs) == 3
+                assert qa_pairs[0].question == "What is X?"
+                assert qa_pairs[0].answer == "X is Y"
+
+    def test_qa_json_malformed_falls_back_to_default(self):
+        """When qa.json is malformed, fall back to default generation."""
+        corpus_data = "passage1\n"
+        qa_json_data = "not valid json{{"
+
+        def mock_open_handler(filename, *args, **kwargs):
+            if "corpus.txt" in filename:
+                return mock_open(read_data=corpus_data)()
+            elif "qa.json" in filename:
+                return mock_open(read_data=qa_json_data)()
+
+        with patch("builtins.open", side_effect=mock_open_handler):
+            with patch("os.path.exists", return_value=True):
+                _, qa_pairs = build_corpus_and_qa()
+                # Should fall back to default generation
+                assert len(qa_pairs) == 3  # 1 passage * 3 augmentations
+
+    def test_qa_json_not_a_list(self):
+        """When qa.json contains non-list data, fall back to default."""
+        corpus_data = "passage1\n"
+        qa_json_data = json.dumps({"not": "a list"})
+
+        def mock_open_handler(filename, *args, **kwargs):
+            if "corpus.txt" in filename:
+                return mock_open(read_data=corpus_data)()
+            elif "qa.json" in filename:
+                return mock_open(read_data=qa_json_data)()
+
+        with patch("builtins.open", side_effect=mock_open_handler):
+            with patch("os.path.exists", return_value=True):
+                _, qa_pairs = build_corpus_and_qa()
+                assert len(qa_pairs) == 3
+
+    def test_qa_missing_required_fields_skipped(self):
+        """QA pairs without question or answer should be skipped."""
+        corpus_data = "passage1\n"
+        qa_json_data = json.dumps(
+            [
+                {"question": "Valid?", "answer": "Yes"},
+                {"question": "No answer?"},  # Missing answer
+                {"answer": "No question"},  # Missing question
+                {},  # Empty
+            ]
+        )
+
+        def mock_open_handler(filename, *args, **kwargs):
+            if "corpus.txt" in filename:
+                return mock_open(read_data=corpus_data)()
+            elif "qa.json" in filename:
+                return mock_open(read_data=qa_json_data)()
+
+        with patch("builtins.open", side_effect=mock_open_handler):
+            with patch("os.path.exists", return_value=True):
+                _, qa_pairs = build_corpus_and_qa()
+                # Only 1 valid QA * 3 augmentations = 3
+                assert len(qa_pairs) == 3
+
+    def test_supporting_passages_string_converted_to_list(self):
+        """When supporting_passages is a string, convert to list."""
+        corpus_data = "passage1\n"
+        qa_json_data = json.dumps(
+            [{"question": "Q?", "answer": "A", "supporting_passages": "single_passage"}]
+        )
+
+        def mock_open_handler(filename, *args, **kwargs):
+            if "corpus.txt" in filename:
+                return mock_open(read_data=corpus_data)()
+            elif "qa.json" in filename:
+                return mock_open(read_data=qa_json_data)()
+
+        with patch("builtins.open", side_effect=mock_open_handler):
+            with patch("os.path.exists", return_value=True):
+                _, qa_pairs = build_corpus_and_qa()
+                assert isinstance(qa_pairs[0].supporting_passages, list)
+                assert qa_pairs[0].supporting_passages == ["single_passage"]
+
+    def test_supporting_passages_none_becomes_empty_list(self):
+        """When supporting_passages is None, use empty list."""
+        corpus_data = "passage1\n"
+        qa_json_data = json.dumps(
+            [{"question": "Q?", "answer": "A", "supporting_passages": None}]
+        )
+
+        def mock_open_handler(filename, *args, **kwargs):
+            if "corpus.txt" in filename:
+                return mock_open(read_data=corpus_data)()
+            elif "qa.json" in filename:
+                return mock_open(read_data=qa_json_data)()
+
+        with patch("builtins.open", side_effect=mock_open_handler):
+            with patch("os.path.exists", return_value=True):
+                _, qa_pairs = build_corpus_and_qa()
+                assert qa_pairs[0].supporting_passages == []
+
+    def test_default_qa_generation_bounded_to_200_passages(self):
+        """Default QA generation should be limited to first 200 passages."""
+        corpus_data = "\n".join([f"passage{i}" for i in range(250)])
+        with patch("builtins.open", mock_open(read_data=corpus_data)):
+            with patch("os.path.exists", return_value=False):
+                _, qa_pairs = build_corpus_and_qa()
+                # 200 passages * 3 augmentations = 600
+                assert len(qa_pairs) == 600
+
+    def test_default_qa_structure(self):
+        """Test default QA pairs have correct structure."""
+        corpus_data = "test passage content\n"
+        with patch("builtins.open", mock_open(read_data=corpus_data)):
+            with patch("os.path.exists", return_value=False):
+                _, qa_pairs = build_corpus_and_qa()
+                base_qa = qa_pairs[0]
+                assert base_qa.question == "What does this passage say?"
+                assert base_qa.answer == "test passage content"[:500]
+                assert base_qa.supporting_passages == ["test passage content"]
+
+    def test_augmentation_creates_three_variants(self):
+        """Each base QA should produce 3 augmented variants."""
+        corpus_data = "passage1\n"
+        qa_json_data = json.dumps(
+            [
+                {
+                    "question": "Can a customer do X?",
+                    "answer": "Yes",
+                    "supporting_passages": ["passage1"],
+                }
+            ]
+        )
+
+        def mock_open_handler(filename, *args, **kwargs):
+            if "corpus.txt" in filename:
+                return mock_open(read_data=corpus_data)()
+            elif "qa.json" in filename:
+                return mock_open(read_data=qa_json_data)()
+
+        with patch("builtins.open", side_effect=mock_open_handler):
+            with patch("os.path.exists", return_value=True):
+                _, qa_pairs = build_corpus_and_qa()
+                assert len(qa_pairs) == 3
+                assert qa_pairs[0].question == "Can a customer do X?"
+                assert qa_pairs[1].question == "Is it possible for a customer do X?"
+                assert qa_pairs[2].question == "Can a customer do X? (please advise)"
+
+    def test_augmentation_preserves_answer_and_passages(self):
+        """Augmented QA pairs should keep the same answer and supporting passages."""
+        corpus_data = "passage1\n"
+        qa_json_data = json.dumps(
+            [
+                {
+                    "question": "Original?",
+                    "answer": "Original answer",
+                    "supporting_passages": ["p1", "p2"],
+                }
+            ]
+        )
+
+        def mock_open_handler(filename, *args, **kwargs):
+            if "corpus.txt" in filename:
+                return mock_open(read_data=corpus_data)()
+            elif "qa.json" in filename:
+                return mock_open(read_data=qa_json_data)()
+
+        with patch("builtins.open", side_effect=mock_open_handler):
+            with patch("os.path.exists", return_value=True):
+                _, qa_pairs = build_corpus_and_qa()
+                for qa in qa_pairs:
+                    assert qa.answer == "Original answer"
+                    assert qa.supporting_passages == ["p1", "p2"]
+
+    def test_answer_truncation_to_500_chars(self):
+        """Default QA answers should be truncated to 500 characters."""
+        long_passage = "x" * 1000
+        corpus_data = long_passage + "\n"
+        with patch("builtins.open", mock_open(read_data=corpus_data)):
+            with patch("os.path.exists", return_value=False):
+                _, qa_pairs = build_corpus_and_qa()
+                assert len(qa_pairs[0].answer) == 500
+
+    def test_file_encoding_utf8(self):
+        """Verify files are opened with UTF-8 encoding."""
+        corpus_data = "passage with émojis 🎉\n"
+        with patch("builtins.open", mock_open(read_data=corpus_data)) as m:
+            with patch("os.path.exists", return_value=False):
+                passages, _ = build_corpus_and_qa()
+                # Check that open was called with utf-8 encoding
+                m.assert_any_call("data/processed/corpus.txt", "r", encoding="utf-8")
+
+    def test_empty_corpus_file(self):
+        """Handle empty corpus file gracefully."""
+        with patch("builtins.open", mock_open(read_data="")):
+            with patch("os.path.exists", return_value=False):
+                passages, qa_pairs = build_corpus_and_qa()
+                assert passages == []
+                assert qa_pairs == []
+
+    def test_multiple_base_qa_all_augmented(self):
+        """Multiple base QA pairs should all be augmented."""
+        corpus_data = "passage1\n"
+        qa_json_data = json.dumps(
+            [{"question": "Q1?", "answer": "A1"}, {"question": "Q2?", "answer": "A2"}]
+        )
+
+        def mock_open_handler(filename, *args, **kwargs):
+            if "corpus.txt" in filename:
+                return mock_open(read_data=corpus_data)()
+            elif "qa.json" in filename:
+                return mock_open(read_data=qa_json_data)()
+
+        with patch("builtins.open", side_effect=mock_open_handler):
+            with patch("os.path.exists", return_value=True):
+                _, qa_pairs = build_corpus_and_qa()
+                # 2 base QA * 3 augmentations = 6
+                assert len(qa_pairs) == 6
diff --git a/tests/unit/test_discriminator.py b/tests/unit/test_discriminator.py
new file mode 100644
index 0000000..8ff71d9
--- /dev/null
+++ b/tests/unit/test_discriminator.py
@@ -0,0 +1,485 @@
+from unittest.mock import MagicMock, Mock, patch
+
+import pytest
+import torch
+
+
+class TestLoadDiscriminator:
+    """Test suite for load_discriminator function."""
+
+    def test_function_exists(self):
+        """Test that load_discriminator can be imported."""
+        from hallucination_reduction.discriminator import load_discriminator
+
+        assert callable(load_discriminator)
+
+    @patch(
+        "hallucination_reduction.discriminator.AutoModelForSequenceClassification.from_pretrained"
+    )
+    @patch("hallucination_reduction.discriminator.AutoTokenizer.from_pretrained")
+    def test_returns_tokenizer_and_model(self, mock_tokenizer, mock_model):
+        """Test that function returns tokenizer and model."""
+        from hallucination_reduction.discriminator import load_discriminator
+
+        mock_tok_instance = MagicMock()
+        mock_model_instance = MagicMock()
+        mock_model_instance.to.return_value = mock_model_instance
+
+        mock_tokenizer.return_value = mock_tok_instance
+        mock_model.return_value = mock_model_instance
+
+        tokenizer, model = load_discriminator()
+
+        assert tokenizer is not None
+        assert model is not None
+
+    @patch(
+        "hallucination_reduction.discriminator.AutoModelForSequenceClassification.from_pretrained"
+    )
+    @patch("hallucination_reduction.discriminator.AutoTokenizer.from_pretrained")
+    def test_uses_default_model_name(self, mock_tokenizer, mock_model):
+        """Test that default model name is used."""
+        from hallucination_reduction.discriminator import DISC_MODEL, load_discriminator
+
+        mock_tok_instance = MagicMock()
+        mock_model_instance = MagicMock()
+        mock_model_instance.to.return_value = mock_model_instance
+
+        mock_tokenizer.return_value = mock_tok_instance
+        mock_model.return_value = mock_model_instance
+
+        load_discriminator()
+
+        mock_tokenizer.assert_called_once_with(DISC_MODEL)
+        mock_model.assert_called_once()
+
+    @patch(
+        "hallucination_reduction.discriminator.AutoModelForSequenceClassification.from_pretrained"
+    )
+    @patch("hallucination_reduction.discriminator.AutoTokenizer.from_pretrained")
+    def test_uses_custom_model_name(self, mock_tokenizer, mock_model):
+        """Test that custom model name is used when provided."""
+        from hallucination_reduction.discriminator import load_discriminator
+
+        custom_model = "bert-base-uncased"
+        mock_tok_instance = MagicMock()
+        mock_model_instance = MagicMock()
+        mock_model_instance.to.return_value = mock_model_instance
+
+        mock_tokenizer.return_value = mock_tok_instance
+        mock_model.return_value = mock_model_instance
+
+        load_discriminator(model_name=custom_model)
+
+        mock_tokenizer.assert_called_once_with(custom_model)
+
+    @patch(
+        "hallucination_reduction.discriminator.AutoModelForSequenceClassification.from_pretrained"
+    )
+    @patch("hallucination_reduction.discriminator.AutoTokenizer.from_pretrained")
+    def test_model_moved_to_device(self, mock_tokenizer, mock_model):
+        """Test that model is moved to the specified device."""
+        from hallucination_reduction.discriminator import load_discriminator
+
+        mock_tok_instance = MagicMock()
+        mock_model_instance = MagicMock()
+        mock_model_instance.to.return_value = mock_model_instance
+
+        mock_tokenizer.return_value = mock_tok_instance
+        mock_model.return_value = mock_model_instance
+
+        custom_device = "cuda:0"
+        load_discriminator(device=custom_device)
+
+        mock_model_instance.to.assert_called_once_with(custom_device)
+
+    @patch(
+        "hallucination_reduction.discriminator.AutoModelForSequenceClassification.from_pretrained"
+    )
+    @patch("hallucination_reduction.discriminator.AutoTokenizer.from_pretrained")
+    def test_model_set_to_eval_mode(self, mock_tokenizer, mock_model):
+        """Test that model is set to eval mode."""
+        from hallucination_reduction.discriminator import load_discriminator
+
+        mock_tok_instance = MagicMock()
+        mock_model_instance = MagicMock()
+        mock_model_instance.to.return_value = mock_model_instance
+
+        mock_tokenizer.return_value = mock_tok_instance
+        mock_model.return_value = mock_model_instance
+
+        _, model = load_discriminator()
+
+        mock_model_instance.eval.assert_called_once()
+
+    @patch(
+        "hallucination_reduction.discriminator.AutoModelForSequenceClassification.from_pretrained"
+    )
+    @patch("hallucination_reduction.discriminator.AutoTokenizer.from_pretrained")
+    def test_num_labels_parameter(self, mock_tokenizer, mock_model):
+        """Test that num_labels parameter is passed correctly."""
+        from hallucination_reduction.discriminator import load_discriminator
+
+        mock_tok_instance = MagicMock()
+        mock_model_instance = MagicMock()
+        mock_model_instance.to.return_value = mock_model_instance
+
+        mock_tokenizer.return_value = mock_tok_instance
+        mock_model.return_value = mock_model_instance
+
+        custom_labels = 3
+        load_discriminator(num_labels=custom_labels)
+
+        call_args = mock_model.call_args
+        assert call_args[1]["num_labels"] == custom_labels
+
+    @patch(
+        "hallucination_reduction.discriminator.AutoModelForSequenceClassification.from_pretrained"
+    )
+    @patch("hallucination_reduction.discriminator.AutoTokenizer.from_pretrained")
+    def test_default_num_labels_is_two(self, mock_tokenizer, mock_model):
+        """Test that default num_labels is 2."""
+        from hallucination_reduction.discriminator import load_discriminator
+
+        mock_tok_instance = MagicMock()
+        mock_model_instance = MagicMock()
+        mock_model_instance.to.return_value = mock_model_instance
+
+        mock_tokenizer.return_value = mock_tok_instance
+        mock_model.return_value = mock_model_instance
+
+        load_discriminator()
+
+        call_args = mock_model.call_args
+        assert call_args[1]["num_labels"] == 2
+
+
+class TestDiscriminatorPredictText:
+    """Test suite for discriminator_predict_text function."""
+
+    @pytest.fixture
+    def mock_classifier(self):
+        """Create a mock classifier."""
+        classifier = MagicMock()
+
+        def mock_forward(**kwargs):
+            # Determine batch size from input
+            batch_size = kwargs.get("input_ids", torch.tensor([[1]])).shape[0]
+            mock_output = MagicMock()
+            mock_output.logits = torch.randn(
+                batch_size, 2
+            )  # Dynamic batch_size, num_classes=2
+            return mock_output
+
+        classifier.side_effect = mock_forward
+        classifier.eval = MagicMock()
+        return classifier
+
+    @pytest.fixture
+    def mock_tokenizer(self):
+        """Create a mock tokenizer."""
+        tokenizer = MagicMock()
+        mock_encoding = {
+            "input_ids": torch.randint(0, 1000, (2, 10)),
+            "attention_mask": torch.ones(2, 10),
+        }
+        mock_encoding_obj = MagicMock()
+        mock_encoding_obj.to.return_value = mock_encoding
+        tokenizer.return_value = mock_encoding_obj
+        return tokenizer
+
+    def test_function_exists(self):
+        """Test that discriminator_predict_text can be imported."""
+        from hallucination_reduction.discriminator import discriminator_predict_text
+
+        assert callable(discriminator_predict_text)
+
+    def test_returns_list(self, mock_classifier, mock_tokenizer):
+        """Test that function returns a list."""
+        from hallucination_reduction.discriminator import discriminator_predict_text
+
+        texts = ["text1", "text2"]
+        result = discriminator_predict_text(mock_classifier, mock_tokenizer, texts)
+
+        assert isinstance(result, list)
+
+    def test_result_contains_pred_and_probs(self, mock_classifier, mock_tokenizer):
+        """Test that each result contains 'pred' and 'probs' keys."""
+        from hallucination_reduction.discriminator import discriminator_predict_text
+
+        texts = ["text1"]
+        result = discriminator_predict_text(mock_classifier, mock_tokenizer, texts)
+
+        assert "pred" in result[0]
+        assert "probs" in result[0]
+
+    def test_pred_is_integer(self, mock_classifier, mock_tokenizer):
+        """Test that prediction is an integer."""
+        from hallucination_reduction.discriminator import discriminator_predict_text
+
+        texts = ["text1"]
+        result = discriminator_predict_text(mock_classifier, mock_tokenizer, texts)
+
+        assert isinstance(result[0]["pred"], int)
+
+    def test_probs_is_list(self, mock_classifier, mock_tokenizer):
+        """Test that probabilities is a list."""
+        from hallucination_reduction.discriminator import discriminator_predict_text
+
+        texts = ["text1"]
+        result = discriminator_predict_text(mock_classifier, mock_tokenizer, texts)
+
+        assert isinstance(result[0]["probs"], list)
+
+    def test_classifier_set_to_eval_mode(self, mock_classifier, mock_tokenizer):
+        """Test that classifier is set to eval mode."""
+        from hallucination_reduction.discriminator import discriminator_predict_text
+
+        texts = ["text1"]
+        discriminator_predict_text(mock_classifier, mock_tokenizer, texts)
+
+        mock_classifier.eval.assert_called()
+
+    def test_tokenizer_called_with_texts(self, mock_classifier, mock_tokenizer):
+        """Test that tokenizer is called with input texts."""
+        from hallucination_reduction.discriminator import discriminator_predict_text
+
+        texts = ["text1", "text2"]
+        discriminator_predict_text(mock_classifier, mock_tokenizer, texts)
+
+        # Tokenizer should be called at least once
+        assert mock_tokenizer.call_count >= 1
+
+    def test_tokenizer_uses_padding_and_truncation(
+        self, mock_classifier, mock_tokenizer
+    ):
+        """Test that tokenizer uses padding and truncation."""
+        from hallucination_reduction.discriminator import discriminator_predict_text
+
+        texts = ["text1"]
+        discriminator_predict_text(mock_classifier, mock_tokenizer, texts)
+
+        call_kwargs = mock_tokenizer.call_args[1]
+        assert call_kwargs.get("padding") is True
+        assert call_kwargs.get("truncation") is True
+
+    def test_handles_empty_text_list(self, mock_classifier, mock_tokenizer):
+        """Test that function handles empty text list."""
+        from hallucination_reduction.discriminator import discriminator_predict_text
+
+        texts = []
+        result = discriminator_predict_text(mock_classifier, mock_tokenizer, texts)
+
+        assert result == []
+
+    def test_batch_size_parameter(self, mock_classifier, mock_tokenizer):
+        """Test that batch_size parameter affects processing."""
+        from hallucination_reduction.discriminator import discriminator_predict_text
+
+        texts = ["text1", "text2", "text3", "text4"]
+        batch_size = 2
+
+        result = discriminator_predict_text(
+            mock_classifier, mock_tokenizer, texts, batch_size=batch_size
+        )
+
+        # Should return results for all texts
+        assert len(result) == len(texts)
+
+    def test_uses_no_grad_context(self, mock_classifier, mock_tokenizer):
+        """Test that predictions are made with torch.no_grad()."""
+        from hallucination_reduction.discriminator import discriminator_predict_text
+
+        texts = ["text1"]
+
+        with patch("torch.no_grad") as mock_no_grad:
+            mock_no_grad.return_value.__enter__ = Mock()
+            mock_no_grad.return_value.__exit__ = Mock()
+
+            discriminator_predict_text(mock_classifier, mock_tokenizer, texts)
+
+            # no_grad should be called
+            mock_no_grad.assert_called()
+
+
+class TestSimpleTextDataset:
+    """Test suite for SimpleTextDataset class."""
+
+    @pytest.fixture
+    def mock_tokenizer(self):
+        """Create a mock tokenizer."""
+        tokenizer = MagicMock()
+        tokenizer.return_value = {
+            "input_ids": torch.tensor([[1, 2, 3]]),
+            "attention_mask": torch.tensor([[1, 1, 1]]),
+        }
+        return tokenizer
+
+    @pytest.fixture
+    def sample_data(self):
+        """Create sample data."""
+        texts = ["text1", "text2", "text3"]
+        labels = [0, 1, 0]
+        return texts, labels
+
+    def test_class_exists(self):
+        """Test that SimpleTextDataset class can be imported."""
+        from hallucination_reduction.discriminator import SimpleTextDataset
+
+        assert SimpleTextDataset is not None
+
+    def test_initialization(self, mock_tokenizer, sample_data):
+        """Test dataset initialization."""
+        from hallucination_reduction.discriminator import SimpleTextDataset
+
+        texts, labels = sample_data
+        dataset = SimpleTextDataset(texts, labels, mock_tokenizer)
+
+        assert dataset is not None
+        assert dataset.texts == texts
+        assert dataset.labels == labels
+
+    def test_len_returns_correct_length(self, mock_tokenizer, sample_data):
+        """Test that __len__ returns correct length."""
+        from hallucination_reduction.discriminator import SimpleTextDataset
+
+        texts, labels = sample_data
+        dataset = SimpleTextDataset(texts, labels, mock_tokenizer)
+
+        assert len(dataset) == len(texts)
+
+    def test_getitem_returns_dict(self, mock_tokenizer, sample_data):
+        """Test that __getitem__ returns a dictionary."""
+        from hallucination_reduction.discriminator import SimpleTextDataset
+
+        texts, labels = sample_data
+        dataset = SimpleTextDataset(texts, labels, mock_tokenizer)
+
+        item = dataset[0]
+        assert isinstance(item, dict)
+
+    def test_getitem_contains_labels(self, mock_tokenizer, sample_data):
+        """Test that returned item contains 'labels' key."""
+        from hallucination_reduction.discriminator import SimpleTextDataset
+
+        texts, labels = sample_data
+        dataset = SimpleTextDataset(texts, labels, mock_tokenizer)
+
+        item = dataset[0]
+        assert "labels" in item
+
+    def test_labels_are_tensors(self, mock_tokenizer, sample_data):
+        """Test that labels are PyTorch tensors."""
+        from hallucination_reduction.discriminator import SimpleTextDataset
+
+        texts, labels = sample_data
+        dataset = SimpleTextDataset(texts, labels, mock_tokenizer)
+
+        item = dataset[0]
+        assert isinstance(item["labels"], torch.Tensor)
+
+    def test_labels_have_correct_dtype(self, mock_tokenizer, sample_data):
+        """Test that labels have dtype long."""
+        from hallucination_reduction.discriminator import SimpleTextDataset
+
+        texts, labels = sample_data
+        dataset = SimpleTextDataset(texts, labels, mock_tokenizer)
+
+        item = dataset[0]
+        assert item["labels"].dtype == torch.long
+
+    def test_correct_label_returned(self, mock_tokenizer, sample_data):
+        """Test that correct label is returned for each index."""
+        from hallucination_reduction.discriminator import SimpleTextDataset
+
+        texts, labels = sample_data
+        dataset = SimpleTextDataset(texts, labels, mock_tokenizer)
+
+        for idx in range(len(labels)):
+            item = dataset[idx]
+            assert item["labels"].item() == labels[idx]
+
+    def test_tokenizer_called_with_correct_text(self, mock_tokenizer, sample_data):
+        """Test that tokenizer is called with correct text."""
+        from hallucination_reduction.discriminator import SimpleTextDataset
+
+        texts, labels = sample_data
+        dataset = SimpleTextDataset(texts, labels, mock_tokenizer)
+
+        _ = dataset[1]
+
+        # Check that tokenizer was called with the second text
+        call_args = mock_tokenizer.call_args[0]
+        assert call_args[0] == texts[1]
+
+    def test_tokenizer_uses_truncation(self, mock_tokenizer, sample_data):
+        """Test that tokenizer uses truncation."""
+        from hallucination_reduction.discriminator import SimpleTextDataset
+
+        texts, labels = sample_data
+        dataset = SimpleTextDataset(texts, labels, mock_tokenizer)
+
+        _ = dataset[0]
+
+        call_kwargs = mock_tokenizer.call_args[1]
+        assert call_kwargs.get("truncation") is True
+
+    def test_tokenizer_uses_padding(self, mock_tokenizer, sample_data):
+        """Test that tokenizer uses padding."""
+        from hallucination_reduction.discriminator import SimpleTextDataset
+
+        texts, labels = sample_data
+        dataset = SimpleTextDataset(texts, labels, mock_tokenizer)
+
+        _ = dataset[0]
+
+        call_kwargs = mock_tokenizer.call_args[1]
+        assert call_kwargs.get("padding") == "max_length"
+
+    def test_custom_max_length(self, mock_tokenizer, sample_data):
+        """Test that custom max_length is used."""
+        from hallucination_reduction.discriminator import SimpleTextDataset
+
+        texts, labels = sample_data
+        custom_max_length = 128
+        dataset = SimpleTextDataset(
+            texts, labels, mock_tokenizer, max_length=custom_max_length
+        )
+
+        _ = dataset[0]
+
+        call_kwargs = mock_tokenizer.call_args[1]
+        assert call_kwargs.get("max_length") == custom_max_length
+
+    def test_default_max_length_is_256(self, mock_tokenizer, sample_data):
+        """Test that default max_length is 256."""
+        from hallucination_reduction.discriminator import SimpleTextDataset
+
+        texts, labels = sample_data
+        dataset = SimpleTextDataset(texts, labels, mock_tokenizer)
+
+        assert dataset.max_length == 256
+
+    def test_all_indices_accessible(self, mock_tokenizer, sample_data):
+        """Test that all indices can be accessed."""
+        from hallucination_reduction.discriminator import SimpleTextDataset
+
+        texts, labels = sample_data
+        dataset = SimpleTextDataset(texts, labels, mock_tokenizer)
+
+        for idx in range(len(dataset)):
+            item = dataset[idx]
+            assert item is not None
+
+    def test_dataset_is_iterable(self, mock_tokenizer, sample_data):
+        """Test that dataset can be used with DataLoader."""
+        from torch.utils.data import DataLoader
+
+        from hallucination_reduction.discriminator import SimpleTextDataset
+
+        texts, labels = sample_data
+        dataset = SimpleTextDataset(texts, labels, mock_tokenizer)
+
+        # Should be able to create a DataLoader
+        dataloader = DataLoader(dataset, batch_size=2)
+        assert dataloader is not None
diff --git a/tests/unit/test_discriminator_training_utils.py b/tests/unit/test_discriminator_training_utils.py
new file mode 100644
index 0000000..236de23
--- /dev/null
+++ b/tests/unit/test_discriminator_training_utils.py
@@ -0,0 +1,329 @@
+from unittest.mock import MagicMock, patch
+
+import pytest
+
+
+class TestEvaluateClassifier:
+    """Test suite for evaluate_classifier function."""
+
+    @pytest.fixture
+    def mock_classifier(self):
+        """Create a mock classifier."""
+        classifier = MagicMock()
+        return classifier
+
+    @pytest.fixture
+    def mock_tokenizer(self):
+        """Create a mock tokenizer."""
+        return MagicMock()
+
+    @pytest.fixture
+    def sample_eval_data(self):
+        """Create sample evaluation data."""
+        texts = ["text1", "text2", "text3", "text4"]
+        labels = [1, 0, 1, 0]
+        return texts, labels
+
+    def test_evaluate_returns_dict(
+        self, mock_classifier, mock_tokenizer, sample_eval_data
+    ):
+        """Test that evaluate_classifier returns a dictionary."""
+        from hallucination_reduction.discriminator_training_utils import (
+            evaluate_classifier,
+        )
+
+        texts, labels = sample_eval_data
+
+        with patch(
+            "hallucination_reduction.discriminator_training_utils.discriminator_predict_text"
+        ) as mock_predict:
+            mock_predict.return_value = [{"probs": [0.3, 0.7]}]
+
+            result = evaluate_classifier(mock_classifier, mock_tokenizer, texts, labels)
+
+            assert isinstance(result, dict)
+
+    def test_evaluate_returns_all_metrics(
+        self, mock_classifier, mock_tokenizer, sample_eval_data
+    ):
+        """Test that all required metrics are returned."""
+        from hallucination_reduction.discriminator_training_utils import (
+            evaluate_classifier,
+        )
+
+        texts, labels = sample_eval_data
+
+        with patch(
+            "hallucination_reduction.discriminator_training_utils.discriminator_predict_text"
+        ) as mock_predict:
+            mock_predict.return_value = [{"probs": [0.3, 0.7]}]
+
+            result = evaluate_classifier(mock_classifier, mock_tokenizer, texts, labels)
+
+            assert "acc" in result
+            assert "prec" in result
+            assert "rec" in result
+            assert "f1" in result
+
+    def test_classifier_set_to_eval_mode(
+        self, mock_classifier, mock_tokenizer, sample_eval_data
+    ):
+        """Test that classifier is set to eval mode."""
+        from hallucination_reduction.discriminator_training_utils import (
+            evaluate_classifier,
+        )
+
+        texts, labels = sample_eval_data
+
+        with patch(
+            "hallucination_reduction.discriminator_training_utils.discriminator_predict_text"
+        ) as mock_predict:
+            mock_predict.return_value = [{"probs": [0.3, 0.7]}]
+
+            evaluate_classifier(mock_classifier, mock_tokenizer, texts, labels)
+
+            mock_classifier.eval.assert_called()
+
+    def test_accuracy_calculated_correctly(
+        self, mock_classifier, mock_tokenizer, sample_eval_data
+    ):
+        """Test that accuracy is calculated using sklearn."""
+        from hallucination_reduction.discriminator_training_utils import (
+            evaluate_classifier,
+        )
+
+        texts, labels = sample_eval_data
+
+        with patch(
+            "hallucination_reduction.discriminator_training_utils.discriminator_predict_text"
+        ) as mock_predict:
+            mock_predict.return_value = [{"probs": [0.3, 0.7]}]
+
+            with patch(
+                "hallucination_reduction.discriminator_training_utils.accuracy_score"
+            ) as mock_acc:
+                mock_acc.return_value = 0.75
+
+                result = evaluate_classifier(
+                    mock_classifier, mock_tokenizer, texts, labels
+                )
+
+                mock_acc.assert_called_once()
+                assert result["acc"] == 0.75
+
+    def test_precision_recall_f1_calculated(
+        self, mock_classifier, mock_tokenizer, sample_eval_data
+    ):
+        """Test that precision, recall, and F1 are calculated."""
+        from hallucination_reduction.discriminator_training_utils import (
+            evaluate_classifier,
+        )
+
+        texts, labels = sample_eval_data
+
+        with patch(
+            "hallucination_reduction.discriminator_training_utils.discriminator_predict_text"
+        ) as mock_predict:
+            mock_predict.return_value = [{"probs": [0.3, 0.7]}]
+
+            with patch(
+                "hallucination_reduction.discriminator_training_utils.precision_recall_fscore_support"
+            ) as mock_prf:
+                mock_prf.return_value = (0.8, 0.75, 0.77, None)
+
+                result = evaluate_classifier(
+                    mock_classifier, mock_tokenizer, texts, labels
+                )
+
+                mock_prf.assert_called_once()
+                assert result["prec"] == 0.8
+                assert result["rec"] == 0.75
+                assert result["f1"] == 0.77
+
+    def test_binary_average_used_for_metrics(
+        self, mock_classifier, mock_tokenizer, sample_eval_data
+    ):
+        """Test that binary averaging is used for precision/recall/F1."""
+        from hallucination_reduction.discriminator_training_utils import (
+            evaluate_classifier,
+        )
+
+        texts, labels = sample_eval_data
+
+        with patch(
+            "hallucination_reduction.discriminator_training_utils.discriminator_predict_text"
+        ) as mock_predict:
+            mock_predict.return_value = [{"probs": [0.3, 0.7]}]
+
+            with patch(
+                "hallucination_reduction.discriminator_training_utils.precision_recall_fscore_support"
+            ) as mock_prf:
+                mock_prf.return_value = (0.8, 0.75, 0.77, None)
+
+                evaluate_classifier(mock_classifier, mock_tokenizer, texts, labels)
+
+                call_args = mock_prf.call_args
+                assert call_args[1]["average"] == "binary"
+
+    def test_zero_division_handled(
+        self, mock_classifier, mock_tokenizer, sample_eval_data
+    ):
+        """Test that zero division is handled in metrics."""
+        from hallucination_reduction.discriminator_training_utils import (
+            evaluate_classifier,
+        )
+
+        texts, labels = sample_eval_data
+
+        with patch(
+            "hallucination_reduction.discriminator_training_utils.discriminator_predict_text"
+        ) as mock_predict:
+            mock_predict.return_value = [{"probs": [0.3, 0.7]}]
+
+            with patch(
+                "hallucination_reduction.discriminator_training_utils.precision_recall_fscore_support"
+            ) as mock_prf:
+                mock_prf.return_value = (0.8, 0.75, 0.77, None)
+
+                evaluate_classifier(mock_classifier, mock_tokenizer, texts, labels)
+
+                call_args = mock_prf.call_args
+                assert call_args[1]["zero_division"] == 0
+
+    def test_handles_empty_labels(self, mock_classifier, mock_tokenizer):
+        """Test handling of empty labels list."""
+        from hallucination_reduction.discriminator_training_utils import (
+            evaluate_classifier,
+        )
+
+        texts = []
+        labels = []
+
+        with patch(
+            "hallucination_reduction.discriminator_training_utils.discriminator_predict_text"
+        ) as mock_predict:
+            mock_predict.return_value = [{"probs": [0.3, 0.7]}]
+
+            result = evaluate_classifier(mock_classifier, mock_tokenizer, texts, labels)
+
+            assert result["acc"] == 0.0
+
+    def test_prediction_threshold_05(self, mock_classifier, mock_tokenizer):
+        """Test that prediction threshold is 0.5."""
+        from hallucination_reduction.discriminator_training_utils import (
+            evaluate_classifier,
+        )
+
+        texts = ["text1", "text2"]
+        labels = [1, 0]
+
+        with patch(
+            "hallucination_reduction.discriminator_training_utils.discriminator_predict_text"
+        ) as mock_predict:
+            # Return probabilities just above and below threshold
+            mock_predict.side_effect = [
+                [{"probs": [0.4, 0.6]}],  # Should predict 1
+                [{"probs": [0.6, 0.4]}],  # Should predict 0
+            ]
+
+            with patch(
+                "hallucination_reduction.discriminator_training_utils.accuracy_score"
+            ) as mock_acc:
+                mock_acc.return_value = 1.0
+
+                evaluate_classifier(mock_classifier, mock_tokenizer, texts, labels)
+
+                # Check that predictions were made correctly
+                pred_calls = mock_acc.call_args[0]
+                assert len(pred_calls) == 2  # labels and predictions
+
+    def test_evaluates_all_texts(self, mock_classifier, mock_tokenizer):
+        """Test that all texts are evaluated."""
+        from hallucination_reduction.discriminator_training_utils import (
+            evaluate_classifier,
+        )
+
+        texts = ["text1", "text2", "text3", "text4", "text5"]
+        labels = [1, 0, 1, 0, 1]
+
+        with patch(
+            "hallucination_reduction.discriminator_training_utils.discriminator_predict_text"
+        ) as mock_predict:
+            mock_predict.return_value = [{"probs": [0.3, 0.7]}]
+
+            evaluate_classifier(mock_classifier, mock_tokenizer, texts, labels)
+
+            # Should be called once per text
+            assert mock_predict.call_count == len(texts)
+
+    def test_metrics_are_numeric(
+        self, mock_classifier, mock_tokenizer, sample_eval_data
+    ):
+        """Test that all metrics are numeric values."""
+        from hallucination_reduction.discriminator_training_utils import (
+            evaluate_classifier,
+        )
+
+        texts, labels = sample_eval_data
+
+        with patch(
+            "hallucination_reduction.discriminator_training_utils.discriminator_predict_text"
+        ) as mock_predict:
+            mock_predict.return_value = [{"probs": [0.3, 0.7]}]
+
+            result = evaluate_classifier(mock_classifier, mock_tokenizer, texts, labels)
+
+            assert isinstance(result["acc"], (int, float))
+            assert isinstance(result["prec"], (int, float))
+            assert isinstance(result["rec"], (int, float))
+            assert isinstance(result["f1"], (int, float))
+
+    def test_handles_two_class_probabilities(self, mock_classifier, mock_tokenizer):
+        """Test normal case with two-class probabilities."""
+        from hallucination_reduction.discriminator_training_utils import (
+            evaluate_classifier,
+        )
+
+        texts = ["text1"]
+        labels = [1]
+
+        with patch(
+            "hallucination_reduction.discriminator_training_utils.discriminator_predict_text"
+        ) as mock_predict:
+            # Return proper two-class probabilities
+            mock_predict.return_value = [{"probs": [0.3, 0.7]}]
+
+            result = evaluate_classifier(mock_classifier, mock_tokenizer, texts, labels)
+
+            # Should handle gracefully
+            assert isinstance(result, dict)
+            assert "acc" in result
+
+
+class TestTrainDiscriminatorMinibatchIntegration:
+    """Integration tests for train_discriminator_minibatch that verify behavior without deep mocking."""
+
+    def test_function_exists_and_callable(self):
+        """Test that the function can be imported."""
+        from hallucination_reduction.discriminator_training_utils import (
+            train_discriminator_minibatch,
+        )
+
+        assert callable(train_discriminator_minibatch)
+
+    def test_function_signature(self):
+        """Test that the function has expected parameters."""
+        import inspect
+
+        from hallucination_reduction.discriminator_training_utils import (
+            train_discriminator_minibatch,
+        )
+
+        sig = inspect.signature(train_discriminator_minibatch)
+        params = list(sig.parameters.keys())
+
+        # Check for expected parameters
+        assert "classifier" in params
+        assert "tokenizer" in params
+        assert "texts" in params
+        assert "labels" in params
diff --git a/tests/unit/test_evaluation.py b/tests/unit/test_evaluation.py
new file mode 100644
index 0000000..dffa134
--- /dev/null
+++ b/tests/unit/test_evaluation.py
@@ -0,0 +1,525 @@
+from unittest.mock import MagicMock, patch
+
+import pytest
+
+from hallucination_reduction.evaluation import (
+    evaluate_classifier,
+    evaluate_old_vs_new_generator,
+    exact_match,
+    f1_score,
+    overlap_fact_check,
+)
+
+
+class TestExactMatch:
+    """Test suite for exact_match function."""
+
+    def test_function_exists(self):
+        """Test that exact_match can be imported."""
+        assert callable(exact_match)
+
+    def test_identical_strings_return_one(self):
+        """Test that identical strings return 1."""
+        result = exact_match("hello", "hello")
+        assert result == 1
+
+    def test_different_strings_return_zero(self):
+        """Test that different strings return 0."""
+        result = exact_match("hello", "world")
+        assert result == 0
+
+    def test_case_insensitive_matching(self):
+        """Test that matching is case insensitive."""
+        result = exact_match("Hello", "hello")
+        assert result == 1
+
+        result = exact_match("HELLO", "hello")
+        assert result == 1
+
+    def test_strips_whitespace(self):
+        """Test that whitespace is stripped before comparison."""
+        result = exact_match("  hello  ", "hello")
+        assert result == 1
+
+        result = exact_match("hello", "  hello  ")
+        assert result == 1
+
+    def test_whitespace_and_case_combined(self):
+        """Test that both whitespace stripping and case insensitivity work together."""
+        result = exact_match("  Hello World  ", "hello world")
+        assert result == 1
+
+    def test_empty_strings_match(self):
+        """Test that empty strings match."""
+        result = exact_match("", "")
+        assert result == 1
+
+    def test_empty_vs_non_empty_no_match(self):
+        """Test that empty and non-empty strings don't match."""
+        result = exact_match("", "hello")
+        assert result == 0
+
+        result = exact_match("hello", "")
+        assert result == 0
+
+    def test_return_type_is_int(self):
+        """Test that return type is int."""
+        result = exact_match("hello", "hello")
+        assert isinstance(result, int)
+
+
+class TestF1Score:
+    """Test suite for f1_score function."""
+
+    def test_function_exists(self):
+        """Test that f1_score can be imported."""
+        assert callable(f1_score)
+
+    def test_identical_strings_return_one(self):
+        """Test that identical strings return 1.0."""
+        result = f1_score("hello world", "hello world")
+        assert result == 1.0
+
+    def test_no_overlap_returns_zero(self):
+        """Test that completely different strings return 0.0."""
+        result = f1_score("hello world", "foo bar")
+        assert result == 0.0
+
+    def test_partial_overlap(self):
+        """Test F1 score with partial overlap."""
+        result = f1_score("hello world", "hello foo")
+        assert result == 0.5
+
+    def test_subset_prediction(self):
+        """Test F1 when prediction is subset of gold."""
+        result = f1_score("hello", "hello world")
+        assert abs(result - 0.6666666666666666) < 0.001
+
+    def test_superset_prediction(self):
+        """Test F1 when prediction is superset of gold."""
+        result = f1_score("hello world", "hello")
+        assert abs(result - 0.6666666666666666) < 0.001
+
+    def test_empty_prediction_returns_zero(self):
+        """Test that empty prediction returns 0.0."""
+        result = f1_score("", "hello world")
+        assert result == 0.0
+
+    def test_empty_gold_returns_zero(self):
+        """Test that empty gold returns 0.0."""
+        result = f1_score("hello world", "")
+        assert result == 0.0
+
+    def test_both_empty_returns_zero(self):
+        """Test that both empty returns 0.0."""
+        result = f1_score("", "")
+        assert result == 0.0
+
+    def test_repeated_tokens_counted_correctly(self):
+        """Test that repeated tokens are counted correctly."""
+        result = f1_score("hello hello", "hello")
+        assert abs(result - 0.6666666666666666) < 0.001
+
+    def test_return_type_is_float(self):
+        """Test that return type is float."""
+        result = f1_score("hello", "hello")
+        assert isinstance(result, float)
+
+    def test_symmetric_with_duplicate_tokens(self):
+        """Test behavior with duplicate tokens."""
+        result = f1_score("the the cat", "the cat cat")
+        assert abs(result - 0.6666666666666666) < 0.001
+
+
+class TestOverlapFactCheck:
+    """Test suite for overlap_fact_check function."""
+
+    def test_function_exists(self):
+        """Test that overlap_fact_check can be imported."""
+        assert callable(overlap_fact_check)
+
+    def test_complete_overlap_returns_one(self):
+        """Test that complete overlap returns 1.0."""
+        answer = "hello world"
+        passages = ["hello world"]
+        result = overlap_fact_check(answer, passages)
+        assert result == 1.0
+
+    def test_no_overlap_returns_zero(self):
+        """Test that no overlap returns 0.0."""
+        answer = "hello world"
+        passages = ["foo bar"]
+        result = overlap_fact_check(answer, passages)
+        assert result == 0.0
+
+    def test_partial_overlap(self):
+        """Test partial overlap calculation."""
+        answer = "hello world"
+        passages = ["hello foo"]
+        result = overlap_fact_check(answer, passages)
+        assert result == 0.5
+
+    def test_multiple_passages_averaged(self):
+        """Test that multiple passages are averaged."""
+        answer = "hello world"
+        passages = ["hello world", "hello foo"]
+        result = overlap_fact_check(answer, passages)
+        assert result == 0.75
+
+    def test_empty_passages_returns_zero(self):
+        """Test that empty passages list returns 0.0."""
+        answer = "hello world"
+        passages = []
+        result = overlap_fact_check(answer, passages)
+        assert result == 0.0
+
+    def test_empty_answer_returns_zero(self):
+        """Test that empty answer returns 0.0."""
+        answer = ""
+        passages = ["hello world"]
+        result = overlap_fact_check(answer, passages)
+        assert result == 0.0
+
+    def test_empty_passage_returns_zero(self):
+        """Test that empty passage returns 0.0 for that passage."""
+        answer = "hello world"
+        passages = [""]
+        result = overlap_fact_check(answer, passages)
+        assert result == 0.0
+
+    def test_case_insensitive_matching(self):
+        """Test that matching is case insensitive."""
+        answer = "Hello World"
+        passages = ["hello world"]
+        result = overlap_fact_check(answer, passages)
+        assert result == 1.0
+
+    def test_superset_answer(self):
+        """Test when answer is superset of passage."""
+        answer = "hello world foo bar"
+        passages = ["hello world"]
+        result = overlap_fact_check(answer, passages)
+        assert result == 1.0
+
+    def test_subset_answer(self):
+        """Test when answer is subset of passage."""
+        answer = "hello"
+        passages = ["hello world foo"]
+        result = overlap_fact_check(answer, passages)
+        assert abs(result - 0.3333333333333333) < 0.001
+
+    def test_return_type_is_float(self):
+        """Test that return type is float."""
+        result = overlap_fact_check("hello", ["world"])
+        assert isinstance(result, float)
+
+    def test_return_value_in_range(self):
+        """Test that return value is in [0, 1] range."""
+        answer = "hello world"
+        passages = ["foo bar baz"]
+        result = overlap_fact_check(answer, passages)
+        assert 0.0 <= result <= 1.0
+
+
+class TestEvaluateOldVsNewGenerator:
+    """Test suite for evaluate_old_vs_new_generator function."""
+
+    @pytest.fixture
+    def mock_qa_pair(self):
+        """Create a mock QA pair."""
+        qa = MagicMock()
+        qa.question = "What is Python?"
+        qa.answer = "A programming language"
+        qa.supporting_passages = ["Python is a programming language"]
+        return qa
+
+    @pytest.fixture
+    def mock_generators(self):
+        """Create mock generator models."""
+        old_gen = MagicMock()
+        new_gen = MagicMock()
+        return old_gen, new_gen
+
+    @pytest.fixture
+    def mock_tokenizer(self):
+        """Create a mock tokenizer."""
+        return MagicMock()
+
+    @pytest.fixture
+    def mock_retriever(self):
+        """Create a mock retriever."""
+        retriever = MagicMock()
+        retriever.retrieve.return_value = [(0, "Retrieved passage")]
+        return retriever
+
+    @pytest.fixture
+    def mock_fact_disc_and_tok(self):
+        """Create mock fact discriminator and tokenizer."""
+        fact_disc = MagicMock()
+        fact_tok = MagicMock()
+        return fact_disc, fact_tok
+
+    def test_function_exists(self):
+        """Test that evaluate_old_vs_new_generator can be imported."""
+        assert callable(evaluate_old_vs_new_generator)
+
+    def test_returns_three_items(
+        self,
+        mock_generators,
+        mock_tokenizer,
+        mock_retriever,
+        mock_fact_disc_and_tok,
+        mock_qa_pair,
+    ):
+        """Test that function returns three items."""
+        old_gen, new_gen = mock_generators
+        fact_disc, fact_tok = mock_fact_disc_and_tok
+
+        with patch("hallucination_reduction.evaluation.generate_answer") as mock_gen:
+            mock_gen.return_value = ["Generated answer"]
+
+            with patch(
+                "hallucination_reduction.evaluation.discriminator_predict_text"
+            ) as mock_pred:
+                mock_pred.return_value = [{"probs": [0.3, 0.7]}]
+
+                result = evaluate_old_vs_new_generator(
+                    old_gen,
+                    new_gen,
+                    mock_tokenizer,
+                    mock_retriever,
+                    [mock_qa_pair],
+                    fact_disc,
+                    fact_tok,
+                )
+
+                assert len(result) == 3
+
+    def test_returns_rows_old_summary_new_summary(
+        self,
+        mock_generators,
+        mock_tokenizer,
+        mock_retriever,
+        mock_fact_disc_and_tok,
+        mock_qa_pair,
+    ):
+        """Test that function returns rows, old_summary, new_summary."""
+        old_gen, new_gen = mock_generators
+        fact_disc, fact_tok = mock_fact_disc_and_tok
+
+        with patch("hallucination_reduction.evaluation.generate_answer") as mock_gen:
+            mock_gen.return_value = ["Generated answer"]
+
+            with patch(
+                "hallucination_reduction.evaluation.discriminator_predict_text"
+            ) as mock_pred:
+                mock_pred.return_value = [{"probs": [0.3, 0.7]}]
+
+                rows, old_summary, new_summary = evaluate_old_vs_new_generator(
+                    old_gen,
+                    new_gen,
+                    mock_tokenizer,
+                    mock_retriever,
+                    [mock_qa_pair],
+                    fact_disc,
+                    fact_tok,
+                )
+
+                assert isinstance(rows, list)
+                assert isinstance(old_summary, dict)
+                assert isinstance(new_summary, dict)
+
+    def test_summaries_contain_required_keys(
+        self,
+        mock_generators,
+        mock_tokenizer,
+        mock_retriever,
+        mock_fact_disc_and_tok,
+        mock_qa_pair,
+    ):
+        """Test that summaries contain required metric keys."""
+        old_gen, new_gen = mock_generators
+        fact_disc, fact_tok = mock_fact_disc_and_tok
+
+        with patch("hallucination_reduction.evaluation.generate_answer") as mock_gen:
+            mock_gen.return_value = ["Generated answer"]
+
+            with patch(
+                "hallucination_reduction.evaluation.discriminator_predict_text"
+            ) as mock_pred:
+                mock_pred.return_value = [{"probs": [0.3, 0.7]}]
+
+                _, old_summary, new_summary = evaluate_old_vs_new_generator(
+                    old_gen,
+                    new_gen,
+                    mock_tokenizer,
+                    mock_retriever,
+                    [mock_qa_pair],
+                    fact_disc,
+                    fact_tok,
+                )
+
+                assert "exact_match_rate" in old_summary
+                assert "avg_f1" in old_summary
+                assert "hallucination_rate" in old_summary
+
+                assert "exact_match_rate" in new_summary
+                assert "avg_f1" in new_summary
+                assert "hallucination_rate" in new_summary
+
+    def test_rows_contain_question_gold_old_new(
+        self,
+        mock_generators,
+        mock_tokenizer,
+        mock_retriever,
+        mock_fact_disc_and_tok,
+        mock_qa_pair,
+    ):
+        """Test that rows contain question, gold, old, new keys."""
+        old_gen, new_gen = mock_generators
+        fact_disc, fact_tok = mock_fact_disc_and_tok
+
+        with patch("hallucination_reduction.evaluation.generate_answer") as mock_gen:
+            mock_gen.return_value = ["Generated answer"]
+
+            with patch(
+                "hallucination_reduction.evaluation.discriminator_predict_text"
+            ) as mock_pred:
+                mock_pred.return_value = [{"probs": [0.3, 0.7]}]
+
+                rows, _, _ = evaluate_old_vs_new_generator(
+                    old_gen,
+                    new_gen,
+                    mock_tokenizer,
+                    mock_retriever,
+                    [mock_qa_pair],
+                    fact_disc,
+                    fact_tok,
+                )
+
+                assert len(rows) > 0
+                row = rows[0]
+                assert "question" in row
+                assert "gold" in row
+                assert "old" in row
+                assert "new" in row
+
+    def test_retriever_called_for_each_qa(
+        self,
+        mock_generators,
+        mock_tokenizer,
+        mock_retriever,
+        mock_fact_disc_and_tok,
+        mock_qa_pair,
+    ):
+        """Test that retriever is called for each QA pair."""
+        old_gen, new_gen = mock_generators
+        fact_disc, fact_tok = mock_fact_disc_and_tok
+
+        qa_pairs = [mock_qa_pair, mock_qa_pair, mock_qa_pair]
+
+        with patch("hallucination_reduction.evaluation.generate_answer") as mock_gen:
+            mock_gen.return_value = ["Generated answer"]
+
+            with patch(
+                "hallucination_reduction.evaluation.discriminator_predict_text"
+            ) as mock_pred:
+                mock_pred.return_value = [{"probs": [0.3, 0.7]}]
+
+                evaluate_old_vs_new_generator(
+                    old_gen,
+                    new_gen,
+                    mock_tokenizer,
+                    mock_retriever,
+                    qa_pairs,
+                    fact_disc,
+                    fact_tok,
+                )
+
+                assert mock_retriever.retrieve.call_count == len(qa_pairs)
+
+    def test_generate_answer_called_twice_per_qa(
+        self,
+        mock_generators,
+        mock_tokenizer,
+        mock_retriever,
+        mock_fact_disc_and_tok,
+        mock_qa_pair,
+    ):
+        """Test that generate_answer is called twice per QA (old and new)."""
+        old_gen, new_gen = mock_generators
+        fact_disc, fact_tok = mock_fact_disc_and_tok
+
+        with patch("hallucination_reduction.evaluation.generate_answer") as mock_gen:
+            mock_gen.return_value = ["Generated answer"]
+
+            with patch(
+                "hallucination_reduction.evaluation.discriminator_predict_text"
+            ) as mock_pred:
+                mock_pred.return_value = [{"probs": [0.3, 0.7]}]
+
+                evaluate_old_vs_new_generator(
+                    old_gen,
+                    new_gen,
+                    mock_tokenizer,
+                    mock_retriever,
+                    [mock_qa_pair],
+                    fact_disc,
+                    fact_tok,
+                )
+
+                # Should be called twice: once for old_gen, once for new_gen
+                assert mock_gen.call_count == 2
+
+    def test_metrics_rates_between_zero_and_one(
+        self,
+        mock_generators,
+        mock_tokenizer,
+        mock_retriever,
+        mock_fact_disc_and_tok,
+        mock_qa_pair,
+    ):
+        """Test that all metric rates are between 0 and 1."""
+        old_gen, new_gen = mock_generators
+        fact_disc, fact_tok = mock_fact_disc_and_tok
+
+        with patch("hallucination_reduction.evaluation.generate_answer") as mock_gen:
+            mock_gen.return_value = ["Generated answer"]
+
+            with patch(
+                "hallucination_reduction.evaluation.discriminator_predict_text"
+            ) as mock_pred:
+                mock_pred.return_value = [{"probs": [0.3, 0.7]}]
+
+                _, old_summary, new_summary = evaluate_old_vs_new_generator(
+                    old_gen,
+                    new_gen,
+                    mock_tokenizer,
+                    mock_retriever,
+                    [mock_qa_pair],
+                    fact_disc,
+                    fact_tok,
+                )
+
+                for summary in [old_summary, new_summary]:
+                    assert 0.0 <= summary["exact_match_rate"] <= 1.0
+                    assert 0.0 <= summary["avg_f1"] <= 1.0
+                    assert 0.0 <= summary["hallucination_rate"] <= 1.0
+
+
+class TestEvaluateClassifier:
+    """Test suite for evaluate_classifier function (from evaluation)."""
+
+    @pytest.fixture
+    def mock_classifier(self):
+        """Create a mock classifier."""
+        return MagicMock()
+
+    @pytest.fixture
+    def mock_tokenizer(self):
+        """Create a mock tokenizer."""
+        return MagicMock()
+
+    def test_function_exists(self):
+        """Test that evaluate_classifier can be imported."""
+        assert callable(evaluate_classifier)
diff --git a/tests/unit/test_frontend_main.py b/tests/unit/test_frontend_main.py
new file mode 100644
index 0000000..b551293
--- /dev/null
+++ b/tests/unit/test_frontend_main.py
@@ -0,0 +1,76 @@
+import base64
+import os
+
+from frontend.main import Api
+
+
+class TestSaveFileChunk:
+    def test_creates_file_on_first_chunk(self, tmp_path, monkeypatch):
+        monkeypatch.setattr("frontend.main.here", str(tmp_path))
+        monkeypatch.setattr("frontend.main.subprocess.run", lambda *a, **k: None)
+
+        api = Api.__new__(Api)
+
+        data = base64.b64encode(b"hello").decode()
+        result = api.save_file_chunk(
+            filename="test.txt",
+            chunk_data=data,
+            chunk_index=0,
+            is_last=False,
+        )
+
+        assert result == "success"
+
+        file_path = os.path.join(tmp_path, "../data/raw/test.txt")
+        with open(file_path, "rb") as f:
+            assert f.read() == b"hello"
+
+    def test_appends_on_subsequent_chunks(self, tmp_path, monkeypatch):
+        monkeypatch.setattr("frontend.main.here", str(tmp_path))
+        monkeypatch.setattr("frontend.main.subprocess.run", lambda *a, **k: None)
+
+        api = Api.__new__(Api)
+
+        chunk1 = base64.b64encode(b"hello ").decode()
+        chunk2 = base64.b64encode(b"world").decode()
+
+        api.save_file_chunk("test.txt", chunk1, 0, False)
+        api.save_file_chunk("test.txt", chunk2, 1, False)
+
+        file_path = os.path.join(tmp_path, "../data/raw/test.txt")
+        with open(file_path, "rb") as f:
+            assert f.read() == b"hello world"
+
+    def test_runs_subprocess_on_last_chunk(self, tmp_path, monkeypatch):
+        monkeypatch.setattr("frontend.main.here", str(tmp_path))
+        monkeypatch.setattr("frontend.main.subprocess.run", lambda *a, **k: None)
+
+        api = Api.__new__(Api)
+
+        called = {"ran": False}
+
+        def fake_run(*args, **kwargs):
+            called["ran"] = True
+
+        monkeypatch.setattr("frontend.main.subprocess.run", fake_run)
+
+        data = base64.b64encode(b"data").decode()
+        result = api.save_file_chunk("final.txt", data, 0, True)
+
+        assert result == "success"
+        assert called["ran"] is True
+
+    def test_returns_error_on_exception(self, monkeypatch):
+        monkeypatch.setattr("frontend.main.subprocess.run", lambda *a, **k: None)
+
+        api = Api.__new__(Api)
+
+        def fake_open(*args, **kwargs):
+            raise IOError("disk failure")
+
+        monkeypatch.setattr("builtins.open", fake_open)
+
+        data = base64.b64encode(b"x").decode()
+        result = api.save_file_chunk("fail.txt", data, 0, False)
+
+        assert result.startswith("error:")
diff --git a/tests/unit/test_generator.py b/tests/unit/test_generator.py
new file mode 100644
index 0000000..f1c1d19
--- /dev/null
+++ b/tests/unit/test_generator.py
@@ -0,0 +1,357 @@
+import unittest
+from unittest.mock import MagicMock, Mock, patch
+
+import torch
+
+from hallucination_reduction.config import DEVICE
+from hallucination_reduction.generator import (
+    build_rag_prompt,
+    generate_answer,
+    load_generator,
+    sft_finetune_generator,
+)
+
+
+class TestLoadGenerator(unittest.TestCase):
+
+    @patch("hallucination_reduction.generator.AutoModelForCausalLM")
+    @patch("hallucination_reduction.generator.AutoTokenizer")
+    def test_load_generator_with_pad_token(
+        self, mock_tokenizer_class, mock_model_class
+    ):
+        """Test loading generator when tokenizer has pad_token"""
+        # Mock tokenizer
+        mock_tokenizer = Mock()
+        mock_tokenizer.pad_token = "[PAD]"
+        mock_tokenizer.eos_token = "[EOS]"
+        mock_tokenizer_class.from_pretrained.return_value = mock_tokenizer
+
+        # Mock model
+        mock_model = Mock()
+        # Make parameters() return a real torch Parameter so next() works
+        mock_model.parameters.return_value = iter(
+            [torch.nn.Parameter(torch.tensor([1.0]))]
+        )
+        mock_model_class.from_pretrained.return_value = mock_model
+
+        # Call the function
+        tokenizer, model = load_generator("test-model", DEVICE)
+
+        # Assertions
+        mock_tokenizer_class.from_pretrained.assert_called_once_with("test-model")
+        mock_model_class.from_pretrained.assert_called_once_with(
+            "test-model",
+            device_map="auto",
+            load_in_4bit=True,
+            dtype=torch.bfloat16,  # matches implementation
+        )
+        self.assertEqual(tokenizer.pad_token, "[PAD]")
+        model.eval.assert_called_once()
+
+    @patch("hallucination_reduction.generator.AutoModelForCausalLM")
+    @patch("hallucination_reduction.generator.AutoTokenizer")
+    def test_load_generator_without_pad_token(
+        self, mock_tokenizer_class, mock_model_class
+    ):
+        """Test loading generator when tokenizer lacks pad_token"""
+        # Mock tokenizer
+        mock_tokenizer = Mock()
+        mock_tokenizer.pad_token = None
+        mock_tokenizer.eos_token = "[EOS]"
+        mock_tokenizer_class.from_pretrained.return_value = mock_tokenizer
+
+        # Mock model
+        mock_model = Mock()
+        mock_model.parameters.return_value = iter(
+            [torch.nn.Parameter(torch.tensor([1.0]))]
+        )
+        mock_model_class.from_pretrained.return_value = mock_model
+
+        # Call the function
+        tokenizer, model = load_generator("test-model", "cpu")
+
+        # The function should set pad_token to eos_token if missing
+        self.assertEqual(tokenizer.pad_token, "[EOS]")
+        model.eval.assert_called_once()
+
+
+class TestBuildRagPrompt(unittest.TestCase):
+
+    def test_build_rag_prompt_single_doc(self):
+        """Test building prompt with single document"""
+        question = "What is the capital of France?"
+        docs = ["Paris is the capital of France."]
+
+        prompt = build_rag_prompt(question, docs)
+
+        self.assertIn("### Context:", prompt)
+        self.assertIn("[1] Paris is the capital of France.", prompt)
+        self.assertIn("### Question:", prompt)
+        self.assertIn(question, prompt)
+        self.assertIn("### Answer:", prompt)
+
+    def test_build_rag_prompt_multiple_docs(self):
+        """Test building prompt with multiple documents"""
+        question = "What are some famous landmarks?"
+        docs = [
+            "The Eiffel Tower is in Paris.",
+            "The Statue of Liberty is in New York.",
+            "The Colosseum is in Rome.",
+        ]
+
+        prompt = build_rag_prompt(question, docs)
+
+        self.assertIn("[1] The Eiffel Tower is in Paris.", prompt)
+        self.assertIn("[2] The Statue of Liberty is in New York.", prompt)
+        self.assertIn("[3] The Colosseum is in Rome.", prompt)
+        self.assertIn(question, prompt)
+
+    def test_build_rag_prompt_empty_docs(self):
+        """Test building prompt with no documents"""
+        question = "What is AI?"
+        docs = []
+
+        prompt = build_rag_prompt(question, docs)
+
+        self.assertIn("### Context:", prompt)
+        self.assertIn("### Question:", prompt)
+        self.assertIn(question, prompt)
+        self.assertIn("### Answer:", prompt)
+
+
+class TestGenerateAnswer(unittest.TestCase):
+
+    def test_generate_answer_single_sequence(self):
+        """Test generating single answer"""
+        mock_generator = Mock()
+        mock_tokenizer = Mock()
+
+        # Mock tokenizer input - needs to return an object with .to() method
+        mock_inputs = MagicMock()
+        mock_inputs.__getitem__.side_effect = lambda key: {
+            "input_ids": torch.tensor([[1, 2, 3]]),
+            "attention_mask": torch.tensor([[1, 1, 1]]),
+        }[key]
+        mock_inputs.to.return_value = mock_inputs
+        mock_tokenizer.return_value = mock_inputs
+        mock_tokenizer.eos_token_id = 0
+
+        # Mock generator output
+        mock_generator.generate.return_value = torch.tensor([[1, 2, 3, 4, 5, 6]])
+        mock_tokenizer.decode.return_value = "This is the generated answer."
+
+        prompt = "Test prompt"
+        texts = generate_answer(
+            mock_generator, mock_tokenizer, prompt, num_return_sequences=1
+        )
+
+        self.assertEqual(len(texts), 1)
+        self.assertEqual(texts[0], "This is the generated answer.")
+        mock_generator.generate.assert_called_once()
+
+    def test_generate_answer_multiple_sequences(self):
+        """Test generating multiple answers"""
+        mock_generator = Mock()
+        mock_tokenizer = Mock()
+
+        mock_inputs = MagicMock()
+        mock_inputs.__getitem__.side_effect = lambda key: {
+            "input_ids": torch.tensor([[1, 2, 3]]),
+            "attention_mask": torch.tensor([[1, 1, 1]]),
+        }[key]
+        mock_inputs.to.return_value = mock_inputs
+        mock_tokenizer.return_value = mock_inputs
+        mock_tokenizer.eos_token_id = 0
+
+        mock_generator.generate.return_value = torch.tensor(
+            [[1, 2, 3, 4, 5], [1, 2, 3, 6, 7]]
+        )
+        mock_tokenizer.decode.side_effect = ["Answer 1", "Answer 2"]
+
+        prompt = "Test prompt"
+        texts = generate_answer(
+            mock_generator, mock_tokenizer, prompt, num_return_sequences=2
+        )
+
+        self.assertEqual(len(texts), 2)
+        self.assertEqual(texts[0], "Answer 1")
+        self.assertEqual(texts[1], "Answer 2")
+
+    def test_generate_answer_parameters(self):
+        """Test that generation uses correct parameters"""
+        mock_generator = Mock()
+        mock_tokenizer = Mock()
+
+        mock_inputs = MagicMock()
+        mock_inputs.__getitem__.side_effect = lambda key: {
+            "input_ids": torch.tensor([[1, 2, 3]]),
+            "attention_mask": torch.tensor([[1, 1, 1]]),
+        }[key]
+        mock_inputs.to.return_value = mock_inputs
+        mock_tokenizer.return_value = mock_inputs
+        mock_tokenizer.eos_token_id = 0
+        mock_generator.generate.return_value = torch.tensor([[1, 2, 3, 4]])
+        mock_tokenizer.decode.return_value = "Answer"
+
+        generate_answer(
+            mock_generator,
+            mock_tokenizer,
+            "prompt",
+            max_new_tokens=100,
+            min_new_tokens=10,
+            temperature=0.5,
+        )
+
+        call_kwargs = mock_generator.generate.call_args[1]
+        self.assertEqual(call_kwargs["max_new_tokens"], 100)
+        self.assertEqual(call_kwargs["min_new_tokens"], 10)
+        self.assertEqual(call_kwargs["temperature"], 0.5)
+        self.assertTrue(call_kwargs["do_sample"])
+        self.assertEqual(call_kwargs["top_k"], 50)
+
+
+class TestSFTFinetuneGenerator(unittest.TestCase):
+
+    def setUp(self):
+        """Set up test fixtures"""
+        self.mock_generator = Mock()
+        self.mock_tokenizer = Mock()
+
+        # Create mock QA pairs
+        self.qa_pairs = []
+        for i in range(3):
+            qa = Mock()
+            qa.question = f"Question {i}?"
+            qa.supporting_passages = [f"Document {i}"]
+            qa.answer = f"Answer {i}"
+            self.qa_pairs.append(qa)
+
+    @patch("hallucination_reduction.generator.DataLoader")
+    @patch("hallucination_reduction.generator.optim.AdamW")
+    def test_sft_finetune_basic(self, mock_adamw, mock_dataloader_class):
+        """Test basic fine-tuning functionality"""
+        # Mock tokenizer
+        self.mock_tokenizer.return_value = {
+            "input_ids": torch.tensor([[1, 2, 3], [4, 5, 6], [7, 8, 9]]),
+            "attention_mask": torch.tensor([[1, 1, 1], [1, 1, 1], [1, 1, 1]]),
+        }
+
+        # Mock dataloader - use MagicMock for __iter__
+        mock_dataloader = MagicMock()
+        mock_batch = (torch.tensor([[1, 2, 3]]), torch.tensor([[1, 1, 1]]))
+        mock_dataloader.__iter__.return_value = iter([mock_batch])
+        mock_dataloader_class.return_value = mock_dataloader
+
+        # Mock optimizer
+        mock_optimizer = Mock()
+        mock_adamw.return_value = mock_optimizer
+
+        # Mock model output - loss needs requires_grad=True for backward
+        mock_output = Mock()
+        mock_output.loss = torch.tensor(0.5, requires_grad=True)
+        self.mock_generator.return_value = mock_output
+        self.mock_generator.parameters.return_value = []
+
+        result = sft_finetune_generator(
+            self.mock_generator,
+            self.mock_tokenizer,
+            self.qa_pairs,
+            epochs=2,
+            batch_size=1,
+            lr=0.001,
+        )
+
+        self.mock_generator.train.assert_called_once()
+        self.mock_generator.eval.assert_called_once()
+        self.assertEqual(result, self.mock_generator)
+
+    @patch("hallucination_reduction.generator.DataLoader")
+    @patch("hallucination_reduction.generator.optim.AdamW")
+    def test_sft_finetune_optimizer_steps(self, mock_adamw, mock_dataloader_class):
+        """Test that optimizer steps are called correctly"""
+        self.mock_tokenizer.return_value = {
+            "input_ids": torch.tensor([[1, 2, 3]]),
+            "attention_mask": torch.tensor([[1, 1, 1]]),
+        }
+
+        mock_dataloader = MagicMock()
+        mock_batch = (torch.tensor([[1, 2, 3]]), torch.tensor([[1, 1, 1]]))
+        mock_dataloader.__iter__.return_value = iter([mock_batch, mock_batch])
+        mock_dataloader_class.return_value = mock_dataloader
+
+        mock_optimizer = Mock()
+        mock_adamw.return_value = mock_optimizer
+
+        mock_output = Mock()
+        mock_output.loss = torch.tensor(0.5, requires_grad=True)
+        self.mock_generator.return_value = mock_output
+        self.mock_generator.parameters.return_value = []
+
+        sft_finetune_generator(
+            self.mock_generator, self.mock_tokenizer, [self.qa_pairs[0]], epochs=1
+        )
+
+        # Should be called twice (once per batch)
+        self.assertEqual(mock_optimizer.zero_grad.call_count, 2)
+        self.assertEqual(mock_optimizer.step.call_count, 2)
+
+    @patch("hallucination_reduction.generator.DataLoader")
+    @patch("hallucination_reduction.generator.optim.AdamW")
+    @patch("builtins.print")
+    def test_sft_finetune_loss_logging(
+        self, mock_print, mock_adamw, mock_dataloader_class
+    ):
+        """Test that losses are logged correctly"""
+        self.mock_tokenizer.return_value = {
+            "input_ids": torch.tensor([[1, 2, 3]]),
+            "attention_mask": torch.tensor([[1, 1, 1]]),
+        }
+
+        mock_dataloader = MagicMock()
+        mock_batch = (torch.tensor([[1, 2, 3]]), torch.tensor([[1, 1, 1]]))
+        mock_dataloader.__iter__.return_value = iter([mock_batch])
+        mock_dataloader_class.return_value = mock_dataloader
+
+        mock_optimizer = Mock()
+        mock_adamw.return_value = mock_optimizer
+
+        mock_output = Mock()
+        mock_output.loss = torch.tensor(0.5, requires_grad=True)
+        self.mock_generator.return_value = mock_output
+        self.mock_generator.parameters.return_value = []
+
+        sft_finetune_generator(
+            self.mock_generator, self.mock_tokenizer, [self.qa_pairs[0]], epochs=2
+        )
+
+        # Should print loss for each epoch
+        self.assertEqual(mock_print.call_count, 2)
+        first_call = mock_print.call_args_list[0][0][0]
+        self.assertIn("SFT epoch 1/2", first_call)
+        self.assertIn("loss=0.5000", first_call)
+
+
+class TestIntegration(unittest.TestCase):
+    """Integration tests for the generator module"""
+
+    def test_prompt_generation_and_answer_flow(self):
+        """Test that prompts can be built and used for generation"""
+        question = "What is machine learning?"
+        docs = [
+            "Machine learning is a subset of AI.",
+            "It involves training models on data.",
+        ]
+
+        prompt = build_rag_prompt(question, docs)
+
+        self.assertIn(question, prompt)
+        for doc in docs:
+            self.assertIn(doc, prompt)
+
+        # Verify prompt structure
+        parts = prompt.split("###")
+        self.assertEqual(len(parts), 4)  # Empty, Context, Question, Answer
+
+
+if __name__ == "__main__":
+    unittest.main()
diff --git a/tests/unit/test_inference.py b/tests/unit/test_inference.py
new file mode 100644
index 0000000..6594811
--- /dev/null
+++ b/tests/unit/test_inference.py
@@ -0,0 +1,467 @@
+import unittest
+from unittest.mock import MagicMock, Mock, mock_open, patch
+
+import numpy as np
+import torch
+
+from hallucination_reduction.inference import (
+    build_embeddings,
+    find_best_model,
+    generate_answer,
+    load_corpus,
+    load_model,
+    retrieve_relevant_chunks,
+)
+
+
+class TestLoadCorpus(unittest.TestCase):
+
+    @patch(
+        "builtins.open",
+        new_callable=mock_open,
+        read_data="Document 1\nDocument 2\nDocument 3\n",
+    )
+    @patch("os.path.exists")
+    def test_load_corpus_success(self, mock_exists, mock_file):
+        """Test successfully loading corpus from file"""
+        mock_exists.return_value = True
+
+        docs = load_corpus("test_corpus.txt")
+
+        self.assertEqual(len(docs), 3)
+        self.assertEqual(docs[0], "Document 1")
+        self.assertEqual(docs[1], "Document 2")
+        self.assertEqual(docs[2], "Document 3")
+        mock_file.assert_called_once_with("test_corpus.txt", "r", encoding="utf-8")
+
+    @patch(
+        "builtins.open", new_callable=mock_open, read_data="Doc 1\n\n\nDoc 2\n  \nDoc 3"
+    )
+    @patch("os.path.exists")
+    def test_load_corpus_filters_empty_lines(self, mock_exists, mock_file):
+        """Test that empty lines and whitespace are filtered"""
+        mock_exists.return_value = True
+
+        docs = load_corpus("test_corpus.txt")
+
+        self.assertEqual(len(docs), 3)
+        self.assertNotIn("", docs)
+        self.assertNotIn("  ", docs)
+
+    @patch("os.path.exists")
+    def test_load_corpus_file_not_found(self, mock_exists):
+        """Test error when corpus file doesn't exist"""
+        mock_exists.return_value = False
+
+        with self.assertRaises(FileNotFoundError) as context:
+            load_corpus("nonexistent.txt")
+
+        self.assertIn("Corpus file not found", str(context.exception))
+
+
+class TestBuildEmbeddings(unittest.TestCase):
+
+    @patch("hallucination_reduction.inference.SentenceTransformer")
+    def test_build_embeddings(self, mock_sentence_transformer_class):
+        """Test building embeddings from documents"""
+        mock_embedder = Mock()
+        mock_embeddings = np.array([[0.1, 0.2, 0.3], [0.4, 0.5, 0.6]])
+        mock_embedder.encode.return_value = mock_embeddings
+        mock_sentence_transformer_class.return_value = mock_embedder
+
+        docs = ["Document 1", "Document 2"]
+        embedder, embeddings = build_embeddings(
+            docs, embed_model_name="test-model", device="cpu"
+        )
+
+        mock_sentence_transformer_class.assert_called_once_with(
+            "test-model", device="cpu"
+        )
+        mock_embedder.encode.assert_called_once_with(
+            docs, convert_to_numpy=True, show_progress_bar=True
+        )
+        self.assertEqual(embedder, mock_embedder)
+        np.testing.assert_array_equal(embeddings, mock_embeddings)
+
+
+class TestRetrieveRelevantChunks(unittest.TestCase):
+
+    def test_retrieve_relevant_chunks(self):
+        """Test retrieving top-k relevant chunks"""
+        mock_embedder = Mock()
+        query_embedding = np.array([[1.0, 0.0]])
+        mock_embedder.encode.return_value = query_embedding
+
+        # Corpus embeddings - doc 2 is most similar to [1.0, 0.0]
+        corpus_embeddings = np.array(
+            [
+                [0.0, 1.0],  # Not similar (perpendicular)
+                [0.5, 0.5],  # Somewhat similar
+                [1.0, 0.0],  # Most similar (identical)
+            ]
+        )
+
+        docs = ["Doc 0", "Doc 1", "Doc 2"]
+
+        top_docs = retrieve_relevant_chunks(
+            "test query", mock_embedder, corpus_embeddings, docs, top_k=2
+        )
+
+        self.assertEqual(len(top_docs), 2)
+        self.assertEqual(top_docs[0], "Doc 2")  # Most similar
+        self.assertEqual(top_docs[1], "Doc 1")  # Second most similar
+        mock_embedder.encode.assert_called_once_with(
+            ["test query"], convert_to_numpy=True
+        )
+
+    def test_retrieve_single_chunk(self):
+        """Test retrieving single most relevant chunk"""
+        mock_embedder = Mock()
+        mock_embedder.encode.return_value = np.array([[1.0, 0.0]])
+
+        corpus_embeddings = np.array(
+            [
+                [0.0, 1.0],
+                [1.0, 0.0],
+                [0.5, 0.5],
+            ]
+        )
+
+        docs = ["Doc A", "Doc B", "Doc C"]
+
+        top_docs = retrieve_relevant_chunks(
+            "query", mock_embedder, corpus_embeddings, docs, top_k=1
+        )
+
+        self.assertEqual(len(top_docs), 1)
+        self.assertEqual(top_docs[0], "Doc B")
+
+
+class TestFindBestModel(unittest.TestCase):
+
+    @patch("os.path.exists")
+    @patch("os.listdir")
+    def test_find_best_model_final(self, mock_listdir, mock_exists):
+        """Test finding generator_final.pt when it exists"""
+        mock_exists.return_value = True
+        mock_listdir.return_value = [
+            "generator_final.pt",
+            "generator_epoch_1.pt",
+            "generator_epoch_2.pt",
+        ]
+
+        result = find_best_model("test_dir")
+
+        self.assertEqual(result, "test_dir/generator_final.pt")
+
+    @patch("os.path.exists")
+    @patch("os.listdir")
+    def test_find_best_model_best_checkpoint(self, mock_listdir, mock_exists):
+        """Test finding best checkpoint when no final exists"""
+        mock_exists.return_value = True
+        mock_listdir.return_value = [
+            "generator_best.pt",
+            "generator_epoch_1.pt",
+            "generator_epoch_2.pt",
+        ]
+
+        result = find_best_model("test_dir")
+
+        self.assertEqual(result, "test_dir/generator_best.pt")
+
+    @patch("os.path.exists")
+    @patch("os.listdir")
+    def test_find_best_model_latest_epoch(self, mock_listdir, mock_exists):
+        """Test finding latest epoch when no final/best exists"""
+        mock_exists.return_value = True
+        mock_listdir.return_value = [
+            "generator_epoch_1.pt",
+            "generator_epoch_5.pt",
+            "generator_epoch_3.pt",
+        ]
+
+        result = find_best_model("test_dir")
+
+        self.assertEqual(result, "test_dir/generator_epoch_5.pt")
+
+    @patch("os.path.exists")
+    @patch("os.listdir")
+    def test_find_best_model_fallback(self, mock_listdir, mock_exists):
+        """Test falling back to first available checkpoint"""
+        mock_exists.return_value = True
+        mock_listdir.return_value = ["generator_custom.pt", "other_file.txt"]
+
+        result = find_best_model("test_dir")
+
+        self.assertEqual(result, "test_dir/generator_custom.pt")
+
+    @patch("os.path.exists")
+    def test_find_best_model_no_directory(self, mock_exists):
+        """Test when weights directory doesn't exist"""
+        mock_exists.return_value = False
+
+        result = find_best_model("nonexistent_dir")
+
+        self.assertIsNone(result)
+
+    @patch("os.path.exists")
+    @patch("os.listdir")
+    def test_find_best_model_no_checkpoints(self, mock_listdir, mock_exists):
+        """Test when no generator checkpoints exist"""
+        mock_exists.return_value = True
+        mock_listdir.return_value = ["other_file.txt", "data.json"]
+
+        result = find_best_model("test_dir")
+
+        self.assertIsNone(result)
+
+
+class TestLoadModel(unittest.TestCase):
+
+    @patch("hallucination_reduction.inference.find_best_model")
+    @patch("hallucination_reduction.inference.AutoModelForCausalLM")
+    @patch("hallucination_reduction.inference.AutoTokenizer")
+    @patch("torch.load")
+    @patch("os.path.exists")
+    @patch("torch.cuda.is_available")
+    def test_load_model_with_finetuned_weights(
+        self,
+        mock_cuda,
+        mock_exists,
+        mock_torch_load,
+        mock_tokenizer_class,
+        mock_model_class,
+        mock_find_best,
+    ):
+        """Test loading model with fine-tuned weights"""
+        mock_cuda.return_value = False
+        mock_exists.return_value = True
+        mock_find_best.return_value = "test_weights.pt"
+
+        # Mock tokenizer
+        mock_tokenizer = Mock()
+        mock_tokenizer_class.from_pretrained.return_value = mock_tokenizer
+
+        # Mock model
+        mock_model = MagicMock()
+        # Use lambda to return a new iterator each time
+        mock_model.parameters.side_effect = lambda: iter(
+            [torch.nn.Parameter(torch.tensor([1.0]))]
+        )
+        mock_model.state_dict.return_value = {"layer.weight": torch.randn(10, 10)}
+        mock_model_class.from_pretrained.return_value = mock_model
+
+        # Mock loaded weights
+        mock_torch_load.return_value = {"layer.weight": torch.randn(10, 10)}
+
+        model, tokenizer, device = load_model("test-model", "test_dir")
+
+        mock_tokenizer_class.from_pretrained.assert_called_once_with("test-model")
+        mock_model_class.from_pretrained.assert_called_once()
+        mock_torch_load.assert_called_once_with("test_weights.pt", map_location="cpu")
+        mock_model.eval.assert_called_once()
+        self.assertEqual(model, mock_model)
+        self.assertEqual(tokenizer, mock_tokenizer)
+
+    @patch("hallucination_reduction.inference.find_best_model")
+    @patch("hallucination_reduction.inference.AutoModelForCausalLM")
+    @patch("hallucination_reduction.inference.AutoTokenizer")
+    @patch("torch.cuda.is_available")
+    def test_load_model_without_finetuned_weights(
+        self, mock_cuda, mock_tokenizer_class, mock_model_class, mock_find_best
+    ):
+        """Test loading base model when no fine-tuned weights exist"""
+        mock_cuda.return_value = False
+        mock_find_best.return_value = None
+
+        # Mock tokenizer
+        mock_tokenizer = Mock()
+        mock_tokenizer_class.from_pretrained.return_value = mock_tokenizer
+
+        # Mock model
+        mock_model = MagicMock()
+        mock_model.parameters.side_effect = lambda: iter(
+            [torch.nn.Parameter(torch.tensor([1.0]))]
+        )
+        mock_model_class.from_pretrained.return_value = mock_model
+
+        model, tokenizer, device = load_model("test-model", "test_dir")
+
+        mock_model.eval.assert_called_once()
+        self.assertEqual(model, mock_model)
+        self.assertEqual(tokenizer, mock_tokenizer)
+
+    @patch("hallucination_reduction.inference.find_best_model")
+    @patch("hallucination_reduction.inference.AutoModelForCausalLM")
+    @patch("hallucination_reduction.inference.AutoTokenizer")
+    @patch("torch.cuda.is_available")
+    def test_load_model_cuda_available(
+        self, mock_cuda, mock_tokenizer_class, mock_model_class, mock_find_best
+    ):
+        """Test that bfloat16 is used when CUDA is available"""
+        mock_cuda.return_value = True
+        mock_find_best.return_value = None
+
+        mock_tokenizer = Mock()
+        mock_tokenizer_class.from_pretrained.return_value = mock_tokenizer
+
+        mock_model = MagicMock()
+        mock_model.parameters.side_effect = lambda: iter(
+            [torch.nn.Parameter(torch.tensor([1.0]))]
+        )
+        mock_model_class.from_pretrained.return_value = mock_model
+
+        load_model("test-model", "test_dir")
+
+        # Check that bfloat16 was used
+        call_kwargs = mock_model_class.from_pretrained.call_args[1]
+        self.assertEqual(call_kwargs["torch_dtype"], torch.bfloat16)
+
+
+class TestGenerateAnswer(unittest.TestCase):
+
+    @patch("hallucination_reduction.inference.Thread")
+    @patch("hallucination_reduction.inference.TextIteratorStreamer")
+    @patch("builtins.print")
+    def test_generate_answer_basic(
+        self, mock_print, mock_streamer_class, mock_thread_class
+    ):
+        """Test basic answer generation"""
+        # Mock model and tokenizer
+        mock_model = MagicMock()
+        mock_tokenizer = Mock()
+
+        # Mock tokenizer return
+        mock_inputs = MagicMock()
+        mock_inputs.__getitem__.side_effect = lambda key: torch.tensor([[1, 2, 3]])
+        mock_inputs.to.return_value = mock_inputs
+        mock_tokenizer.return_value = mock_inputs
+        mock_tokenizer.eos_token_id = 0
+
+        # Mock streamer
+        mock_streamer = MagicMock()
+        mock_streamer.__iter__.return_value = iter(["Hello", " world", "!"])
+        mock_streamer_class.return_value = mock_streamer
+
+        # Mock thread
+        mock_thread = Mock()
+        mock_thread_class.return_value = mock_thread
+
+        device = torch.device("cpu")
+        question = "What is AI?"
+        retrieved_docs = ["AI is artificial intelligence."]
+
+        result = generate_answer(
+            mock_model, mock_tokenizer, device, question, retrieved_docs
+        )
+
+        self.assertEqual(result, "Hello world!")
+        mock_thread.start.assert_called_once()
+        mock_thread.join.assert_called_once()
+        mock_streamer_class.assert_called_once_with(
+            mock_tokenizer, skip_prompt=True, skip_special_tokens=True
+        )
+
+    @patch("hallucination_reduction.inference.Thread")
+    @patch("hallucination_reduction.inference.TextIteratorStreamer")
+    @patch("builtins.print")
+    def test_generate_answer_with_multiple_docs(
+        self, mock_print, mock_streamer_class, mock_thread_class
+    ):
+        """Test answer generation with multiple retrieved documents"""
+        mock_model = MagicMock()
+        mock_tokenizer = Mock()
+
+        mock_inputs = MagicMock()
+        mock_inputs.__getitem__.side_effect = lambda key: torch.tensor([[1, 2, 3]])
+        mock_inputs.to.return_value = mock_inputs
+        mock_tokenizer.return_value = mock_inputs
+        mock_tokenizer.eos_token_id = 0
+
+        mock_streamer = MagicMock()
+        mock_streamer.__iter__.return_value = iter(["Answer"])
+        mock_streamer_class.return_value = mock_streamer
+
+        mock_thread = Mock()
+        mock_thread_class.return_value = mock_thread
+
+        device = torch.device("cpu")
+        question = "What is machine learning?"
+        retrieved_docs = [
+            "ML is a subset of AI.",
+            "It involves training models.",
+            "It uses data and algorithms.",
+        ]
+
+        result = generate_answer(
+            mock_model, mock_tokenizer, device, question, retrieved_docs
+        )
+
+        self.assertEqual(result, "Answer")
+        # Verify tokenizer was called with a prompt containing all docs
+        called_prompt = mock_tokenizer.call_args[0][0]
+        for doc in retrieved_docs:
+            self.assertIn(doc, called_prompt)
+        self.assertIn(question, called_prompt)
+
+    @patch("hallucination_reduction.inference.Thread")
+    @patch("hallucination_reduction.inference.TextIteratorStreamer")
+    @patch("builtins.print")
+    def test_generate_answer_custom_max_tokens(
+        self, mock_print, mock_streamer_class, mock_thread_class
+    ):
+        """Test answer generation with custom max_new_tokens"""
+        mock_model = MagicMock()
+        mock_tokenizer = Mock()
+
+        mock_inputs = MagicMock()
+        mock_inputs.__getitem__.side_effect = lambda key: torch.tensor([[1, 2, 3]])
+        mock_inputs.to.return_value = mock_inputs
+        mock_tokenizer.return_value = mock_inputs
+        mock_tokenizer.eos_token_id = 0
+
+        mock_streamer = MagicMock()
+        mock_streamer.__iter__.return_value = iter(["Test"])
+        mock_streamer_class.return_value = mock_streamer
+
+        mock_thread = Mock()
+        mock_thread_class.return_value = mock_thread
+
+        device = torch.device("cpu")
+
+        generate_answer(
+            mock_model, mock_tokenizer, device, "question", ["doc"], max_new_tokens=512
+        )
+
+        # Verify Thread was called with max_new_tokens=512
+        thread_kwargs = mock_thread_class.call_args[1]["kwargs"]
+        self.assertEqual(thread_kwargs["max_new_tokens"], 512)
+
+
+class TestIntegration(unittest.TestCase):
+    """Integration tests for the inference module"""
+
+    @patch("hallucination_reduction.inference.SentenceTransformer")
+    def test_embeddings_and_retrieval_flow(self, mock_st_class):
+        """Test the flow from building embeddings to retrieval"""
+        mock_embedder = Mock()
+
+        # Create embeddings that make doc 1 most similar to query
+        corpus_embs = np.array([[0.1, 0.1], [0.9, 0.9], [0.2, 0.2]])
+        query_emb = np.array([[0.85, 0.85]])
+
+        mock_embedder.encode.side_effect = [corpus_embs, query_emb]
+        mock_st_class.return_value = mock_embedder
+
+        docs = ["Doc 0", "Doc 1", "Doc 2"]
+
+        # Build embeddings
+        embedder, embeddings = build_embeddings(docs)
+
+        # Retrieve
+        top_docs = retrieve_relevant_chunks(
+            "test query", embedder, embeddings, docs, top_k=1
+        )
+
+        self.assertEqual(len(top_docs), 1)
+        self.assertEqual(top_docs[0], "Doc 1")
diff --git a/tests/unit/test_main.py b/tests/unit/test_main.py
new file mode 100644
index 0000000..0d1ff36
--- /dev/null
+++ b/tests/unit/test_main.py
@@ -0,0 +1,592 @@
+from unittest.mock import MagicMock, patch
+
+from hallucination_reduction.main import main, unwrap
+
+
+class TestUnwrap:
+    """Test suite for unwrap function."""
+
+    def test_function_exists(self):
+        """Test that unwrap can be imported."""
+        assert callable(unwrap)
+
+    def test_unwrap_regular_model(self):
+        """Test unwrapping a regular model returns itself."""
+        model = MagicMock()
+        # Model without 'module' attribute
+        del model.module
+
+        result = unwrap(model)
+        assert result == model
+
+    def test_unwrap_dataparallel_model(self):
+        """Test unwrapping DataParallel model returns module."""
+        model = MagicMock()
+        inner_model = MagicMock()
+        model.module = inner_model
+
+        result = unwrap(model)
+        assert result == inner_model
+
+    def test_unwrap_preserves_model_without_module(self):
+        """Test that model without module attribute is returned as-is."""
+
+        class SimpleModel:
+            def __init__(self):
+                self.layers = []
+
+        model = SimpleModel()
+        result = unwrap(model)
+        assert result is model
+
+
+class TestMainFunction:
+    """Test suite for main function."""
+
+    def test_function_exists(self):
+        """Test that main function can be imported."""
+        assert callable(main)
+
+    @patch("hallucination_reduction.main.torch.save")
+    @patch("hallucination_reduction.main.reinforcement_learning_loop")
+    @patch("hallucination_reduction.main.evaluate_old_vs_new_generator")
+    @patch("hallucination_reduction.main.sft_finetune_generator")
+    @patch("hallucination_reduction.main.evaluate_classifier")
+    @patch("hallucination_reduction.main.train_discriminator_minibatch")
+    @patch("hallucination_reduction.main.load_discriminator")
+    @patch("hallucination_reduction.main.load_generator")
+    @patch("hallucination_reduction.main.SimpleRetriever")
+    @patch("hallucination_reduction.main.build_corpus_and_qa")
+    @patch("torch.cuda.is_available")
+    def test_main_runs_without_error(
+        self,
+        mock_cuda,
+        mock_build,
+        mock_retriever,
+        mock_load_gen,
+        mock_load_disc,
+        mock_train_disc,
+        mock_eval_class,
+        mock_sft,
+        mock_eval_gen,
+        mock_rl,
+        mock_save,
+    ):
+        """Test that main function runs without errors."""
+        # Setup mocks
+        mock_cuda.return_value = False
+
+        # Mock data
+        mock_qa = MagicMock()
+        mock_qa.question = "Q?"
+        mock_qa.answer = "A"
+        mock_qa.supporting_passages = ["P"]
+        mock_build.return_value = (["passage"], [mock_qa])
+
+        # Mock retriever
+        mock_retriever_instance = MagicMock()
+        mock_retriever.return_value = mock_retriever_instance
+
+        # Mock generator
+        mock_gen = MagicMock()
+        mock_tok = MagicMock()
+        mock_load_gen.return_value = (mock_tok, mock_gen)
+
+        # Mock discriminator
+        mock_disc = MagicMock()
+        mock_disc_tok = MagicMock()
+        mock_load_disc.return_value = (mock_disc_tok, mock_disc)
+
+        # Mock training
+        mock_train_disc.return_value = mock_disc
+        mock_eval_class.return_value = {"acc": 0.9, "prec": 0.9, "rec": 0.9, "f1": 0.9}
+        mock_eval_gen.return_value = (
+            [{"question": "Q?", "gold": "A", "old": "O", "new": "N"}],
+            {"exact_match_rate": 0.5, "avg_f1": 0.6, "hallucination_rate": 0.3},
+            {"exact_match_rate": 0.7, "avg_f1": 0.8, "hallucination_rate": 0.1},
+        )
+        mock_sft.return_value = mock_gen
+        mock_rl.return_value = []
+
+        # Run main
+        with patch("builtins.print"):
+            main()
+
+        # Verify key functions were called
+        assert mock_build.called
+        assert mock_load_gen.called
+        assert mock_load_disc.called
+
+    @patch("hallucination_reduction.main.torch.save")
+    @patch("hallucination_reduction.main.reinforcement_learning_loop")
+    @patch("hallucination_reduction.main.evaluate_old_vs_new_generator")
+    @patch("hallucination_reduction.main.sft_finetune_generator")
+    @patch("hallucination_reduction.main.evaluate_classifier")
+    @patch("hallucination_reduction.main.train_discriminator_minibatch")
+    @patch("hallucination_reduction.main.load_discriminator")
+    @patch("hallucination_reduction.main.load_generator")
+    @patch("hallucination_reduction.main.SimpleRetriever")
+    @patch("hallucination_reduction.main.build_corpus_and_qa")
+    @patch("torch.cuda.is_available")
+    def test_cuda_device_selected_when_available(
+        self,
+        mock_cuda,
+        mock_build,
+        mock_retriever,
+        mock_load_gen,
+        mock_load_disc,
+        mock_train_disc,
+        mock_eval_class,
+        mock_sft,
+        mock_eval_gen,
+        mock_rl,
+        mock_save,
+    ):
+        """Test that CUDA device is selected when available."""
+        mock_cuda.return_value = True
+
+        # Setup minimal mocks
+        mock_qa = MagicMock()
+        mock_qa.question = "Q?"
+        mock_qa.answer = "A"
+        mock_qa.supporting_passages = ["P"]
+        mock_build.return_value = (["passage"], [mock_qa])
+        mock_retriever.return_value = MagicMock()
+
+        mock_gen = MagicMock()
+        mock_tok = MagicMock()
+        mock_load_gen.return_value = (mock_tok, mock_gen)
+
+        mock_disc = MagicMock()
+        mock_disc_tok = MagicMock()
+        mock_load_disc.return_value = (mock_disc_tok, mock_disc)
+
+        mock_train_disc.return_value = mock_disc
+        mock_eval_class.return_value = {"acc": 0.9, "prec": 0.9, "rec": 0.9, "f1": 0.9}
+        mock_eval_gen.return_value = (
+            [{"question": "Q?", "gold": "A", "old": "O", "new": "N"}],
+            {"exact_match_rate": 0.5, "avg_f1": 0.6, "hallucination_rate": 0.3},
+            {"exact_match_rate": 0.7, "avg_f1": 0.8, "hallucination_rate": 0.1},
+        )
+        mock_sft.return_value = mock_gen
+        mock_rl.return_value = []
+
+        with patch("builtins.print") as mock_print:
+            main()
+
+            # Check that CUDA device message was printed
+            print_calls = [str(call) for call in mock_print.call_args_list]
+            cuda_mentioned = any("cuda" in str(call).lower() for call in print_calls)
+            assert cuda_mentioned
+
+    @patch("hallucination_reduction.main.torch.save")
+    @patch("hallucination_reduction.main.reinforcement_learning_loop")
+    @patch("hallucination_reduction.main.evaluate_old_vs_new_generator")
+    @patch("hallucination_reduction.main.sft_finetune_generator")
+    @patch("hallucination_reduction.main.evaluate_classifier")
+    @patch("hallucination_reduction.main.train_discriminator_minibatch")
+    @patch("hallucination_reduction.main.load_discriminator")
+    @patch("hallucination_reduction.main.load_generator")
+    @patch("hallucination_reduction.main.SimpleRetriever")
+    @patch("hallucination_reduction.main.build_corpus_and_qa")
+    @patch("torch.cuda.is_available")
+    def test_loads_corpus_and_qa(
+        self,
+        mock_cuda,
+        mock_build,
+        mock_retriever,
+        mock_load_gen,
+        mock_load_disc,
+        mock_train_disc,
+        mock_eval_class,
+        mock_sft,
+        mock_eval_gen,
+        mock_rl,
+        mock_save,
+    ):
+        """Test that corpus and QA pairs are loaded."""
+        mock_cuda.return_value = False
+
+        mock_qa = MagicMock()
+        mock_qa.question = "Q?"
+        mock_qa.answer = "A"
+        mock_qa.supporting_passages = ["P"]
+        mock_build.return_value = (["passage"], [mock_qa])
+        mock_retriever.return_value = MagicMock()
+
+        mock_gen = MagicMock()
+        mock_tok = MagicMock()
+        mock_load_gen.return_value = (mock_tok, mock_gen)
+
+        mock_disc = MagicMock()
+        mock_disc_tok = MagicMock()
+        mock_load_disc.return_value = (mock_disc_tok, mock_disc)
+
+        mock_train_disc.return_value = mock_disc
+        mock_eval_class.return_value = {"acc": 0.9, "prec": 0.9, "rec": 0.9, "f1": 0.9}
+        mock_eval_gen.return_value = (
+            [{"question": "Q?", "gold": "A", "old": "O", "new": "N"}],
+            {"exact_match_rate": 0.5, "avg_f1": 0.6, "hallucination_rate": 0.3},
+            {"exact_match_rate": 0.7, "avg_f1": 0.8, "hallucination_rate": 0.1},
+        )
+        mock_sft.return_value = mock_gen
+        mock_rl.return_value = []
+
+        with patch("builtins.print"):
+            main()
+
+        mock_build.assert_called_once()
+
+    @patch("hallucination_reduction.main.torch.save")
+    @patch("hallucination_reduction.main.reinforcement_learning_loop")
+    @patch("hallucination_reduction.main.evaluate_old_vs_new_generator")
+    @patch("hallucination_reduction.main.sft_finetune_generator")
+    @patch("hallucination_reduction.main.evaluate_classifier")
+    @patch("hallucination_reduction.main.train_discriminator_minibatch")
+    @patch("hallucination_reduction.main.load_discriminator")
+    @patch("hallucination_reduction.main.load_generator")
+    @patch("hallucination_reduction.main.SimpleRetriever")
+    @patch("hallucination_reduction.main.build_corpus_and_qa")
+    @patch("torch.cuda.is_available")
+    def test_trains_three_discriminators(
+        self,
+        mock_cuda,
+        mock_build,
+        mock_retriever,
+        mock_load_gen,
+        mock_load_disc,
+        mock_train_disc,
+        mock_eval_class,
+        mock_sft,
+        mock_eval_gen,
+        mock_rl,
+        mock_save,
+    ):
+        """Test that three discriminators are trained (fact, style, safety)."""
+        mock_cuda.return_value = False
+
+        mock_qa = MagicMock()
+        mock_qa.question = "Q?"
+        mock_qa.answer = "A"
+        mock_qa.supporting_passages = ["P"]
+        mock_build.return_value = (["passage"], [mock_qa])
+        mock_retriever.return_value = MagicMock()
+
+        mock_gen = MagicMock()
+        mock_tok = MagicMock()
+        mock_load_gen.return_value = (mock_tok, mock_gen)
+
+        mock_disc = MagicMock()
+        mock_disc_tok = MagicMock()
+        mock_load_disc.return_value = (mock_disc_tok, mock_disc)
+
+        mock_train_disc.return_value = mock_disc
+        mock_eval_class.return_value = {"acc": 0.9, "prec": 0.9, "rec": 0.9, "f1": 0.9}
+        mock_eval_gen.return_value = (
+            [{"question": "Q?", "gold": "A", "old": "O", "new": "N"}],
+            {"exact_match_rate": 0.5, "avg_f1": 0.6, "hallucination_rate": 0.3},
+            {"exact_match_rate": 0.7, "avg_f1": 0.8, "hallucination_rate": 0.1},
+        )
+        mock_sft.return_value = mock_gen
+        mock_rl.return_value = []
+
+        with patch("builtins.print"):
+            main()
+
+        # Should be called 3 times (fact, style, safety)
+        assert mock_train_disc.call_count == 3
+
+    @patch("hallucination_reduction.main.torch.save")
+    @patch("hallucination_reduction.main.reinforcement_learning_loop")
+    @patch("hallucination_reduction.main.evaluate_old_vs_new_generator")
+    @patch("hallucination_reduction.main.sft_finetune_generator")
+    @patch("hallucination_reduction.main.evaluate_classifier")
+    @patch("hallucination_reduction.main.train_discriminator_minibatch")
+    @patch("hallucination_reduction.main.load_discriminator")
+    @patch("hallucination_reduction.main.load_generator")
+    @patch("hallucination_reduction.main.SimpleRetriever")
+    @patch("hallucination_reduction.main.build_corpus_and_qa")
+    @patch("torch.cuda.is_available")
+    def test_runs_sft_finetuning(
+        self,
+        mock_cuda,
+        mock_build,
+        mock_retriever,
+        mock_load_gen,
+        mock_load_disc,
+        mock_train_disc,
+        mock_eval_class,
+        mock_sft,
+        mock_eval_gen,
+        mock_rl,
+        mock_save,
+    ):
+        """Test that SFT fine-tuning is executed."""
+        mock_cuda.return_value = False
+
+        mock_qa = MagicMock()
+        mock_qa.question = "Q?"
+        mock_qa.answer = "A"
+        mock_qa.supporting_passages = ["P"]
+        mock_build.return_value = (["passage"], [mock_qa])
+        mock_retriever.return_value = MagicMock()
+
+        mock_gen = MagicMock()
+        mock_tok = MagicMock()
+        mock_load_gen.return_value = (mock_tok, mock_gen)
+
+        mock_disc = MagicMock()
+        mock_disc_tok = MagicMock()
+        mock_load_disc.return_value = (mock_disc_tok, mock_disc)
+
+        mock_train_disc.return_value = mock_disc
+        mock_eval_class.return_value = {"acc": 0.9, "prec": 0.9, "rec": 0.9, "f1": 0.9}
+        mock_eval_gen.return_value = (
+            [{"question": "Q?", "gold": "A", "old": "O", "new": "N"}],
+            {"exact_match_rate": 0.5, "avg_f1": 0.6, "hallucination_rate": 0.3},
+            {"exact_match_rate": 0.7, "avg_f1": 0.8, "hallucination_rate": 0.1},
+        )
+        mock_sft.return_value = mock_gen
+        mock_rl.return_value = []
+
+        with patch("builtins.print"):
+            main()
+
+        mock_sft.assert_called_once()
+
+    @patch("hallucination_reduction.main.torch.save")
+    @patch("hallucination_reduction.main.reinforcement_learning_loop")
+    @patch("hallucination_reduction.main.evaluate_old_vs_new_generator")
+    @patch("hallucination_reduction.main.sft_finetune_generator")
+    @patch("hallucination_reduction.main.evaluate_classifier")
+    @patch("hallucination_reduction.main.train_discriminator_minibatch")
+    @patch("hallucination_reduction.main.load_discriminator")
+    @patch("hallucination_reduction.main.load_generator")
+    @patch("hallucination_reduction.main.SimpleRetriever")
+    @patch("hallucination_reduction.main.build_corpus_and_qa")
+    @patch("torch.cuda.is_available")
+    def test_runs_reinforcement_learning(
+        self,
+        mock_cuda,
+        mock_build,
+        mock_retriever,
+        mock_load_gen,
+        mock_load_disc,
+        mock_train_disc,
+        mock_eval_class,
+        mock_sft,
+        mock_eval_gen,
+        mock_rl,
+        mock_save,
+    ):
+        """Test that reinforcement learning loop is executed."""
+        mock_cuda.return_value = False
+
+        mock_qa = MagicMock()
+        mock_qa.question = "Q?"
+        mock_qa.answer = "A"
+        mock_qa.supporting_passages = ["P"]
+        mock_build.return_value = (["passage"], [mock_qa])
+        mock_retriever.return_value = MagicMock()
+
+        mock_gen = MagicMock()
+        mock_tok = MagicMock()
+        mock_load_gen.return_value = (mock_tok, mock_gen)
+
+        mock_disc = MagicMock()
+        mock_disc_tok = MagicMock()
+        mock_load_disc.return_value = (mock_disc_tok, mock_disc)
+
+        mock_train_disc.return_value = mock_disc
+        mock_eval_class.return_value = {"acc": 0.9, "prec": 0.9, "rec": 0.9, "f1": 0.9}
+        mock_eval_gen.return_value = (
+            [{"question": "Q?", "gold": "A", "old": "O", "new": "N"}],
+            {"exact_match_rate": 0.5, "avg_f1": 0.6, "hallucination_rate": 0.3},
+            {"exact_match_rate": 0.7, "avg_f1": 0.8, "hallucination_rate": 0.1},
+        )
+        mock_sft.return_value = mock_gen
+        mock_rl.return_value = []
+
+        with patch("builtins.print"):
+            main()
+
+        mock_rl.assert_called_once()
+
+    @patch("hallucination_reduction.main.torch.save")
+    @patch("hallucination_reduction.main.reinforcement_learning_loop")
+    @patch("hallucination_reduction.main.evaluate_old_vs_new_generator")
+    @patch("hallucination_reduction.main.sft_finetune_generator")
+    @patch("hallucination_reduction.main.evaluate_classifier")
+    @patch("hallucination_reduction.main.train_discriminator_minibatch")
+    @patch("hallucination_reduction.main.load_discriminator")
+    @patch("hallucination_reduction.main.load_generator")
+    @patch("hallucination_reduction.main.SimpleRetriever")
+    @patch("hallucination_reduction.main.build_corpus_and_qa")
+    @patch("torch.cuda.is_available")
+    def test_saves_models(
+        self,
+        mock_cuda,
+        mock_build,
+        mock_retriever,
+        mock_load_gen,
+        mock_load_disc,
+        mock_train_disc,
+        mock_eval_class,
+        mock_sft,
+        mock_eval_gen,
+        mock_rl,
+        mock_save,
+    ):
+        """Test that models are saved."""
+        mock_cuda.return_value = False
+
+        mock_qa = MagicMock()
+        mock_qa.question = "Q?"
+        mock_qa.answer = "A"
+        mock_qa.supporting_passages = ["P"]
+        mock_build.return_value = (["passage"], [mock_qa])
+        mock_retriever.return_value = MagicMock()
+
+        mock_gen = MagicMock()
+        mock_tok = MagicMock()
+        mock_load_gen.return_value = (mock_tok, mock_gen)
+
+        mock_disc = MagicMock()
+        mock_disc_tok = MagicMock()
+        mock_load_disc.return_value = (mock_disc_tok, mock_disc)
+
+        mock_train_disc.return_value = mock_disc
+        mock_eval_class.return_value = {"acc": 0.9, "prec": 0.9, "rec": 0.9, "f1": 0.9}
+        mock_eval_gen.return_value = (
+            [{"question": "Q?", "gold": "A", "old": "O", "new": "N"}],
+            {"exact_match_rate": 0.5, "avg_f1": 0.6, "hallucination_rate": 0.3},
+            {"exact_match_rate": 0.7, "avg_f1": 0.8, "hallucination_rate": 0.1},
+        )
+        mock_sft.return_value = mock_gen
+        mock_rl.return_value = []
+
+        with patch("builtins.print"):
+            main()
+
+        # Should save 4 models: generator, fact_disc, style_disc, safety_disc
+        assert mock_save.call_count == 4
+
+    @patch("hallucination_reduction.main.torch.save")
+    @patch("hallucination_reduction.main.reinforcement_learning_loop")
+    @patch("hallucination_reduction.main.evaluate_old_vs_new_generator")
+    @patch("hallucination_reduction.main.sft_finetune_generator")
+    @patch("hallucination_reduction.main.evaluate_classifier")
+    @patch("hallucination_reduction.main.train_discriminator_minibatch")
+    @patch("hallucination_reduction.main.load_discriminator")
+    @patch("hallucination_reduction.main.load_generator")
+    @patch("hallucination_reduction.main.SimpleRetriever")
+    @patch("hallucination_reduction.main.build_corpus_and_qa")
+    @patch("torch.cuda.is_available")
+    def test_evaluates_before_and_after_training(
+        self,
+        mock_cuda,
+        mock_build,
+        mock_retriever,
+        mock_load_gen,
+        mock_load_disc,
+        mock_train_disc,
+        mock_eval_class,
+        mock_sft,
+        mock_eval_gen,
+        mock_rl,
+        mock_save,
+    ):
+        """Test that evaluation happens before and after training."""
+        mock_cuda.return_value = False
+
+        mock_qa = MagicMock()
+        mock_qa.question = "Q?"
+        mock_qa.answer = "A"
+        mock_qa.supporting_passages = ["P"]
+        mock_build.return_value = (["passage"], [mock_qa])
+        mock_retriever.return_value = MagicMock()
+
+        mock_gen = MagicMock()
+        mock_tok = MagicMock()
+        mock_load_gen.return_value = (mock_tok, mock_gen)
+
+        mock_disc = MagicMock()
+        mock_disc_tok = MagicMock()
+        mock_load_disc.return_value = (mock_disc_tok, mock_disc)
+
+        mock_train_disc.return_value = mock_disc
+        mock_eval_class.return_value = {"acc": 0.9, "prec": 0.9, "rec": 0.9, "f1": 0.9}
+        mock_eval_gen.return_value = (
+            [{"question": "Q?", "gold": "A", "old": "O", "new": "N"}],
+            {"exact_match_rate": 0.5, "avg_f1": 0.6, "hallucination_rate": 0.3},
+            {"exact_match_rate": 0.7, "avg_f1": 0.8, "hallucination_rate": 0.1},
+        )
+        mock_sft.return_value = mock_gen
+        mock_rl.return_value = []
+
+        with patch("builtins.print"):
+            main()
+
+        # Should evaluate: baseline, after SFT, final
+        assert mock_eval_gen.call_count >= 3
+
+    @patch("hallucination_reduction.main.torch.save")
+    @patch("hallucination_reduction.main.reinforcement_learning_loop")
+    @patch("hallucination_reduction.main.evaluate_old_vs_new_generator")
+    @patch("hallucination_reduction.main.sft_finetune_generator")
+    @patch("hallucination_reduction.main.evaluate_classifier")
+    @patch("hallucination_reduction.main.train_discriminator_minibatch")
+    @patch("hallucination_reduction.main.load_discriminator")
+    @patch("hallucination_reduction.main.load_generator")
+    @patch("hallucination_reduction.main.SimpleRetriever")
+    @patch("hallucination_reduction.main.build_corpus_and_qa")
+    @patch("torch.cuda.is_available")
+    def test_creates_baseline_generator_copy(
+        self,
+        mock_cuda,
+        mock_build,
+        mock_retriever,
+        mock_load_gen,
+        mock_load_disc,
+        mock_train_disc,
+        mock_eval_class,
+        mock_sft,
+        mock_eval_gen,
+        mock_rl,
+        mock_save,
+    ):
+        """Test that a baseline copy of generator is created."""
+        mock_cuda.return_value = False
+
+        mock_qa = MagicMock()
+        mock_qa.question = "Q?"
+        mock_qa.answer = "A"
+        mock_qa.supporting_passages = ["P"]
+        mock_build.return_value = (["passage"], [mock_qa])
+        mock_retriever.return_value = MagicMock()
+
+        mock_gen = MagicMock()
+        mock_tok = MagicMock()
+        mock_load_gen.return_value = (mock_tok, mock_gen)
+
+        mock_disc = MagicMock()
+        mock_disc_tok = MagicMock()
+        mock_load_disc.return_value = (mock_disc_tok, mock_disc)
+
+        mock_train_disc.return_value = mock_disc
+        mock_eval_class.return_value = {"acc": 0.9, "prec": 0.9, "rec": 0.9, "f1": 0.9}
+        mock_eval_gen.return_value = (
+            [{"question": "Q?", "gold": "A", "old": "O", "new": "N"}],
+            {"exact_match_rate": 0.5, "avg_f1": 0.6, "hallucination_rate": 0.3},
+            {"exact_match_rate": 0.7, "avg_f1": 0.8, "hallucination_rate": 0.1},
+        )
+        mock_sft.return_value = mock_gen
+        mock_rl.return_value = []
+
+        with patch("builtins.print"):
+            with patch("hallucination_reduction.main.copy.deepcopy") as mock_deepcopy:
+                mock_deepcopy.return_value = MagicMock()
+                main()
+
+                # Should create a deep copy for baseline
+                mock_deepcopy.assert_called_once()
diff --git a/tests/unit/test_rl_utils.py b/tests/unit/test_rl_utils.py
new file mode 100644
index 0000000..10d4204
--- /dev/null
+++ b/tests/unit/test_rl_utils.py
@@ -0,0 +1,710 @@
+from unittest.mock import MagicMock, patch
+
+import pytest
+import torch
+
+from hallucination_reduction.rl_utils import (
+    compute_reward,
+    is_repetitive,
+    monte_carlo_rewards,
+    reinforce_update,
+    reinforcement_learning_loop,
+    safe_save_state,
+)
+
+
+class TestIsRepetitive:
+    """Test suite for is_repetitive function."""
+
+    def test_function_exists(self):
+        """Test that is_repetitive can be imported."""
+        assert callable(is_repetitive)
+
+    def test_empty_string_not_repetitive(self):
+        """Test that empty string is not repetitive."""
+        assert is_repetitive("") is False
+
+    def test_normal_text_not_repetitive(self):
+        """Test that normal text is not repetitive."""
+        text = "This is a normal sentence with different words"
+        assert is_repetitive(text) is False
+
+    def test_highly_repetitive_text(self):
+        """Test that highly repetitive text is detected."""
+        text = "the the the the the the the the the the"
+        assert is_repetitive(text) is True
+
+    def test_barely_repetitive_text(self):
+        """Test text at the threshold."""
+        # 6 out of 10 tokens are "the" (60%)
+        text = "the the the the the the word word word word"
+        result = is_repetitive(text, repeat_threshold=0.6)
+        assert result is True
+
+    def test_just_below_threshold(self):
+        """Test text just below threshold is not repetitive."""
+        # 5 out of 10 tokens are "the" (50%)
+        text = "the the the the the word word word word word"
+        result = is_repetitive(text, repeat_threshold=0.6)
+        assert result is False
+
+    def test_single_word(self):
+        """Test single word text."""
+        text = "word"
+        # 1 out of 1 = 100%, above threshold
+        assert is_repetitive(text) is True
+
+    def test_two_different_words(self):
+        """Test two different words."""
+        text = "word1 word2"
+        # Max is 1 out of 2 = 50%
+        assert is_repetitive(text, repeat_threshold=0.6) is False
+
+    def test_custom_threshold(self):
+        """Test with custom threshold."""
+        text = "a a a b b"
+        # 3 out of 5 = 60%
+        assert is_repetitive(text, repeat_threshold=0.5) is True
+        assert is_repetitive(text, repeat_threshold=0.7) is False
+
+    def test_whitespace_only(self):
+        """Test string with only whitespace."""
+        text = "   "
+        assert is_repetitive(text) is False
+
+
+class TestSafeSaveState:
+    """Test suite for safe_save_state function."""
+
+    def test_function_exists(self):
+        """Test that safe_save_state can be imported."""
+        assert callable(safe_save_state)
+
+    def test_saves_model_successfully(self):
+        """Test successful model save."""
+        model = MagicMock()
+        model.state_dict.return_value = {"weight": torch.randn(10, 10)}
+
+        with patch("torch.save") as mock_save:
+            safe_save_state(model, "test_path.pt")
+            mock_save.assert_called_once()
+
+    def test_handles_save_exception(self):
+        """Test that exceptions during save are caught."""
+        model = MagicMock()
+        model.state_dict.return_value = {"weight": torch.randn(10, 10)}
+
+        with patch("torch.save", side_effect=Exception("Save failed")):
+            with patch("builtins.print") as mock_print:
+                # Should not raise exception
+                safe_save_state(model, "test_path.pt")
+                # Should print warning
+                assert mock_print.called
+
+
+class TestComputeReward:
+    """Test suite for compute_reward function."""
+
+    @pytest.fixture
+    def mock_discriminators(self):
+        """Create mock discriminators."""
+        fact_disc = MagicMock()
+        style_disc = MagicMock()
+        safety_disc = MagicMock()
+        return fact_disc, style_disc, safety_disc
+
+    @pytest.fixture
+    def mock_tokenizers(self):
+        """Create mock tokenizers."""
+        fact_tok = MagicMock()
+        style_tok = MagicMock()
+        safety_tok = MagicMock()
+        return fact_tok, style_tok, safety_tok
+
+    def test_function_exists(self):
+        """Test that compute_reward can be imported."""
+        assert callable(compute_reward)
+
+    def test_returns_tuple(self, mock_discriminators, mock_tokenizers):
+        """Test that compute_reward returns a tuple."""
+        fact_disc, style_disc, safety_disc = mock_discriminators
+        fact_tok, style_tok, safety_tok = mock_tokenizers
+
+        with patch(
+            "hallucination_reduction.rl_utils.discriminator_predict_text"
+        ) as mock_pred:
+            mock_pred.return_value = [{"probs": [0.3, 0.7]}]
+
+            with patch(
+                "hallucination_reduction.rl_utils.overlap_fact_check", return_value=0.8
+            ):
+                result = compute_reward(
+                    "Generated answer",
+                    ["doc1"],
+                    ["passage1"],
+                    fact_disc,
+                    style_disc,
+                    safety_disc,
+                    fact_tok,
+                    style_tok,
+                    safety_tok,
+                )
+
+                assert isinstance(result, tuple)
+                assert len(result) == 2
+
+    def test_returns_float_reward_and_debug_dict(
+        self, mock_discriminators, mock_tokenizers
+    ):
+        """Test return types."""
+        fact_disc, style_disc, safety_disc = mock_discriminators
+        fact_tok, style_tok, safety_tok = mock_tokenizers
+
+        with patch(
+            "hallucination_reduction.rl_utils.discriminator_predict_text"
+        ) as mock_pred:
+            mock_pred.return_value = [{"probs": [0.3, 0.7]}]
+
+            with patch(
+                "hallucination_reduction.rl_utils.overlap_fact_check", return_value=0.8
+            ):
+                reward, debug = compute_reward(
+                    "Generated answer",
+                    ["doc1"],
+                    ["passage1"],
+                    fact_disc,
+                    style_disc,
+                    safety_disc,
+                    fact_tok,
+                    style_tok,
+                    safety_tok,
+                )
+
+                assert isinstance(reward, float)
+                assert isinstance(debug, dict)
+
+    def test_debug_contains_expected_keys(self, mock_discriminators, mock_tokenizers):
+        """Test that debug dict contains expected keys."""
+        fact_disc, style_disc, safety_disc = mock_discriminators
+        fact_tok, style_tok, safety_tok = mock_tokenizers
+
+        with patch(
+            "hallucination_reduction.rl_utils.discriminator_predict_text"
+        ) as mock_pred:
+            mock_pred.return_value = [{"probs": [0.3, 0.7]}]
+
+            with patch(
+                "hallucination_reduction.rl_utils.overlap_fact_check", return_value=0.8
+            ):
+                _, debug = compute_reward(
+                    "Generated answer",
+                    ["doc1"],
+                    ["passage1"],
+                    fact_disc,
+                    style_disc,
+                    safety_disc,
+                    fact_tok,
+                    style_tok,
+                    safety_tok,
+                )
+
+                assert "p_fact" in debug
+                assert "p_style" in debug
+                assert "p_safe" in debug
+                assert "overlap" in debug
+                assert "combined" in debug
+
+    def test_reward_in_valid_range(self, mock_discriminators, mock_tokenizers):
+        """Test that reward is in [0, 1] range."""
+        fact_disc, style_disc, safety_disc = mock_discriminators
+        fact_tok, style_tok, safety_tok = mock_tokenizers
+
+        with patch(
+            "hallucination_reduction.rl_utils.discriminator_predict_text"
+        ) as mock_pred:
+            mock_pred.return_value = [{"probs": [0.3, 0.7]}]
+
+            with patch(
+                "hallucination_reduction.rl_utils.overlap_fact_check", return_value=0.8
+            ):
+                reward, _ = compute_reward(
+                    "Generated answer",
+                    ["doc1"],
+                    ["passage1"],
+                    fact_disc,
+                    style_disc,
+                    safety_disc,
+                    fact_tok,
+                    style_tok,
+                    safety_tok,
+                )
+
+                assert 0.0 <= reward <= 1.0
+
+    def test_penalty_applied_when_fact_low(self, mock_discriminators, mock_tokenizers):
+        """Test that penalty is applied when factuality is low."""
+        fact_disc, style_disc, safety_disc = mock_discriminators
+        fact_tok, style_tok, safety_tok = mock_tokenizers
+
+        with patch(
+            "hallucination_reduction.rl_utils.discriminator_predict_text"
+        ) as mock_pred:
+            # Low factuality score (p_fact < 0.5)
+            mock_pred.return_value = [{"probs": [0.7, 0.3]}]
+
+            with patch(
+                "hallucination_reduction.rl_utils.overlap_fact_check", return_value=0.8
+            ):
+                reward, _ = compute_reward(
+                    "Generated answer",
+                    ["doc1"],
+                    ["passage1"],
+                    fact_disc,
+                    style_disc,
+                    safety_disc,
+                    fact_tok,
+                    style_tok,
+                    safety_tok,
+                )
+
+                # Should have penalty applied
+                assert reward >= 0.0
+
+    def test_repetitive_text_penalty(self, mock_discriminators, mock_tokenizers):
+        """Test that repetitive text gets penalty."""
+        fact_disc, style_disc, safety_disc = mock_discriminators
+        fact_tok, style_tok, safety_tok = mock_tokenizers
+
+        with patch(
+            "hallucination_reduction.rl_utils.discriminator_predict_text"
+        ) as mock_pred:
+            mock_pred.return_value = [{"probs": [0.3, 0.7]}]
+
+            with patch(
+                "hallucination_reduction.rl_utils.overlap_fact_check", return_value=0.8
+            ):
+                # Repetitive text
+                reward, _ = compute_reward(
+                    "the the the the the the the the",
+                    ["doc1"],
+                    ["passage1"],
+                    fact_disc,
+                    style_disc,
+                    safety_disc,
+                    fact_tok,
+                    style_tok,
+                    safety_tok,
+                )
+
+                # Should have low reward due to repetition penalty
+                assert reward < 0.5
+
+
+class TestMonteCarloRewards:
+    """Test suite for monte_carlo_rewards function."""
+
+    @pytest.fixture
+    def mock_generator(self):
+        """Create mock generator."""
+        generator = MagicMock()
+        return generator
+
+    @pytest.fixture
+    def mock_tokenizer(self):
+        """Create mock tokenizer."""
+        return MagicMock()
+
+    @pytest.fixture
+    def mock_discriminators(self):
+        """Create mock discriminators."""
+        return MagicMock(), MagicMock(), MagicMock()
+
+    @pytest.fixture
+    def mock_tokenizers(self):
+        """Create mock tokenizers."""
+        return MagicMock(), MagicMock(), MagicMock()
+
+    def test_function_exists(self):
+        """Test that monte_carlo_rewards can be imported."""
+        assert callable(monte_carlo_rewards)
+
+    def test_returns_tuple_of_three(
+        self, mock_generator, mock_tokenizer, mock_discriminators, mock_tokenizers
+    ):
+        """Test that function returns 3 items."""
+        fact_disc, style_disc, safety_disc = mock_discriminators
+        fact_tok, style_tok, safety_tok = mock_tokenizers
+
+        with patch("hallucination_reduction.rl_utils.generate_answer") as mock_gen:
+            mock_gen.return_value = ["sample1", "sample2", "sample3"]
+
+            with patch(
+                "hallucination_reduction.rl_utils.compute_reward"
+            ) as mock_reward:
+                mock_reward.return_value = (0.7, {"p_fact": 0.8})
+
+                result = monte_carlo_rewards(
+                    "prompt",
+                    mock_generator,
+                    mock_tokenizer,
+                    ["doc1"],
+                    ["passage1"],
+                    fact_disc,
+                    style_disc,
+                    safety_disc,
+                    fact_tok,
+                    style_tok,
+                    safety_tok,
+                )
+
+                assert len(result) == 3
+
+    def test_returns_avg_reward_debug_samples(
+        self, mock_generator, mock_tokenizer, mock_discriminators, mock_tokenizers
+    ):
+        """Test return types."""
+        fact_disc, style_disc, safety_disc = mock_discriminators
+        fact_tok, style_tok, safety_tok = mock_tokenizers
+
+        with patch("hallucination_reduction.rl_utils.generate_answer") as mock_gen:
+            mock_gen.return_value = ["sample1", "sample2"]
+
+            with patch(
+                "hallucination_reduction.rl_utils.compute_reward"
+            ) as mock_reward:
+                mock_reward.return_value = (0.7, {"p_fact": 0.8})
+
+                avg_reward, debug_list, samples = monte_carlo_rewards(
+                    "prompt",
+                    mock_generator,
+                    mock_tokenizer,
+                    ["doc1"],
+                    ["passage1"],
+                    fact_disc,
+                    style_disc,
+                    safety_disc,
+                    fact_tok,
+                    style_tok,
+                    safety_tok,
+                )
+
+                assert isinstance(avg_reward, float)
+                assert isinstance(debug_list, list)
+                assert isinstance(samples, list)
+
+    def test_sets_generator_to_eval_mode(
+        self, mock_generator, mock_tokenizer, mock_discriminators, mock_tokenizers
+    ):
+        """Test that generator is set to eval mode."""
+        fact_disc, style_disc, safety_disc = mock_discriminators
+        fact_tok, style_tok, safety_tok = mock_tokenizers
+
+        with patch("hallucination_reduction.rl_utils.generate_answer") as mock_gen:
+            mock_gen.return_value = ["sample1"]
+
+            with patch(
+                "hallucination_reduction.rl_utils.compute_reward"
+            ) as mock_reward:
+                mock_reward.return_value = (0.7, {"p_fact": 0.8})
+
+                monte_carlo_rewards(
+                    "prompt",
+                    mock_generator,
+                    mock_tokenizer,
+                    ["doc1"],
+                    ["passage1"],
+                    fact_disc,
+                    style_disc,
+                    safety_disc,
+                    fact_tok,
+                    style_tok,
+                    safety_tok,
+                )
+
+                mock_generator.eval.assert_called()
+
+    def test_computes_average_reward(
+        self, mock_generator, mock_tokenizer, mock_discriminators, mock_tokenizers
+    ):
+        """Test that average reward is computed correctly."""
+        fact_disc, style_disc, safety_disc = mock_discriminators
+        fact_tok, style_tok, safety_tok = mock_tokenizers
+
+        with patch("hallucination_reduction.rl_utils.generate_answer") as mock_gen:
+            mock_gen.return_value = ["sample1", "sample2", "sample3"]
+
+            with patch(
+                "hallucination_reduction.rl_utils.compute_reward"
+            ) as mock_reward:
+                # Return different rewards for each sample
+                mock_reward.side_effect = [
+                    (0.6, {"p_fact": 0.7}),
+                    (0.8, {"p_fact": 0.9}),
+                    (0.7, {"p_fact": 0.8}),
+                ]
+
+                avg_reward, _, _ = monte_carlo_rewards(
+                    "prompt",
+                    mock_generator,
+                    mock_tokenizer,
+                    ["doc1"],
+                    ["passage1"],
+                    fact_disc,
+                    style_disc,
+                    safety_disc,
+                    fact_tok,
+                    style_tok,
+                    safety_tok,
+                    n_rollouts=3,
+                )
+
+                # Average of 0.6, 0.8, 0.7 = 0.7
+                assert abs(avg_reward - 0.7) < 0.01
+
+
+class TestReinforceUpdate:
+    """Test suite for reinforce_update function."""
+
+    @pytest.fixture
+    def mock_generator(self):
+        """Create mock generator."""
+        generator = MagicMock()
+        mock_output = MagicMock()
+        # Logits must require grad for backward() to work in tests
+        logits = torch.randn(1, 10, 1000, requires_grad=True)
+        mock_output.logits = logits
+        generator.return_value = mock_output
+        generator.parameters.return_value = [torch.nn.Parameter(torch.randn(10, 10))]
+        return generator
+
+    @pytest.fixture
+    def mock_tokenizer(self):
+        """Create mock tokenizer."""
+        tokenizer = MagicMock()
+        mock_encoding = MagicMock()
+        mock_encoding.input_ids = torch.randint(0, 1000, (1, 10))
+        mock_encoding.attention_mask = torch.ones(1, 10)
+        mock_encoding.to.return_value = mock_encoding
+        tokenizer.return_value = mock_encoding
+        return tokenizer
+
+    @pytest.fixture
+    def mock_optimizer(self):
+        """Create mock optimizer."""
+        return MagicMock()
+
+    def test_function_exists(self):
+        """Test that reinforce_update can be imported."""
+        assert callable(reinforce_update)
+
+    def test_returns_float(self, mock_generator, mock_tokenizer, mock_optimizer):
+        """Test that function returns a float."""
+        prompts = ["prompt1"]
+        samples = ["sample1"]
+        rewards = [0.7]
+
+        result = reinforce_update(
+            mock_generator, mock_tokenizer, prompts, samples, rewards, mock_optimizer
+        )
+
+        assert isinstance(result, float)
+
+    def test_handles_empty_prompts(
+        self, mock_generator, mock_tokenizer, mock_optimizer
+    ):
+        """Test handling of empty prompts list."""
+        result = reinforce_update(
+            mock_generator, mock_tokenizer, [], [], [], mock_optimizer
+        )
+
+        assert result == 0.0
+
+    def test_sets_generator_to_train_mode(
+        self, mock_generator, mock_tokenizer, mock_optimizer
+    ):
+        """Test that generator is set to train mode."""
+        prompts = ["prompt1"]
+        samples = ["sample1"]
+        rewards = [0.7]
+
+        reinforce_update(
+            mock_generator, mock_tokenizer, prompts, samples, rewards, mock_optimizer
+        )
+
+        mock_generator.train.assert_called()
+
+    def test_calls_optimizer_step(self, mock_generator, mock_tokenizer, mock_optimizer):
+        """Test that optimizer step is called."""
+        prompts = ["prompt1"]
+        samples = ["sample1"]
+        rewards = [0.7]
+
+        reinforce_update(
+            mock_generator, mock_tokenizer, prompts, samples, rewards, mock_optimizer
+        )
+
+        mock_optimizer.step.assert_called()
+
+    def test_handles_generator_error_gracefully(self, mock_tokenizer, mock_optimizer):
+        """Test that generator errors are handled."""
+        mock_gen = MagicMock()
+        mock_gen.side_effect = RuntimeError("Generator error")
+
+        prompts = ["prompt1"]
+        samples = ["sample1"]
+        rewards = [0.7]
+
+        with patch("builtins.print"):
+            result = reinforce_update(
+                mock_gen, mock_tokenizer, prompts, samples, rewards, mock_optimizer
+            )
+
+            # Should return 0.0 on error
+            assert result == 0.0
+
+
+class TestReinforcementLearningLoop:
+    """Test suite for reinforcement_learning_loop function."""
+
+    @pytest.fixture
+    def mock_components(self):
+        """Create all mock components."""
+        generator = MagicMock()
+        gen_tokenizer = MagicMock()
+        fact_disc = MagicMock()
+        style_disc = MagicMock()
+        safety_disc = MagicMock()
+        fact_tok = MagicMock()
+        style_tok = MagicMock()
+        safety_tok = MagicMock()
+        retriever = MagicMock()
+
+        return {
+            "generator": generator,
+            "gen_tokenizer": gen_tokenizer,
+            "fact_disc": fact_disc,
+            "style_disc": style_disc,
+            "safety_disc": safety_disc,
+            "fact_tok": fact_tok,
+            "style_tok": style_tok,
+            "safety_tok": safety_tok,
+            "retriever": retriever,
+        }
+
+    @pytest.fixture
+    def mock_qa_pairs(self):
+        """Create mock QA pairs."""
+        qa = MagicMock()
+        qa.question = "What is Python?"
+        qa.answer = "A programming language"
+        qa.supporting_passages = ["Python is a language"]
+        return [qa]
+
+    def test_function_exists(self):
+        """Test that reinforcement_learning_loop can be imported."""
+        assert callable(reinforcement_learning_loop)
+
+    def test_returns_history(self, mock_components, mock_qa_pairs):
+        """Test that function returns history list."""
+        with patch("hallucination_reduction.rl_utils.monte_carlo_rewards") as mock_mc:
+            mock_mc.return_value = (
+                0.7,
+                [{"sample": "test", "debug": {"combined": 0.7}}],
+                ["sample"],
+            )
+
+            with patch(
+                "hallucination_reduction.rl_utils.reinforce_update", return_value=0.1
+            ):
+                with patch("hallucination_reduction.rl_utils.optim.AdamW"):
+                    with patch("torch.save"):
+                        with patch("builtins.print"):
+                            mock_components["retriever"].retrieve.return_value = [
+                                (0, "doc")
+                            ]
+
+                            history = reinforcement_learning_loop(
+                                mock_components["generator"],
+                                mock_components["gen_tokenizer"],
+                                mock_components["fact_disc"],
+                                mock_components["style_disc"],
+                                mock_components["safety_disc"],
+                                mock_components["fact_tok"],
+                                mock_components["style_tok"],
+                                mock_components["safety_tok"],
+                                mock_components["retriever"],
+                                mock_qa_pairs,
+                            )
+
+                            assert isinstance(history, list)
+
+    def test_saves_checkpoints(self, mock_components, mock_qa_pairs):
+        """Test that checkpoints are saved."""
+        with patch("hallucination_reduction.rl_utils.monte_carlo_rewards") as mock_mc:
+            mock_mc.return_value = (
+                0.7,
+                [{"sample": "test", "debug": {"combined": 0.7}}],
+                ["sample"],
+            )
+
+            with patch(
+                "hallucination_reduction.rl_utils.reinforce_update", return_value=0.1
+            ):
+                with patch("hallucination_reduction.rl_utils.optim.AdamW"):
+                    with patch("torch.save") as mock_save:
+                        with patch("builtins.print"):
+                            mock_components["retriever"].retrieve.return_value = [
+                                (0, "doc")
+                            ]
+
+                            reinforcement_learning_loop(
+                                mock_components["generator"],
+                                mock_components["gen_tokenizer"],
+                                mock_components["fact_disc"],
+                                mock_components["style_disc"],
+                                mock_components["safety_disc"],
+                                mock_components["fact_tok"],
+                                mock_components["style_tok"],
+                                mock_components["safety_tok"],
+                                mock_components["retriever"],
+                                mock_qa_pairs,
+                            )
+
+                            # Should save checkpoints
+                            assert mock_save.called
+
+    def test_creates_optimizer(self, mock_components, mock_qa_pairs):
+        """Test that optimizer is created."""
+        with patch("hallucination_reduction.rl_utils.monte_carlo_rewards") as mock_mc:
+            mock_mc.return_value = (
+                0.7,
+                [{"sample": "test", "debug": {"combined": 0.7}}],
+                ["sample"],
+            )
+
+            with patch(
+                "hallucination_reduction.rl_utils.reinforce_update", return_value=0.1
+            ):
+                with patch(
+                    "hallucination_reduction.rl_utils.optim.AdamW"
+                ) as mock_adamw:
+                    with patch("torch.save"):
+                        with patch("builtins.print"):
+                            mock_components["retriever"].retrieve.return_value = [
+                                (0, "doc")
+                            ]
+
+                            reinforcement_learning_loop(
+                                mock_components["generator"],
+                                mock_components["gen_tokenizer"],
+                                mock_components["fact_disc"],
+                                mock_components["style_disc"],
+                                mock_components["safety_disc"],
+                                mock_components["fact_tok"],
+                                mock_components["style_tok"],
+                                mock_components["safety_tok"],
+                                mock_components["retriever"],
+                                mock_qa_pairs,
+                            )
+
+                            mock_adamw.assert_called_once()