MVP Discussions

[billhimmelsbach]

A place to consolidate MVP discussions related to the shared filing platform and SBL app.

Shared filing platform

Epic: Getting started shared landing page (unauthenticated) #7

User stories:

• [Story] Go to a website and log in to existing account #3
• [Story] Get help with setting up account #4
• [Story] Understand the CFPB's legal right to request information #29

Remaining design work:

• Visual approach to presenting various notices and statements
• Update mock-up to reflect MVP requirements

Discussion notes:

• There was some discussion about if this page should be a wagtail page since the header, footer, etc. were straight from cf.gov and would require regular maintenance to keep updated in the react app
• Instead of making it a wagtail page, we decided to strip down the header and footer to only the essentials parts that we will commit to maintain

Email sign up is not required for MVP

Epic: Complete your user profile (first time user) #12

User stories:

• [Story] Complete user profile (first name + last name) upon first login #17
• [Story] Prevent the completion of user profile with personal email address #18
• [Story] Associate with pre-approved institution(s) via email domain #19
• [Story] Next steps to take when financial institution does not yet have an LEI #23
• [Story] Actionable feedback when incomplete user profile form is submitted #27

Remove user story from MVP requirements:

• [Story] Self-associate from full financial institution database and submit for review #22

Remaining design work

• Update mock-up to reflect MVP requirements

Discussion notes:

• Remove the ability for a user to self select their LEI using the multiselect and instead handle this with an in-page link that sends them to the existing SBL help form (Salesforce).
• Users will not be able search and select their LEI and submit their selection to SBL help. Instead users will be directed to a Salesforce form where they will manually request to be associated with a specific LEI.
• After digging through the HMDA data, only 3 users needed to be associated with multiple institutions / LEIs
• First name and last name do NOT come from login.gov, will need to be stored
• Users who have no associated LEI should be directed to a SBL Help registration form via Salesforce (need a mockup for this)
  • Do these users even need to see the First Name / Last Name "Provide your identifying information" section if that data is provided via the form and will not be submitted on this page since they have no associated financial institution?
  • For this use case, could the "Submit" button be replaced with an "Open form" button? The "Clear form" would then be removed
• Users should also be directed to use the SBL Help registration form if they want to associate themselves with a financial institution that they are authorized to file for but it is not currently listed from the checklist

User profile submission status

• If we require users to go through SBL Help to add new associations between email domain and financial institution, then we no longer need this page
• After registration is complete, users would skip straight to the SBL landing page

CFPB Filing home shared landing page #8

User stories (these user stories have not been turned into issues yet):

• As a filer who submits both SBL and other data to CFPB (e.g. HMDA or NBR), I would like my financial institution details to be centrally managed, so that I don’t have to maintain the same information in multiple places.
• As a filer who submits both SBL and other data to CFPB (e.g. HMDA or NBR), I want to be able to have a single user profile that is shared among the CFPB platforms, so that I don’t have to maintain the same information in multiple places.

Discussion notes:

• A choice between three options for this page:
  • include some link to HMDA?
  • only include SBL related information?
  • remove this page entirely and go straight to filing?
• need to chat with @mmshelton about this one maybe? Confirm with her that we don't need any link to HMDA for MVP

Epic: Request changes to your user profile (#10)

#10

User stories (these user stories have not been turned into issues yet):

• As a filer, I want to view the information contained in my user profile, so that I can make sure that it's accurate.
• As a filer, I want to be able to associate with additional financial institutions, so that I can file on behalf of all financial institutions that I am responsible for.
• As a filer, I want to view the list of financial institutions I’m associated with, so I know which financial institutions I need to file for.
• As a filer, I would like to be able to select a financial institution from the list of financial institutions I'm associated with, so that I can view the individual financial institution details.
• As a filer, I want to update/change my email address, so that I can keep my FI email address current.

Discussion notes:

• Users should be directed to contact SBL Help to change this information (read-only)
• Should this be a separate form or just an email?
• Name changes were very rare in HMDA

Epic: View financial institution details (read-only)

#11

User stories:

• [Story] View financial institution details #37

  As a filer, I would like to view my financial institution data as the CFPB understands it, so that I can make sure that my filing details will be accurate.

• [Story] Instructions on how to update data on financial institution details  #38

  As a filer, I would like clear instructions on how to change read-only financial institution fields, so that I can correct any errors prior to filing.

• [Story] View institution data change history #39

  As a filer, I would like to view the history of changes to my institution data

  • Who: person or automation w/ data source
  • What: Which fields changed from what to what
  • When: Timestamp
  • Why: automation or human note

• As a filer, I would like to know where the CFPB obtained the data about my financial institution.
• As a filer, I would like to review my Parent and Top Holder information to ensure it is accurate.

SBL filing app

Epic: Confirm financial institution details (for a given filing period) #12

User stories (these have not been turned into issues yet)

• As a filer, I can confirm my institution data is accurate for given filing period.
• As a filer, I want clear instructions on what to do to if my institution data is inaccurate.

Discussion notes:

• "Financial institutional details" section will be read-only for MVP
• "Identifying information" section will be read-only except institution type
• The "Affiliate Information" section has several questions around it regarding what data should be read-only and when
  • For now, if the data comes in from GLIEF/NIC, that data should be read-only
  • Will be following up with @Kibrael about making a flow chart to visualize this
• Contact information should always be user-editable
  • This contact information section could appear at the signing step or somewhere else in the filing flow instead of on this page
  • • "Financial institution details" section should be read-only, changes via SBL Help
• "Identifying information" section should be read-only except "Type of financial institution"
  • Do we want users to be able to pick this value themselves @Kibrael and @nongarak?
  • @Kibrael and @chynnakeys mentioned that users often picked the wrong value for a similar field in HMDA, so maybe verification through SBL Help is preferable at first?
• "Affilate information"
  • allows user inputted responses as long as there is no available data in the database already for these fields
  • if there is data for any of the affiliate information, then the associated fields are read-only on the front end
  • @Kibrael might be working on a flow chart to visualize how this affiliate data might be reconciled before being entered into the database for his own team
• "Provide a financial institution point of contact" this section might be moved to somewhere else in the filing flow depending on @natalia-fitzgerald / @dan-padgett input

Data retention

• the goal was for the beta's DB to be able to be wiped clean at any point for testing purposes.
• However if a user goes through the laborious process of setting up a new financial institution with us via the Salesforce form, it would be preferable for that data to be retained
• The option of only keeping associations between the email domains and their institutions was discussed
• This is still an open question with details that need to be hammered out

Save and continue

• when a user clicks "Save and continue" that data will be sent to the backend to allow users to resume the filing process where they left off
  

Filing flow

• everyone agreed that the SBL filing process past the "Confirm institution details page" would be very similar to HMDA
• the last page of the filing flow will include a summary of the data they are submitting and a checkbox to click for signature verification

Backend MVP

• there were some discussions before the meeting about potential backend MVP changes that could be made with @lchen-2101 and @billhimmelsbach

For the backend part, I wouldn't call it single threaded processing; rather synchronous processing, vs asynchronous processing. 3 approaches in my head:

• (not MVP) filing API pushes uploaded file to S3 -> S3 publishes event to some form of queue / messaging bus -> validation service process message (the file) from queue -> persist validation results to DB -> filing API responds with the results.
• (completely synchronous MVP) filing API pushes uploaded file to S3, processes the file on the spot, persists results to DB, and responds with the results.
• (asynchronous MVP) filing API pushes file to S3 -> filing API reaches out to validation API to process the file -> validation API validates the file, persist results, and responds to filing API -> filing API responds to user with results.
  For clarifications, when I say API, I mean a microservice that has REST API endpoints, when I say service, I mean the microservice has no REST API endpoints (i.e. nothing can reach the microservice directly)

Broader discussions

SBL help forms

• How many Salesforce forms do we need?
  • Brainstorming possible solutions
    • 1 for the project
    • 1 for registration and 1 for user details
    • 1 per page
    • 1 per section / well
    • Some combination of the above?
  • Note: people on HMDA said that there's a long turnaround time when working with the Salesforce team, which might impact our choices
• We should emphasize in the copy of these forms and call to actions that lead to forms:
  • We direct users to SBL Help to verify their details for security and to help them comply with regulations

Further action items

• Get people to read this thing 😅 If you read this whole thing, add a 👍 to this description.

[nongarak]

@billhimmelsbach yes, the FI needs to pick this value themselves. They can pick as many of the values as they like. The rule text:

Paragraph 109(b)(9).

1. Type of financial institution. A financial institution complies with § 1002.109(b)(9) by selecting the applicable type or types of financial institution from the list below. A financial institution shall select all applicable types.
   i. Bank or savings association.
   ii. Minority depository institution.
   iii. Credit union.
   iv. Nondepository institution.
   v. Community development financial institution (CDFI).
   vi. Other nonprofit financial institution.
   vii. Farm Credit System institution.
   viii. Government lender.
   ix. Commercial finance company.
   x. Equipment finance company.
   xi. Industrial loan company.
   xii. Online lender.
   xiii. Other

2. Use of “other” for type of financial institution. A financial institution reports type of financial institution as “other” where none of the enumerated types of financial institution appropriately describe the applicable type of financial institution, and the institution reports the type of financial institution via free-form text field. A financial institution that selects at least one type from the list is permitted, but not required, to also report “other” (with appropriate free-form text) if there is an additional aspect of its business that is not one of the enumerated types set out in comment 109(b)(9)-1. 3. Additional types of financial institution. The Bureau may add additional types of financial institutions via the Filing Instructions Guide and related materials. Refer to the Filing Instructions Guide for any updates for each reporting year.

[billhimmelsbach]

Thanks @nongarak! We'll need a big change in the UI here, including an "other" field @natalia-fitzgerald

Use of “other” for type of financial institution. A financial institution reports type of financial institution as “other” where none of the enumerated types of financial institution appropriately describe the applicable type of financial institution, and the institution reports the type of financial institution via free-form text field.

So a user needs to be able to select multiple types of institutions and/or be able to select "other" and add free-form text?

[nongarak]

That's correct.

[lchen-2101]

For the backend part, I wouldn't call it single threaded processing; rather synchronous processing, vs asynchronous processing. 3 approaches in my head:

• (not MVP) filing API pushes uploaded file to S3 -> S3 publishes event to some form of queue / messaging bus -> validation service process message (the file) from queue -> persist validation results to DB -> filing API responds with the results.
• (completely synchronous MVP) filing API pushes uploaded file to S3, processes the file on the spot, persists results to DB, and responds with the results.
• (asynchronous MVP) filing API pushes file to S3 -> filing API reaches out to validation API to process the file -> validation API validates the file, persist results, and responds to filing API -> filing API responds to user with results.
  For clarifications, when I say API, I mean a microservice that has REST API endpoints, when I say service, I mean the microservice has no REST API endpoints (i.e. nothing can reach the microservice directly)

[billhimmelsbach]

I wouldn't call it single threaded processing;

Sorry about that @lchen-2101 , you and I even had a whole discussion about how that, but it landed in my notes somehow and I forgot to change it. I've edited it. 👍

[natalia-fitzgerald]

@billhimmelsbach @chynnakeys @angelcardoz @hkeeler
I reorganized this post by pages and by Shared filing platform and SBL app. I also added the lists of user stories for each epic. Since the user stories organize the work, we should be reviewing them as a part of this process and confirming that they are all still relevant. We should remove user stories that will no longer prioritize for MVP. Once we nail things down at least for the shared filing platform pages we should also go back to the epic and story issues and make sure we update them and close any stories or tasks that are no longer part of MVP.

For certain pages (noted above) we still do not have issues created for each user story. Who is responsible to creating these Story issues? The devs are starting to pick up work on some of these pages so it would be best to have story issues that the devs can then write tasks for.

Should the MVP requirements for each epic be a list of user stories? Technical requirements? @hkeeler?

[dan-padgett]

For the question of SBL Help Forms, we might want to think about different approaches. It seems like the goal behind multiple forms is to make sure that SBL Help doesn't get inundated with unnecessary information, and that we don't waste a filer's time asking them to provide info that may not be needed. The concern with multiple forms is that you're assuming the filer knows which form they need to use, and that they'll take the time to find the correct form.

This isn't a showstopper for the solution, but it is something we should try to test before moving forward with it.

[natalia-fitzgerald]

Another concern with multiple forms is that these forms are built and managed in Salesforce (separate team). So, if we need to make adjustments or changes (or even build the inital form to spec) the process is quite cumbersome (and lengthy). So we should consider this aspect as well - in terms of the maintenance burden. If we don't make multiple forms is there an option where we make the single form more useful? Just a thought.

I support the idea of testing our assumptions and starting with something more focused.