RACI Matrix
RACI Matrix: {{PROJECT_NAME}}Drop — Fintech Payment App
Project: {{PROJECT_NAME}}Drop — Remittance + QR Payments
Version: {{VERSION}}1.0
Date: {{DATE}}2026-02-23
Author: {{AUTHOR}}John (AI Director)
Status: Draft | In Review | Approved
Reviewers: {{REVIEWERS}}Alem Bašić (CEO)
Document History
| Version |
Date |
Author |
Changes |
| 0.1 |
{{DATE}}2026-02-23 |
{{AUTHOR}}John |
Initial draft — Drop-specific roles and activities |
1. Purpose & How to Use This Matrix
This RACI matrix defines responsibility assignments for all activitiesDrop project activities. Drop is an AI-native internal product of ALAI Holding AS. Most "team" roles are filled by AI agents coordinated by John (AI Director). Alem Bašić (CEO) is the sole human, responsible for strategic decisions, partnerships, and deliverablesregulatory in the {{PROJECT_NAME}} project. It serves as the authoritative reference for:submissions.
Who does the work (Responsible)
Who is ultimately answerable for the outcome (Accountable)
Who provides input and expertise (Consulted)
Who needs to be kept informed (Informed)
Conflict resolution: When disagreements arise about ownership, refer to this document. Disputes escalate to the Accountable party, then to John (AI Director), ifthen unresolved.Alem (CEO) for strategic/financial issues.
2. RACI Definitions
| Letter |
Role |
Definition |
Rule |
| R |
Responsible |
The person(s) who doDoes the work to complete the activity |
Can be multiple per activity |
| A |
Accountable |
The one person who is ultimatelyUltimately answerable; signs off on completion |
MUST be exactly ONEone per activity |
| C |
Consulted |
Provides expertise/input; two-way communication required |
Optional; should be minimized |
| I |
Informed |
Kept up to date on decisions/progress;updated; one-way communication |
Should be only those who need to know |
Common Mistakes to Avoid:
Multiple A's on one activity — pick one, make others C or I
No R — every activity must have someone doing the work
Too many C's — consult only who truly adds value; too many slows work down
Missing I's — key stakeholders left uninformed create escalations
3. Project Roles
| Role Code |
Role Title |
Person / Agent |
Org |
Notes |
| CEO |
Chief Executive Officer |
Alem | ALAIBašić |
Strategic decisions, finalpartnerships, budgetbudget, approvalregulatory submissions |
| JD |
AI Director |
John | ALAI(Claude Opus) |
Delivery accountability, architecture, agent coordination |
PMBUILD |
ProjectBuilder ManagerAgent |
{{NAME/AGENT}}Claude Sonnet (per-task) |
ALAI | Feature Day-to-dayimplementation, coordination,API reportingroutes, frontend |
POVAL |
ProductValidator OwnerAgent |
{{NAME/AGENT}}Claude Sonnet (per-task) |
ALAITesting, /validation, Client | code Backlog,review requirements prioritization(read-only) |
BASEC |
BusinessSecurity AnalystAgent |
{{NAME/AGENT}}Claude (per-sprint) |
ALAI | Threat Requirementsmodelling, elicitation,security documentationaudit, compliance checks |
TLLEGAL |
TechLegal LeadAgent |
{{NAME/AGENT}}Claude (as needed) |
ALAI |
Architecture, codeRegulatory review, technicaldocument decisionsdrafting |
DEVFIN |
Developer(s)Finance Agent |
{{NAME/AGENT}}Claude (as needed) |
ALAI | Budget Featureanalysis, implementationfinancial projections |
DESEXT |
DesignerExternal Advisor |
{{NAME/AGENT}}TBD (human) |
ALAILegal /advisor Contract | for UI/UX,Finanstilsynet, visualBaaS assets |
QA |
QA Engineer |
{{NAME/AGENT}} |
ALAI |
Test planning, execution, sign-off |
OPS |
DevOps / Infrastructure |
{{NAME/AGENT}} |
ALAI |
CI/CD, deployment, monitoring |
CS |
Client Sponsor |
{{NAME}} |
{{CLIENT}} |
Executive decisions, final acceptance |
CPO |
Client Product Owner |
{{NAME}} |
{{CLIENT}} |
Day-to-day client requirementscontracts |
4. RACI Matrix — Project Phases & Activities
4.1 Project Initiation & Planning
| Activity / Deliverable |
CEO |
JD |
PMBUILD |
POVAL |
BASEC |
TLLEGAL |
DEVFIN |
DES |
QA |
OPS |
CS |
CPOEXT |
Project Charter creation |
I |
A |
R |
C |
C |
C |
|
|
|
|
C |
I |
|
Project Brief / Proposal |
I |
A |
R |
R |
R |
C |
|
|
|
C |
IC |
I |
| Budget approval |
A |
C |
I |
I |
|
|
|
|
|
|
I |
|
Stakeholder identification |
I |
C |
R |
C |
R |
|
|
|
|
|
A |
C |
Communication Plan |
I |
C |
A |
C |
R |
|
|
|
|
|
I |
I |
| Risk Register (initial) |
I |
C |
A |
C |
C |
R |
|
|
|
|
C |
IC |
C |
|
| RACI Matrix |
I |
A |
|
|
|
|
|
|
| Stakeholder identification |
C |
A |
|
|
|
R |
C |
|
| Communication Plan |
I |
A |
|
|
|
|
|
|
I |
|
Project kick-off meeting |
I |
A |
R |
R |
R |
R |
R |
R |
R |
R |
A |
R |
4.2 Requirements & Analysis
| Activity / Deliverable |
CEO |
JD |
PMBUILD |
POVAL |
BASEC |
TLLEGAL |
DEVFIN |
DES |
QA |
OPS |
CS |
CPOEXT |
DiscoveryBusiness workshopsRequirements Document (BRD) |
IC |
IA |
|
|
|
R |
R |
|
| Functional Requirements (FRS) |
C |
A |
R |
|
C |
|
|
|
| Non-Functional Requirements |
C |
A |
R |
|
C |
|
|
|
| User Stories |
I |
A |
R |
|
|
|
|
C |
R |
BusinessAcceptance Requirements Doc (BRD) |
I |
CCriteria |
I |
A |
R |
C |
|
|
|
|
C |
R |
Functional Requirements (FRS) |
I |
C |
I |
A |
R |
R |
C |
C |
C |
|
I |
R |
Non-Functional Requirements |
I |
C |
I |
C |
R |
A |
C |
|
C |
C |
I |
C |
User Stories (backlog creation) |
I |
I |
I |
A |
R |
C |
C |
|
|
|
I |
R |
Requirements sign-off |
A |
C |
I |
C |
R |
I |
|
|
|
|
A |
R |
| Requirements Traceability Matrix |
I |
I |
I |
A |
R |
C |
|
|
R |
|
| Regulatory requirements mapping |
C |
C |
|
I |
I |
A |
|
R |
4.3 Architecture & Design
| Activity / Deliverable |
CEO |
JD |
PMBUILD |
POVAL |
BASEC |
TLLEGAL |
DEVFIN |
DES |
QA |
OPS |
CS |
CPOEXT |
UXSystem researcharchitecture / user flows(ADRs) |
I |
I |
I |
C |
C |
|
|
A |
|
|
I |
R |
Wireframes |
I |
I |
I |
C |
C |
|
|
A |
|
|
I |
R |
High-fidelity mockups |
I |
I |
I |
C |
|
C |
|
A |
|
|
R |
C |
Design system / style guide |
I |
I |
I |
C |
|
C |
C |
A |
|
|
I |
I |
Design review & approval |
I |
C |
I |
C |
|
C |
|
R |
|
|
A |
C |
Technical architecture design |
I |
C |
I |
C |
C |
A |
R |
|
|
C |
|
|
Architecture Decision Records (ADRs) |
I |
C |
|
|
|
A |
R |
|
|
C |
|
|
| Database schema design |
I |
|
I |
C |
C |
A |
R |
|
C |
C |
|
|
| API contract design |
I |
A |
R |
|
C |
|
|
|
| Security architecture |
I |
C |
C |
|
A |
|
|
|
| PSD2 pass-through model design |
I |
A |
R |
|
C |
|
|
C |
| UI/UX design (Figma) |
I |
A |
|
|
|
|
|
|
| Infrastructure design (Fly.io / Docker) |
I |
A |
IR |
|
|
C |
|
|
|
A |
|
|
4.4 Development
| Activity / Deliverable |
CEO |
JD |
PMBUILD |
POVAL |
BASEC |
TLLEGAL |
DEVFIN |
DES |
QA |
OPS |
CS |
CPOEXT |
SprintBackend planningAPI routes (26 endpoints) |
|
I |
C |
A |
C |
C |
R |
|
C |
|
|
I |
FeatureFrontend implementation | pages | (Next.js I | — I | 10 I |
|
C |
A |
|
|
|
|
|
Code review |
|
|
I |
screens) |
|
A |
R |
|
|
|
|
|
UnitDatabase testschema writing+ migrations |
|
A |
I |
|
|
C |
AR |
|
C |
|
|
|
IntegrationAuthentication development(JWT + BankID mock) |
|
|
I |
|
C |
A |
R |
|
|
C |
|
|
UI implementation |
|
|
I |
C |
|
C |
R |
A |
|
|
|
|
DailyRemittance standupflow implementation |
|
I |
A |
R |
R |
RC |
R |
R |
R |
R |
|
|
SprintQR demopayment flow implementation |
|
I |
R |
A |
R |
R |
RC |
R |
R |
R |
I |
R |
Sprint retrospective |
|
I |
A |
R |
R |
R |
R |
R |
R |
R |
|
|
TechnicalMerchant documentation | dashboard |
|
I |
implementation |
|
A |
R |
|
|
|
|
|
| Feature flags implementation |
|
A |
R |
|
|
|
|
|
| CI/CD pipeline (GitHub Actions) |
|
A |
R |
|
|
|
|
|
| Docker containerisation |
|
A |
R |
|
|
|
|
|
| Code review |
|
A |
|
R |
|
|
|
|
| Unit test writing |
|
A |
R |
C |
|
|
|
|
4.5 TestingSecurity &Hardening Quality(Phase Assurance0.5)
| Activity / Deliverable |
CEO |
JD |
PMBUILD |
POVAL |
BASEC |
TLLEGAL |
DEVFIN |
DES |
QA |
OPS |
CS |
CPOEXT |
TestSecurity planaudit creation(full codebase) |
I |
|
I |
C |
C |
C |
|
|
A |
|
|
I |
TestJWT casesecret creation |
|
|
I |
C |
C |
C |
Chardening |
|
A |
|
|
I |
Unit testing execution |
|
|
I |
R |
|
C |
R |
|
A |
|
|
|
IntegrationCVV/card testingdata removal |
|
A |
I |
R |
|
C |
R |
|
A |
C |
|
|
PerformanceCSRF testingprotection implementation |
|
A |
R |
|
C |
|
|
I |
| Rate limiting (persistent) |
|
A |
R |
|
C |
|
|
|
| CSP headers implementation |
|
A |
R |
|
C |
|
|
|
| Session management |
|
A |
R |
|
C |
|
|
|
| Demo credential removal |
|
A |
R |
|
C |
|
|
|
| Compliance documentation (gap analysis) |
I |
C |
|
|
A |
CR |
|
I |
SecurityPenetration testing (pre-launch) |
I |
C |
I |
|
|
C |
|
|
A |
4.6 Testing & QA
| Activity / Deliverable |
CEO |
JD |
BUILD |
VAL |
SEC |
LEGAL |
FIN |
EXT |
| Test strategy |
I |
A |
C |
R |
C |
|
|
|
UATTest preparationplan |
|
|
RI |
A |
C |
R |
|
|
|
R |
|
I |
C |
UATUnit executiontests (Vitest — 40 tests) |
|
A |
IR |
C |
|
|
|
|
CIntegration tests (20+ tests) |
|
RA |
A |
UAT sign-off |
I |
C |
IR |
C |
|
|
|
|
CE2E tests (Playwright — 3 projects) |
|
A |
R |
Defect triage |
|
|
I |
C |
|
C |
R |
|
|
|
|
| Performance tests (benchmarks) |
|
A |
C |
R |
C |
|
|
|
| Security tests (input chaos) |
|
A |
C |
R |
A |
|
|
|
Regression testingtests |
|
A |
R |
C |
|
|
I |
|
| Definition of Done validation |
|
A |
C |
R |
|
A |
|
|
|
| Go/No-Go decision |
I |
A |
C |
|
R |
C |
|
|
|
4.7 Compliance & Regulatory
| Activity / Deliverable |
CEO |
JD |
BUILD |
VAL |
SEC |
LEGAL |
FIN |
EXT |
| PSD2 regulatory gap analysis |
C |
C |
|
|
R |
CA |
|
|
| GDPR compliance review |
C |
C |
|
|
C |
A |
|
|
| AML/KYC compliance setup |
C |
C |
|
|
C |
A |
|
R |
| Finanstilsynet PISP/AISP registration |
A |
C |
|
|
|
C |
|
R |
| Legal terms + privacy policy |
C |
C |
|
|
|
A |
|
|
| BaaS partner contract negotiation |
A |
C |
|
|
|
C |
|
R |
4.68 Deployment & Launch
| Activity / Deliverable |
CEO |
JD |
PMBUILD |
POVAL |
BASEC |
TLLEGAL |
DEVFIN |
DES |
QA |
OPS |
CS |
CPOEXT |
| Deployment checklist |
|
C |
I |
|
A |
C |
C |
|
C |
A |
|
|
| Staging deployment | |
(Fly.io) |
I |
IA |
R |
C |
R |
|
R |
A |
|
|
| Production deployment |
|
C |
I |
I |
|
CA |
R |
|
R |
A |
|
|
DNS / SSL setup |
|
|
|
|
|
C |
|
|
|
A |
|
|
Monitoring /+ alerting setup |
|
|
I |
|
|
C |
|
|
|
A |
|
|
Go-live communication |
I |
I |
A |
R |
|
|
|
|
|
|
I |
R |
LaunchApp announcement | Store Isubmission (iOS) |
I |
A |
R |
|
|
|
|
|
| Google Play submission (Android) |
I |
A |
R |
|
|
|
|
|
| Go-live communication |
A |
C |
|
|
C |
C |
|
|
| Merchant onboarding (200 targets) |
A |
I |
|
|
|
|
|
|
| Post-launch monitoring (48h) |
|
C |
I |
|
|
C |
A |
|
R |
A |
I |
|
|
4.79 Post-Launch & Maintenance
| Activity / Deliverable |
CEO |
JD |
PMBUILD |
POVAL |
BASEC |
TLLEGAL |
DEVFIN |
DES |
QA |
OPS |
CS |
CPOEXT |
| Post-launch review (30 days) |
I |
C |
A |
R |
R |
R |
R |
|
R |
R |
C |
R |
Lessons learned documentation |
I |
C |
A |
R |
R |
R |
R |
R |
R |
R |
I |
I |
Handover documentation |
I |
C |
A |
R |
R |
A |
R |
R |
|
R |
C |
I |
Bug fix triage |
|
|
I |
A |
|
C |
R |
|
R |
|
I |
C |
Performance optimization |
|
|
I |
C |
|
A |
R |
|
C |
C |
|
|
ClientBug trainingfix triage + resolution |
I |
|
C |
CA |
R |
C |
|
|
|
|
| Performance optimisation |
I |
A |
R |
C |
|
|
|
|
| Lessons learned documentation |
I |
A |
R |
R |
C |
C |
C |
|
| Incident response |
I |
A |
R |
|
C |
|
|
|
| Monthly financial reporting |
A |
C |
|
|
|
|
R |
|
| User feedback analysis |
C |
A |
R |
|
|
|
|
|
| Project closure sign-off |
A |
C |
R |
|
|
|
|
|
|
|
A |
|
5. Escalation Matrix
| Escalation Level |
Trigger |
Escalate To |
Response Time |
Resolution Time |
| L1 |
Task-level disagreementblocker |
Tech LeadJohn (technical) / PM (process)JD) |
4 hours |
1 business day |
| L2 |
Role/accountabilityArchitecture/scope dispute |
PMJohn + John(JD) |
4 hours |
1 business day |
| L3 |
Scope/priorityStrategic/financial conflictdecision |
JohnAlem + PO(CEO) |
224 hours |
Same day |
| L4 |
Contract/budget/strategicLegal/regulatory decision |
John + Alem |
4 hours |
2 business days |
L5 |
External/client disputeblocker |
Alem + ClientExternal SponsorAdvisor |
2448 hours |
3 business days |
6. Handling Common RACI Conflicts
Issue: Multiple people marked A on same activity
Action: Hold a 15-minute meeting; the most senior person or domain owner retains A; others become R or C.
Issue: No one marked R on an activity
Action: PM escalates to John immediately. A without R = activity will not get done.
Issue: Too many C's (>4) on a single activity
Action: Review each C — can they be demoted to I? Consult only those who provide unique value.
Issue: Key stakeholder says "I didn't know about X"
Action: Review their I assignments; add missing I designations; improve communication plan frequency.
Issue: Team member disputes their R assignment
Action: Discuss with PM; if skill gap, arrange training or reassign; document decision.
7. Review Cadence
Trigger |
Review Type |
Owner |
|---|
Project phase change |
Full matrix review |
PM |
New team member joins |
Role assignments update |
PM |
Team member leaves |
Responsibility reassignment |
PM |
Scope change approved |
Impact on roles |
PM + PO |
Monthly |
Sanity check; any gaps? |
PM |
Project retrospective |
Lessons for next RACI |
PM |
Approval
| Role |
Name |
Date |
Signature |
| Author |
John (AI Director) |
2026-02-23 |
| Approved
Reviewer |
|
|
|
Project Manager |
|
|
(AI) |
| AI Director (John) |
John |
2026-02-23 |
Approved |
| Project Sponsor / CEO |
Alem Bašić |
TBD |
|