[Epic] Provide filing details

[angelcardoz]

Milestone:

Epic: Provide filing details

Overview

• In this step a filer is asked to provide information that is specific to the current filing
  • Voluntary reporter status
  • Filing point of contact information
• The information provided on this page meets the following criteria:
  • Is always user supplied
  • Is requested for every filing
  • Does not live in the financial institution profile

Small business lending rule

Voluntary reporter status

Regulation B requires financial institutions to report whether they are voluntarily reporting covered applications from small businesses. According to the official interpretation of Paragraph 109(b)(10), a financial institution that is not a covered financial institution but that elects to voluntary compile, maintain, and report data complies with § 1002.109(b)(10) by selecting “voluntary reporter.”

Point of contact information

Regulations B requires financial institutions to report the name and business contact information of a person who may be contacted with questions about the financial institution’s submission: § 1002.109(b)(1)(iii) https://www.consumerfinance.gov/rules-policy/regulations/1002/109/#a-3

"The name and business contact information of a person that the Bureau or other regulators may contact about the financial institution’s submission."

Tasks

Use the following checklist to ensure each epic is built out properly. If needed, you can add or remove items.

• Pull together initial list of relevant user stories for this epic
• Make a list of the content requirements for this epic
• Make a list of the technical requirements for this epic
• Post current wireframes and mock-ups
• Review wireframes and mock-ups with FEWD, BEWD, Data, SBL Help, Content team members
• Refine user stories to prepare for development phase
• Identify and capture tasks for user testing
• Conduct user testing

User stories

MVP (release date: 12/31/2024)

• [Story] Understand the purpose of the provide filing details step #275
• [Story] Indicate voluntary reporter status #243
• [Story] Provide phone extension for business point of contact #265

Backlog:

• [Story] Auto-format phone numbers #270
• Under point of contact, we need a story for privacy data for production. The language we have now is for beta.

Beta release (8/1/2024)

• [Story] Provide business point of contact information for filing #147
• [Story] Save point of contact information #149

Backlog (post-MVP)

• Story (link)

User testing

Research goals

• Determine what information filers need to provide a POC for the filing.
• Determine what additional information we can provide to help filers provide a POC.
• Learn how often filers expect the POC to change.
• Understand how easily filers can determine whether their institution is a voluntary reporter.

Task ideation

• Complete the POC fields.
• Make the appropriate selection for the voluntary reporter section

Curent mock-ups

Updated:

[natalia-fitzgerald]

@nongarak @Kibrael
I would like to clarify a few things as we move forward with this epic.

From what I've seen, SBL is pretty vague about what specific fields we should collect for point of contact. HMDA is more specific. HMDA includes a detailed list with guidelines in the filing instructions guide. Do we plan to add this level of detail to the small business lending filing instructions guide? Should we request the business contact phone number?

Here's the latest mock-up (updated to include HMDA fields): Epic: Point of contact (current mock-up)

[nongarak]

I just confirmed with Tim Lambert of OFLEO, and pending any revisions from someone else in the office who is on vacation, the fields that we should capture are the same as HMDA. Name, email, phone, and business address.

[nongarak]

I don't know what validations are in place for HMDA on phone number, but if it's possible to standardize phone number input in the field that would be a good thing probably. Like, 10 digits only, or requiring +1, or +1 (xxx) xxx-xxxx, or whatever other standard we want. I don't care, but probably locking it down is good. Especially so folks don't put in "nunya" or something.

[natalia-fitzgerald]

@nongarak
Here's what I pulled from HMDA (filing instructions guide):

"Enter the name, telephone number, e-mail address, and office address of a person who may be contacted with questions about your institution's submission."

Enter the contact person's:

1. Name
2. Telephone Number
3. E-mail Address
4. Address
   a. Street Address 
   b. City
   c. State
   d. ZIP Code

Formatting specifications

1. Full Name as (1) data field
2. Telephone Number (Format: 999-999-9999)
3. E-mail Address
4. Address
   a. Street Address as (1) data field 
   b. City as (1) data field
   c. State (two-letter state code as (1) data field 
   (aa) State means any state, the District of Columbia, the Commonwealth of Puerto Rico, or any territory or possession of the United States.
   d. ZIP Code as (1) data field 

@billhimmelsbach - What other field formatting can we do for these types of fields? We can provide formatting examples in the fields but I'd like to identify what's possible for the front end to do as well. If we want the full name to ultimately be one data field do we have to only show one text input field "Full name" or can we show "First name" and "Last name" and have these be merged as one data field on our end? Preference?

@nongarak

• HMDA says that phone number should be formatted as follows: 999-999-9999. Is this what we want to use for SBL?
• What US territories should be included, in addition to the states?

HMDA:

https://ffiec.cfpb.gov/documentation/fig/2023/overview#1-5-to-1-11-paragraph-5a3iiicontact-person

Enter the name, telephone number, e-mail address, and office address of a person who may be contacted with questions about your institution's submission.

[hkeeler]

As for the State field, I'm guessing we'd want to go with the same values we allow for institution records. On cfpb/regtech-user-fi-management#48 (comment) we said...

Values here should be pretty self-explanatory. All 50 states and D.C. and territories...

code	name
AS	American Samoa
DC	District of Columbia
GU	Guam
MP	Northern Mariana Islands
PR	Puerto Rico
UM	United States Minor Outlying Islands
VI	Virgin Islands, U.S.

...assuming we're going with ISO-3166.

Pretty sure we decided to go with that.

[natalia-fitzgerald]

Items to explore/track down

(Notes from DSR/SBL frontend meeting on 3/7/2024)

• Should we include an urbanization field to account for Puerto Rico? USWDS includes this as a separate field with "Urbanization" label. USPS docs on it: https://pe.usps.com/text/pub28/28c2_042.htm
• Should the state picker show a default? If so what should it be?
  • I will audit cf.gov and review best practices and CFPB Design System standards.
• Should we change the state picker label to "State or territory"?
  • Is there any reason we wouldn't want to do this? If not, I added it to the mock-up.
• Which fields would benefit from formatting examples?
  • I will explore this
• Add real content for introduction text
  • I will work with @angelcardoz on this
• Zip codes: Do we want to support a 5 digit zip code or Zip+4 (9 digit zip code)
  20002 vs 20002-3457 On the frontend we could support either or both, but what do we want to tell the user?

Notes:

• List of states and territories should get pulled from the backend
• We're sticking with the phone number format XXX-XXX-XXXX for now
• We're going to only have 2 address lines for now, and see if users want more

USWDS recommendations: https://designsystem.digital.gov/patterns/create-a-user-profile/address/

• Provide rich information cues in dropdowns. For example, for state dropdowns, use MD - Maryland and TX - Texas, rather than the state code alone
• Do provide the Puerto Rican Urbanization field, unless your program does not serve Puerto Rico.
• Avoid dropdowns that require long scrolling. If possible, let users type their state or territories’ abbreviation when they reach the state dropdown menu, instead of having to scroll and select. (USWDS uses the Combo box component: https://designsystem.digital.gov/components/combo-box/)
  • We will use the standard Select for MVP. We can consider the Combo box for post-MVP

@billhimmelsbach @hkeeler - Please edit as needed for accuracy or additional context.