We need good abstractions. However, sometimes there is little point in providing abstractions that have no special utility. So, it is a trade off to make. If you need to err, though, do it on the side of creating the domain-specific type for a simple datum like int or string.
I consider it generally ok to include primitive date types within another abstraction (like your Account), as such fields in such a container provide the context/meaning for these types. BirthDate or AccountStartDate are examples, that I feel are sufficient as simple dates; their meaning is in context of the containing type. Wrapping these in extra types here doesn't necessarily offer value, and can make the values harder to use.
However number types and string types are so common (and low-level) that they can be very error prone in usage, so merit additional attention, e.g. being wrapped in domain-meaningful types. It is not ok is to find these primitive types/attributes on their own far outside of some containing abstraction. So, if you see a primitive field's value being shared broadly in code, detached from a containing object, then that is a smell that they should have their own types.
In the other direction, as with birth date, it can be be overkill to give each specific field a specific type. For another example, there's a notion of phone number for an emergency contact. Dialing this number is the same as dialing any other number, so we don't want or need special classes for dialing an emergency phone number, and we simply know that it is the emergency contact from the containing abstraction by the field rather than by type.