diff --git a/README.md b/README.md
index 5bead7b4..bb266201 100644
--- a/README.md
+++ b/README.md
@@ -34,6 +34,35 @@ Cloning and editing in local is faster due to virtual workspace in online VS Cod
Go through this [detailed guide](./content/README.md) on how to write content
+## Asset Management
+
+### Strapi Assets Bucket
+
+All images and assets for the documentation are stored in the `strapi-assets` bucket. When uploading images or assets:
+
+1. **Bucket Name**: `strapi-assets`
+2. **Folder Structure**: Follow the same folder structure as the content layer in `/content`
+3. **URL Format**: `https://storage.googleapis.com/strapi-assets/latest/{path-to-asset}`
+
+### Example Asset Upload
+
+If you have an image for the Account Aggregator consent object flow diagram:
+
+- **Content path**: `/content/data/account-aggregator/consent-object.mdx`
+- **Asset path**: `/data/account-aggregator/consent-object-flow.png`
+- **Final URL**: `https://storage.googleapis.com/strapi-assets/latest/data/account-aggregator/consent-object-flow.png`
+
+### Using Assets in Content
+
+Reference assets in your MDX files using the `MainImage` component:
+
+```mdx
+
+```
+
### Install VS code extensions
For easy syntax higlighting, `VSCode MDX`
diff --git a/api-references/data/account-aggregator.json b/api-references/data/account-aggregator.json
index b10f2abe..26905300 100644
--- a/api-references/data/account-aggregator.json
+++ b/api-references/data/account-aggregator.json
@@ -3500,6 +3500,7 @@
"type": "string",
"enum": [
"PENDING",
+ "INITIATED",
"FAILED",
"ACTIVE",
"PAUSED",
@@ -3507,7 +3508,7 @@
"EXPIRED",
"REJECTED"
],
- "description": "Surrogate status for this consent"
+ "description": "Surrogate status for this consent. INITIATED status is returned only for bank selection flow when user needs to select FIP before consent creation."
},
"detail": {
"description": "The identifier of the Customer.",
diff --git a/content/data/account-aggregator/consent-object.mdx b/content/data/account-aggregator/consent-object.mdx
index 6808e7b8..81cfaf92 100644
--- a/content/data/account-aggregator/consent-object.mdx
+++ b/content/data/account-aggregator/consent-object.mdx
@@ -11,6 +11,11 @@ The consent object is the core of the AA framework. When an FIU requires data ab
Consent object contains the information about all the different types of data the FIU needs, the purpose of the data, and how the FIU plans to use the data and so on.
+
+## FIP Selector Screen
+
+**→ Scroll down to see the detailed FIP Selector Screen section**
+
As specified in the table below, some parameters have to be passed mandatorily
when creating a consent.
@@ -221,4 +226,142 @@ The `context` parameter accepts key-value pairs to customize the consent flow. B
+
+
+## FIP Selector Screen
+
+
+ This feature is coming soon and will be available in future releases.
+
+
+### Overview
+
+The FIP Selector Screen is a feature that helps improve AA journey success rates by intelligently routing users to the best performing Account Aggregator (AA) - FIP pair.
+
+It enables FIUs to:
+
+- Select the best-performing AA for a given FIP (instead of just the highest overall-performing AA).
+- Provide explicit user consent for using PII (mobile number) to discover pre-existing handles on AAs.
+- Reduce drop-offs on the account linking page by routing users to an AA where they already have a handle.
+- Move away from latency-prone autodiscovery flows by adopting a faster, targeted manual discovery approach.
+
+All of this enables better consent conversion across the funnel
+
+### How it works
+
+1. User lands on the FIP Selector Screen before the AA journey
+2. FIU (or Setu module) shows available FIPs and takes explicit user consent to use PII data via a checkbox.
+3. Setu uses this consent to:
+ - Discover pre-existing AA handles (using mobile number).
+ - Route requests to the best-performing AA for that specific FIP.
+4. The improved routing logic kicks in, reducing drop-offs and boosting success rates.
+
+### Flow diagram
+
+
+
+The FIP Selector Screen flow works as follows:
+
+1. **User selects FIP** → User chooses their preferred Financial Information Provider
+2. **Consent checkbox for discovery** → User provides explicit consent for PII usage
+3. **Setu checks AA handles using mobile number** → System discovers pre-existing handles
+4. **Best performing AA for FIP** → Intelligent routing based on performance data
+5. **Consent creation via AA** → Consent is created through the optimal AA
+6. **Account linking + Data fetch** → Final step of account connection and data retrieval
+
+### How FIUs can enable this
+
+#### ✅ Case 1: FIUs with an existing FIP Selector Screen
+
+1. Add the consent checkbox to your FIP Selector Screen.
+2. Share a screenshot of the updated screen with Setu.
+3. For Finvu, also complete the AA Profile Discovery API Access Request form.
+4. For OneMoney and Anumati, Setu will share your screenshot with the AA for approval.
+5. Once confirmed, this data will be used in the AA routing logic.
+
+#### ✅ Case 2: FIUs without an FIP Selector Screen
+
+1. Setu will provide an opt-in module for the FIP Selector Screen.
+2. No need to share screenshots - Setu will handle UI, routing, and compliance requirements end-to-end.
+3. Setu will also assist with form submissions for AA sign-offs
+
+### Tech implementation
+
+#### Case 1: FIUs NOT passing Account Aggregator the context filter (Multi AA)
+
+**Create Consent API Changes**
+
+Request Payload:
+```json
+{
+ "vua": "9999999999" // Only mobile number (no AA suffix)
+}
+```
+
+Response Payload:
+```json
+{
+ "vua": "9999999999", // Only mobile number
+ "status": "INITIATED", // Initial status (PENDING status sent via notification once actual consent is created with AA)
+ // ...other fields remain unchanged
+}
+```
+
+**Key Changes:**
+- Initial status is `INITIATED` instead of `PENDING`
+- VUA contains only mobile number without AA suffix
+- Actual `PENDING` status communicated via notification after consent creation
+
+**Notification Handler Updates**
+
+Once the user completes the bank selection, we'll create consent on the most optimal Account Aggregator (AA) for the selected Financial Information Provider (FIP) and then send the PENDING status.
+
+Success Notification Payload:
+```json
+{
+ "data": {
+ "status": "PENDING", // New additional status
+ "vua": "9999999999@selectedAA" // Updated with selected AA
+ },
+ "success": true,
+ "type": "CONSENT_STATUS_UPDATE",
+ "error": null,
+ "consentId": "<>",
+ "notificationId": "<>",
+ "timestamp": "2024-01-29T07:28:24.547Z"
+}
+```
+
+Failure Notification Payload:
+```json
+{
+ "success": false,
+ "error": {
+ "code": "ConsentObjectCreationFailure",
+ "message": "Internal server error occurred while fetching consent details from upstream AA"
+ },
+ "data": null,
+ "consentId": "<>",
+ "notificationId": "<>",
+ "timestamp": "2024-01-29T07:28:24.547Z",
+ "type": "CONSENT_STATUS_UPDATE"
+}
+```
+
+**Required Implementation:**
+- Add `CONSENT_STATUS_UPDATE` notification handler
+- Update status management logic
+- Handle VUA format changes
+
+#### Case 2: FIUs passing specific AA in the context filter
+
+✅ **No changes required from FIUs for Case 2**
+
+This case works immediately with existing implementations as it's purely an optimization that doesn't affect consent status transitions.
+
+
+