import hashlib

invoice_v1 = b"Invoice 1042 | Amount 2,50,000 | Payee: Exporter A"
stored_hash = hashlib.sha256(invoice_v1).hexdigest()

received = b"Invoice 1042 | Amount 2,90,000 | Payee: Exporter A"
ok = hashlib.sha256(received).hexdigest() == stored_hash
print("Document unchanged?", ok)    # False — the amount was altered

Why banks usually choose permissioned ledgers
Public chain:       anyone can join and read; strong openness
Permissioned chain: only approved institutions join; identity known
Banks need:         known participants, privacy, regulatory control,
                    predictable performance
So most banking pilots use permissioned distributed ledgers.

Simplified trade finance flow on a shared ledger
1. Exporter uploads invoice hash and shipping document reference
2. Shipper confirms goods loaded → status updated on ledger
3. Importer's bank sees confirmation without separate emails
4. Smart contract marks payment due when agreed conditions are met
5. All permitted parties see the same, time-stamped history
Real systems add identity checks, privacy controls and legal agreements.

import hashlib

def h(x): return hashlib.sha256(x.encode()).hexdigest()

txns = ["pay A->B 100", "pay B->C 40", "pay C->D 25", "pay D->A 10"]
level = [h(t) for t in txns]
while len(level) > 1:
    level = [h(level[i] + level[i + 1]) for i in range(0, len(level), 2)]
print("Merkle root:", level[0][:16])
# One short root summarises all transactions in a block;
# changing any transaction changes the root.

Is blockchain the right fit? (answer Yes/No)
1. Do several independent organisations need the same records?   ___
2. Do they lack a trusted central party they all accept?         ___
3. Is reconciliation slow or costly today?                       ___
4. Can participant identities be known and managed?              ___
5. Can privacy rules be met with the design?                     ___
Mostly No → a shared database or API may be better

Privacy pattern: keep data off-chain, proofs on-chain
Off-chain (bank systems): full customer and document data
On-chain (shared ledger): document hash, status, timestamps, party IDs
Verification: any party recomputes the hash of the document it holds
             and compares with the ledger
Benefit: tamper evidence without exposing private details

Case study: blockchain for [use case]
1. Current process and pain points
2. Parties involved and their incentives
3. Proposed ledger design (permissioned? what is on-chain?)
4. Smart contract rules (if any)
5. Privacy and regulatory considerations
6. Integration with existing systems
7. Risks and alternatives (would a shared database work?)
8. Success measures

Stakeholder Map
Party            Role            Benefit from ledger     Concern
Bank A           ______          ______________          ______
Bank B           ______          ______________          ______
Corporate client ______          ______________          ______
Regulator        ______          ______________          ______

Learning path for banking blockchain roles
☐ Banking basics: payments, trade finance, KYC, settlement
☐ Blockchain fundamentals: hashing, consensus, permissioned ledgers
☐ Smart contracts basics
☐ Data protection and regulatory awareness
☐ Integration: APIs, databases
☐ One case study write-up